[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IPsec Architecture -- proposed changes
Folks,
In response to discussions at Munich and later comments from the working
group, here's a list of proposed changes for the IPsec Architecture
document. (It does not include minor edits -- typos, simple
clarifications, address changes, etc.) Many of these items are offered
for discussion and are not meant to be a final resolutions drawn from
mailing list consensus. Please let us know by 10/13 of any issues we've
missed and any feedback you have on the items below.
Thank you,
Karen
=============================================================================
1. Which documents should contain references to current default
algorithms (mandatory-to-implement)? We currently have:
- AH mandatories in AH, Arch (and DOI).
- ESP mandatories in ESP, Arch (and DOI).
Per discussion on 7/22 between Rodney Thayer, Ted Tso... We propose
to leave the references in the AH, ESP, and Architecture documents.
=============================================================================
2. How should we handle the security gateway problem -- discovery of the
security gateway, verification of its authenticity and authorization,
etc.?
Per discussion at Munich IETF... In section 4.6.3 "Locating a
Security Gateway", we propose to:
- remove the [NOTE: This topic is still under discussion...]
on page 18.
- leave the problem description in place (pages 18-19)
- remove the rest of the section and replace it with:
"To address these problems, a host or security gateway MUST
have an administrative interface that allows the
user/administrator to configure the address of a security
gateway for any sets of destination addresses that require its
use. This includes the ability to configure:
o the SAs to use for a communication association to the
destination host. In the example above, this would
mean 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 the destination host
fails. In the example above, this would mean 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 the relevant
security gateways. In the example above, the relevant
security gateways would be SG1 and SG2.
This document does not address the issue of how to automate
the discovery/verification of security gateways."
=============================================================================
3. How should we handle MLS issues?
Per discussion at the Munich IETF and following up on email to the
list (8/19, Steve Kent), we propose to defer this problem to another
document that will be issued later. The following text will be
included in Section 10. "Use in systems supporting information flow
security":
"The use of IPsec in an MLS environment imposes additional
requirements on IPsec implemntations. A separate document will
address these requirements."
=============================================================================
4. Clarification about using a different SPI when a new SA is created
because of rekeying...
Following up on discussion on the mailing list (8/6, Bill Sommerfeld,
Catherine Gibson, Dan McDonald), we propose to include text in the
section 4.6 "SA Establishment", before 4.6.1 "Manual Techniques" and
4.6.2 "Automatic Techniques -- Key Mgt Protocol Requirements" that
says:
"The rekeying of an SA implies creation of a new SA with a new SPI."
=============================================================================
5. Should the IPsec architecture enable an application, which is using a
single socket to communicate with multiple peers, to use different
security policies for different peers?
From observations by Charlie Lynn -- "UDP sockets may, and do, switch
destination addresses on a packet by packet basis. SAs would also
have to correspondingly change on a packet by packet basis based on
the packet's destination (and maybe other things)...People are
already thinking about how applications might specify security policy
requirements, e.g., the 8/1/97 draft-metz-net-security-api-00.txt,
"Network Security API for Sockets."
To address this concern, we propose to add the following text to
section 4.4.1, "Security Policy Database", paragraph 3, after
sentence 1.
"This interface must allow the user/application to specify a set
of policies that can be invoked on a packet by packet basis for
a single socket, e.g., for UDP traffic. Also, the system
administrator MUST be able to specify whether or not a
user/application can circumvent system policies."
=============================================================================
6. Should AH/ESP be a selector? What should this selector be called?
Per suggestion from Charlie Lynn, we propose that AH and ESP be
allowed as selector inputs, and that the name for this selector be
"IPsec Protocols". A new selector paragraph will be added to section
4.4.3 "Selectors":
"IPsec protocol (AH or ESP or AH/ESP): If present, this is
obtained from the IPv4 "Protocol" field or the IPv6 "Next
Header" field. [REQUIRED for all implementations]
NOTE: These fields could contain a Transport Protocol, Routing
Header, AH, ESP, Fragmentation Header, Destination Options,
Hop-by-hop options, etc. And while IPv6 recommends a particular
order for extension headers, it also specifies that the
implementation must be prepared to accept them in any order. So
to check for the existence of an IPsec header, a system has to
chain through the packet headers checking the Protocol/Next
Header field until it has checked all that are not opaque."
=============================================================================
7. Should the "Transport Protocol" selector be required only for systems
supporting IPv6, and be optional for IPv4?
Per suggestion from the working group and given the proposal to add
IPsec protocol as a selector (see above), we propose to modify the
Transport Protocol paragraphs of section 4.4.3 "Selectors" as
follows:
- At the end of the paragraph on "Transport Protocol", change
"[REQUIRED for all implementations]" to "[REQUIRED for IPv6
implementations, MAY be supported in IPv4 implementations]
- Change the first Transport Protocol paragraph by rewording the
first 2 sentence and deleting the last 3 sentences. Leave
the second paragraph as is. This results in:
"Transport Layer Protocol: Obtained from the IPv4
"Protocol" or the IPv6 "Next Header" fields. These
fields may not contain the Transport Protocol due to the
presence of IP extension headers, e.g., a Routing
Header, AH, ESP, Fragmentation Header, Destination
Options, Hop-by-hop options, etc.
[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."
=============================================================================
8. Additional selector changes -- adding TOS and renaming IPv6
"Priority" to "Class".
Based on discussion at the Munich IETF, we propose to add TOS for
IPv4 as a selector and change the IPv6 Priority field to "Class" to
match the IPv6 spec. This involves changing Section 4.4.3
"Selectors" by:
Adding the text:
"IPv4 Type of Service (TOS): Obtained from IP header
[REQUIRED for all systems that implement IPv4]"
Changing "IPv6 Priority..." to "IPv6 Class..."
=============================================================================
9. Additional warnings that certain selectors may not always be
accessible....
Per suggestion in private email from a working group member, we
propose to make the following changes to section 4.4.3 "Selectors":
Paragraph 1 (An SA (or SA bundle) may be...) after the third
sentence, insert the text:
"In the case of receipt of a packet with an ESP header, e.g., at
an encapsulating security gateway or bump in the wire
implementation, the transport layer protocol and ports may be
opaque, thus making them unavailable for use as selectors."
Paragraph 9 (Source and Destination (TCP/UDP) Ports...) at the
end, add the text:
"Note that the source and destination ports may not be available
in the case of receipt of a packet with an ESP header."
The proposed paragraph from item (7) on "Transport Protocol", add the
text:
"Note that the Transport Protocol may not be available in the
case of receipt of a packet with an ESP header."
=============================================================================
10. How should we handle header copying in tunnel mode?
Per discussion at the Munich IETF, we propose to use an approach
similar to that described in RFC 2003 "IP Encapsulation with IP".
This RFC minimizes the complexity of this problem by generally not
copying options, e.g., source routing. Since RFC 2003 does not
address IPv6 and to avoid having to worry about the text in RFC 2003
that is not needed by the IPsec architecture document, we propose to
write text that is modeled after RFC 2003 rather than to simply refer
the reader to RFC2003.
ICMP processing -- Section 6.1.1 DF bit and 6.1.2 Path MTU
Discovery, leave text as is.
Appendix B "Analysis/Discussion of PMTU/DF/Fragmentation Issues",
leave text as is.
Inbound processing -- Section 5.2 "Processing Inbound IPsec Traffic,
add the text:
"The handling of the inner and outer IP headers, extension
headers, and options for AH and ESP tunnels should be done
as described in the tables in Section 5.1.
Outbound processing -- Section 5.1.2 "Header construction for tunnel
mode",
o Delete the first (parenthetical) paragraph, "There are a
variety..."
o Replace the rest of the section with:
"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. The
general idea is modeled after the one used in RFC 2003,
"IP Encapsulation with IP":
- The outer IP header Source Address and Destination
Address identify the "endpoints" of the tunnel (the
encapsulator and decapsulator). The inner IP header
Source Address and Destination Addresses identify the
original sender and recipient of the datagram,
respectively.
- The inner IP header is not changed except to decrement
the TTL as noted below, and remains unchanged during
its delivery to the tunnel exit point.
- No change to IP options or extension headers in the
inner header occurs during delivery of the
encapsulated datagram through the tunnel.
- If need be, other protocol headers such as the IP
Authentication header [1] may be inserted between the
outer IP header and the inner IP header.
The tables in the following sub-sections show the handling for
the different header/option fields (constructed = the value in
the outer field is constructed independently of the value in
the inner):
5.1.2.1 IPv4 -- Header construction for tunnel mode
<-------- How Outer Hdr Relates to Inner Hdr --------->
IPv4 Outer Hdr at Encapsulator Inner Hdr at Decapsulator
Header fields
version 4 or 6 (1) no change
header length constructed no change
TOS copied from inner hdr no change
total length constructed no change
ID constructed no change
flags (DF,MF) constructed, DF copie no change
fragmt offset constructed no change
TTL copy from inner header (2) copy from outer hdr (2) &
decrement before forwarding decrement before forwarding
protocol AH, ESP, routing hdr no change
checksum constructed no change
src address constructed (3) no change
dest address constructed (3) no change
Options never copied no change
1. The IP version in the encapsulating header can be different
from the value in the inner header.
2. In order to support dynamic (rather than manual) set up of
tunnels, the TTL (or hop count) must be processable by the
receiver without requiring coordination with the sender, etc.
In particular multicast traffic should not require preconfigured
tunnels. The TTL (or hop count) is decremented at each hop
in the tunnel as well as at the encapsulator and
decapsulator.
3. 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.
5.1.2.2 IPv6 -- Header construction for tunnel mode
See previous section 5.1.2 for notes indicated by (#).
<-------- How Outer Hdr Relates to Inner Hdr --------->
IPv6 Outer Hdr at Encapsulator Inner Hdr at Decapsulator
Header fields:
version 6 no change
priority copy or configure no change
flow id copy or configure no change
len construct no change
next header AH,ESP,routing hdr no change
hop count copy from inner hdr (2) & copy from outer hdr (2) &
decrement before forwarding decrement before forwarding
src address constructed (3) no change
dest address constructed (3) no change
Extension headers never copied no change
=============================================================================
11. Multicast clarification.
Following up on discussion at the Munich IETF, we propose to modify
Section 4.7 "Security Associations and Multicast":
a) delete the last 2 sentences of paragraph 2, which describe
the case of using asymmetric cryptographic algorithsm.
b) replace the third paragraph with "Other cases of multicast
will be addressed in other documents."
=============================================================================
12. How should we ensure interoperable mapping of key material to keys?
We propose adding the following text to Section 4.6.2 "Automatic
Techniques -- Key Mgt Protocol Requirements"
"Multiple keys may be needed for a single ESP SA, either because
the encryption algorithm uses multiple keys (e.g., triple DES)
or because both encryption and authentication algorithms are
employed. The Key Management System may provide a seprate
string of bits for each key or it may generate one string of
bits from which all of them are extracted. If a single string
of bits is provided, care needs to be taken to ensure that the
parts of the system that map the string of bits to the required
keys do so in the same fashion at both ends of the SA. To
ensure that the IPsec implementations at each end of the SA use
the same bits for the same keys, and irrespective of which part
of the system divides the string of bits into individual keys,
the encryption keys MUST be taken from the first (left-most,
high-order) bits and the authentication key(s) MUST be taken
from the remaining bits. The number of bits for each key is
defined in the relevant algorithm specification RFC. In the
case of multiple encryption keys, the specification for the
encryption algorithm must specify the order in which they are to
be selected from a single string of bits provided to the
algorithm."
=============================================================================
13. In *TRANSPORT MODE*, allowing arbitrary ordering of IPsec headers.
Following up on the mailing list discussion on nesting IPsec headers
(8/22 to 8/30), we propose to modify the Architecture document by:
a) Adding a section in Outbound Processing --> 5.1.3, "Header nesting
for transport mode" that says:
"If more than one IPsec header/extension is required:
o the order of nesting of the security headers MUST be
defined by security policy
o The following 3 cases MUST be supported:
1. [IP][AH][upper]
2. [IP][ESP][upper]
3. [IP][AH][ESP][upper]
o arbitrary nesting is allowed -- Senders MAY generate
arbitrary nestings of IPsec headers and Receivers SHOULD
accept arbitrary nestings of IPsec headers.
Support for arbitrary nesting requires that implementations
ensure that any mutable "AH protected" fields outside/above the
AH header, i.e., IP length, IP Next Protocol and any IPsec
headers, are appropriately handled by Outbound and Inbound
processing as the headers are nested and unnested. To ensure
interoperability, the implementation should ignore the existence
(i.e., neither zero the contents nor try to predict the contents) of
IPsec headers to be applied later when
o constructing an IPsec header
o adjusting the IP length and IP Next Protocol in the IP
header or immediately preceding IP extension header
This will apply to:
[IP][ESP or AH][ESP or AH]...[ESP or AH] [AH][upper]
Nesting involving only ESP headers should not be problematic:
[IP][ESP][ESP]...[ESP][upper]
(While a native IP or bump-in-the-stack implementation could
predict the contents of later IPsec headers that it applies
itself, it won't be possible for it to predict any IPsec headers
added by a bump-in-the-wire implementation between the host and
the network.)"
b) In Section 5.2 "Processing Inbound IPsec Traffic", adding the
following text:
"If there is more than one IPsec header/extension present, the
processing for each one ignores (does not zero, does not use)
any IPsec headers applied subsequent to the header being
processed."
=============================================================================
14. Revision of Section 4. "Security Associations"
Following up on discussions at the Munich IETF, subsequent email,
etc., this section will be rewritten to:
o remove the Security Association Map (section 4.4.2 "Security
Association Outbound Processing) from the design because of
problems identified by several people on the list.
o revise the Selectors section to reconcile the selectors for
SAs defined in the IPsec Architecture document, the ID ranges
for SAs defined in the IPsec DOI for ISAKMP, and the name
forms in certificates.
o add the following attributes to the Security Association
Database:
- Anti-replay window size
- Largest valid (has passed ICV check) sequence number
seen (receiver only)
- Sequence Number counter (sender only)
o address the question "Should the architecture allow a single
SA to alternate between transport and tunnel mode for
different packets?" Following up on email from Dan McDonald
(9/21)...
"It is my opinion that, while there are processing
differences between transport and tunnel modes of IPsec,
to explicitly distinguish them as an SA attribute is
wrong. They should be "Selectors" in your abstraction
of the Security Policy Database. I may wish to use a
pair of SAs for both tunnel mode and transport mode
simultaneously. The differences between tunnel and
transport mode are important, but they should be
indicated with respect to processing and policy decision
making, rather than be an explicit SA attribute."
We propose to:
- add IPsec protocol mode (transport or tunnel) to the
Security Policy Database (SPD).
- remove the "IPsec protocol mode (transport or tunnel)"
as an SA attribute from Section 4.4.4 "Security
Association Database (SAD)"
=============================================================================
15. Per email from Dan McDonald 9/21...
We propose to give GKMP as an example of work in progress for
multicast key distribution in section 4.7. However, per IETF
requirements for RFCs, we won't be able to formally cite it unless
there is an RFC.
=============================================================================
16. Per email from Dan McDonald 9/21...
We propose to add a note to the appendix on PMTU/DF processing:
"If a bump-in-the-stack implementation of IPsec attempts to
apply different IPsec algorithms based on source/destination
ports, it will be difficult to apply Path MTU adjustments."
=============================================================================
17. Per Dan McDonald 9/21...
Text will be added to section 11. "Performance Issues":
"The initial SA establishment overhead will be felt in the first
packet. This delay could impact the transport layer and
application. For example, it could cause TCP to retransmit the
SYN before the ISAKMP exchange is done. The effect of the delay
would be different on UDP than TCP because TCP shouldn't
transmit anything other than the SYN until the connection is set
up whereas UDP will go ahead and transmit data beyond the 1st
packet."
=============================================================================
18. Should the IPsec architecture support enforcement of
receiver-specified security policies?
Per Charlie Lynn,
"There is a need for a mechanism for a receiver to specify what
IPsec services MUST be present for a given traffic stream, based
on (post-IPsec processing) packet selectors."
Per Dan McDonald 9/21,
"Consider the security gateway example...
<subnet a.b.c/24> -- SG ==(The Internet)== SG' -- <a.b.d/24>
...SG may accept legitimate SA establishment requests from
parties other than SG'. If this is so, it is CRUCIAL that SG
take care that a malicious party M doesn't use its legitimate
SAs to tunnel forged packets from a.b.d.X to a.b.c.Y. A naive
SG implementation may say "Oh, it was decrypted, of COURSE I can
forward the inner packet" regardless of WHICH PEER SG sent it."
[I.e., there's another security gateway SG" which has an SA with SG.
And M is behind SG" but pretending to be a host behind SG'.]
To address their concerns, we propose to make the following changes
o modify section 4.4.1 "The Security Policy Database (SPD)"
- end of paragraph 2, add the sentence: "This applies to
the IPsec protection to be applied by a sender and to
the IPsec protection that must be present at the
receiver.
- paragraph 3, 1st sentence, change from "For every
IPsec implementation, there MUST be some form of
administrative interface...." to "For every IPsec
implementation, there MUST be some form of
administrative interface for both outbound and inbound
traffic ...
o include the following text in section 5.2 "Processing Inbound
Traffic":
"For each packet, its SA attributes (IPsec protocol,
etc.) must be recorded to allow them to be checked
against the receiver's security policy. Care must be
taken to do this for all IPsec headers that are
present including those that are nested. After all
IPsec processing has been completed, the receiver
looks up the packet's selectors in its inbound
security policy database and verifies that the
required IPsec protection was present in the given
packet. If not, it discards the packet."
Follow-Ups: