Network Working Group T. Hardjono Request for Comments: 3740 Verisign Category: Informational B. Weis Cisco March 2004 The Multicast Group Security Architecture
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document provides an overview and rationale of the multicast
security architecture used to secure data packets of large multicast groups. The document begins by introducing a Multicast Security
Reference Framework, and proceeds to identify the security services
that may be part of a secure multicast solution.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Scope. . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.
2. Summary of Contents of Document. . . . . . . . . . . . . 3 1.
3. Audience . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Terminology. . . . . . . . . . . . . . . . . . . . . . . 4
2. Architectural Design: The Multicast Security Reference
Framework. . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. The Reference Framework. . . . . . . . . . . . . . . . . 4 2.2. Elements of the Centralized Reference Framework. . . . . 5 2.2.1. Group Controller and Key Server. . . . . . . . . 6 2.2.2. Sender and Receiver. . . . . . . . . . . . . . . 7 2.2.3. Policy Server. . . . . . . . . . . . . . . . . . 7
2.3. Elements of the Distributed Reference Framework. . . . . 8
3. Functional Areas . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Multicast Data Handling. . . . . . . . . . . . . . . . . 9 3.2. Group Key Management . . . . . . . . . . . . . . . . . . 10
3.3. Multicast Security Policies. . . . . . . . . . . . . . . 11
4. Group Security Associations (GSA). . . . . . . . . . . . . . . 12 4.1. The Security Association . . . . . . . . . . . . . . . . 12 Hardjono & Weis Informational [Page 1]
4.2. Structure of a GSA: Introduction . . . . . . . . . . . . 13 4.3. Structure of a GSA: Reasoning. . . . . . . . . . . . . . 14 4.4. Definition of GSA. . . . . . . . . . . . . . . . . . . . 15
4.5. Typical Compositions of a GSA. . . . . . . . . . . . . . 17
5. Security Services. . . . . . . . . . . . . . . . . . . . . . . 17 5.1. Multicast Data Confidentiality . . . . . . . . . . . . . 18 5.2. Multicast Source Authentication and Data Integrity . . . 18 5.3. Multicast Group Authentication . . . . . . . . . . . . . 19 5.4. Multicast Group Membership Management. . . . . . . . . . 19 5.5. Multicast Key Management . . . . . . . . . . . . . . . . 20
5.6. Multicast Policy Management. . . . . . . . . . . . . . . 21
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 22 6.1. Multicast Data Handling. . . . . . . . . . . . . . . . . 22 6.2. Group Key Management . . . . . . . . . . . . . . . . . . 22
6.3. Multicast Security Policies. . . . . . . . . . . . . . . 22
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 8.1. Normative References . . . . . . . . . . . . . . . . . . 23
8.2. Informative References . . . . . . . . . . . . . . . . . 23
9. Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . 25
10. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 26 1. Introduction
Securing IP multicast group communication is a complex task that
involves many aspects. Consequently, a secure IP multicast protocol suite must have a number of functional areas that address different
aspects of the solution. This document describes those functional
areas and how they are related.
1.1. Scope
This architecture is concerned with the securing of large multicast
groups. Whereas it can also be used for smaller groups, it is not
necessarily the most efficient means. Other architectures (e.g., the Cliques architecture [STW]) can be more efficient for small ad-hoc
group communication.
This architecture is "end to end", and does not require multicast
routing protocols (e.g., PIM [RFC2362]) to participate in this
architecture. Inappropriate routing may cause denial of service to
application layer groups conforming to this architecture. However
the routing cannot affect the authenticity or secrecy of group data
or management packets. The multicast routing protocols could
themselves use this architecture to protect their own multicast and
group packets. However, this would be independent of any secure
application layer group.
Hardjono & Weis Informational [Page 2]
This architecture does not require IP multicast admission control
protocols (e.g., IGMP [RFC3376], MLD [RFC3019]) to be a part of
secure multicast groups. As such, a "join" or "leave" operation for a secure group is independent of a "join" or "leave" of an IP
multicast group. For example, the process of joining a secure group requires being authenticated and authorized by a security device,
while the process of joining an IP multicast group entails contacting a multicast-aware router. Admission control protocols could
themselves use this architecture to protect their own multicast
packets. However, this would be independent of any secure
application layer group.
This architecture does not explicitly describe how secure multicast
groups deal with Network Address Translation (NAT) [RFC2663].
Multicast routing protocols generally require the source and
destination addresses and ports of an IP multicast packet to remain
unchanged. This allows consistent multicast distribution trees to be created throughout the network. If NAT is used in a network, then
the connectivity of senders and receivers may be adversely affected. This situation is neither improved or degraded as a result of
deploying this architecture.
This architecture does not require the use of reliable mechanisms,
for either data or management protocols. The use of reliable
multicast routing techniques (e.g., FEC [RFC3453]) enhance the
availability of secure multicast groups. However the authenticity or secrecy of group data or management packets is not affected by the
omission of that capability from a deployment.
1.2. Summary of Contents of Document
This document provides an architectural overview that outlines the
security services required to secure large multicast groups. It
provides a Reference Framework for organizing the various elements
within the architecture, and explains the elements of the Reference
Framework.
The Reference Framework organizes the elements of the architecture
along three Functional Areas pertaining to security. These elements cover the treatment of data when it is to be sent to a group, the
management of keying material used to protect the data, and the
policies governing a group.
Another important item in this document is the definition and
explanation of Group Security Associations (GSA), which is the
multicast counterpart of the unicast Security Association (SA). The GSA is specific to multicast security, and is the foundation of the
work on group key management.
Hardjono & Weis Informational [Page 3]
1.3. Audience
This document is addressed to the technical community, implementers
of IP multicast security technology, and others interested in gaining a general background understanding of multicast security. This
document assumes that the reader is familiar with the Internet
Protocol, the IPsec suite of protocols (e.g., [RFC2401]), related
networking technology, and general security terms and concepts.
1.4. Terminology
The following key terms are used throughout this document.
1-to-N
A group which has one sender and many receivers.
Group Security Association (GSA)
A bundling of Security Associations (SAs) that together define how a group communicates securely. The GSA may include a registration protocol SA, a rekey protocol SA, and one or more data security
protocol SAs.
M-to-N
A group which has many senders and many receivers, where M and N
are not necessarily the same value.
Security Association (SA)
A set of policy and cryptographic keys that provide security
services to network traffic that matches that policy.
2. Architectural Design: The Multicast Security Reference Framework
This section considers the complex issues of multicast security in
the context of a Reference Framework. This Reference Framework is
used to classify functional areas, functional elements, and
interfaces. Two designs of the Reference Framework are shown: a
centralized design, and a distributed design that extends the
centralized design for very large groups.
2.1. The Reference Framework
The Reference Framework is based on three broad functional areas (as shown in Figure 1). The Reference Framework incorporates the main
entities and functions relating to multicast security, and depicts Hardjono & Weis Informational [Page 4]
the inter-relations among them. It also expresses multicast security from the perspective of multicast group types (1-to-N and M-to-N),
and classes of protocols (the exchanged messages) needed to secure
multicast packets.
The aim of the Reference Framework is to provide some general context around the functional areas, and the relationships between the
functional areas. Note that some issues span more than one
functional area. In fact, the framework encourages the precise
identification and formulation of issues that involve more than one
functional area or those which are difficult to express in terms of a single functional area. An example of such a case is the expression of policies concerning group keys, which involves both the functional areas of group key management and multicast policies.
When considering the Reference Framework diagrams, it is important to realize that the singular "boxes" in the framework do not necessarily imply a corresponding singular entity implementing a given function. Rather, a box in the framework should be interpreted loosely as
pertaining to a given function related to a functional area. Whether that function is in reality implemented as one or more physical
entities is dependent on the particular solution. As an example, the box labeled "Key Server" must be interpreted in broad terms as
referring to the functions of key management.
Similarly, the Reference Framework acknowledges that some
implementations may in fact merge a number of the "boxes" into a
single physical entity. This could be true even across functional
areas. For example, an entity in a group could act as both a Group
Controller and a Sender to a group.
The protocols to be standardized are depicted in the Reference
Framework diagrams by the arrows that connect the various boxes. See more details in Section 4, below.
2.2. Elements of the Centralized Reference Framework
The Reference Framework diagram of Figure 1 contains boxes and
arrows. The boxes are the functional entities and the arrows are the interfaces between them. Standard protocols are needed for the
interfaces, which support the multicast services between the
functional entities.
In some cases, a system implementing the multicast security
architecture may not need to implement protocols to account for every interface. Rather, those interfaces may be satisfied through the use of manual configuration, or even omitted if they are not necessary
for the application.
Hardjono & Weis Informational [Page 5]
There are three sets of functional entities. Each is discussed
below.
+--------------------------------------+
| |
| |
| FUNCTIONAL |
| AREAS |
| |
| +------+ |
| Multicast |Policy| |
| Security |Server| |
| Policies +------+ |
| ^ |
| | |
| | |
| v |
| +------+ |
| Group |Group | |
| Key |Ctrl/ |<---------+ |
| Management |Key | | |
| |Server| V |
| +------+ +--------+ |
| ^ | | |
| | |Receiver| |
| | | | |
| v +--------+ |
| +------+ ^ |
| | | | |
| Multicast |Sender|----------+ |
| Data | | |
| Handling | | |
| +------+ |
| |
+--------------------------------------+
Figure 1: Centralized Multicast Security Reference Framework
2.2.1. Group Controller and Key Server
The Group Controller and Key Server (GCKS) represent both the entity and functions relating to the issuance and management of
cryptographic keys used by a multicast group. The GCKS also conducts user-authentication and authorization checks on the candidate members of the multicast group.
Hardjono & Weis Informational [Page 6]
The Key Server (KS) and the Group Controller (GC) have somewhat
different functionality and may in principle be regarded as separate entities. Currently the framework regards the two entities as one
"box" in order to simplify the design, and in order not to mandate
standardization of the protocol between the KS and the GC. It is
stressed that the KS and GC need not be co-located. Furthermore,
future designs may choose to standardize the protocol between the GC and the KS, without altering other components.
2.2.2. Sender and Receiver
The Sender is an entity that sends data to the multicast group. In a 1-to-N multicast group only a single sender is authorized to transmit data to the group. In an M-to-N multicast group, two or more group
members are authorized to be senders. In some groups all members are authorized as senders.
Both Sender and Receiver must interact with the GCKS entity for the
purpose of key management. This includes user and/or device
authentication, user and/or device authorization, the obtaining of
keying material in accordance with some key management policies for
the group, obtaining new keys during key-updates, and obtaining other messages relating to the management of keying material and security
parameters.
Senders and Receivers may receive much of their policy from the GCKS entities. The event of joining a multicast group is typically
coupled with the Sender/Receiver obtaining keying material from a
GCKS entity. This does not preclude the direct interaction between
the Sender/Receiver and the Policy Server.
2.2.
3. Policy Server
The Policy Server represents both the entity and functions used to
create and manage security policies specific to a multicast group.
The Policy Server interacts with the GCKS entity in order to install and manage the security policies related to the membership of a given multicast group and those related to keying material for a multicast group.
The interactions between the Policy Server and other entities in the Reference Framework is dependent to a large extent on the security
circumstances being addressed by a given policy.
Hardjono & Weis Informational [Page 7]
2.3. Elements of the Distributed Reference Framework
The need for solutions to be scalable to large groups across wide
geographic regions of the Internet requires the elements of the
framework to also function as a distributed system. Figure 2 shows
how distributed designs supporting large group scalability fit into
the Reference Framework.
+-----------------------------------------------------------------+ | | | | | FUNCTIONAL | | AREAS | | +------+ +------+ | | Multicast |Policy|<-------------------------------->|Policy| | | Security |Server| |Server| | | Policies +------+ +------+ | | ^ ^ | | | | | | | | | | v v | | +------+ +------+ | | Group |Group |<-------------------------------> |Group | | | Key |Ctrl/ |<---------+ |Ctlr/ | | | Management |Key | | |Key | | | |Server| V |Server| | | +------+ +--------+ +------+ | | ^ | | ^ | | | |Receiver| | | | | | | | | | v +--------+ | | | +------+ ^ V | | | | | +--------+ | | Multicast |Sender|----------+ | | | | Data | |-------------------------------->|Receiver| | | Handling | | | | | | +------+ +--------+ | +-----------------------------------------------------------------+ Figure 2: Distributed Multicast Security Reference Framework
In a distributed design the GCKS entity interacts with other GCKS
entities to achieve scalability in the key management related
services. GCKS entities will require a means of authenticating their peer GCKS entities, a means of authorization, and a means of
interacting securely to pass keys and policy.
Hardjono & Weis Informational [Page 8]
Similarly, Policy Servers must interact with each other securely to
allow the communication and enforcement of policies across the
Internet.
Two Receiver boxes are displayed corresponding to the situation where both the Sender and Receiver employ the same GCKS entity (centralized architecture) and where the Sender and Receiver employ different GCKS entities (distributed architecture). In the distributed design, all Receivers must obtain identical keys and policy. Each member of a
multicast group may interact with a primary GCKS entity (e.g., the
"nearest" GCKS entity, measured in terms of a well-defined and
consistent metric). Similarly, a GCKS entity may interact with one
or more Policy Servers, also arranged in a distributed architecture.
3. Functional Areas
The Reference Framework identifies three functional areas. They are: - Multicast data handling. This area covers the security-related treatments of multicast data by the sender and the receiver.
This functional area is further discussed in Section 3.1.
- Group Key Management. This area is concerned with the secure
distribution and refreshment of keying material. This
functional area is further discussed in Section 3.2.
- Multicast Security Policies. This area covers aspects of
policy in the context of multicast security, taking into
consideration the fact that policies may be expressed in
different ways: that they may exist at different levels in a
given multicast security architecture, and that they may be
interpreted differently according to the context in which they are specified and implemented. This functional area is further discussed in Section 3.3.
3.1. Multicast Data Handling
In a secure multicast group, the data typically needs to be:
1. Encrypted using the group key, mainly for access control and
possibly also for confidentiality.
2. Authenticated, for verifying the source and integrity of the
data. Authentication takes two flavors:
a. Source authentication and data integrity. This
functionality guarantees that the data originated with the
claimed source and was not modified en route (either by a
group member or an external attacker).
Hardjono & Weis Informational [Page 9]
b. Group authentication. This type of authentication only
guarantees that the data was generated (or last modified) by some group member. It does not guarantee data integrity
unless all group members are trusted.
While multicast encryption and group authentication are fairly
standard and similar to encrypting and authenticating a point-to-
point communication, source authentication for multicast is
considerably more involved. Consequently, off-the-shelf solutions
(e.g., taken from IPsec [RFC2406]) may be sufficient for encryption
and group authentication. For source authentication, however,
special-purpose transformations are necessary. See [CCPRRS] for
further elaboration on the concerns regarding the data transforms.
Multicast data encrypted and/or authenticated by a sender should be
handled the same way by both centralized and distributed receivers,
(as shown in Figure 2).
The "Multicast Encapsulating Security Payload" [BCCR] provides the
definition for Multicast ESP for data traffic. The "Multicast Source Authentication Transform Specification" [PCW] defines the use of the TESLA algorithm for source authentication in multicast.
3.2. Group Key Management
The term "keying material" refers to the cryptographic keys belonging to a group, the state associated with the keys, and the other
security parameters related to the keys. Hence, the management of
the cryptographic keys belonging to a group necessarily requires the management of their associated state and parameters. A number of
solutions for specific issues must be addressed. These may include
the following:
- Methods for member identification and authentication.
- Methods to verify the membership to groups.
- Methods to establish a secure channel between a GCKS entity and
the member, for the purpose of delivery of shorter-term keying
material pertaining to a group.
- Methods to establish a long-term secure channel between one GCKS
entity and another, for the purpose of distributing shorter-term
keying material pertaining to a group.
- Methods to effect the changing of keys and keying material.
- Methods to detect and signal failures and perceived compromises to keys and keying material.
The requirements related to the management of keying material must be seen in the context of the policies that prevail within the given
circumstance.
Hardjono & Weis Informational [Page 10]
Core to the area of key management is Security Association (SA)
Management, which will be discussed further below.
A "Group Key Management Architecture" document [BCDL] further defines the key management architecture for multicast security. It builds on the Group Security Association (GSA) concept, and further defines the roles of the Key Server and Group Controller.
"The Group Domain of Interpretation" [RFC3547], "GSAKMP" [GSAKMP],
and "MIKEY" [ACLNM] are three instances of protocols implementing the group key management function.
3.3. Multicast Security Policies
Multicast Security Policies must provide the rules for operation for the other elements of the Reference Framework. Security Policies may be distributed in an ad-hoc fashion in some instances. However,
better coordination and higher levels of assurance are achieved if a Policy Controller distributes Security Policies policy to the group. Multicast security policies must represent, or contain, more
information than a traditional peer-to-peer policy. In addition to
representing the security mechanisms for the group communication, the policy must also represent the rules for the governance of the secure group. For example, policy would specify the authorization level
necessary in order for an entity to join a group. More advanced
operations would include the conditions when a group member must be
forcibly removed from the group, and what to do if the group members need to resynchronize because of lost key management messages.
The application of policy at the Group Controller element and the
member (sender and receiver) elements must be described. While there is already a basis for security policy management in the IETF,
multicast security policy management extends the concepts developed
for unicast communication in the areas of:
- Policy creation,
- High-level policy translation, and
- Policy representation.
Examples of work in multicast security policies include the Dynamic
Cryptographic Context Management project [Din], Group Key Management Protocol [Har1, Har2], and Antigone [McD].
Policy creation for secure multicast has several more dimensions than the single administrator specified policy assumed in the existing
unicast policy frameworks. Secure multicast groups are usually large and by their very nature extend over several administrative domains, Hardjono & Weis Informational [Page 11]
if not spanning a different domain for each user. There are several methods that need to be considered in the creation of a single,
coherent group security policy. They include a top-down
specification of the group policy from the group initiator and
negotiation of the policy between the group members (or prospective
members). Negotiation can be as simple as a strict intersection of
the policies of the members or extremely complicated using weighted
voting systems.
The translation of policy rules from one data model to another is
much more difficult in a multicast group environment. This is
especially true when group membership spans multiple administrative
domains. Policies specified at a high level with a Policy Management tool must be translated into more precise rules that the available
security policy mechanisms can both understand and implement. When
dealing with multicast communication and its multiple participants,
it is essential that the individual translation performed for each
participant result in the use of a mechanism that is interoperable
with the results of all of the other translations. Typically, the
translation from high-level policy to specific policy objects must
result in the same objects in order to achieve communication between all of the group members. The requirement that policy translation
results in the same objects places constraints on the use and
representations in the high-level policies.
It is also important that policy negotiation and translation be
performed as an integral part of joining a group. Adding a member to a group is meaningless if they will not be able to participate in the group communications.
4. Group Security Associations (GSA)
4.1. The Security Association
A security association is a commonly used term in cryptographic
systems (e.g., [RFC2401, RFC2406bis, RFC2409]). This document uses
the term to mean any set of policy and cryptographic keys that
provide security services for the network traffic matching that
policy. A Security Association usually contains the following
attributes:
- selectors, such as source and destination transport addresses. - properties, such as an security parameter index (SPI) or cookie pair, and identities.
- cryptographic policy, such as the algorithms, modes, key
lifetimes, and key lengths used for authentication or
confidentiality.
- keys, such as authentication, encryption and signing keys. Hardjono & Weis Informational [Page 12]
Group key management uses a different set of abstractions than
point-to-point key management systems (such as IKE [RFC2409]).
Notwithstanding, the abstractions used in the Group Key Management
functional area may be built from the point-to-point key management
abstractions.
4.2. Structure of a GSA: Introduction
Security associations (SAs) for group key management are more
complex, and are usually more numerous, than for point-to-point key
management algorithms. The latter establishes a key management SA to protect application SAs (usually one or two, depending on the
protocol). However, group key management may require up to three or more SAs. These SAs are described in later sections.
A GSA contains all of the SA attributes identified in the previous
section, as well some additional attributes pertaining to the group. As shown in Figure 3, the GSA builds on the SA in two distinct ways. - First, the GSA is a superset of an SA (Figure 3(a)). A GSA has
group policy attributes. For example, the kind of signed
credentials needed for group membership, whether group members
will be given new keys when a member is added (called "backward
re-key" below), or whether group members will be given new keys
when a member is removed from the group ("forward re-key"). A GSA also includes an SA as an attribute of itself.
- Second, the GSA is an aggregation of SAs (Figure 3(b)). A GSA is comprised of multiple SAs, and these SAs may be used for several
independent purposes.
+---------------+ +-------------------+
| GSA | | GSA |
| | | +-----+ +-----+ |
| | | | SA1 | | SA2 | |
| +----+ | | +-----+ +-----+ |
| | SA | | | +-----+ |
| +----+ | | | SA3 | |
| | | +-----+ |
+---------------+ +-------------------+
(a) superset (b) aggregation
Figure 3: Relationship of GSA to SA
Hardjono & Weis Informational [Page 13]
4.3. Structure of a GSA: Reasoning
Figure 4 shows three categories of SAs that can be aggregated into a GSA.
+------------------------------------------------------------+
| |
| +------------------+ |
| | GCKS | |
| | | |
| | REG REG | |
| | / REKEY \ | |
| +---/-----|----\---+ |
| / | \ |
| / | \ |
| / | \ |
| / | \ |
| / | \ |
| +----------/------+ | +------\----------+ |
| | REG | | | REG | |
| | REKEY-----+----REKEY | |
| | Sender | | Receiver | |
| | DATA----------DATA | |
| +-----------------+ +-----------------+ |
| |
| |
+------------------------------------------------------------+
Figure 4: GSA Structure and 3 categories of SAs
The three categories of SAs are:
- Registration SA (REG): A separate unicast SA between the GCKS and each group member, regardless of whether the group member is a
sender or a receiver or acting in both roles.
- Re-key SA (REKEY): A single multicast SA between the GCKS and all of the group members.
- Data Security SA (DATA): A multicast SA between each multicast
source speaker and the group’s receivers. There may be as many
data SAs as there are multicast sources allowed by the group’s
policy.
Each of these SAs are defined in more detail in the next section. Hardjono & Weis Informational [Page 14]
4.4. Definition of GSA
The three categories of SAs correspond to three different kinds of
communications commonly required for group communications. This
section describes the SAs depicted in Figure 4 in detail.
- Registration SA (REG):
An SA is required for (bi-directional) unicast communications
between the GCKS and a group member (be it a Sender or Receiver). This SA is established only between the GCKS and a Member. The
GCKS entity is charged with access control to the group keys, with policy distribution to members (or prospective members), and with group key dissemination to Sender and Receiver members. This use of a (unicast) SA as a starting point for key management is common in a number of group key management environments [RFC3547, GSAKMP, CCPRRS, RFC2627, BMS].
The Registration SA is initiated by the member to pull GSA
information from the GCKS. This is how the member requests to
join the secure group, or has its GSA keys re-initialized after
being disconnected from the group (e.g., when its host computer
has been turned off during re-key operations). The GSA
information pulled down from the GCKS is related to the other two SAs defined as part of the GSA.
Note that this (unicast) SA is used to protect the other elements of the GSA. As such, the Registration SA is crucial and is
inseparable from the other two SAs in the definition of a GSA.
However, the requirement of a registration SA does not imply the
need of a registration protocol to create that Registration SA.
The registration SA could instead be setup through some manual
means, such as distributed on a smart card. Thus, what is
important is that a Registration SA exists, and is used to protect the other SAs.
From the perspective of one given GCKS, there are as many unique
registration SAs as there are members (Senders and/or Receivers)
in the group. This may constitute a scalability concern for some applications. A registration SA may be established on-demand with a short lifetime, whereas re-key and data security SAs are
established at least for the life of the sessions that they
support.
Conversely the registration SA could be left in place for the
duration of the group lifetime, if scalability is not an issue.
Such a long term registration SA would be useful for re-
synchronization or deregistration purposes.
Hardjono & Weis Informational [Page 15]
- Re-key SA (REKEY):
In some cases, a GCKS needs the ability to "push" new SAs as part of the GSA. These new SAs must be sent to all group members. In other cases, the GCKS needs the ability to quickly revoke access
to one or more group members. Both of these needs are satisfied
with the Re-key SA.
This Re-key SA is a unidirectional multicast transmission of key
management messages from the GCKS to all group members. As such, this SA is known by the GCKS and by all members of the group.
This SA is not negotiated, since all the group members must share it. Thus, the GCKS must be the authentic source and act as the
sole point of contact for the group members to obtain this SA.
A rekey SA is not absolutely required to be part of a GSA. For
example, the lifetime of some groups may be short enough such that a rekey is not necessary. Conversely, the policy for the group
could specify multiple rekey SAs of different types. For example, if the GC and KS are separate entities, the GC may deliver rekey
messages that adjust the group membership, and the KS may deliver rekey messages with new DATA SAs.
- Data Security SA (DATA):
The Data Security SA protects data between member senders and
member receivers.
One or more SAs are required for the multicast transmission of
data-messages from the Sender to other group members. This SA is known by the GCKS and by all members of the group.
Regardless of the number of instances of this third category of
SA, this SA is not negotiated. Rather, all group members obtain
it from the GCKS. The GCKS itself does not use this category of
SA.
From the perspective of the Receivers, there is at least one data security SA for the member sender (one or more) in the group. If the group has more than one data security SA, the data security
protocol must have a means of differentiating the SAs (e.g., with a SPI).
Hardjono & Weis Informational [Page 16]
There are a number of possibilities with respect to the number of data security SAs:
1. Each sender in the group could be assigned a unique data
security SA, thereby resulting in each receiver having to
maintain as many data security SAs as there are senders in the group. In this case, each sender may be verified using source origin authentication techniques.
2. The entire group deploys a single data security SA for all
senders. Receivers would then be able to maintain only one
data security SA.
3. A combination of 1. and 2.
4.5. Typical Compositions of a GSA
Depending on the multicast group policy, many compositions of a GSA
are possible. For illustrative purposes, this section describes a
few possible compositions.
- A group of memory-constrained members may require only a REG SA,
and a single DATA SA.
- A "pay-per-session" application, where all of the SA information
needed for the session may be distributed over a REG SA. Re-key
and re-initialization of DATA SAs may not be necessary, so there
is no REKEY SA.
- A subscription group, where keying material is changed as
membership changes. A REG SA is needed to distribute other SAs; a REKEY SA is needed to re-initialize a DATA SA at the time
membership changes.
5. Security Services
This section identifies security services for designated interfaces
of Figure 2. Distinct security services are assigned to specific
interfaces. For example, multicast source authentication, data
authentication, and confidentiality occur on the multicast data
interface between Senders and Receivers in Figure 2. Authentication and confidentiality services may also be needed between the Key
Server and group members (i.e., the Senders and Receivers of Figure
2), but the services that are needed for multicast key management may be unicast as well as multicast. A security service in the Multicast Security Reference Framework therefore identifies a specific function along one or more Figure 2 interfaces.
Hardjono & Weis Informational [Page 17]
This paper does not attempt to analyze the trust relationships,
detailed functional requirements, performance requirements, suitable algorithms, and protocol specifications for IP multicast and
application-layer multicast security. Instead, that work will occur as the security services are further defined and realized in
algorithms and protocols.
5.1. Multicast Data Confidentiality
This security service handles the encryption of multicast data at the Sender’s end and the decryption at the Receiver’s end. This security service may also apply the keying material that is provided by
Multicast Key Management in accordance with Multicast Policy
Management, but it is independent of both.
An important part of the Multicast Data Confidentiality security
service is in the identification of and motivation for specific
ciphers that should be used for multicast data. Obviously, not all
ciphers will be suitable for IP multicast and application-layer
multicast traffic. Since this traffic will usually be connectionless UDP flows, stream ciphers may be unsuitable, though hybrid
stream/block ciphers may have advantages over some block ciphers.
Regarding application-layer multicast, some consideration is needed
to consider the effects of sending encrypted data in a multicast
environment lacking admission-control, where practically any
application program can join a multicast event independently of its
participation in a multicast security protocol. Thus, this security service is also concerned with the effects of multicast
confidentiality services (intended and otherwise) on application
programs. Effects to both Senders and Receivers are considered.
In Figure 2, the Multicast Data Confidentiality security service is
placed in Multicast Data Handling Area along the interface between
Senders and Receivers. The algorithms and protocols that are
realized from work on this security service may be applied to other
interfaces and areas of Figure 2 when multicast data confidentiality is needed.
5.2. Multicast Source Authentication and Data Integrity
This security service handles source authentication and integrity
verification of multicast data. It includes the transforms to be
made both at the Sender’s end and at the Receiver’s end. It assumes that the appropriate signature and verification keys are provided via Multicast Key Management in accordance with Multicast Policy
Management as described below. This is one of the harder areas of
multicast security due to the connectionless and real-time
Hardjono & Weis Informational [Page 18]
requirements of many IP multicast applications. There are classes of application-layer multicast security, however, where offline source
and data authentication will suffice. As discussed previously, not
all multicast applications require real-time authentication and
data-packet integrity. A robust solution to multicast source and
data authentication, however, is necessary for a complete solution to multicast security.
In Figure 2, the Multicast Source and Data Authentication security
service is placed in Multicast Data Handling Area along the interface between Senders and Receivers. The algorithms and protocols that are produced for this functional area may have applicability to security services in other functional area that use multicast services such as Group Key Management.
5.3. Multicast Group Authentication
This security service provides a limited amount of authenticity of
the transmitted data: It only guarantees that the data originated
with (or was last modified by) one of the group members. It does not guarantee authenticity of the data in case that other group members
are not trusted.
The advantage of group authentication is that it is guaranteed via
relatively simple and efficient cryptographic transforms. Therefore, when source authentication is not paramount, group authentication
becomes useful. In addition, performing group authentication is
useful even when source authentication is later performed: it
provides a simple-to-verify weak integrity check that is useful as a measure against denial-of-service attacks.
The Multicast Group Authentication security service is placed in the Multicast Data Handling Area along the interface between Senders and Receivers.
5.4. Multicast Group Membership Management
This security service describes the functionality of registration of members with the Group Controller, and de-registration of members
from the Group Controller. These are security functions, which are
independent from IP multicast group "join" and "leave" operations
that the member may need to perform as a part of group admission
control protocols (i.e., IGMP [RFC3376], MLD [RFC3019]).
Registration includes member authentication, notification and
negotiation of security parameters, and logging of information
according to the policies of the group controller and the would-be Hardjono & Weis Informational [Page 19]
member. (Typically, an out-of-band advertisement of group information would occur before the registration takes place. The registration
process will typically be invoked by the would-be member.)
De-registration may occur either at the initiative of the member or
at the initiative of the group controller. It would result in
logging of the de-registration event by the group controller and an
invocation of the appropriate mechanism for terminating the
membership of the de-registering member (see Section 5.5).
This security service also describes the functionality of the
communication related to group membership among different GCKS
servers in a distributed group design.
In Figure 2, the Multicast Group Membership security service is
placed in the Group Key Management Area and has interfaces to Senders and Receivers.
5.5. Multicast Key Management
This security service describes the functionality of distributing and updating the cryptographic keying material throughout the life of the group. Components of this security service may include:
- GCKS to group member (Sender or Receiver) notification
regarding current keying material (e.g., group encryption and
authentication keys, auxiliary keys used for group management, keys for source authentication, etc.).
- Updating of current keying material, depending on circumstances and policies.
- Termination of groups in a secure manner, including the secure group itself and the associated keying material.
Among the responsibilities of this security service is the secure
management of keys between Key Servers and group members, the
addressing issues for the multicast distribution of keying material, and the scalability or other performance requirements for multicast
key management [RFC2627, BMS]. Key Servers and group members may
take advantage of a common Public Key Infrastructure (PKI) for
increased scalability of authentication and authorization.
To allow for an interoperable and secure IP multicast security
protocol, this security service may need to specify host abstractions such as a group security association database (GSAD) and a group
security policy database (GSPD) for IP multicast security. The
degree of overlap between IP multicast and application-layer
multicast key management needs to be considered. Thus, this security service takes into account the key management requirements for IP Hardjono & Weis Informational [Page 20]
《SQL Server 2008数据库案例教程》练习题及模拟试卷答案 第1章 一、判断题 1. 数据库技术是是计算机数据处理与信息管理系统的核心。(√) 2. 数据是用于描述现实世界中具体事物或抽象概念,可存储的数字符号。(×) 3. 数据库是一个长期存储在计算机内的、有组织的、有共享的、统一管理的数据集合。(√) 4. 数据库管理系统是一个按数据结构来存储和管理数据的服务器管理系统。(×) 5. 关系数据库，是建立在关系模型基础上的数据库。(√) 二、单选题 1. 数据(Data)是一些可存储并具有明确意义的(A) A. 符号 B.图形 C.文字 D.数字 2. 人工阶段计算机用于数值计算，没有操作系统及管理数据的软件。这一阶段的年代是（C） A. 19世纪80年代 B. 20世纪20年代 C.20世纪50年代 D. 20世纪80年代 3. 在网页中常用的图像格式是（D） A..bmp和.jpg B..gif和.bmp C. .png和.bmp D. .gif和.jpg 4.数据库系统的重要特征是什么？（D） A. 数据的独立性和动态性 B．数据的静态性和独立性 C．数据的动态性和共享性 D．数据的独立性和共享性 三、多选题 1.与数据库技术密切相关的基本概念有（ABCD） A. 数据 B. 数据库 C. 数据库管理系统 D. 数据库系统 2.数据库可分为哪几种类型？（ABC） A. 关系型数据库 B. 网状数据库 C. 层次数据库 D.树形数据库 3. DBMS提供数据操作语言DML，为用户提供了哪些操作？（ABCD） A．数据的追加B．数据的删除C．数据的更新D．数据的查询 4.DBMS要分类组织、存储和管理各种数据，包括哪些内容？（ABC） A. 数据字典 B. 用户数据 C. 存取路径 D.服务器 5. 目前，DBMS常见品牌有哪些公司？（ABC） A.微软公司的SQL Server B．IBM公司的DB2 C．甲骨文公司的ORACLE D．索尼公司的MySQL 四、填空题 1.数据库（管理）技术经历了人工管理阶段和文件管理阶段。 2.文件系统不提供对任意部分数据的（快速）访问 3.关系数据库，是建立在关系（模型）基础上的数据库。 4.实体-联系模型（简称E-R模型）是由P.P.Chen于（1976）年首先提出的。
对翻译中异化法与归化法的正确认识 班级：外语学院、075班 学号：074050143 姓名：张学美 摘要：运用异化与归化翻译方法,不仅是为了让读者了解作品的内容,也能让读者通过阅读译作,了解另一种全新的文化,因为进行文化交流才是翻译的根本任务。从文化的角度考虑,采用异化法与归化法,不仅能使译文更加完美,更能使不懂外语的人们通过阅读译文,了解另一种文化,促进各民族人们之间的交流与理解。翻译不仅是语言符号的转换,更是跨文化的交流。有时,从语言的角度所作出的译文可能远不及从文化的角度所作出的译文完美。本文从翻译策略的角度，分别从不同时期来说明人们对异化法与归化法的认识和运用。 关键词:文学翻译；翻译策略；异化；归化；辩证统一 一直以来,无论是在我国还是在西方,直译(literal translation)与意译(liberal translation)是两种在实践中运用最多,也是被讨论研究最多的方法。1995年,美籍意大利学者劳伦斯-韦努蒂(Lawrence Venuti)提出了归化(domestication)与异化(foreignization)之说,将有关直译与意译的争辩转向了对于归化与异化的思考。归化与异化之争是直译与意译之争的延伸,是两对不能等同的概念。直译和意译主要集中于语言层面,而异化和归化则突破语言的范畴,将视野扩展到语言、文化、思维、美学等更多更广阔的领域。 一、归化翻译法 Lawrwnce Venuti对归化的定义是,遵守译入语语言文化和当前的主流价值观,对原文采用保守的同化手段,使其迎合本土的典律,出版潮流和政治潮流。采用归化方法就是尽可能不去打扰读者,而让作者向读者靠拢(the translator leaves the reader in peace, as much as possible, and moves the author towards him)。归化翻译法的目的在于向读者传递原作的基本精神和语义内容,不在于语言形式或个别细节的一一再现。它的优点在于其流利通顺的语言易为读者所接受,译文不会对读者造成理解上的障碍,其缺点则是译作往往仅停留在内容、情节或主要精神意旨方面,而无法进入沉淀在语言内核的文化本质深处。 有时归化翻译法的采用也是出于一种不得已,翻译活动不是在真空中进行的,它受源语文化和译语文化两种不同文化语境的制约,还要考虑到两种文化之间的
1) With the rapid improvement in.../growing awareness of..., more and more.../sth.... 1 随着…的飞速发展/越来越多的关注，越来越… (e.g. With the considerable improvement in building industry, more and more structures are being erected to set the people's minds at ease.) 例：随着建筑业的大力推进，人们对建立越来越多的房屋建筑感到宽心。 2) Recently, sth./the problem of...has been brought to popular attention/ has become the focus of public concern. 2 近来，某事/某问题引起了人们的普遍关注/成了公众关注的焦点。 (e.g. Recently, the problem of unemployment has been brought to such popular attention that governments at all levels place it on the agenda as the first matter.) 例：近来失业问题引起了人们的普遍关注，各级政府已把它列为首要议程。 3) One of the universal issues we are faced with/that cause increasing concern is that... 3 我们面临的一个普遍问题是… /一个越来越引人关注的普遍问题 是… (e.g. One of the universal issues that draw (cause) growing concern is whether it is wise of man to have invented the automobile.) 例：一个越来越引人关注的普遍问题是，发明汽车是否为人 4) In the past few years, there has been a boom/sharp growth/decline in.. . 4 在过去的几年里，…经历了突飞猛进/迅猛增长/下降。 (e.g. In the past ten years, there has been a sharp decline in the number of species.) 例：在过去的几年里，物种数量骤然下降。 5) Nowadays, more/most important/dangerous for our society is... 5 如今对我们社会更（最）为重要的（危险的）事情是… (e.g. Nowadays, most dangerous for our society is the tendency to take advantage of each other in political circles.) 例：对我们社会最为危险的事情是政界倾向于互相利用。 6) According to the information given in the table/graph, we can find that... 6 根据图表资料，我们可以发现… 7) As can be seen from the table/graph/figure, there is a marked increase /decline/favorable (an unfavorable) change in... 7 根据图表（数字）显示，…明显增长（下降）/发生了有利（不利）变化。 8) As we can see from the table/graph/figure above, drastic/considerable/ great changes have taken place in...over the period of time from...(年份)to...( 年份) 8 据上面图表（数字）所示，从某年到某年某方面发生了剧烈的（相当大的；巨大的）变化。
一、数据库概述 数据库（DataBase，DB）：指长期保存在计算机的存储设备上，按照一定规则组织起来，可以被各种用户或应用共享的数据集合。(文件系统) 数据库管理系统（DataBase Management System，DBMS）：指一种操作和管理数据库的大型软件，用于建立、使用和维护数据库，对数据库进行统一管理和控制，以保证数据库的安全性和完整性。用户通过数据库管理系统访问数据库中的数据。 数据库软件应该为数据库管理系统，数据库是通过数据库管理系统创建和操作的。 数据库：存储、维护和管理数据的集合。 二、数据库的安装与配置 * 安装 * 参照图解 * 一路下一步 * 配置 * 参照图解 * 到选择字符集时停 登录Mysql： mysql -u root -p abc * 卸载 1.停止mysql服务net stop mysql 启动mysql服务net start mysql 2.卸载mysql 3.找到mysql 安装目录下的my.ini datadir="C:/ProgramData/MySQL/MySQL Server 5.5/Data/" * 修改密码 运行cmd * 安装成功了打开cmd --> mysql -uroot -p你的密码 * 修改mysql root用户密码 1) 停止mysql服务运行输入services.msc 停止mysql服务 或者cmd --> net stop mysql 2) 在cmd下输入mysqld--skip-grant-tables 启动服务器光标不动（不要关闭该窗口） 3) 新打开cmd 输入mysql -u root -p 不需要密码
一、表的结构及完整性约束 新建一个数据库jxsk，包括S、C、SC、T、TC五个表，结构如下：C表： S表： SC表： T表：
TC表： 二、安全性控制及视图机制 1、三类角色：depart、teacher、student depart的权限： teacher的权限：
student的权限： 2、有2个院系用户：d_jsj，d_xx，同属于depart角色。
有1个教师用户：t ，属于teacher 角色。
有一个学生用户：s，属于student角色。 3、创建计算机系教师视图t_view_jsj、计算机系学生视图s_view_jsj，并授予d_jsj 用户在这两个视图上的select、delete、update、insert权限。 计算机系教师视图t_view_jsj： create view t_view_jsj as select tno,tn,sex,age,prof,sal,comm,dept from t where dept='计算机' with check option
授予d_jsj用户在计算机系教师视图t_view_jsj 上的select、delete、update、insert 权限： grant select,update,delete,insert on t_view_jsj to d_jsj 计算机系学生视图t_view_jsj： create view s_view_jsj as select sno,sn,sex,age,dept,resume,native from s where dept='计算机' with check option 授予d_jsj用户在计算机系学生视图s_view_jsj 上的select、delete、update、insert 权限： grant select,update,delete,insert on s_view_jsj to d_jsj …… 4、创建一个视图，显示学号,姓名,院系,课程名,成绩。 create view score_view(学号,姓名,院系,课程名,成绩) as select s.sno,sn,dept,cn,score from s,sc,c where s.sno=sc.sno and https://www.doczj.com/doc/7010127285.html,o=https://www.doczj.com/doc/7010127285.html,o 三、完整性控制--触发器、规则 1、要求当删除C表中某课程信息时，同时删除SC和TC中与此课程相关的记录。create trigger c_delete_trigger on c after delete as delete from sc where cno in (select cno from deleted) delete from tc where cno in (select cno from deleted) go
北语14秋《高级英语I》导学资料一 Unit1, Unit2& Unit3 一、本阶段学习内容概述 各位同学，大家好，本课程第一阶段学习的主要内容为Unit1：Party Politics, Unit2：The New Singles, Unit3：教材课文：Doctor’s Dilemma: Treat or Let Die? 网络课件课文：Computer Violence中包括课前练习（Warm-up）、单词和词组（New words and phrases）、课文（Text）、课后练习（Exercises）及补充阅读（Supplementary readings）中的指定内容。 课前练习：大家应先了解课前练习的要求，根据已有的知识思考其中问题，或者利用网络与同学开展一些讨论，争取在阅读课文前了解文章主要论述的问题，有利于更好的了解作者的思想观点和思维过程，从而了解文章所反映的思想文化，这样既能提高阅读理解能力又能获取知识和信息。 单词和词组:名词、动词和形容词是词汇练习和记忆中的重要部分。Unit 1、2、3中所列出的新单词绝大部分都是这三类，因此，大家一定要掌握好新单词。要开发利用多种方法记单词，如联想法、音节法、构词法等。单词和词组基本上给出了英语直接释义，可以培养大家英语思维的习惯。如果在阅读释义后还有疑问，一定要查阅英语词典，寻找一些相关的解释来加深对单词的理解和记忆。许多词的释义中给出了若干同义词或近义词，能帮助大家迅速扩大词汇量，同时，课后练习的词汇（Vocabulary Study）部分又给出了一些相关的练习，大家可以在学习完单词和词组后，乘热打铁，立即做词汇练习的第一小题（选择填空）和第二小题（找出意义相近的替代词）这样可以及时巩固所学单词，大概了解这些词的用法，为正确阅读课文打下基础，也能使得练习题做起来不是那么难。 （特别说明：高级英语阶段的学习，提高词汇量和词汇运用能力是一个很大，并且很重要，同时又是比较难的问题，这是我们必须面对的问题，所以，请大家务必花时间多熟悉单词。所谓的磨刀不误砍材功，先熟悉单词和短语，才能流畅的阅读文章。更关键的是，单词和短语在考试中所占比例不少！） 课文：每单元有一篇课文（Unit1：Party Politics, Unit2：The New Singles, Unit3：教材课文：Doctor’s Dilemma: Treat or Let Die? 网络课件课文：Computer Violence）。在掌握单词和词组之后，阅读课后注释，学习课文的背景资料、作者介绍和相关内容，如人物、事件、地点等的解释，这能帮助大家准确快速的理解文章的内容。在课件资源的帮助下，认真学习课文，包括课文中常用词语和句型的用法。文章比较长，大家一定要有耐心和毅力，坚持就是胜利。在学习完整篇文章后，及时完成课文理解（Comprehension Check）的练习。其中第一小题是根据课文内容选择最佳答案，第二小题是将部分文中的句子用英语注释。只要认真学习了课件资料，相信能很快准确地完成。同时也考察大家对课文理解的程度，督促大家很好的阅读课文。 课后练习：共有四个大题。 1.课文理解（Comprehension Check）：有两个题型。在借助课件学习完课文之后，大家可以先自己做这一部分的练习，然后再看课件，对正答案的同时，再重温课文的大意。 2.词汇（Vocabulary Study）：有两个题型。在学完课文和单词后，大家可以自己先做这一部分的词汇练习，不会做得可以看课件，并牢固掌握，对于补充的单词也要掌握。这样有利于快速扩充词汇量。 3.翻译（Translation）：有的单元是汉译英，有的单元是英译汉。都是一段与课文内容相近的短文。先认真思考，仔细看文章，如果有一定的难度，可以参考课件的解说，然后再组织语言完成翻译练习。
“异化”与“归化”之间的关系并评述 1、什么是归化与异化 归化”与“异化”是翻译中常面临的两种选择。钱锺书相应地称这两种情形叫“汉化”与“欧化”。A．归化 所谓“归化”（domestication 或target-language-orientedness），是指在翻译过程中尽可能用本民族的方式去表现外来的作品；归化翻译法旨在尽量减少译文中的异国情调，为目的语读者提供一种自然流畅的译文。Venuti 认为，归化法源于这一著名翻译论说，“尽量不干扰读者，请作者向读者靠近” 归化翻译法通常包含以下几个步骤：（1）谨慎地选择适合于归化翻译的文本；（2）有意识地采取一种自然流畅的目的语文体；（3）把译文调整成目的语篇体裁；（4）插入解释性资料；（5）删去原文中的实观材料；（6）调协译文和原文中的观念与特征。 B．“异化”（foreignization或source-language-orientedness）则相反，认为既然是翻译，就得译出外国的味儿。异化是根据既定的语法规则按字面意思将和源语文化紧密相连的短语或句子译成目标语。例如，将“九牛二虎之力”译为“the strength of nine bulls and two tigers”。异化能够很好地保留和传递原文的文化内涵，使译文具有异国情调，有利于各国文化的交流。但对于不熟悉源语及其文化的读者来说，存在一定的理解困难。随着各国文化交流愈来愈紧密，原先对于目标语读者很陌生的词句也会变得越来越普遍，即异化的程度会逐步降低。 Rome was not built in a day. 归化:冰冻三尺,非一日之寒. 异化:罗马不是一天建成的. 冰冻三尺,非一日之寒 异化:Rome was not built in a day. 归化:the thick ice is not formed in a day. 2、归化异化与直译意译 归化和异化，一个要求“接近读者”，一个要求“接近作者”，具有较强的界定性；相比之下，直译和意译则比较偏重“形式”上的自由与不自由。有的文中把归化等同于意译，异化等同于直译，这样做其实不够科学。归化和异化其实是在忠实地传达原作“说了什么”的基础之上，对是否尽可能展示原作是“怎么说”，是否最大限度地再现原作在语言文化上的特有风味上采取的不同态度。两对术语相比，归化和异化更多地是有关文化的问题，即是否要保持原作洋味的问题。 3、不同层面上的归化与异化 1、句式 翻译中“归化”表现在把原文的句式（syntactical structure）按照中文的习惯句式译出。
高级英语写作1-10课翻译
The Delicate Art of the Forest 库珀的创造天分并不怎么样；但是他似乎热衷于此并沾沾自喜。确实，他做了一些令人感到愉快的事情。在小小的道具箱内，他为笔下的森林猎人和土人准备了七八种诡计或圈套，这些人以此诱骗对方。利用这些幼稚的技巧达到了预期的效果，没有什么更让他高兴得了。其中一个就是他最喜欢的，就是让一个穿着鹿皮靴的人踩着穿着鹿皮靴敌人的脚印，借以隐藏了自己行踪。这么做使库珀磨烂不知多少桶鹿皮靴。他常用的另一个道具是断树枝。他认为断树枝效果最好，因此不遗余力地使用。在他的小说中，如果哪章中没有人踩到断树枝惊着两百码外的印第安人和白人，那么这一节则非常平静/那就谢天谢地了。每次库珀笔下的人物陷入危险，每分钟绝对安静的价格是4美元/一分静一分金，这个人肯定会踩到断树枝。尽管附近有上百种东西可以踩，但这都不足以使库珀称心。他会让这个人找一根干树枝；如果找不到，就去借一根。事实上，《皮袜子故事系列丛书》应该叫做《断树枝故事集》。 很遗憾，我没有足够的篇幅，写上几十个例子，看看奈迪·班波和其他库伯专家们是怎样运用他的森林中的高招。大概我们可以试着斗胆举它两三个例子。库伯曾经航过海—当过海军军官。但是他却一本正经/煞有介事地告诉我们，一条被风刮向海岸遇险的船，被船长驶向一个有离岸暗流的地点而得救。因为暗流顶着风，把船冲了回来。看看这森林术，这行船术，或者叫别的什么术，很高明吧？库珀在炮兵部队里待过几年，他应该注意到炮弹落到地上时，要么爆炸，要么弹起来，跳起百英尺，再弹再跳，直到跳不动了滚几下。现在某个地方他让几个女性—他总是这么称呼女的—在一个迷雾重重的夜晚，迷失在平原附近一片树林边上—目的是让班波有机会向读者展示他在森林中的本事。这些迷路的人正在寻找一个城堡。他们听到一声炮响，接着一发炮弹就滚进树林，停在他们脚下。对女性，这毫无价值。但对可敬的班波就完全不同了。我想，如果班波要是不马上冲出来，跟着弹痕，穿过浓雾，跨过平原，找到要塞，我就再也不知道什么是“和平”了。是不是非常聪明？如果库伯不是对自然规律一无所知，他就是故意隐瞒事实。比方说，他的精明的印地安专家之一，名叫芝稼哥（我想，该读作芝加哥）的，跟踪一个人，在穿过树林的时候，脚印就找不到了。很明显，脚印是再也没法找到了。无论你还是我，都猜不出，怎么会
淮海工学院计算机工程学院实验报告书 课程名：数据库原理及应用 题目：实验七数据库应用系统实例 班级：D计算机081 学号： 姓名：
一、实验目的 开发学生学籍管理系统小型数据库应用系统数据库连接、数据操程作序编写，熟练使用Microsoft Visual Studio 2005开发平台。 二、实验内容和要求 1．后台为SQL server2000, 2．前台为面向对象编程语言（可选择） 3．完成数据库连接 4．完成对前面实验所建立的studb109学籍数据库中的数据通过应用系统界面进行更新和查询等操作。 三、实验步骤和实验结果 1．连接SQL Server的数据库访问编程实例。编写一个应用程序来连接数据库名为studb109的SQL Sever数据库，并根据连接结果输出一些信息。 （1）.运行Microsoft V isual Studio 2005 （2）.新建网站
（3）.设计网站 using System; using System.Collections; using System.Configuration; using System.Data; using System.Linq; using System.Web; using System.Web.Security; using System.Web.UI; using System.Web.UI.HtmlControls; using System.Web.UI.WebControls; using System.Web.UI.WebControls.WebParts; using System.Xml.Linq; using System.Data.SqlClient; namespace web { public partial class_Default : System.Web.UI.Page { protected void Page_Load(object sender, EventArgs e){} protected void Button1_Click(object sender, EventArgs e) {try {SqlConnection coon = new SqlConnection(); coon .ConnectionString =" Server =localhost; uid = sa;pwd=; database=studb109"; coon .Open (); Label1 .Text ="连接成功"; } catch { Label1 .Text ="连接失败"; }}}}
万方数据
万方数据
万方数据
万方数据
翻译的归化与异化 作者：熊启煦 作者单位：西南民族大学,四川,成都,610041 刊名： 西南民族大学学报（人文社科版） 英文刊名：JOURNAL OF SOUTHWEST UNIVERSITY FOR NATIONALITIES（HUMANITIES AND SOCIAL SCIENCE） 年，卷(期)：2005,26(8) 被引用次数：14次 参考文献(3条) 1.鲁迅且介亭杂文二集·题未定草 2.刘英凯归化--翻译的歧路 3.钱钟书林纾的翻译 引证文献(15条) 1.郭锋一小议英语翻译当中的信达雅[期刊论文]-青春岁月 2011(4) 2.许丽红论汉英语言中的文化差异与翻译策略[期刊论文]-考试周刊 2010(7) 3.王笑东浅谈汉英语言中的差异与翻译方法[期刊论文]-中国校外教育（理论） 2010(6) 4.王宁中西语言中的文化差异与翻译[期刊论文]-中国科技纵横 2010(12) 5.鲍勤.陈利平英语隐喻类型及翻译策略[期刊论文]-云南农业大学学报(社会科学版) 2010(2) 6.罗琴.宋海林浅谈汉英语言中的文化差异及翻译策略[期刊论文]-内江师范学院学报 2010(z2) 7.白蓝跨文化视野下文学作品的英译策略[期刊论文]-湖南社会科学 2009(5) 8.王梦颖探析汉英语言中的文化差异与翻译策略[期刊论文]-中国校外教育（理论） 2009(8) 9.常晖英汉成语跨文化翻译策略[期刊论文]-河北理工大学学报（社会科学版） 2009(1) 10.常晖对翻译文化建构的几点思考[期刊论文]-牡丹江师范学院学报（哲学社会科学版） 2009(4) 11.常晖认知——功能视角下隐喻的汉译策略[期刊论文]-外语与外语教学 2008(11) 12.赵勇刚汉英语言中的文化差异与翻译策略[期刊论文]-时代文学 2008(6) 13.常晖.胡渝镛从文化角度看文学作品的翻译[期刊论文]-重庆工学院学报(社会科学版) 2008(7) 14.曾凤英从文化认知的视角谈英语隐喻的翻译[期刊论文]-各界 2007(6) 15.罗琴.宋海林浅谈汉英语言中的文化差异及翻译策略[期刊论文]-内江师范学院学报 2010(z2) 本文链接：https://www.doczj.com/doc/7010127285.html,/Periodical_xnmzxyxb-zxshkxb200508090.aspx
英语专业(高级翻译)简介 ·日期：2007-06-07 ·点击次数： 1446 培养目标：本专业培养具有扎实的英语语言基础，较强的语言交际能力和跨文化交际能力，掌握多方面的翻译知识和技巧，能熟练地运用英、汉语在外事、外交、经贸、文化、科技等部门从事口译、笔译的专门人才。 知识能力 要求：1．语音、语调准确，清楚自然。 2．词法、句法、章法(包括遣词造句与谋篇布局)规范、表达得体。 3．认知词汇10000~12000，且能正确而熟练地使用其中的5000~6000个单词及其最常用的搭配。 4．听、说、读、写、译技能熟练，具有较强的英语综合运用能力。毕业时达到英语专业八级水平。 听的能力：听懂真实交际场合中各种英语会话；听懂英 语国家广播电台以及电视台(如VOA, BBC, CNN)有关政治、经济、文化、教育、科技 等方面的新闻、现场报道、专题报道、综合 评述以及与此类题材相关的演讲和演讲后 的问答；听懂电视时事报道和电视短剧中的 对话。语速为每分钟150~180个单词，理解 准确率不低于60%。 说的能力：能就国内外重大问题与外宾进行流利而得体 的交流；能系统、深入、连贯地发表自己的 见解。 读的能力：能读懂一般英美报刊杂志上的社论和书评、 英语国家出版的有一定难度的历史传记和 文学作品；能分析上述题材文章的思想观 点、语篇结构、语言特点和修辞手法。能在
5分钟内速读1600词左右的文章，掌握文章 的主旨和大意，理解事实和细节。 写的能力：能写各类体裁的文章，做到内容充实，语言 通顺，用词恰当，表达得体。写作速度为30 分钟300~400个单词。能撰写长度为 5000~6000个单词的毕业论文，要求思路清 晰、内容充实、语言通顺。 译的能力：1)笔译：能运用翻译的理论和技巧，将英美报 刊上的文章、文学、科技、文化、经贸方面 的原文译成汉语，或将我国报刊、杂志上的 文章、一般文学作品、科技、文化、经贸方 面的原文译成英语，速度为每小时250~300 个单词。译文要求忠实原意，语言流畅。 2)口译：掌握连续或同步口译所需的技巧及基 本要求，能担任外经外贸、外事、外交、国 际文化、科技交流活动的口译和国际会议的 同声传译任务。 5．具有宽广的英语专业知识和相关学科知识。英语专业知识包括文学、语言学和对象国社会与文化的知识。相关学科的知识涉及教育学、教育心理学、语言习得理论、英语教学法、英语测试理论与实践、课程设置等领域。6．具有获取知识的能力、运用知识的能力、分析问题的能力、独立提出见解的能力和创新的能力。 7．熟悉中、英两种文字计算机基本技术并能实际应用。 主干课程：基础英语、高级英语、散文选读、英语泛读、英语口语、基础英语写作、高级英语写作、英汉/汉英口译、英汉笔译、英语视听说、英语报刊选读、英美文学，同声传译、连续传译、经贸法律翻译等。 修业年4年
翻译作业10 Nov 15 一、请按归化法(Domestication)翻译下列习语。 Kill two birds with one stone a wolf in sheep’s clothing strike while the iron is hot. go through fire and water add fuel to the flames / pour oil on the flames spring up like mushrooms every dog has his day keep one’s head above water live a dog’s life as poor as a church mouse a lucky dog an ass in a lion’s skin a wolf in sheep’s clothing Love me, love my dog. a lion in the way lick one’s boots as timid as a hare at a stone’s throw as stupid as a goose wet like a drown rat as dumb as an oyster lead a dog’s life talk horse One boy is a boy, two boys half a boy, and three boys nobody. Man proposes, God disposes. Cry up wine and sell vinegar (cry up, to praise; extol: to cry up one's profession) Once bitten, twice shy. An hour in the morning is worth two in the evening． New booms sweep clean. take French leave seek a hare in a hen’s nest have an old head on young shoulder Justice has long arms You can’t teach an old dog Rome was not built in a day. He that lives with cripples learns to limp. Everybody’s business is nobody’s business. The more you get, the more you want. 二、请按异化法(foreignization)翻译下列习语。 Kill two birds with one stone a wolf in sheep’s clothing
北京理工大学翻硕(MTI)考研应用文写 作复习方法及指导 有无目标是成功者与平庸者的根本差别。凯程北京理工大学翻译硕士老师给大家详细讲解所遇到的问题。特别申明，以下信息绝对准确，凯程就是王牌的北京理工大学翻译硕士考研机构！ 一、北京理工大学翻译硕士考研复习指导 1．基础英语： 基础英语选择题考的特别细致，没有专门的教材，还是重在平时积累，凯程老师在讲课过程中特别重视对于考生基础知识的积累。凯程老师会对考生的阅读理解进行系统的训练。阅读理解也是偏政治，凯程老师会重点训练同学的答题速度，培养同学们阅读答题技巧，针对作文这方面，凯程老师也会对考生进行一系列的训练，让同学们勤加练习，多做模拟作文。 2．翻译英语： 翻译硕士基础这门课是需要下功夫的，英汉词条互译的部分完全需要你的积累，主要是词汇量和分析抓取能力。凯程老师会对学生的这两个方面进行很完善的训练。 凯程老师总结了以下提升翻译技巧的方法，供考研学子参考。 词组互译：大多考的都很常见，所以多看看中英文的报纸还是有好处的。 英汉：对文章的背景有一定的了解是最好的，如果没有，就需要体现出自身的翻译素养。翻译也要注意文风，语气之类的，要符合原文的风格。 凯程老师也很重视答题技巧，在此凯程名师友情提示大家，最好在开头就能让老师看到你的亮点，不管怎样至少留下个好印象。不管风格怎么变，翻译功底扎实，成绩都不会太差。所以还是提高自己翻译水平，才能以不变应万变。 3．百科： 先说说名词解释。这道题考得知识面很全，可能涉及到天文、地理、历史、法律、政治、中外文学、中外文化、音乐、翻译专有名词等，准备起来比较棘手，但是凯程老师会给学生准备好知识库，方便学生复习。百科的准备，一要广泛，二要抓重点，尤其要重视学校的参考书目，同时凯程也会提供凯程自己的教材及讲义来帮助大家。 接下来是应用文写作。其实这个根本不用担心，常出的无非是那几个：倡议书、广告、感谢信、求职信、计划书、说明书等，到12月份再看也不晚。但要注意一点，防止眼高手低，貌似很简单，真到写的时候却写不出来，所以还是需要练习的，凯程老师会在学生复习过程中对应用文的写作进行系统的训练。另外，考试的时候也要注意格式、合理性，如果再加上点文采，无异于锦上添花。 最后说说大作文。这个让很多同学担心，害怕到考场上无素材可写，或者语言生硬，拼凑一篇，毕竟大学四年，写作文的机会很少，早没有手感了。所以，凯程老师会针对这种情况，让考生从复习开始时，就进行写作训练，同时也会为考生准备好素材。 最后，注意考场上字体工整，不要乱涂乱画，最好打上横线，因为答题纸一般是白纸。 二、北京理工大学翻译硕士考研的复习方法解读 （一）、参考书的阅读方法 （1）目录法：先通读各本参考书的目录，对于知识体系有着初步了解，了解书的内在逻辑结构，然后再去深入研读书的内容。 （2）体系法：为自己所学的知识建立起框架，否则知识内容浩繁，容易遗忘，最好能
T h e D e l i c a t e A r t o f t h e F o r e s t 库珀的创造天分并不怎么样；但是他似乎热衷于此并沾沾自喜。确实，他做了一些令人感到愉快的事情。在小小的道具箱内，他为笔下的森林猎人和土人准备了七八种诡计或圈套，这些人以此诱骗对方。利用这些幼稚的技巧达到了预期的效果，没有什么更让他高兴得了。其中一个就是他最喜欢的，就是让一个穿着鹿皮靴的人踩着穿着鹿皮靴敌人的脚印，借以隐藏了自己行踪。这么做使库珀磨烂不知多少桶鹿皮靴。他常用的另一个道具是断树枝。他认为断树枝效果最好，因此不遗余力地使用。在他的小说中，如果哪章中没有人踩到断树枝惊着两百码外的印第安人和白人，那么这一节则非常平静/那就谢天谢地了。每次库珀笔下的人物陷入危险，每分钟绝对安静的价格是4美元/一分静一分金，这个人肯定会踩到断树枝。尽管附近有上百种东西可以踩，但这都不足以使库珀称心。他会让这个人找一根干树枝；如果找不到，就去借一根。事实上，《皮袜子故事系列丛书》应该叫做《断树枝故事集》。 很遗憾，我没有足够的篇幅，写上几十个例子，看看奈迪·班波和其他库伯专家们是怎样运用他的森林中的高招。大概我们可以试着斗胆举它两三个例子。库伯曾经航过海—当过海军军官。但是他却一本正经/煞有介事地告诉我们，一条被风刮向海岸遇险的船，被船长驶向一个有离岸暗流的地点而得救。因为暗流顶着风，把船冲了回来。看看这森林术，这行船术，或者叫别的什么术，很高明吧？库珀在炮兵部队里待过几年，他应该注意到炮弹落到地上时，要么爆炸，要么弹起来，跳起百英尺，再弹再跳，直到跳不动了滚几下。现在某个地方他让几个女性—他总是这么称呼女的—在一个迷雾重重的夜晚，迷失在平原附近一片树林边上—目的是让班波有机会向读者展示他在森林中的本事。这些迷路的人正在寻找一个城堡。他们听到一声炮响，接着一发炮弹就滚进树林，停在他们脚下。对女性，这毫无价值。但对可敬的班波就完全不同了。我想，如果班波要是不马上冲出来，跟着弹痕，穿过浓雾，跨过平原，找到要塞，我就再也不知道什么是“和平”了。是不是非常聪明？如果库伯不是对自然规律一无所知，他就是故意隐瞒事实。比方说，他的精明的印地安专家之一，名叫芝稼哥（我想，该读作芝加哥）的，跟踪一个人，在穿过树林的时候，脚印就找不到了。很明显，脚
归化和异化这对翻译术语是由美国著名翻译理论学家劳伦斯韦努蒂（Lawrence Venuti）于1995年在《译者的隐身》中提出来的。 归化：是要把源语本土化，以目标语或译文读者为归宿，采取目标语读者所习惯的表达方式来传达原文的内容。归化翻译要求译者向目的语的读者靠拢，译者必须像本国作者那样说话，原作者要想和读者直接对话，译作必须变成地道的本国语言。归化翻译有助于读者更好地理解译文，增强译文的可读性和欣赏性。 异化：是“译者尽可能不去打扰作者，让读者向作者靠拢”。在翻译上就是迁就外来文化的语言特点，吸纳外语表达方式，要求译者向作者靠拢，采取相应于作者所使用的源语表达方式，来传达原文的内容，即以目的语文化为归宿。使用异化策略的目的在于考虑民族文化的差异性、保存和反映异域民族特征和语言风格特色，为译文读者保留异国情调。 作为两种翻译策略，归化和异化是对立统一，相辅相成的，绝对的归化和绝对的异化都是不存在的。在广告翻译实践中译者应根据具体的广告语言特点、广告的目的、源语和目的语语言特点、民族文化等恰当运用两种策略，已达到具体的、动态的统一。 归化、异化、意译、直译 从历史上看，异化和归化可以视为直译和意译的概念延伸，但又不完全等同于直译和意译。直译和意译所关注的核心问题是如何在语言层面处理形式和意义，而异化和归化则突破了语言因素的局限，将视野扩展到语言、文化和美学等因素。按韦努蒂（Venuti）的说法，归化法是“把原作者带入译入语文化”，而异化法则是“接受外语文本的语言及文化差异，把读者带入外国情景”。（Venuti，1995:20）由此可见，直译和意译主要是局限于语言层面的价值取向，异化和归化则是立足于文化大语境下的价值取向，两者之间的差异是显而易见的，不能混为一谈。 归化和异化并用互补、辩证统一 有些学者认为归化和异化，无论采取哪一种都必须坚持到底，不能将二者混淆使用。然而我们在实际的翻译中，是无法做到这么纯粹的。翻译要求我们忠实地再现原文作者的思想和风格，而这些都是带有浓厚的异国情调的，因此采用异化法是必然；同时译文又要考虑到读者的理解及原文的流畅，因此采用归化法也是必然。选取一个策略而完全排除另一种策略的做法是不可取的，也是不现实的。它们各有优势，也各有缺陷，因此顾此失彼不能达到最终翻译的目的。 我们在翻译中，始终面临着异化与归化的选择，通过选择使译文在接近读者和接近作者之间找一个“融会点”。这个“融会点”不是一成不变的“居中点”，它有时距离作者近些，有时距离读者近些，但无论接近哪
In return作为（对某物）的付款或回报What do we give them in return. Conceive of 想像、认为 I laughed to myself at the men and the ladies. Who never conceived of us billion-dollar Babies（俚语：人）。 对于那些认为我们从不会成为腰缠万贯的巨富的先生和女士们，我们总是暗自嘲笑他们。 Scores of很多 Scores of young people. Strike sb. as … 给某人留下印象 These conclusion strike me as reasonable. 我认为他们的话是合情合理的 Drop out 脱离传统社会 Ever since自从 In hopes of 怀着…希望 Every since civilization began，certain individuals（人）have tried to run away from it in hopes of finding a simpler，more pastoral，and more peaceful life Support oneself自食其力 Run out of没有，用完，耗尽 Our planet is running out of noble savages and unsullied landscapes. 我们地球上高尚的野蛮人和未玷污的地方越来越少 the other way （round）相反 come off 成功 These are the ones whose revolutions did not come off. In need of 需要 It dawns on a familiar，workaday place，still in need of groceries and sewage disposal. 它洒在一个司空见惯，平凡庸碌的地方，一个仍然无法摆脱食品杂货，污水处理的地方。 In short supply供应不足，短缺 Break down瓦解，崩溃 Broke down our resolve. 丧失了我们的决心 Out of work失业 dawn on sb. 逐渐明白 It dawned on us rather suddenly that the number of passengers on the small spaceship we inhabit is doubling about every forty years. Come down （from…）（to…）从一处来到另一处 Eat sth. up 吃光 In profusion 大量地 She had magnificent blonde hair，in profusion. Take a shot猜测 As a point of departure 起点 As doctors often do I take a trial shot at it as a point of departure. 作为医生我经常根据猜测可能出现的总是进行提问 as yet到现在为止 As yet,no man has set foot on Mars. 到目前为止还没有人登上火星。 Get somewhere 有进展，取得一些成就 If only 只要 If only they wouldn‘t use the word “hurt” I might be able to get somewhere. Up to sb.取决于某人