[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Internet Draft -- IPsec Architecture
Network Working Group Stephen Kent, BBN Corp
Internet Draft Randall Atkinson, @Home Network
draft-ietf-ipsec-arch-sec-01.txt 30 July 1997
Security Architecture for the Internet Protocol
Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its working groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of 6 months.
Internet Drafts may be updated, replaced, or obsoleted by other
documents at any time. It is not appropriate to use Internet Drafts
as reference material or to cite them other than as "work in
progress". Please check the I-D abstract listing contained in each
Internet Draft directory to learn the current status of this or any
other Internet Draft.
This particular Internet Draft is a product of the IETF's IP Security
(IPsec) working group. It is intended that a future version of this
draft be submitted to the IESG for publication as a Draft Standard
RFC. Comments about this draft may be sent to the authors or to the
IPsec WG mailing list <ipsec@tis.com>. Distribution of this document
is unlimited.
Kent, Atkinson [Page 1]
Internet Draft Security Architecture for IP 30 July 1997
Table of Contents
1. Introduction............................................................4
1.1 Summary of Contents of Document.....................................4
1.2 Audience -- assumptions about background knowledge..................4
1.3 Related Documents...................................................4
2. Design Objectives (how this system fits into the IP environment)........5
2.1 Goals/Objectives/Requirements/Problem Description...................5
2.2 Caveats and Assumptions.............................................5
3. System Overview ........................................................5
3.1 What IPSEC Does.....................................................6
3.2 How IPSEC Works.....................................................6
3.3 Where IPSEC May Be Implemented......................................7
4. Security Associations...................................................8
4.1 Definition and Scope................................................8
4.2 Security Association Functionality..................................9
4.3 Combining Security Associations....................................10
4.4 Security Association Processing....................................11
4.4.1 The Security Policy Database (SPD)............................11
4.4.2 Security Association Outbound Processing......................12
4.4.3 Selectors.....................................................13
4.4.4 Security Association Database (SAD)...........................14
4.5 Basic Combinations of Security Associations........................15
4.6 SA Establishment...................................................17
4.6.1 Manual Techniques.............................................17
4.6.2 Automatic Techniques -- Key Mgt Protocol Requirements.........18
4.6.3 Locating a security gateway...................................18
4.7 Security Associations and Multicast................................20
5. Processing IPSEC Traffic...............................................
5.1 Processing Outbound IPsec Traffic..................................
5.1.1 Mapping to an SA or a bundle of SAs...........................
5.1.2 Header construction for tunnel mode...........................
5.1.2.1 IPv4 -- Header construction for tunnel mode..............
5.1.2.2 IPv6 -- Header construction for tunnel mode..............
5.2 Processing Inbound IPsec Traffic...................................
6. ICMP processing (relevant to IPsec)....................................
6.1 PMTU/DF processing.................................................
6.1.1 DF bit........................................................
6.1.2 Path MTU Discovery (PMTU).....................................
6.1.2.1 Propagation of PMTU......................................
6.1.2.2 Calculation of PMTU......................................
6.1.2.3 Granularity of PMTU processing...........................
6.1.2.4 PMTU Aging...............................................
7. Algorithm Descriptions.................................................
8. Usage Scenarios........................................................
9. Auditing...............................................................
10. Use in systems supporting information flow security...................
11. Performance Issues....................................................
12. Conformance Requirements..............................................
13. Security Considerations...............................................
14. Differences from RFC 1825.............................................
Kent, Atkinson [Page 2]
Internet Draft Security Architecture for IP 30 July 1997
Acknowledgements..........................................................
Appendix A -- Glossary....................................................
A.1. Relevant Network Security Terminology.............................
A.2 Requirements Terminology...........................................
Appendix B -- Analysis/Discussion of PMTU/DF/Fragmentation Issues.........
B.1 DF bit.............................................................
B.2 Fragmentation......................................................
B.3 Path MTU Discovery.................................................
B.3.1 Identifying the Originating Host(s)...........................
B.3.2 Calculation of PMTU...........................................
B.3.3 Granularity of Maintaining PMTU Data..........................
B.3.4 Per Socket Maintenance of PMTU Data...........................
B.3.5 Delivery of PMTU Data to the Transport Layer..................
B.3.6 Aging of PMTU Data............................................
Appendix C - Sequence Space Window Code Example...........................
References................................................................
Disclaimer................................................................
Author Information........................................................
Kent, Atkinson [Page 3]
Internet Draft Security Architecture for IP 30 July 1997
1. Introduction
1.1 Summary of Contents of Document
This memo specifies the architecture of a system aimed at providing
security for traffic at the IP layer, both IPv4 and IPv6. This
document describes the goals of the system, its components and how
they fit together with each other and into the IP environment. It
also describes the security services offered by the IPsec protocols,
and how these services can be used in the IP environment. The
following fundamental components of IPsec security architecture are
discussed in terms of their underlying, required functionality.
Additional RFCs (see Section 1.3 for pointers to other documents)
define the protocols in (a), (c), and (d).
a. Security Protocols -- Authentication Header (AH) and
Encapsulating Security Payload (ESP)
b. Security Associations -- what they are and how they work,
how they are managed, associated processing
c. Key Management -- manual and automatic (Oakley/ISAKMP)
d. Algorithms for authentication and encryption
This document is not an overall Security Architecture for the
Internet; it addresses security only at the IP layer, provided
through the use of a combination of cryptographic and protocol
security mechanisms.
[This version of the document is a VERY ROUGH DRAFT and requires
considerable additional work.]
1.2 Audience
The target audience for this document includes implementers of this
IP security technology and others interested in gaining a general
background understanding of this system. In particular, prospective
users of this technology (end users or system administrators) are
part of the target audience. A glossary is provided as an appendix
to help fill in gaps in background/vocabulary. This document assumes
that the reader is familiar with the Internet Protocol, related
networking technology, and general security terms and concepts.
1.3 Related Documents
As mentioned above, other documents provide detailed definitions of
some of the components of IPsec and of their inter-relationship.
They include RFCs on the following topics:
a. "IP Security Document Roadmap" -- a document providing
guidelines for specifications describing encryption and
authentication algorithms used in this system.
b. security protocols -- RFCs describing the Authentication
Kent, Atkinson [Page 4]
Internet Draft Security Architecture for IP 30 July 1997
Header (AH) and Encapsulating Security Payload (ESP) protocols.
c. algorithms for authentication and encryption -- a separate
RFC for each algorithm
d. automatic key management, e.g., an RFC on Oakley/ISAKMP
2. Design Objectives
2.1 Goals/Objectives/Requirements/Problem Description
IPsec is designed to provide interoperable, high quality,
cryptographically-based security for IPv4 and IPv6. The set of
security services offered includes access control, connectionless
integrity, data origin authentication, protection against replays (a
form of partial sequence integrity), confidentiality (encryption),
and limited traffic flow confidentiality. These services are
provided at the IP layer, offering protection for IP and/or upper
layer protocols.
These objectives are met through the use of two traffic security
protocols, the Authentication Header (AH) and the Encapsulating
Security Payload (ESP), and through the use of cryptographic key
management procedures and protocols. The set of IPsec protocols
employed in any context, and the ways in which they are employed,
will be determined by the security and system requirements of users,
applications, and/or sites/organizations
When these mechanisms correctly implemented and deployed, they ought
not adversely affect users, hosts, and other Internet components that
do not employ these security mechanisms for protection of their
traffic. These mechanisms also are designed to be algorithm-
independent. This modularity permits selection of different sets of
algorithms without affecting the other parts of the implementation.
For example, different user communities may select different sets of
algorithms (creating cliques) if required.
A standard set of default algorithms is specified to facilitate
interoperability in the global Internet. The use of these
algorithms, in conjunction with IPsec traffic protection and key
management protocols, is intended to permit system and application
developers to deploy high quality, Internet layer, cryptographic
security technology.
2.2 Caveats and Assumptions
[To be supplied]
3. System Overview
This section provides a high level description of how IPsec works,
the components of the system, and how they fit together to provide
Kent, Atkinson [Page 5]
Internet Draft Security Architecture for IP 30 July 1997
the security services noted above. The goal of this description is
to enable the reader to "picture" the overall process/system, see how
it fits into the IP environment, and to provide context for later
sections of this document, which describe each of the components in
more detail.
3.1 What IPSEC Does
IPsec provides security services at the IP layer by enabling a system
to select required security protocols, determine the algorithm(s) to
use for the service(s), and put in place any cryptographic keys
required to provide the requested services. IPsec can be used to
protect paths between a pair of hosts, between a pair of security
gateways, or between a security gateway and a host. (The term
"security gateway" is used throughout the IPsec documents to refer to
an intermediate system that implements IPsec protocols. For example,
a router or a firewall implementing IPsec is a security gateway.)
The set of security services that IPsec can provide includes access
control connectionless integrity, data origin authentication,
protection against replays (providing a form of partial sequence
integrity), confidentiality (encryption), and limited traffic flow
confidentiality. Because these services are provided at the IP
layer, they can be used by any higher layer protocol, e.g., TCP, UDP,
ICMP, BGP, etc.
NOTE: When encryption is employed within IPsec, it prevents effective
compression by lower protocol layers. However, IPsec does not
provide its own compression services. Such services may be provided
by existing higher layer protocols, or, in the future, in IP itself.
The IETF working group, "IP Payload Compression Protocol (ippcp)" has
the charter to "develop protocol specifications that make it possible
to perform lossless compression on individual payloads before the
payload is processed by a protocol that encrypts it. These
specifications will allow for compression operations to be performed
prior to the encryption of a payload by such protocols as IPSec."
3.2 How IPSEC Works
IPsec uses two protocols to provide traffic security --
Authentication Header (AH) and Encapsulating Security Payload (ESP).
Both protocols are described in more detail below in Section 5
("Security Protocols") and in complete detail in their respective
RFCs [KA97a, KA97b].
o The IP Authentication Header (AH) [KA97a] provides
connectionless integrity, data origin authentication, and an
optional anti-replay service (a form of partial sequence integrity).
o The Encapsulating Security Payload (ESP) header/protocol provides
confidentiality (encryption), and limited traffic flow
confidentiality. It also may provide connectionless
Kent, Atkinson [Page 6]
Internet Draft Security Architecture for IP 30 July 1997
integrity, data origin authentication, an optional
anti-replay service (a form of partial sequence integrity).
o Both AH and ESP are vehicles for access control, based on
the distribution of cryptographic keys and the management of
traffic flows relative to these security protocols.
These protocols may be applied alone or in combination with the each
other to provide desired sets of security services in IPv4 and IPv6.
They support two modes of use: transport mode and tunnel mode. In
transport mode the protocols provide protection primarily for upper
layer protocols; in tunnel mode, the protocols are applied to a
tunneled IP packet. The differences between the two modes are
discussed in Section 4.
IPsec allows the user (or system administrator) to control the
granularity at which a service is offered. For example, one can
create a single encrypted tunnel to carry all traffic between two
security gateways or a separate encrypted tunnel can be created for
each TCP connection between each pair of hosts communicating across
these gateways. IPsec management incorporates facilities for
specifying:
o which security services to use and in what combinations
o the granularity at which a given security protection should be
applied
o the algorithms used to effect cryptographic-based security
Because these security services use shared secret values
(cryptographic keys), IPsec relies on a separate set of mechanisms
for putting these keys in place. (The keys are used for
authentication and for encryption services.) This document requires
support for both manual and automatic distribution of keys. It
specifies a specific public-key based approach (Oakley/ISAKMP
[Reference???]) for automatic key management, but other automated key
distribution techniques could be used. For example, KDC-based
systems such as Kerberos and other public-key systems such as SKIP
could be employed.
3.3 Where IPSEC May Be Implemented
There are several ways in which IPsec may be implemented in hosts or
in conjunction with routers or firewalls (to create a security
gateway). Several common examples are provided below:
a. Integration of IPSEC into the native IP implementation.
This requires access to the IP source code and is applicable
to both hosts and security gateways.
b. "Bump-in-the-stack" (BITS) implementations, where IPSEC is
implemented "underneath" an existing implementation of an
IP protocol stack, between the native IP and the local
Kent, Atkinson [Page 7]
Internet Draft Security Architecture for IP 30 July 1997
network drivers. Source code access for stack is not
required in this context, making it appropriate for use
with legacy systems. This is generally assumed to be
implemented in hosts.
c. The use of an outboard crypto processor is a common design
feature of network security systems used by the military,
and of some commercial systems as well. It is sometimes
referred to as a "Bump-in-the-wire" (BITW) implementation.
Such implementations may be designed to serve either a host
or a gateway (or both). Usually the device is IP addressable.
When supporting a single host, it may be quite analogous to
a BITS implementation, but in supporting a router or
firewall, it is more like a security gateway.
4. Security Associations
This section defines Security Association management requirements for
all IPv6 implementations and for those IPv4 implementations that
implement AH, ESP, or both. The concept of a "Security Association"
(SA) is fundamental to IPsec. Both AH and ESP make use of SAs and a
major function of Oakley/ISAKMP is the establishment and maintenance
of Security Associations. All implementations of AH or ESP MUST
support the concept of a Security Association as described below.
The remainder of this section describes various aspects of Security
Association management, defining required characteristics for SA
policy management, traffic processing, and SA management techniques.
4.1 Definition and Scope
A Security Association (SA) is a simplex "connection" that affords
security services to the traffic carried by it. Security services
are afforded to an SA by the use of AH, or of ESP, but not both. If
both AH and ESP protection is applied to a traffic stream, then two
(or more) SAs are created to afford protection to the traffic stream.
To secure typical, bi-directional communication between two hosts (or
between two security gateways), two Security Associations (one in
each direction) are required.
The combination of a Security Parameter Index (SPI), a Destination
Address, and the security protocol identifier uniquely identifies a
Security Association. In principle, the Destination Address may be a
unicast address, an IP broadcast address, or a multicast group
address. However, IPsec SA management mechanisms currently are
defined only for unicast SAs. Hence, in the discussions that follow,
SAs will be described in the context of point-to-point communication,
even though the concept is applicable in the point-to-multipoint case
as well.
As noted above, two types of SAs are defined: transport mode and
tunnel mode. A transport mode SA is a security association between
Kent, Atkinson [Page 8]
Internet Draft Security Architecture for IP 30 July 1997
two hosts. The security protocol header appears immediately after
the IP header (and any options or extensions), and before any higher
layer protocols (e.g., TCP or UDP). In the case of ESP, a tunnel
mode SA provides security services only for these higher layer
protocols, not for the IP header. In the case of AH, the protection
is also extended to selected portions of the IP header (and options).
For more details on the coverage afforded by AH, see the AH
specification [KA97b].
A tunnel mode SA is essentially an SA applied to an IP tunnel.
Whenever either end of a security association is a security gateway,
the SA MUST be tunnel mode. So, an SA between two security gateways
is always a tunel mode SA, as is an SA between a host and a security
gateway. Two hosts MAY establish a tunnel mode SA between them. An
SA involving a security gateway must be a tunnel SA to avoid
potential problems with regard to fragmentation and reassembly, and
in circumstances where multiple paths (e.g., via different routers or
firewalls) exist to the same destination (behind the security
gateway).
For a tunnel mode SA, there is an "outer" IP header that specifies
the IPsec processing destination, plus an "inner" IP header that
specifies the (apparently) ultimate destination for the packet. The
security protocol header appears after the outer IP header, and
before the inner IP header. If AH is employed in tunnel mode,
portions of the outer IP header are afforded protection (as above),
as well as all of the tunneled IP packet (i.e., all of the inner IP
header is protected, as well as higher layer protocols). If ESP is
employed, the protection is afforded only to the tunneled packet, not
to the outer header.
4.2 Security Association Functionality
The set of security services offered by an SA depends on the security
protocol selected, the SA mode, the endpoints of the SA, and on the
election of optional services within the protocol. For example, AH
provides data origin authentication and connectionless integrity for
IP datagrams (hereafter referred to as just "authentication"). The
"precision" of the authentication service is a function of the
granularity of the security association with which AH is employed, as
discussed in Section 4.??.
AH also offers an anti-replay (partial sequence integrity) service at
the discretion of the receiver, to counter denial of service attacks.
AH is an appropriate protocol to employ when confidentiality is not
required (or is not permitted, e.g , due to government restrictions
on encryption). AH also provides authentication for selected
portions of the IP header, which may be necessary in some contexts.
For example, if the integrity of an IP option or IPv6 extended header
must be protected en route between sender and receiver, AH can
provide this service.
Kent, Atkinson [Page 9]
Internet Draft Security Architecture for IP 30 July 1997
ESP always provides confidentiality for traffic. It also may
optionally provide authentication (as defined above). If
authentication is negotiated for an ESP SA, the receiver also may
elect to enforce an anti-replay service with the same features as the
AH anti-replay service. The scope of the authentication offered by
ESP is narrower than for AH, i.e., the IP header "below" the ESP
header is not protected. If only the upper layer protocols need to
be authenticated, then ESP is an appropriate choice and is more space
efficient than nested use of AH.
An ESP (tunnel mode) SA between two security gateways can offer
partial traffic flow confidentiality. The use of tunnel mode allows
the inner IP headers to be encrypted, concealing the identities of
the (ultimate) traffic source and destination. Moreover, ESP payload
padding also can be invoked to hide the size of the packets, further
concealing the external characteristics of the traffic. Similar
traffic flow confidentiality services may be offered when a mobile
user is assigned a dynamic IP address in a dialup context, and
establishes a (tunnel mode) ESP SA to a corporate firewall (acting as
a security gateway).
4.3 Combining Security Associations
The IP datagrams transmitted over an individual security association
are afforded protection by exactly one security protocol, either AH
or ESP. Sometimes a security policy may call for a combination of
services and service sitings for a particular traffic flow that is
not achievable with a single SA. In such instances it will be
necessary to employ multiple SAs to implement the required security
policy. The term "security association bundle" or "SA bundle" is
applied to a sequence of SAs through which traffic must be processed
to satisfy a security policy. (Note that the SAs that comprise a
bundle need may terminate at different endpoints.)
Security associations may be combined into bundles in two ways:
transport adjacency and iterated tunneling. Transport adjacency
refers to applying more than one security protocol to the same IP
datagram, without invoking tunneling. This approach to combining AH
and ESP allows for only one level of combination; further nesting
yields no added benefit since the processing is performed at one
IPsec instance the (ultimate) destination. Iterated tunneling refers
to the application of multiple layers of security protocols effected
through tunneling. This approach allows for multiple levels of
nesting, since each tunnel can terminate at a different IPsec site
along the path. These two approaches also can be combined, i.e., an
SA bundle could be constructed from one tunnel mode SA and one or two
transport mode SAs, applied in sequence.
For transport mode SAs, only one ordering of security protocols seems
appropriate. AH is applied to both the upper layer protocols and
(parts of) the IP header. Thus if AH is used in a transport mode, in
Kent, Atkinson [Page 10]
Internet Draft Security Architecture for IP 30 July 1997
conjunction with ESP, AH should appear as the first header after IP,
then ESP. In that context, AH is applied to the ciphertext output of
ESP. In contrast, for tunnel mode SAs, one can imagine uses for
various orderings of AH and ESP.
4.4 Security Association Databases
Many of the details associated with processing IP traffic in an IPsec
implementation are largely a local matter, not subject to
standardization. However, some external aspects of the processing
must be standardized, to ensure interoperability and to provide a
minimum management capability that is essential for productive use of
IPsec. This section describes a general model for processing IP
traffic relative to security associations, in support of these
interoperability and functionality goals.
4.4.1 The Security Policy Database (SPD)
Ultimately, a security association is a management construct used to
enforce a security policy in the IPsec environment. Thus an
essential element of SA processing is an underlying Security Policy
Database (SPD) that specifies what services are to be offered to IP
datagrams and in what fashion. The form of the database and its
interface are outside the scope of this specification. However, this
section does specify certain minimum management functionality that
must be provided, to allow a user or system administrator to control
how IPsec is applied to traffic transmitted or received by a host or
transiting a security gateway.
An SPD must discriminate among traffic that is afforded IPsec
protection and traffic that is allowed to bypass IPsec. For any
(outbound) datagram three processing choices are possible: discard,
bypass, protect. The first choice refers to traffic that is not
allowed to exit the host or traverse the security gateway, at all.
The second choice refers to traffic that is allowed to pass without
IPsec protection. The third choice refers to traffic that is
afforded IPsec protection, and for such traffic the SPD must specify
the security services to be provided, protocols to be employed,
algorithms to be used, etc.
For every IPsec implementation, there MUST be some form of
administrative interface that allows a user or system administrator
to manage the SPD. The form of the management interface is not
specified by this document and may differ for hosts vs. security
gateways, and within hosts the interface may differ for socket-based
vs. BITS implementations. However, this document does specify a
standard set of SPD elements that all IPsec implementations MUST
support.
The SPD contains an ordered list of policy entries that define the
security services, protocols, and algorithms that will be employed
Kent, Atkinson [Page 11]
Internet Draft Security Architecture for IP 30 July 1997
for IP traffic that processed by the IPsec implementation. Each
policy entry is keyed by one or more selectors that define the set of
IP traffic encompassed by this policy entry. The selectors are the
sort of information that could be used to create a socket in a host.
These define the granularity of SAs. Each entry also includes an
indication of whether traffic matching this policy will be bypassed,
discarded, or subject to IPsec processing. Finally, the entry
includes an SA (or SA bundle) specification, listing the IPsec
protocols, modes, and algorithms to be employed, including nesting
requirements. For example, an entry may call for all matching
traffic to be protected by ESP in transport mode using 3DES-CBC with
explicit IV, nested inside of AH in tunnel mode using HMAC/SHA-1.
As described below in Section 4.4.3, selectors may include "wildcard"
entries and hence the selectors for two entries may overlap. Thus,
to ensure consistent, predictable processing, SPD entries must be
ordered.
Note that the SPD does not map traffic to specific SAs or SA bundles.
Instead, it can be thought of as the reference database for security
policy, to be consulted when no existing SA or SA bundle matches the
requirements for traffic. In a host IPsec implementation based on
sockets, the SPD will be consulted whenever a new socket was created,
to determine what, if any, IPsec processing will be applied to the
traffic that will flow on that socket. The SPD also will be
consulted when any IPsec implementation is the target of an SA
establishment request from another IPsec implementation, e.g., using
Oakley/ISAKMP.
An IPsec implementation in a security gateway, BITW or BITS context,
it usually will be necessary to examine every outbound packet to
determine what, Ipsec processing, if any, is needed. In these
instances, a second database is required. The Security Association
Map is the database that maps selectors to existing SAs (or SA
bundles) and will be consulted on a per-packet basis (for outbound
traffic). Section 4.4.2 defines the requirements for this database
4.4.2 Security Association Map (SAM)
The Security Association Map (SAM) is a nominal database used to map
outbound traffic IP to a security association (or to an SA bundle)
when the IPsec implementation does not make use of a socket-based
interface. This likely to be the sort of interface encountered for
most security gateways, BITW and BITS IPsec implementations. This
document does not specify a required form for the database nor an
interface. It provides an illustration of database entries and entry
contents as a guide for implementors.
Like the SPD, this is an ordered database in which each entry is
keyed by one or more selectors that define the granularity of SAs (or
SA bundles). Unlike the SPD, entries in the SAM refer to existing
Kent, Atkinson [Page 12]
Internet Draft Security Architecture for IP 30 July 1997
SAs, or define traffic that is to be bypassed or discarded. Thus
each entry that calls for IPsec processing points to an ordered list
of SAs (to support SA bundles) that will be applied to the traffic.
When SAs are created, an entry is made in the SAM, and when SAs
expire or are otherwise explicitly terminated, entries in the SAM are
deleted. The selectors used in the SAM are the same as those used in
the SPD, and are defined below in Section 4.4.3.
4.4.3 Selectors
An SA (or SA bundle) may be fine-grained or coarse-grained, depending
on the selectors used to define the set of (outbound) traffic for the
SA. For example, all traffic between two hosts may be carried via a
single SA, and afforded a uniform set of security services.
Alternatively, traffic between a pair of hosts might be spread over
multiple SAs, depending on the applications being used (as defined by
the Next Protocol and Port fields), with different security services
offered for different SAs. Similarly, all traffic between a pair of
security gateways could be carried on a single SA, or one SA could be
assigned for each communicating host pair. The following selector
parameters MUST be supported for SA management to facilitate control
of SA granularity:
- Destination IP Address(es): this may be a single IP address
(unicast or multicast group), an enumerated list of addresses,
or a wildcard (mask) address. The last two are required to
support more than one destination system sharing the same SA
(behind a security gateway).
[REQUIRED for all implementations]
- Source IP Address(es): this may be a single IP address, an
enumerated list of addresses, or a wildcard (mask) address. The
last two are required to support more than one source system
sharing the same SA (e.g., behind a security gateway or in a
multihomed host).
[REQUIRED for all implementations]
- UserID: a user identifier from the operating system. (The use
of a User ID as a SA selector is sometimes referred to as
"user-oriented keying.")
[REQUIRED for host implementations, unless the layering of the
implementation precludes access to this information, e.g., a
BITS implementation need not support this selector.]
- Data sensitivity level: (IPSO/CIPSO labels)
[REQUIRED for all systems providing label-based security,
OPTIONAL for all other systems]
- Transport Layer Protocol (formerly Next Protocol): Both the IPv4
"Protocol" and the IPv6 "Next Header" fields may not contain the
Transport Protocol due to the presence of IP extension headers.
Kent, Atkinson [Page 13]
Internet Draft Security Architecture for IP 30 July 1997
These fields could contain a Routing Header, AH, ESP,
Fragmentation Header, Destination Options, Hop-by-hop options,
etc. To address the question of which Protocol/Next-Header to
use when there is more than one, this selector has been defined
to be the Transport Layer Protocol selector. This is based on
the assumption that it is not necessary to allow use (as
selectors) of Protocol or Next Header fields other than the one
containing the Transport Protocol field. It is assumed to be
unlikely that a policy administrator might want to map a
security association to a communication association using a
Protocol or Next Header field with an extension header value.
This means, for example, it will not be possible to specify that
"Any packet with a routing header (which defines a source route)
must be authenticated so that the destination can tell whether
or not to accept the packet."
[REQUIRED for all implementations]
NOTE: To locate the transport protocol, a system has to chain
through the packet headers checking the "Next Protocol" field
until it encounters either one it recognizes as a transport
protocol or until it reaches one that isn't on its list of
extension headers.
- Source and Destination (TCP/UDP) Ports: These may be individual
UPD or TCP port values, an enumerated list of ports, or a
wildcard (mask) port. (The use of the Next Protocol field and
the Source and/or Destination Port fields (in conjunction with
the Source and/or Destination Address fields), as an SA selector
is sometimes referred to as "session-oriented keying.")
[REQUIRED for all implementations]
- IPv6 Priority (from IP header): This may be expressed as ???
[REQUIRED for all systems that implement IPv6]
- IPv6 Flow Label (from IP header): This may be expressed as ???.
The IPv6 spec (RFC 1883) calls for all datagrams for a given
IPv6 Flow Label to have the same Source Address, Destination
Address, Hop-by-hop Options header, and Routing Header. The
Flow Label may be assigned on a per socket basis. It would then
be correlated with the Source/Destination and could be used to
provide finer granularity selection of security association(s).
[REQUIRED for all systems that implement IPv6]
4.4.4 Security Association Database (SAD)
In each IPsec implementation there is a nominal Security Association
Database, in which each entry defines the parameters associated with
one SA. Each entry in the SAD is indexed by a destination IP
address,IPsec protocol type, and SPI, for use in inbound IPsec packet
processing. For outbound processing, entries are pointed to by
entries in the SAM. The following parameters are associated with
Kent, Atkinson [Page 14]
Internet Draft Security Architecture for IP 30 July 1997
each entry in the SAD. This description does not purport to be a
MIB, but only a specification of the minimal data items required to
support an SA in an IPsec implementation.
- Destination IP address: the IPv4 or IPv6 address used as an index
for SA lookup in this database.
[REQUIRED for all implementations]
- IPsec Protocol: AH or ESP. Specifies the IPsec protocol to be
applied to the traffic on this SA.
[REQUIRED for all implementations]
- SPI: the 32-bit value used to distinguish among different SAs
terminating at the same destination and using the same IPsec protocol.
[REQUIRED for all implementations]
- IPsec protocol mode: tunnel or transport. Indicates which mode of
AH or ESP is applied to traffic on this SA.
[REQUIRED for all implementations]
- Replay Protection: selection/non-selection by receiver and window size.
[REQUIRED for all implementations]
- AH Authentication algorithm.
[REQUIRED for AH implementations]
- ESP Encryption algorithm and mode.
[REQUIRED for ESP implementations]
- ESP authentication algorithm. If the authentication service is not
selected, this field will be null.
[REQUIRED for ESP implementations]
- Lifetime of this Security Association: a time interval after
which an SA must be rekeyed or terminated, plus an indication of
which of these actions should occur.
[REQUIRED for all implementations]
4.5 Basic Combinations of Security Associations
There are 4 obvious examples of combinations of security
associations. Support for each of these is required. Note that
there may be other uses of IPSEC; but these appear to be the most
critical ones, ones that all compliant (host/security gateway)
implementations are required to support. The diagrams and text below
describe the basic cases. The legend for the diagrams is:
Kent, Atkinson [Page 15]
Internet Draft Security Architecture for IP 30 July 1997
==== = security association (AH or ESP, transport or tunnel)
---- = connectivity (or if so labelled, administrative boundary)
Hx = host x
SGx = security gateway x
X* = X supports IPSEC
NOTE: The security associations below can be either AH or ESP. The
mode (tunnel vs transport) is determined by the nature of the
endpoints. For host-to-host SAs, the mode can be either transport or
tunnel. For host-to-gateway SAs and gateway-to-gateway SAs the mode
can ONLY be tunnel. Section 5.4, "Required Support for AH and ESP
Combinations", provides additional detail on the required support for
different combinations of IPsec protocols and modes.
Case 1. The case of providing end-to-end security between 2 hosts
across the Internet (or an Intranet).
====================================
| |
H1* ------ (Inter/Intranet) ------ H2*
Case 2. This case includes creating virtual private networks.
===========================
| |
---------------------|---- ---|-----------------------
| | | | | |
| H1 -- (Local --- SG1* |--- (Internet) ---| SG2* --- (Local --- H2 |
| Intranet) | | Intranet) |
-------------------------- ---------------------------
admin. boundary admin. boundary
Case 3. This case takes case 2 and adds end-to-end security between
the sending and receiving hosts
===============================================================
| |
| ========================= |
| | | |
---|-----------------|---- ---|-------------------|---
| | | | | | | |
| H1* -- (Local --- SG1* |-- (Internet) --| SG2* --- (Local --- H2* |
| Intranet) | | Intranet) |
-------------------------- ---------------------------
admin. boundary admin. boundary
Kent, Atkinson [Page 16]
Internet Draft Security Architecture for IP 30 July 1997
Case 4. This covers the situation where a remote host (H1) is using
the Internet to reach an organization's firewall (SG1) and to
then gain access to some server or other machine (H2). The
remote host could be a mobile host (H1) dialing up to a local
PPP/ARA server (not shown) on the Internet and then crossing the
Internet to the home organization's firewall (SG1), etc. The
details of support for this case, (how H1 locates SG1,
authenticates it, and verifies its authorization to represent
H2) are discussed in Section 4.4.3, "Locating a Security
Gateway".
======================================================
| |
|============================== |
|| | |
|| ---|----------------------|---
|| | | | |
H1* ----- (Internet) ------| SG1* ---- (Local ----- H2* |
^ | Intranet) |
| ------------------------------
could be dialup admin. boundary (optional)
to PPP/ARA server
4.6 SA Establishment
4.6.1 Manual Techniques
The simplest form of management is manual management, in which a
person manually configures each system with keying material and
security association management data relevant to secure communication
with other systems. Manual techniques are quite practical in small,
static environments but they do not scale well. It is not a viable
medium-term or long-term approach, but might be appropriate and
useful in some environments in the near-term. For example, a company
could create a Virtual Private Internet (VPI) using IPsec in security
gateways at several sites. If the number of sites is small, and
since all the sites come under the purview of a single administrative
domain, this is likely to be a feasible context for manual management
techniques. In this case, the security gateway might selectively
protect traffic to and from other sites within the organization using
a manually configured key, while not encrypting traffic for other
destinations. It also might be appropriate when only selected
communications need to be secured. A similar argument might apply to
use of IPsec entirely within an organization, for a small number of
hosts and/or gateways. Manual management techniques often employ
statically configured, symmetric keys, though other options also
exist.
Kent, Atkinson [Page 17]
Internet Draft Security Architecture for IP 30 July 1997
4.6.2 Automatic Techniques -- Key Mgt Protocol Requirements
Widespread deployment and use of IP security requires an Internet-
standard, scalable, key management protocol. This protocol should
not be limited to supporting IP security. This protocol should be
compatible with the IETF's DNS Security work and should include the
ability to obtain bootstrapping information (e.g. keys, addresses)
from the Secure DNS as a mandatory-to-implement feature. Signed host
keys to the Domain Name System [EK96] The DNS keys enable the
originating party to authenticate key management messages with the
other key management party using an asymmetric algorithm. A
standards-track key management protocol for use with IP Security MUST
provide the property of "Perfect Forward Secrecy" as a mandatory-to-
implement feature. Further, any standards-track key management
protocol MUST permit the secure negotiation or secure identification
of the Security Association attributes to all parties of that
Security Association.
4.6.3 Locating a Security Gateway
This section discusses the issues relating to how a host learns about
the existence of relevant security gateways and once a host has
contacted these security gateways, how it knows that these are the
correct security gateways.
[NOTE: This topic is still under discussion so the text below
describes the problem and some proposed approaches rather than a
final agreed-upon solution.]
Suppose you have a remote host (H1) which is using the Internet to
gain access to a server or other machine (H2) and there is a primary
security gateway (SG1), e.g., a firewall, through which the H1's
traffic must pass. Suppose also that there is a secondary security
gateway (SG2) available as a backup path. An example of this
situation would be a mobile host (Road Warrior) dialing up to a local
PPP/ARA server on the Internet and then crossing the Internet to the
home organization's firewall (SG1), etc. The following discussion
also applies to the situation where the remote entity setting up the
security associations to SG1 (or SG2) is H1's security gateway (SG3)
acting on behalf of H1.
To support this kind of situation, H1 MUST be able to create a
communication association to H2 that makes use of two SAs -- a tunnel
mode SA from H1 to to SG1 and a transport mode SA from H1 to H2. The
diagram below illustrates this. The legend for the diagram is:
==== = security association (AH or ESP, transport or tunnel)
---- = connectivity (or if so labelled, administrative boundary)
Hx = host x
SGx = security gateway x
X* = X supports IPSEC
Kent, Atkinson [Page 18]
Internet Draft Security Architecture for IP 30 July 1997
======================================================
| |
|============================== |
|| | |
|| ---|----------------------|---
|| | | | |
H1* ----- (Internet) ------|-SG1* ---- (Local ----- H2* |
^ | | Intranet) |
| | | | |
| -----------|-SG2* --------- |
| ------------------------------
could be dialup admin. boundary (optional)
to PPP/ARA server
This situation raises several questions:
1. How does H1 know/learn about the existence of the security
gateway SG1?
2. How does it authenticate SG1, and once it has authenticated
SG1, how does it confirm that SG1 has the "right" to
represent H2?
3. How does SG1 authenticate H1 and verify that H1 is authorized
to contact H2?
4. How does H1 know to use SG2 as an alternate path to H2 when
something disrupts connectivity via SG1?
There are appear to be 2 main instances where this situation would
arise.
1. H1 is the system of an individual associated with the
organization administering SG1/SG2/H2, e.g., an employee. H1
might be remotely accessing a home system H2 through the
firewall SG1 and the H1 to SG1 connection could be part of a
Virtual Private Network.
In this case, it is reasonable for H1 to be pre-configured
with the requisite information about SG1, SG2, and H2. To do
this, H1 MUST have an administrative interface that allows
the user/administrator to specify:
o the SAs to use for a communication association to H2
-- a tunnel mode SA from H1 to SG1 and a transport
mode SA from H1 to H2.
o the SAs to use if the path to H2 via SG1 fails -- a
tunnel mode SA from H1 to SG2 and a transport mode SA
from H1 to H2.
o the requisite information for locating, authenticating,
and verifying the authorization of SG1 and SG2.
2. H1 is the system of a person who's been told about system H2
at the organization administering SG1/H2, but who's otherwise
Kent, Atkinson [Page 19]
Internet Draft Security Architecture for IP 30 July 1997
unconnected to that organization. When H1 tries to contact
H2, several things will need to happen to dynamically provide
H1 with the requisite information:
a) H1 needs to find out about SG1.
b) H1 must have a mechanism that allows it to
authenticate SG1 and verify that SG1 is authorized to
represent H2.
c) SG1 has to have a mechanism to authenticate H1 and
verify that H1 is authorized to contact H2.
d) If the path via SG1 is unusable for some reason, (SG1
is down, source routing, etc.), then H1 must know to
use SG2 and then (b), (c), and (d) apply to SG2.
To address this situation, an approach has been proposed that
uses a new "key exchange" record (KX) in the Secure Domain
Name System (DNS) as a mechanism to allow a host/gateway to
determine the set "of authorised remote key exchanger
systems" for a given destination. (See Randall Atkinson's
Internet Draft, "Key Exchange Delegation Record for the DNS"
for details.)
In both cases:
1. H1 MUST be able to use SG1's public key certificate to
authenticate that the connection is to the real SG1. The
same applies to H1 authenticating SG2.
2. SG1 MUST be able to use H1's public key certificate to
authenticate H1. The same applies to SG2 authenticating H1.
3. SG1 and SG2 MUST be able to check H1's authorization to
contact H2.
NOTE: If H2 were outside the firewall/security gateway perimeter, it
might be possible to handle this situation by use of SSL [need
reference].
4.7 Security Associations and Multicast
The receiver-orientation of the Security Association implies that, in
the case of unicast traffic, the destination system will normally
select the SPI value. By having the destination select the SPI
value, there is no potential for manually configured Security
Associations that conflict with automatically configured (e.g. via a
key management protocol) Security Associations. For multicast
traffic, there are multiple destination systems but a single
destination multicast group, so some system or person will need to
select SPIs on behalf of that multicast group and then communicate
the information to all of the legitimate members of that multicast
group via mechanisms not defined here.
Multiple senders to a multicast group SHOULD use a single Security
Association (and hence Security Parameter Index) for all traffic to
Kent, Atkinson [Page 20]
Internet Draft Security Architecture for IP 30 July 1997
that group when a symmetric cryptographic algorithm is in use. In
that case, the receiver only knows that the message came from a
system knowing the security association data for that multicast
group. A receiver cannot generally authenticate which system sent
the multicast traffic when symmetric algorithms (e.g. DES, IDEA) are
in use. Multicast senders SHOULD use a separate Security Association
for each sender to the multicast group when an asymmetric
cryptographic algorithm is in use. In this last case, the receiver
can know the specific system that originated the message.
Multicast key distribution was an active research area in the
published literature at the time this specification was published.
For multicast groups having relatively few members, manual key
distribution or multiple use of existing unicast key distribution
algorithms such as modified Diffie-Hellman appears feasible. For
very large groups, new scalable techniques will be needed.
5. IPSEC Traffic Processing
5.1 Outbound IPsec Traffic Processing
5.1.1 Selecting an SA or SA Bundle
- socket-based host implementations - SAM-based mapping - sequential
application of SAs to traffic - fragmentation
5.1.2 Header construction for tunnel mode
[There are a variety of unresolved issues here. The text below is
included as a starting place for further discussion. For example,
RFC 1853 may be an appropriate basis for this discussion, for
outbound processing]
This section describes the handling of the inner and outer IP
headers, extension headers, and options for AH and ESP tunnels. This
includes how to construct the encapsulating (outer) IP header, how to
handle fields in the inner IP header, and what other actions should
be taken. This description is based on the situation below with H1
sending IP traffic to H2 and an IPsec tunnel between SG1 and SG2.
==== = security association (AH or ESP, tunnel)
---- = connectivity
Hx = host x
Gx = gateway x
SGx = security gateway x
X* = X supports IPSEC
===========================
| |
| |
Kent, Atkinson [Page 21]
Internet Draft Security Architecture for IP 30 July 1997
H1 -- G1 -- G2 - SG1* -- G3 -- G4 -- G5--- SG2* -- G6 -- G7 -- H2
This processing is a function of:
a) which stage of processing is occurring:
- outbound (the sender at the beginning of the tunnel)
- inbound (the receiver at the end of the tunnel)
b) IP version
c) header/option fields
d) security policy
The tables in the following sub-sections show the handling for the
different header/option fields using the following "actions":
constructed-indep = the value in the outer field is constructed
independently of the value in the inner field.
constructed-calc = for outbound packets, the value in the outer
field is computed from the inner field and possibly some
other information. For inbound packets, the value in
the inner field is computed from the outer field and
possibly some other information.
configured = the derivation of the value in the field is
"configurable" by the administrator to one of several
choices, e.g., outer header's TOS can be (a) "copied"
from the inner field, (b) hardwired by the configuration
to a particular value, (c) "filtered", i.e., the
administrator defines a range such that within (or
outside of) the range, the value in the inner field is
used; and outside (or within) the range, a
configuration-defined value is used.
copied = the value in the outer field is always copied as is
from the inner field.
never copied = the value in the inner field is never copied to
the outer field.
consumed = the outer field is ignored/discarded.
nc = no change.
5.1.2.1 IPv4 -- Header construction for tunnel mode
Kent, Atkinson [Page 22]
Internet Draft Security Architecture for IP 30 July 1997
<-------- How Outer Hdr Relates to Inner Hdr --------->
Outbound Inbound
------------------------------ --------------------
IPv4 Outer hdr Inner hdr Outer header Inner
Header fields
version constructed-indep(11) nc consumed nc
header length constructed-calc nc consumed nc
TOS configured (6) nc consumed nc
total length constructed-calc nc consumed nc
ID constructed-indep nc consumed nc
flags (DF,MF) constructed-calc (8) nc consumed nc
fragmt offset constructed-calc nc consumed nc
TTL configured (7) nc consumed conf (5)
protocol AH, ESP, routing hdr nc consumed nc
checksum constructed-calc nc consumed constr-calc
src address constructed-calc (9) nc consumed nc
dest address constructed-calc (9) nc consumed nc
Options
sec option copied nc consumed nc
loose src route configured (1) nc consumed conf (1)
strict src route configured (1) nc consumed conf (1)
record route configured (10) nc consumed cnstr-calc(10)
timestamp copied nc consumed cnstr-calc (2)
end constructed-calc (3) nc consumed nc
nop constructed-calc (4) nc consumed nc
(1) loose and strict source routing for IPv4 raise several issues:
a) Should source routing information from the inner IP
header be copied to the outer header?
b) If yes, how does SG1 figure out how to construct the
outer IP header, i.e., what part of the source route
comes before SG2 and should be copied to the outer
header?
c) If yes, should SG2 copy the recorded route
information from the outer header to the inner
header?
For IPv4, SG1 can be configured with:
a) 2 choices for outbound processing:
o outer header is constructed from remaining hops in
inner routing header with SG2 as the last
destination. If part of the source route is
"beyond" SG2, then SG1 needs to construct an outer
header containing just the part of the source route
that extends up to SG2, inserting SG2 as the last
hop (destination). [Need to specify how SG1
figures out how much of the source route belongs in
the outer header, e.g., use an ICMP message from
Kent, Atkinson [Page 23]
Internet Draft Security Architecture for IP 30 July 1997
SG2]
o outer routing header is constructed based on
security policy specification for the tunnel.
b) 3 choices for the inbound processing:
o inner routing header is updated to know to skip
over "used" hops in outer header but the recorded
route information is not copied over and the
corresponding information for the "used" hops is
zero'd in the inner header.
o inner routing header is updated to know to skip
over "used" hops in outer header and the recorded
route information is copied over to the inner
header.
o inner routing header is constructed based on
security policy specification for the tunnel.
For IPv6, SG1 can be configured with:
a) 2 choices for outbound processing:
o outer (version 0) routing header is constructed
from remaining hops in inner routing header.
o outer (version 0) routing header is constructed
based on security policy specification for the
tunnel.
b) 3 choices for the inbound processing:
o inner routing header is updated to know to skip
over "used" hops in outer header but the recorded
route information is not copied over and the
locations where the recorded route information
would normally be placed for the "used" hops is
zero'd in the inner header.
o inner routing header is updated to know to skip
over "used" hops in outer header and the recorded
route information is copied over to the inner
header.
o inner routing header is constructed based on
security policy specification for the tunnel.
(2) copy the inner fields to the outer fields. At the tunnel
destination, the inner fields MUST be updated with any
additional information recorded on outside header.
(3) for outside field, this is inserted if needed based on
whatever else was copied. At the tunnel destination, it is
not changed as any changes made to the inner option fields
cannot change the length of an option.
(4) constructed, based on alignment and options copied
(5) [needs to be coordinated between src endpoint and dst
endpoint] The following steps assume that IPSEC does the
decapsulating of the packet and then passes it to the IP
forwarding code where the decrementing of TTL occurs.
Accordingly no decrementing is done in IPSEC.
(a) if the outer TTL was a configured number, leave
inner TTL as is.
Kent, Atkinson [Page 24]
Internet Draft Security Architecture for IP 30 July 1997
(b) if inner TTL was copied to outer field, replace
inner TTL with outer TTL.
(6) [needs to be coordinated between src endpoint and dst
endpoint] Choices = copy from inner header, use configured
value, "filter" (administrator defines a range such that
within (outside of) the range, the inner IP header value is
used; and outside (inside) the range, a
configuration-defined value is used.)
(7) choices = copy from inner header, use configured value.
MUST be consistent with (5).
(8) see Section Y on PMTU/DF.
(9) src and dst addresses depend on the SA, which is used to
determine the dst address which in turn determines which src
address (net interface) is used to forward the packet.
(10) whether to copy the inner fields to outer fields is
"configurable"; but "always" update the inner fields with
the hops (if any) recorded in the outer fields.
(11) the IP version in the encapsulating header can be different
from the value in the inner header.
5.1.2.2 IPv6 -- Header construction for tunnel mode
<-------- How Outer Hdr Relates to Inner Hdr --------->
Outbound Inbound
------------------------------ --------------------
IPv6 Outer hdr Inner hdr Outer header Inner
Header fields
version constr.-indep (11) nc consumed nc
priority configured (6) nc consumed nc
flow id configured (6) nc consumed nc
len constructed-calc nc consumed nc
next header AH,ESP,routing hdr nc consumed nc
hop count configured (7) nc consumed conf (5)
src address constructed-calc(9) nc consumed nc
dest address constructed-calc(9) nc consumed nc
Extension headers
destination options
pad 1 constructed-calc(4) nc consumed nc
pad N constructed-calc(4) nc consumed nc
EID never copied nc consumed nc
hop by hop options
pad 1 constructed-calc(4) nc consumed nc
pad N constructed-calc(4) nc consumed nc
jumbogram copied but adjusted nc consumed nc
fragmentation never copied (12) nc consumed (12) nc
routing configured (1) nc consumed conf (1)
AH/ESP constr.-indep(13) nc consumed nc
(1), (4)-(7), (9), (11) see table notes from Section 4.3.1.4.1,
"IPv4 -- Header construction for tunnel mode"
Kent, Atkinson [Page 25]
Internet Draft Security Architecture for IP 30 July 1997
(12) in tunnelling, the new packet can be fragmented. At the
tunnel end, the outer header should have been removed by
re-assembly.
(13) the outer header is constructed for the tunnel and is not
derived from any inner header AH/ESP
In IPv6 source routing, the system routes the packet (reading the
IPv6 header) until the current router = the destination in the IPv6
header, then the current router processes the next header. At each
router, the next hop in the routing header's chain of source routes
is swapped with the IPv6 destination field; the Segments Left field
is decremented by 1. The system routes the packet onward (goes no
further up the stack) until the Segments Left field is 0. Any
headers that are after the RH are processed only when Segments Left
field is 0. Suppose, you have the sample headers/options below RH =
routing header version 0 (processed by routers listed in RH):
A B
---- ----
IPv6 IPv6
RH AH/ESP
AH/ESP RH
TCP TCP
In case A, the AH/ESP header gets processed only after the packet
reaches the final destination (RH Segments Left = 0). This is the
typical case for end-to-end AH/ESP.
In case B, the AH/ESP header will get processed at every router
listed in the RH (they get copied to the IPv6 header). In a typical
case, the AH/ESP header is validated and replaced with a different
SA(s) at each hop listed in the source route.
5.2 Processing Inbound IPsec Traffic
Processing of inbound IPsec traffic generally is easier that
processing of outbound processing. This is because each inbound IP
datagram to which IPsec processing will be applied is identified by
the appearance of the AH or ESP values in the IP Next Protocol field
(or of AH or ESP as an extension header in the IPv6 context).
Moreover, mapping the IP datagram to the appropriate SA is simplified
because of the presence of the SPI in the AH or ESP header.
- mapping packets to a SAD entry - iterative processing for nested
SAs - reassembly
6. ICMP processing (relevant to IPsec)
- anything other than PMTU issues?
Kent, Atkinson [Page 26]
Internet Draft Security Architecture for IP 30 July 1997
6.1 PMTU/DF processing
6.1.1 DF bit
In cases where a system (host or gateway) adds an encapsulating
header (ESP or AH tunnel), it MUST support the option of copying the
DF bit from the original packet to the encapsulating header (and
processing ICMP PMTU messages). This means that it MUST be possible
to configure the system's treatment of the DF bit (set, clear, copy
from encapsulated header) for each interface. (See Appendix B for
rationale.)
6.1.2 Path MTU Discovery (PMTU)
[This section assumes PMTU processing based on inputs from possibly
untrusted intermediate routers. We must consider whether such
processing is optionally supported, with the alternative of
processing based only on information from trusted routers (see
Richardson I-D on this topic).]
This section discusses IPsec handling for Path MTU Discovery
messages. ICMP PMTU is used here to refer to an ICMP message for:
IPv4:
- Type = 3 (Destination Unreachable)
- Code = 4 (Fragmentation needed and DF set)
- Next-Hop MTU in the low-order 16 bits of the second
word of the ICMP header (labelled "unused" in RFC
792), with high-order 16 bits set to zero
IPv6 (RFC 1885):
- Type = 2 (Packet Too Big)
- Code = 0 (Fragmentation needed and DF set)
- Next-Hop MTU in the 32 bit MTU field of the ICMP6
message
6.1.2.1 Propagation of PMTU
The amount of information returned with the ICMP PMTU message (IPv4
or IPv6) is limited and this affects what selectors are available for
use in further propagating the PMTU information. (See Appendix B for
more detailed discussion of this topic.)
o PMTU message with 64 bits of IPSEC header -- If the ICMP PMTU
message contains only 64 bits of the IPSEC header (minimum for
IPv4), then a security gateway MUST support the following options
on a per SPI/SA basis:
a. if the originating host(s) can be determined, send the PMTU
information to all the possible originating hosts.
Kent, Atkinson [Page 27]
Internet Draft Security Architecture for IP 30 July 1997
b. if the originating host(s) cannot be determined, store the
PMTU with the SA and wait until the next packet(s) arrive
from the originating host(s) for the relevant security
association. If the packet(s) are bigger than the PMTU, drop
the packet(s), and compose ICMP PMTU message(s) with the new
packet(s) and the updated PMTU, and send the ICMP message(s)
about the problem to the originating host(s). Retain the
PMTU information for any message that might arrive subsequently
(until ???)
o PMTU message with >64 bits of IPSEC header -- If the ICMP message
contains more information from the original packet, e.g., the 576
byte minimum for IPv6, then there MAY be enough information to
immediately determine to which host to propagate the ICMP/PMTU
message and to provide that system with a 5-selector pointer for
storing/updating the PMTU. Under such circumstances, a security
gateway MUST generate an ICMP PMTU message immediately upon receipt
of an ICMP PMTU from further down the path.
o Distributing the PMTU to the Transport Layer -- The host mechanism
for getting the updated PMTU to the transport layer is unchanged,
as specified in RFC 1191 (Path MTU Discovery).
6.1.2.2 Calculation of PMTU
The calculation of PMTU from an ICMP PMTU MUST take into account the
addition of any IPSEC header -- ESP or AH transport, or ESP or AH
tunnel. (See Appendix B for discussion of implementation issues.)
6.1.2.3 Granularity of PMTU processing
In hosts, the granularity with which ICMP PMTU processing can be done
differs depending on the implementation situation. Looking at a
host, there are 3 situations that are of interest with respect to
PMTU issues (See Appendix B for detailed discussion of this issue):
a. Integration of IPSEC into the native IP implementation
b. Bump-in-the-stack implementations, where IPSEC is implemented
"underneath" an existing implementation of a TCP/IP protocol
stack, between the native IP and the local network drivers
c. No IPSEC implementation -- This case is included because it
is relevant in cases where a security gateway is sending PMTU
information back to a host.
Only in case (a) can the PMTU data be maintained at the same
granularity as communication associations. In (b) and (c), the IP
layer will only be able to maintain PMTU data at the granularity of
source and destination IP addresses (and optionally ToS), as
described in RFC 1191. This is an important difference, because more
than one communication association may map to the same source and
Kent, Atkinson [Page 28]
Internet Draft Security Architecture for IP 30 July 1997
destination IP addresses, and each communication association may have
a different amount of IPSEC header overhead (e.g., due to use of
different transforms or different algorithms).
Implementation of the calculation of PMTU and support for PTMUs at
the granularity of individual communication associations is a local
matter. However, a socket-based implementation of IPSEC in a host
SHOULD maintain the information on a per socket basis. Bump in the
stack systems MUST pass an ICMP PMTU to the host IP implementation,
after adjusting it for any IPSEC header overhead added by these
systems. The calculation of the overhead SHOULD be determined by
analysis of the SPI and any other selector information present in a
returned ICMP PMTU message.
6.1.2.4 PMTU Aging
In all systems (host or gateway) implementing IPSEC and maintaining
PMTU information, the PMTU associated with a security association
(transport or tunnel) MUST be "aged" and some mechanism put in place
for updating the PMTU in a timely manner, especially for discovering
if the PMTU is smaller than it needs to be. A given PMTU has to
remain in place long enough for a packet to get from the source end
of the security association to the system at the other end of the
security association and propagate back an ICMP error message if the
current PMTU is too big. Systems SHOULD use the approach described
in the Path MTU Discovery document (RFC 1191, Section 6.3), which
suggests periodically resetting the PMTU to the first-hop data-link
MTU and then letting the normal PMTU Discovery processes update the
PMTU as necessary. The period SHOULD be configurable.
7. Algorithm Descriptions
[To be supplied -- refers to separate algorithm documents]
8. Usage Scenarios
[To be supplied. including s subsection on special processing in an
information flow security environment, e.g., MLS hosts and networks.]
9. Auditing
Not all systems that implement IPsec will implement auditing.
However, if a system supports auditing, then the IPsec implementation
MUST also support auditing and MUST allow a system administrator to
enable or disable auditing for IPsec. For the most part, the
granularity of auditing is a local matter. However, several
auditable events are identified in the AH and ESP specifications and
for each of these events a minimum set of information that SHOULD be
included in an audit log is defined. Additional information also MAY
be included in the audit log for each of these events, and additional
events, not explicitly called out in this specification, also MAY
Kent, Atkinson [Page 29]
Internet Draft Security Architecture for IP 30 July 1997
result in audit log entries. There is no requirement for the
receiver to transmit any message to the purported transmitter in
response to the detection of an auditable event, because of the
potential to induce denial of service via such action.
10. Use in systems supporting information flow security
[To be supplied]
11. Performance Issues
The use of IPsec imposes computational performance costs on the hosts
or security gateways that implement these protocols. These costs are
associated with the computation of integrity check values, encryption
and decryption,and added per-packet handling. These per-packet
computational costs will be manifested by increased latency and,
possibly, reduced throughout. Use of security association management
protocols, especially ones that employ public key cryptography, also
adds computational performance costs to use of IPsec. These per-
association computational costs will be manifested in terms of
increased latency in association establishment. For many hosts, it
is anticipated that software-based cryptography will not appreciably
reduce throughput, but hardware may be required for security gateways
(since they represent aggregation points), and for some hosts.
The use of IPsec also imposes bandwidth utilization costs on
transmission, switching, and routing components of the Internet
infrastructure, components not implementing IPsec. This is due to
the increase in the packet size resulting from the addition of AH
and/or ESP headers, ESP tunneling (which adds a second IP header),
and the increased packet traffic associated with key management
protocols. It is anticipated that, in most instances, this increased
bandwidth demand will not noticeably affect the Internet
infrastructure. However, in some instances, the effects may be
significant, e.g., transmission of ESP encrypted traffic over a
dialup link that otherwise would have compressed the traffic.
Note: As discussed above, compression can still employed at layers
above IP. There is an IETF working group (IP Payload Compression
Protocol (ippcp)) working on "protocol specifications that make it
possible to perform lossless compression on individual payloads
before the payload is processed by a protocol that encrypts it. These
specifications will allow for compression operations to be performed
prior to the encryption of a payload by IPsec protocols.
12. Conformance Requirements
[Will be a summary]
Kent, Atkinson [Page 30]
Internet Draft Security Architecture for IP 30 July 1997
13. Security Considerations
[To be supplied]
14. Differences from RFC 1825
[To be supplied]
Acknowledgements
Many of the concepts embodied in this specification were derived from
or influenced by the US Government's SP3 security protocol, ISO/IEC's
NLSP, the proposed swIPe security protocol [SDNS, ISO, IB93, IBK93],
and the work done for SNMP Security and SNMPv2 Security.
For over 2 years, this document has evolved through multiple versions
and iterations. During this time, many people have contributed
significant ideas and energy to the process and the documents
themselves. The authors would like to thank Karen Seo for providing
extensive help in the review, editing, background research, and
coordination for this version of the specification. The authors
would also like to thank the members of the IPSEC and IPng working
groups, with special mention of the efforts of (in alphabetic order):
Steve Bellovin, Steve Deering, James Hughes, Phil Karn, Frank
Kastenholz, Perry Metzger, David Mihelcic, Hilarie Orman, William
Simpson, Harry Varnis, and Nina Yuan.
Kent, Atkinson [Page 31]
Internet Draft Security Architecture for IP 30 July 1997
Appendix A -- Glossary
A.1. Relevant Network Security Terminology
This section provides definitions for several key terms that are
employed in this document. Other documents provide additional
definitions and background information relevant to this technology,
e.g., [VK83, HA94]. Included in this glossary are generic security
service and security mechanism terms, plus IPsec-specific terms.
Access Control
Access control is a security service that prevents unauthorized
use of a resource, including the prevention of use of a resource
in an unauthorized manner. In the IPsec context, the resource to
which access is being controlled often is a network interface on a
host security gateway.
Anti-replay
[See "Integrity" below]
Authentication
This term is used informally to refer to the combination of two
nominally distinct security services, data origin authentication
and connectionless integrity. See the definitions below for each
of these services.
Availability
Availability, when viewed as a security service, addresses the
security concerns engendered by attacks against networks that deny
or degrade service. For example, in the IPsec context, the use of
anti-replay mechanisms in AH and ESP support availability.
Confidentiality
Confidentiality is the security service that protects data from
unauthorized disclosure. The primary confidentiality concern in
most instances is unauthorized disclosure of application level
data, but disclosure of the external characteristics of
communication also can be a concern in some circumstances.
Traffic flow confidentiality is the service addresses this latter
concern by concealing source and destination addresses, message
length, or frequency of communication. In the IPsec context,
using ESP in tunnel mode, especially at a security gateway, can
provide some level of traffic flow confidentiality. (See also
traffic analysis, below.)
Encryption
Encryption is a security mechanism used to transform data from an
intelligible form (plaintext) into an unintelligible form
(ciphertext), to provide confidentiality. The inverse
transformation process is designated "decryption." Oftimes the
term "encryption" is used to generically refer to both processes.
Kent, Atkinson [Page 32]
Internet Draft Security Architecture for IP 30 July 1997
Data Origin Authentication
Data origin authentication is a security service that verifies the
identity of the claimed source of data. This service is usually
bundled with the connectionless integrity service.
Integrity
Integrity is a security service that ensures that modifications to
data are detectable. Integrity comes in various flavors, to
match application requirements. IPsec supports two forms of
integrity: connectionless and a form of partial sequence
integrity. Connectionless integrity is a service that detects
modification of an individual IP datagram, without regard to the
ordering of the datagram in a stream of traffic. The form of
partial sequence integrity offered in IPsec is referred to as
anti-replay integrity, and it detects arrival of duplicate IP
datagrams (within a constrained window). This is in contrast to
connection-oriented integrity, which imposes more stringent
sequencing requirements on traffic, e.g., to be able to detect
lost messages. Although authentication and integrity services
often are cited separately, in practice they are intimately
connected and almost always offered in tandem.
Security Association (SA)
A simplex (uni-directional) logical connection, created for
security purposes. All traffic traversing an SA is provided the
same security processing. In IPsec, an SA is an internet layer
abstraction enforced through the use of AH or ESP.
Security Gateway
A security gateway is an intermediate system that acts as the
communications interface between two networks. The set of hosts
(and nets) on the external side of the security gateway is viewed
as untrusted (or less trusted), while the networks and hosts and
on the internal side are viewed as trusted (or more trusted). The
internal subnets and hosts served by a security gateway are
presumed to be trusted by virtue of sharing a common, local,
security administration. (See "Trusted Subnetwork" below.) In
the IPsec context, a security gateway is a point at which AH
and/or ESP is implemented in order to serve a set of internal
hosts, providing security services for these hosts when they
communicate with external hosts also employing IPsec (either
directly or via another security gateway).
SPI
Acronym for "Security Parameters Index." The combination of an
SPI, a destination address, and a security protocol uniquely
identifies a security association (SA, see above). The SPI is
carried in AH and ESP protocols to select the SA under which a
received packet will be processed. An SPI has only local
significance, as defined by the creator of the SA (usually the
receiver of the packet carrying the SPI); thus an SPI is generally
Kent, Atkinson [Page 33]
Internet Draft Security Architecture for IP 30 July 1997
viewed as an opaque bit string. However, the creator of an SA may
choose to interpret the bits in an SPI to facilitate local
processing.
Traffic Analysis
The analysis of network traffic flow for the purpose of deducing
information that is useful to an adversary. Examples of such
information are frequency of transmission, the identities of the
conversing parties, sizes of packets, flow Identifiers, etc.
[Sch94]
Trusted Subnetwork
A subnetwork containing hosts and routers that trust each other
not to engage in active or passive attacks. There also is an
assumption that the underlying communications channel (e.g., a LAN
or CAN) isn't being attacked by other means.
A.2. Requirements Terminology
In this document, the words that are used to define the significance
of each particular requirement are usually capitalized. These words
are:
MUST
This word or the adjective "REQUIRED" means that implementation of
the item is an absolute requirement of the specification.
SHOULD
This word or the adjective "RECOMMENDED" means that there might
exist valid reasons in particular circumstances to not implement
this item, but the full implications should be understood and the
case carefully weighed before taking a different course.
MAY
This word or the adjective "OPTIONAL" means that this item is
truly optional to implement. For example, one vendor might choose
to include the item because a particular marketplace requires it
or because it enhances the product; another vendor might omit the
same item.
Kent, Atkinson [Page 34]
Internet Draft Security Architecture for IP 30 July 1997
Appendix B -- Analysis/Discussion of PMTU/DF/Fragmentation Issues
B.1 DF bit
In cases where a system (host or gateway) adds an encapsulating
header (e.g., ESP tunnel), should/must the DF bit in the original
packet be copied to the encapsulating header?
Fragmenting seems correct for some situations, e.g., it might be
appropriate to fragment packets over a network with a very small MTU,
e.g., a packet radio network, or a cellular phone hop to mobile node,
rather than propagate back a very small PMTU for use over the rest of
the path. In other situations, it might be appropriate to set the DF
bit in order to get feedback from later routers about PMTU
constraints which require fragmentation. The existence of both of
these situations argues for enabling a system to decide whether or
not to fragment over a particular network "link", i.e., for requiring
an implementation to be able to copy the DF bit (and to process ICMP
PMTU messages), but making it an option to be selected on a per
interface basis. In other words, an administrator should be able to
configure the router's treatment of the DF bit (set, clear, copy from
encapsulated header) for each interface.
B.2 Fragmentation
Fragmentation MUST be done after outbound IPSEC processing. Reassembly
MUST be done before inbound IPSEC processing. The general reasoning is
shown below (delimited by the *******'s).
NOTE: IPSEC always has to figure out what the encapsulating IP header
fields are. This is independent of where you insert IPSEC and is
intrinsic to the definition of IPSEC. Therefore any IPSEC
implementation that is not integrated into an IP implementation must
include code to construct the necessary IP headers (IP2):
o AH-tunnel --> IP2-AH-IP1-Transport-Data
o ESP-tunnel --> IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer
****************************************************************************
Overall, the fragmentation/reassembly approach described above works
for all cases examined.
Kent, Atkinson [Page 35]
Internet Draft Security Architecture for IP 30 July 1997
AH Xport AH Tunnel ESP Xport ESP Tunnel
Implementation approach IPv4 IPv6 IPv4 IPv6 IPv4 IPv6 IPv4 IPv6
----------------------- ---- ---- ---- ---- ---- ---- ---- ----
Hosts (integr w/ IP stack) Y Y Y Y Y Y Y Y
Hosts (betw/ IP and drivers) Y Y Y Y Y Y Y Y
S. Gwy (integr w/ IP stack) Y Y Y Y
Outboard crypto processor *
* If the crypto processor system has its own IP address, then it
is covered by the security gateway case. This box receives
the packet from the host and performs IPSEC processing. It
has to be able to handle the same AH, ESP, and related
IPv4/IPv6 tunnel processing that a security gateway would have
to handle. If it doesn't have it's own address, then it is
similar to the bump-in-the stack implementation between IP and
the network drivers.
The following analysis assumes that:
1. There is only one IPSEC module in a given system's stack.
There isn't an IPSEC module A (adding ESP/encryption and
thus) hiding the transport protocol, SRC port, and DEST port
from IPSEC module B.
2. There are several places where IPSEC could be implemented
(as shown in the table above).
a. Hosts with integration of IPSEC into the native IP
implementation. Implementer has access to the source
for the stack.
b. Hosts with bump-in-the-stack implementations, where
IPSEC is implemented between IP and the local network
drivers. Source access for stack is not available;
but there are well-defined interfaces that allows the
IPSEC code to be incorporated into the system.
c. Security gateways and outboard crypto processors with
integration of IPSEC into the stack.
3. Not all of the above approaches are feasible in all hosts.
But it was assumed that for each approach, there are some
hosts for whom the approach is feasible.
For each of the above 3 categories, there are IPv4 and IPv6, AH
transport and tunnel modes, and ESP transport and tunnel modes -- for
a total of 24 cases (3 x 2 x 4).
Some header fields and interface fields are listed here for ease of
reference -- they're not in the header order, but instead listed to
allow comparison between the columns. (* = not covered by AH
authentication. ESP authentication doesn't cover any headers that
precede it.)
Kent, Atkinson [Page 36]
Internet Draft Security Architecture for IP 30 July 1997
IP/Transport Interface
IPv4 IPv6 (RFC 1122 -- Sec 3.4)
---- ---- ----------------------
Version = 4 Version = 6
Header Len
*TOS Prty,Flow Lbl TOS
Packet Len Payload Len Len
ID ID (optional)
*Flags DF
*Offset
*TTL *Hop Limit TTL
Protocol Next Header
*Checksum
Src Address Src Address Src Address
Dst Address Dst Address Dst Address
Options? Options? Opt
? = AH covers Option-Type and Option-Length, but
not Option-Data.
The results for each of the 24 cases is shown below ("works" = will
work if system fragments after outbound IPSEC processing, reassembles
before inbound IPSEC processing). Notes indicate implementation
issues.
a. Hosts (integrated into IP stack)
o AH-transport --> (IP1-AH-Transport-Data)
- IPv4 -- works
- IPv6 -- works
o AH-tunnel --> (IP2-AH-IP1-Transport-Data)
- IPv4 -- works
- IPv6 -- works
o ESP-transport --> (IP1-ESP_hdr-Transport-Data-ESP_trailer)
- IPv4 -- works
- IPv6 -- works
o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer)
- IPv4 -- works
- IPv6 -- works
b. Hosts (Bump-in-the-stack) -- put IPSEC between IP layer and
network drivers. In this case, the IPSEC module would have to
do something like one of the following for fragmentation and
reassembly.
- do the fragmentation/reassembly work itself and
send/receive the packet directly to/from the network
layer. In AH or ESP transport mode, this is fine. In
AH or ESP tunnel mode where the tunnel is to the
ultimate destination, this is fine. But in AH or ESP
tunnel modes where the tunnel end is different from
the ultimate destination and where the source host is
multi-homed, this approach could result in sub-optimal
Kent, Atkinson [Page 37]
Internet Draft Security Architecture for IP 30 July 1997
routing because the IPSEC module may be unable to
obtain the information needed (LAN interface and
next-hop gateway) to direct the packet to the
appropriate network interface. This is not a problem
if the interface and next-hop gateway are the same for
the ultimate destination and for the tunnel end. But
if they are different, then IPSEC would need to know
the LAN interface and the next-hop gateway for the
tunnel end. (Note: The tunnel end (security gateway)
is highly likely to be on the regular path to the
ultimate destination. But there could also be more
than one path to the destination, e.g., the host could
be at an organization with 2 firewalls. And the path
being used could involve the less commonly chosen
firewall.)
OR
- pass the IPSEC'd packet back to the IP layer where an
extra IP header would end up being pre-pended and the
IPSEC module would have to check and let IPSEC'd
fragments go by.
OR
- pass the packet contents to the IP layer in a form
such that the IP layer recreates an appropriate IP
header
At the network layer, the IPSEC module will have access to
the following selectors from the packet -- SRC address, DST
address, TOS, Next Protocol, and if there's a transport layer
header --> SRC port and DST port. One cannot assume IPSEC
has access to the User ID. It is assumed that the available
selector information is sufficient to figure out the relevant
Security Association(s).
o AH-transport --> (IP1-AH-Transport-Data)
- IPv4 -- works
- IPv6 -- works
o AH-tunnel --> (IP2-AH-IP1-Transport-Data)
- IPv4 -- works
- IPv6 -- works
o ESP-transport --> (IP1-ESP_hdr-Transport-Data-ESP_trailer)
- IPv4 -- works
- IPv6 -- works
o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer)
- IPv4 -- works
- IPv6 -- works
c. Security gateways -- integrate IPSEC into the IP stack
NOTE: The IPSEC module will have access to the following
selectors from the packet -- SRC address, DST address, TOS,
Next Protocol, and if there's a transport layer header -->
Kent, Atkinson [Page 38]
Internet Draft Security Architecture for IP 30 July 1997
SRC port and DST port. It won't have access to the User ID
(only Hosts have access to User ID information.) It also
won't have access to the transport layer information if there
is an ESP header, or if it's not the first fragment of a
fragmented message. It is assumed that the available
selector information is sufficient to figure out the relevant
Security Association(s).
o AH-tunnel --> (IP2-AH-IP1-Transport-Data)
- IPv4 -- works
- IPv6 -- works
o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer)
- IPv4 -- works
- IPv6 -- works
****************************************************************************
B.3 Path MTU Discovery
As mentioned earlier, "ICMP PMTU" refers to an ICMP message used for
Path MTU Discovery.
The legend for the diagrams below in B.3.1 and B.3.3 (but not B.3.2)
is:
==== = security association (AH or ESP, transport or tunnel)
---- = connectivity (or if so labelled, administrative boundary)
.... = ICMP message (hereafter referred to as ICMP PMTU) for
IPv4:
- Type = 3 (Destination Unreachable)
- Code = 4 (Fragmentation needed and DF set)
- Next-Hop MTU in the low-order 16 bits of the second
word of the ICMP header (labelled unused in RFC 792),
with high-order 16 bits set to zero
IPv6 (RFC 1885):
- Type = 2 (Packet Too Big)
- Code = 0 (Fragmentation needed and DF set)
- Next-Hop MTU in the 32 bit MTU field of the ICMP6
Hx = host x
Rx = router x
SGx = security gateway x
X* = X supports IPSEC
B.3.1 Identifying the Originating Host(s)
The amount of information returned with the ICMP message is limited
and this affects what selectors are available to identify security
Kent, Atkinson [Page 39]
Internet Draft Security Architecture for IP 30 July 1997
associations, originating hosts, etc. for use in further propagating
the PMTU information.
In brief... An ICMP message must contain the following information
from the "offending" packet:
- IPv4 (RFC 792) -- IP header plus a minimum of 64 bits
- IPv6 (RFC 1885) -- IP header plus a minimum of 576 bytes
Accordingly, in the IPv4 context, an ICMP PMTU may identify only the
first (outermost) security association. This is because the ICMP
PMTU may contain only 64 bits of the "offending" packet beyond the IP
header, which would capture only the first SPI from AH or ESP. In
the IPv6 context, an ICMP PMTU will probably provide all the SPIs and
the selectors in the IP header, but maybe not the SRC/DST ports (in
the transport header) or the encapsulated (TCP, UDP, etc.) protocol.
Moreover, if ESP is used, the transport ports and protocol selectors
may be encrypted.
Looking at the diagram below of a security gateway tunnel (as
mentioned elsewhere, security gateways do not use transport mode)...
H1 =================== H3
\ | | /
H0 -- SG1* ---- R1 ---- SG2* ---- R2 -- H5
/ ^ | \
H2 |........| H4
Suppose that the security policy for SG1 is to use a single SA to SG2
for all the traffic between hosts H0, H1, and H2 and hosts H3, H4,
and H5. And suppose H0 sends a data packet to H5 which causes R1 to
send an ICMP PMTU message to SG1. If the PMTU message has only the
SPI, SG1 will be able to look up the SA and find the list of possible
hosts (H0, H1, H2); but SG1 will have no way to figure out that H0
sent the traffic that triggered the ICMP PMTU message.
Kent, Atkinson [Page 40]
Internet Draft Security Architecture for IP 30 July 1997
original after IPSEC ICMP
packet processing packet
-------- ----------- ------
IP-3 header (S = R1, D = SG1)
ICMP header (includes PMTU)
IP-2 header IP-2 header (S = SG1, D = SG2)
ESP header minimum of 64 bits of ESP hdr (*)
IP-1 header IP-1 header
TCP header TCP header
TCP data TCP data
ESP trailer
(*) The 64 bits will include enough of the ESP (or AH) header to
include the SPI.
- ESP -- SPI (32 bits), unknown (32 bits) -- could be
the optional Replay counter but one can't be sure.
- AH -- Next header (8 bits), Payload Len (8 bits),
Reserved (16 bits), SPI (32 bits)
This limitation on the amount of information returned with an ICMP
message creates a problem in identifying the originating hosts for
the packet (so as to know where to further propagate the ICMP PMTU
information). If the ICMP message contains only 64 bits of the IPSEC
header (minimum for IPv4), then the 5 original IPSEC selectors will
have been lost -- Source and Destination addresses, Next Protocol,
Source and Destination ports. But the ICMP error message will still
provide SG1 with the SPI, the PMTU information and the source and
destination gateways for the relevant security association.
The destination security gateway and SPI uniquely define a security
association which in turn defines a set of possible originating
hosts. At this point, SG1 could:
a. send the PMTU information to all the possible originating hosts.
This would not work well if the host list is a wild card or if
many/most of the hosts weren't sending to SG1; but it might work
if the SPI/destination/etc mapped to just one host.
b. store the PMTU with the SPI/etc and wait until the next packet(s)
arrive from the originating host(s) for the relevant security
association. If it/they are bigger than the PMTU, drop the
packet(s), and compose ICMP PMTU message(s) with the new
packet(s) and the updated PMTU, and send the originating host(s)
the ICMP message(s) about the problem. This involves a delay in
notifying the originating host(s), but avoids the problems of (a).
Since only the latter approach is feasible in all instances, a
security gateway MUST provide such support, as an option. However,
if the ICMP message contains more information from the original
packet, e.g., the 576 byte minimum for IPv6, then there MAY be enough
information to immediately determine to which host to propagate the
ICMP/PMTU message and to provide that system with a 5-selector
Kent, Atkinson [Page 41]
Internet Draft Security Architecture for IP 30 July 1997
pointer for storing/updating the PMTU. Under such circumstances, a
security gateway MUST generate an ICMP PMTU message immediately upon
receipt of an ICMP PMTU from further down the path. NOTE: The Next
Protocol field MAY not be contained in the 576 bytes and the use of
ESP encryption MAY hide the selector fields that have been encrypted.
B.3.2 Calculation of PMTU
The calculation of PMTU from an ICMP PMTU has to take into account
the addition of any IPSEC header by H1 -- ESP or AH transport, or ESP
or AH tunnel. Within a single host, multiple applications may share
an SPI and nesting of security associations may occur. The diagram
below illustrates several possible combinations of security
associations between a pair of hosts (as viewed from the perspective
of one of the hosts.) (ESPt or AHt = tunnel mode; ESPx or AHx =
transport mode)
Socket 1 ----------------------------------------------- I
| n
Socket 2 (ESPt/SPI-A) ------------------------------- | t
\| e
Socket 3 (AHx/SPI-B, ESPt/SPI-C) --- AHx (SPI-D) --- ESPt (SPI-E)--r
/ n
Socket 4 (ESPx/SPI-F, ESPt/SPI-G) -- ESPx (SPI-H) --- e
t
In order to figure out the PMTU for each socket that maps to SPI-E,
it will be necessary to have backpointers from SPI-E to each of the 4
paths that lead to it -- Socket 1, SPI-A, SPI-D, and SPI-H.
B.3.3 Granularity of Maintaining PMTU Data
In hosts, the granularity with which PMTU ICMP processing can be done
differs depending on the implementation situation. Looking at a
host, there are 3 situations that are of interest with respect to
PMTU issues:
a. Integration of IPSEC into the native IP implementation
b. Bump-in-the-stack implementations, where IPSEC is implemented
"underneath" an existing implementation of a TCP/IP protocol
stack, between the native IP and the local network drivers
c. No IPSEC implementation -- This case is included because it is
relevant in cases where a security gateway is sending PMTU
information back to a host.
Only in case (a) can the PMTU data be maintained at the same
granularity as communication associations. In the other cases, the
IP layer will maintain PMTU data at the granularity of Source and
Destination IP addresses (and optionally ToS), as described in RFC
1191. This is an important difference, because more than one
communication association may map to the same source and destination
Kent, Atkinson [Page 42]
Internet Draft Security Architecture for IP 30 July 1997
IP addresses, and each communication association may have a different
amount of IPSEC header overhead (e.g., due to use of different
transforms or different algorithms). The examples below illustrate
this.
In cases (a) and (b)... Suppose you have the following situation.
H1 is sending to H2 and the packet to be sent from R1 to R2 exceeds
the PMTU of the network hop between them.
==================================
| |
H1* --- R1 ----- R2 ---- R3 ---- H2*
^ |
|.......|
If R1 is configured to not fragment subscriber traffic, then R1 sends
an ICMP PMTU message with the appropriate PMTU to H1. H1's
processing would vary with the nature of the implementation. In case
(a) (native IP), the security services are bound to sockets or the
equivalent. Here the IP/IPSEC implementation in H1 can store/update
the PMTU for the associated socket. In case (b), the IP layer in H1
can store/update the PMTU but only at the granularity of Source and
Destination addresses and possibly ToS, as noted above. So the
result may be sub-optimal, since the PMTU for a given SRC/DST/ToS
will be the subtraction of the largest amount of IPSEC header used
for any communication association between a given source and
destination.
In case (c), there has to be a security gateway to have any IPSEC
processing. So suppose you have the following situation. H1 is
sending to H2 and the packet to be sent from SG1 to R exceeds the
PMTU of the network hop between them.
================
| |
H1 ---- SG1* --- R --- SG2* ---- H2
^ |
|.......|
As described above for case (b), the IP layer in H1 can store/update
the PMTU but only at the granularity of Source and Destination
addresses, and possibly ToS. So the result may be sub-optimal, since
the PMTU for a given SRC/DST/ToS will be the subtraction of the
largest amount of IPSEC header used for any communication association
between a given source and destination.
B.3.4 Per Socket Maintenance of PMTU Data
Implementation of the calculation of PMTU (Section B.2.2) and support
for PMTUs at the granularity of individual "communication
associations" (Section B.2.3) is a local matter. However, a socket-
Kent, Atkinson [Page 43]
Internet Draft Security Architecture for IP 30 July 1997
based implementation of IPSEC in a host SHOULD maintain the
information on a per socket basis. Bump in the stack systems MUST
pass an ICMP PMTU to the host IP implementation, after adjusting it
for any IPSEC header overhead added by these systems. The
determination of the overhead SHOULD be determined by analysis of the
SPI and any other selector information present in a returned ICMP
PMTU message.
B.3.5 Delivery of PMTU Data to the Transport Layer
The host mechanism for getting the updated PMTU to the transport
layer is unchanged, as specified in RFC 1191 (Path MTU Discovery).
B.3.6 Aging of PMTU Data
In all systems (host or gateway) implementing IPSEC and maintaining
PMTU information, the PMTU associated with a security association
(transport or tunnel) has to be "aged" and some mechanism put in
place for updating the PMTU in a timely manner, especially for
discovering if the PMTU is smaller than it needs to be. A given PMTU
has to remain in place long enough for a packet to get from the
source end of the security association to the system at the other end
of the security association and propagate back an ICMP error message
if the current PMTU is too big.
Systems SHOULD use the approach described in the Path MTU Discovery
document (RFC 1191, Section 6.3), which suggests periodically
resetting the PMTU to the first-hop data-link MTU and then letting
the normal PMTU Discovery processes update the PMTU as necessary.
The period SHOULD be Configurable.
Kent, Atkinson [Page 44]
Internet Draft Security Architecture for IP 30 July 1997
Appendix C - Sequence Space Window Code Example
This appendix contains a routine that implements a bitmask check for
a 32 packet window. It was provided by James Hughes
(jim_hughes@stortek.com) and Harry Varnis (hgv@anubis.network.com)
and is intended as an implementation example. Note that this code
both checks for a replay and updates the window. Thus the algorithm,
as shown, should only be called AFTER the packet has been
authenticated. Implementers might wish to consider splitting the
code to do the check for replays before computing the ICV. If the
packet is not a replay, the code would then compute the ICV, (discard
any bad packets), and if the packet is OK, update the window.
#include <stdio.h>
#include <stdlib.h>
typedef unsigned long u_long;
enum {
ReplayWindowSize = 32
};
u_long bitmap = 0; /* session state - must be 32 bits */
u_long lastSeq = 0; /* session state */
/* Returns 0 if packet disallowed, 1 if packet permitted */
int ChkReplayWindow(u_long seq);
int ChkReplayWindow(u_long seq) {
u_long diff;
if (seq == 0) return 0; /* first == 0 or wrapped */
if (seq > lastSeq) { /* new larger sequence number */
diff = seq - lastSeq;
if (diff < ReplayWindowSize) { /* In window */
bitmap <<= diff;
while (diff > 1) bitmap &= ~(1 << --diff);
bitmap |= 1; /* set bit for this packet */
} else bitmap = 1; /* This packet has a "way larger" */
lastSeq = seq;
return 1; /* larger is good */
}
diff = lastSeq - seq;
if (diff >= ReplayWindowSize) return 0; /* too old or wrapped */
if (bitmap & (1 << diff)) return 0; /* this packet already seen */
bitmap |= (1 << diff); /* mark as seen */
return 1; /* out of order but good */
}
char string_buffer[512];
#define STRING_BUFFER_SIZE sizeof(string_buffer)
Kent, Atkinson [Page 45]
Internet Draft Security Architecture for IP 30 July 1997
int main() {
int result;
u_long last, current, bits;
printf("Input initial state (bits in hex, last msgnum):0);
if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) exit(0);
sscanf(string_buffer, "%lx %lu", &bits, &last);
if (last != 0)
bits |= 1;
bitmap = bits;
lastSeq = last;
printf("bits:%08lx last:%lu0, bitmap, lastSeq);
printf("Input value to test (current):0);
while (1) {
if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) break;
sscanf(string_buffer, "%lu", ¤t);
result = ChkReplayWindow(current);
printf("%-3s", result ? "OK" : "BAD");
printf(" bits:%08lx last:%lu0, bitmap, lastSeq);
}
return 0;
}
Kent, Atkinson [Page 46]
Internet Draft Security Architecture for IP 30 July 1997
References
[BCCH94] R. Braden, D. Clark, S. Crocker, & C. Huitema, "Report of
IAB Workshop on Security in the Internet Architecture",
RFC-1636, DDN Network Information Center, June 1994.
[Bel89] Steven M. Bellovin, "Security Problems in the TCP/IP
Protocol Suite", ACM Computer Communications Review, Vol.
19, No. 2, March 1989.
[Bel95] Steven M. Bellovin, Presentation at IP Security Working
Group Meeting, Proceedings of the 32nd Internet Engineering
Task Force, March 1995, Internet Engineering Task Force,
Danvers, MA.
[Bel96] Steven M. Bellovin, "Problem Areas for the IP Security
Protocols", Proceedings of the Sixth Usenix Unix Security
Symposium, July, 1996.
[BL73] Bell, D.E. & LaPadula, L.J., "Secure Computer Systems:
Mathematical Foundations and Model", Technical Report M74-
244, The MITRE Corporation, Bedford, MA, May 1973.
[CERT95] CA-95:01
[CB94] William R. Cheswick & Steven M. Bellovin, Firewalls &
Internet Security, Addison-Wesley, Reading, MA, 1994.
[CG96] Shu-jen Chang & Rob Glenn, "HMAC-SHA IP Authentication with
Replay Prevention", Internet Draft, 1 May 1996.
[DIA] US Defense Intelligence Agency, "Compartmented Mode
Workstation Specification", Technical Report DDS-2600-
6243-87.
[DoD85] US National Computer Security Center, "Department of
Defense Trusted Computer System Evaluation Criteria", DoD
5200.28-STD, US Department of Defense, Ft. Meade, MD.,
December 1985.
[DoD87] US National Computer Security Center, "Trusted Network
Interpretation of the Trusted Computer System Evaluation
Criteria", NCSC-TG-005, Version 1, US Department of
Defense, Ft. Meade, MD., 31 July 1987.
[DH76] W. Diffie & M. Hellman, "New Directions in Cryptography",
IEEE Transactions on Information Theory, Vol. IT-22, No. 6,
November 1976, pp. 644-654.
[DH95] Steve Deering & Bob Hinden, Internet Protocol version 6
Kent, Atkinson [Page 47]
Internet Draft Security Architecture for IP 30 July 1997
(IPv6) Specification, RFC-1883, December 1995.
[EK96] D. Eastlake III & C. Kaufman, "Domain Name System Protocol
Security Extensions", Internet Draft, 30 January 1996.
[GM93] J. Galvin & K. McCloghrie, Security Protocols for version 2
of the Simple Network Management Protocol (SNMPv2), RFC-
1446, DDN Network Information Center, April 1993.
[HA94] N. Haller & R. Atkinson, "On Internet Authentication",
RFC-1704, DDN Network Information Center, October 1994.
[Hugh96] J. Hughes (Editor), "Combined DES-CBC, HMAC, and Replay
Prevention Security Transform", Internet Draft, June 1996.
[ISO] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC
DIS 11577, International Standards Organisation, Geneva,
Switzerland, 29 November 1992.
[IB93] John Ioannidis and Matt Blaze, "Architecture and
Implementation of Network-layer Security Under Unix",
Proceedings of USENIX Security Symposium, Santa Clara, CA,
October 1993.
[IBK93] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: Network-
Layer Security for IP", presentation at the Spring 1993
IETF Meeting, Columbus, Ohio
[KA97a] Steve Kent, Randall Atkinson, "IP Authentication Header",
Internet Draft, ?? 1997.
[KA97b] Steve Kent, Randall Atkinson, "IP Encapsulating Security
Payload (ESP)", Internet Draft, ?? 1997.
[Ken91] Steve Kent, US DoD Security Options for the Internet
Protocol, RFC-1108, DDN Network Information Center,
November 1991.
[Ken93] Steve Kent, Privacy Enhancement for Internet Electronic
Mail: Part II: Certificate-Based Key Management, RFC-1422,
DDN Network Information Center, 10 February 1993.
[KB93] J. Kohl & B. Neuman, The Kerberos Network Authentication
Service (V5), RFC-1510, DDN Network Information Center, 10
September 1993.
[NS78] R.M. Needham & M.D. Schroeder, "Using Encryption for
Authentication in Large Networks of Computers",
Communications of the ACM, Vol. 21, No. 12, December 1978,
pp. 993-999.
Kent, Atkinson [Page 48]
Internet Draft Security Architecture for IP 30 July 1997
[NS81] R.M. Needham & M.D. Schroeder, "Authentication Revisited",
ACM Operating Systems Review, Vol. 21, No. 1., 1981.
[OG96] Mike Oehler & Rob Glenn, "HMAC-MD5 IP Authentication with
Replay Prevention", Internet Draft, 1 May 1996.
[OTA94] US Congress, Office of Technology Assessment, "Information
Security & Privacy in Network Environments", OTA-TCT-606,
Government Printing Office, Washington, DC, September 1994.
[Sch94] Bruce Schneier, Applied Cryptography, Section 8.6, John
Wiley & Sons, New York, NY, 1994.
[SDNS] SDNS Secure Data Network System, Security Protocol 3, SP3,
Document SDN.301, Revision 1.5, 15 May 1989, published in
NIST Publication NIST-IR-90-4250, February 1990.
[STD-1] J. Postel, "Internet Official Protocol Standards", STD-1,
March 1996.
[VK83] V.L. Voydock & S.T. Kent, "Security Mechanisms in High-
level Networks", ACM Computing Surveys, Vol. 15, No. 2,
June 1983.
[ZDESZ93] Zhang, L., Deering, S., Estrin, D., Shenker, S., and
Zappala, D., "RSVP: A New Resource ReSerVation Protocol",
IEEE Network magazine, September 1993.
Disclaimer
The views and specification expressed in this document are those of
the authors and are not necessarily those of their employers. The
authors and their employers specifically disclaim responsibility for
any problems arising from correct or incorrect implementation or use
of this design.
Kent, Atkinson [Page 49]
Internet Draft Security Architecture for IP 30 July 1997
Author Information
Stephen Kent
BBN Corporation
70 Fawcett Street
Cambridge, MA 02140
USA
E-mail: kent@bbn.com
Telephone: +1 (617) 873-3988
Randall Atkinson
@Home Network
385 Ravendale Drive
Mountain View, CA 94043
USA
E-mail: rja@inet.org
Kent, Atkinson [Page 50]