IPsec Architecture -- proposed changes
Karen Seo <kseo@bbn.com> Tue, 07 October 1997 06:34 UTC
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA15483 for ipsec-outgoing; Tue, 7 Oct 1997 02:34:20 -0400 (EDT)
Message-Id: <199710070649.CAA15157@relay.hq.tis.com>
Date: Tue, 07 Oct 1997 02:32:35 -0400
From: Karen Seo <kseo@bbn.com>
To: ipsec@tis.com
cc: kseo@bbn.com
Subject: IPsec Architecture -- proposed changes
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
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."
- IPsec Architecture -- proposed changes Karen Seo
- Re: IPsec Architecture -- proposed changes C. Harald Koch
- RE: IPsec Architecture -- proposed changes Freedman, Jerome
- Re: IPsec Architecture -- proposed changes Michael C. Richardson
- Re: IPsec Architecture -- proposed changes Cheryl Madson
- Re: IPsec Architecture -- proposed changes C. Harald Koch
- Re: IPsec Architecture -- proposed changes C. Harald Koch
- Re: IPsec Architecture -- proposed changes Cheryl Madson
- Re: IPsec Architecture -- proposed changes Matt Thomas
- Re: IPsec Architecture -- proposed changes C. Harald Koch
- Re: IPsec Architecture -- proposed changes Ran Atkinson
- Re: IPsec Architecture -- proposed changes Steven Bellovin
- Re: IPsec Architecture -- proposed changes Robert Moskowitz
- Re: IPsec Architecture -- proposed changes Matt Thomas
- Re: IPsec Architecture -- proposed changes Stephen Kent
- Re: IPsec Architecture -- proposed changes Theodore Y. Ts'o
- Re: IPsec Architecture -- proposed changes Charles Lynn
- Re: IPsec Architecture -- proposed changes C. Harald Koch