Latest AH/ESP/Arch drafts and changes
Karen Seo <kseo@bbn.com> Mon, 11 May 1998 14:10 UTC
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA13040 for ipsec-outgoing; Mon, 11 May 1998 10:10:20 -0400 (EDT)
Message-Id: <199805110517.BAA05493@relay.hq.tis.com>
Date: Mon, 11 May 1998 01:16:17 -0400
From: Karen Seo <kseo@bbn.com>
To: ipsec@tis.com
cc: kseo@bbn.com
Subject: Latest AH/ESP/Arch drafts and changes
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Folks, In follow-up to the IESG vote/feedback and recent email... 1. Per direction from Ted Ts'o, we are sending to the IETF secretariat and the mailing list, revised versions of the following drafts: o AH -- draft-ietf-ipsec-auth-header-06.txt o ESP -- draft-ietf-ipsec-esp-v2-05.txt o Architecture -- draft-ietf-ipsec-arch-sec-05.txt These drafts contain the changes listed below in part 1 and part 2. 2. Part 1 below contains edits that have been made since Ted's 4/28 email "IPSEC standardization status". If you've already read the changes that Ted posted to the Web on 4/28, then you only need to look at these new changes. 3. Part 2 below contains the changes made to the 3/13 Internet Drafts up until Ted's 4/28 email on "IPSEC standardization status". He posted these changes (and corresponding drafts, which were not sent to the IETF secretariat) to the Web. They are included here for those who haven't yet had a chance to pull them over from the Web site. Please let us know if you have any questions, etc. Thank you, Karen ******************************************************************************* Part 1 -- Changes made to the drafts since Ted's 4/28 email "IPSEC standardization status" ******************************************************************************* AH 1. Section 3.3.3.1 "Handling Mutable Fields" -- Amended to match IP (v4 and v6) handling of unrecognized extension headers and to clarify the distinction between IPv6 options and extension headers -- per (IPng and IPsec) mailing list discussion. Changed 3.3.3.1, second paragraph, from: ... If the IPsec implementation encounters an extension header that it does not recognize, it MUST zero the whole header except for the Next Header and Hdr Ext Len fields. The length of the extension header MUST be computed by 8 * Hdr Ext Len value + 8. If the IPsec implementation encounters an IPv4 option that it does not recognize, it should zero the whole option, using the second byte of the option as the length. (IPv6 options contain a flag indicating mutability, which determines appropriate processing for such options.) to: ... If the IP (v4 or v6) implementation encounters an extension header that it does not recognize, it will discard the packet and send an ICMP message. IPsec will never see the packet. If the IPsec implementation encounters an IPv4 option that it does not recognize, it should zero the whole option, using the second byte of the option as the length. IPv6 options (in Destination extension headers or Hop by Hop extension header) contain a flag indicating mutability, which determines appropriate processing for such options. 2. Section 3.3.3.1.2.2 "Extension Headers -- Options" -- changed wording to clarify the distinction between IPv6 options and extension headers -- per email from Ted Ts'o on 5/5/98 Changed title from: 3.3.3.1.2.2 Extension Headers -- Options to: 3.3.3.1.2.2 Extension Headers Containing Options Deleted the first sentence of section: The IPv6 extension headers (that are options) are explicitly listed in Appendix A and classified as immutable, mutable but predictable, or mutable. 3. Section 3.3.3.1.2.3 "Extension Headers -- non-Options" -- changed wording to clarify that IPv6 options are contained in extension headers (Hop by Hop and Destination) -- per email from Ted Ts'o on 5/5/98 Changed title from: 3.3.3.1.2.3 Extension Headers -- non-Options to: 3.3.3.1.2.3 Extension Headers Not Containing Options =========================================================================== ESP 1. Section 3.4.3 "Sequence Number Verification" -- fixed incorrect reference -- per email from Marc Hasson on 4/30/98. Changed 3.4.3, second paragraph from: If the receiver does not enable anti-replay for an SA....To avoid having the sender do unnecessary sequence number monitoring and SA setup (see section 3.3.2)..... to: If the receiver does not enable anti-replay for an SA....To avoid having the sender do unnecessary sequence number monitoring and SA setup (see section 3.3.3)..... 2. Section 3.4.5 "Packet Decryption" -- changed this section to be consistent with Section 2.4 "Padding (for Encryption)" paragraph on default padding scheme which says, "When this [the default] padding scheme is employed, the receiver SHOULD inspect the Padding field." -- per email from Marc Hasson on 4/30/98. Changed 3.4.5, step 2 from: 2. processes any padding as specified in the encryption algorithm specification. The default action is to remove/ignore any padding. to: 2. processes any padding as specified in the encryption algorithm specification. If the default padding scheme (see Section 2.4) has been employed, the receiver SHOULD inspect the Padding field before removing the padding prior to passing the decrypted data to the next layer. =========================================================================== Architecture: 1. Section 4.1 "Definition and Scope" -- changed to clarify the distinction between IPv6 options and extension headers -- per email from Ted Ts'o on 5/5/98 NOTE: Because an extension header can be used with IPv4 as well as with IPv6, we did not say that extension headers are IPv6. Changed third paragraph from: ... 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 [KA98a]... to: ... In the case of AH, the protection is also extended to selected portions of the IP header, selected portions of extension headers, and selected options (contained in the IPv4 header, IPv6 Hop-by-Hop extension header, or IPv6 Destination extension headers). For more details on the coverage afforded by AH, see the AH specification [KA98a] 2. Section 4.4.2 "Selectors" paragraphs on Destination IP Address and Source IP Address -- corrected to reflect the fact that IPv6 does not have broadcast addresses -- per email from Marc Hasson on 4/30/98. RFC 1884 says "IPv6 addresses are 128-bit identifiers for interfaces and sets of interfaces. There are three types of addresses: Unicast: .... Anycast: .... Multicast: .... So we also changed these paragraphs to include "anycast", even though anycast addresses are not syntactically distinguishable from unicast addresses. Changed paragraph on Destination Addresses from: - Destination IP Address (IPv4 or IPv6): this may be a single IP address (unicast, broadcast, or multicast group), a range of addresses (high and low values (inclusive), address + mask, or a wildcard address.... - Source IP Address(es) (IPv4 or IPv6): this may be a single IP address (unicast, broadcast, or multicast group), range of addresses (high and low values inclusive), address + mask, or a wildcard address.... to: - Destination IP Address (IPv4 or IPv6): this may be a single IP address (unicast, anycast, broadcast (IPv4 only), or multicast group), a range of addresses (high and low values (inclusive), address + mask, or a wildcard address.... - Source IP Address(es) (IPv4 or IPv6): this may be a single IP address (unicast, anycast,, broadcast (IPv4 only), or multicast group), range of addresses (high and low values inclusive), address + mask, or a wildcard address.... 3. Section 4.4.2 "Selectors" paragraph on Source IP Address -- The current text says: - Source IP Address(es) (IPv4 or IPv6): this may be a single IP address (unicast, broadcast, or multicast group), range of addresses (high and low values inclusive), address + mask, or a wildcard address. In his 4/30 email, Marc Hasson asked, "Can a source address really be a broadcast or multicast? This seems like we're having IPSEC condone illegal IP[v6] packet behavior...." Since a packet's source address FIELD may not contain a broadcast or multicast address, at first glance, it doesn't make sense for a source address SELECTOR to be a broadcast or multicast address. But this raises the question of what happens during IKE's SA negotiation -- what does the receiving end of an SA setup request do when the destination address is broadcast or multicast and it tries to set up the return half of the SA pair? In particular, what does the (outbound) SPD use for the Source IP Address selector value (as opposed to what would be in a packet)? This seems like a case where the selector values would need to be different from the packet values and hence the current text is correct, provided we change "broadcast" to "broadcast (IPv4 only). Note also that if a multicast receiver initiates an ISAKMP exchange, e.g., to obtain a key from (each) sender to the group, the "destination address selector" would be the multicast sender's address (a unicast address) while the "source address selector" would contain the multicast group address. For now, we are leaving the text as is to cover the possibility that broadcast/multicast might be useful in the future, e.g., to enable one to use a multicast address when doing secure multicasting operations. Since the multicast problem has been deferred to IPsecond (or later?), this issue is similarly deferred.. 4. Appendix B.2 "Fragmentation" -- very last paragraph The last paragraph currently says: c. Security gateways -- integrate IPsec into the IP stack NOTE: The IPsec module will have access to the following selectors .... Unlike Bump-in-the-stack implementations, security gateways may be able to look up the Source Address in the DNS to provide a System Name, e.g., in situations involving use of dynamically assigned IP addresses in conjunction with dynamically updated DNS entries.... From email from Marc Hasson on 4/30/98...[referring to the sentence above, "Unlike Bump-in-the-stack...."] "I'm not sure why this statement is here. Having done both an IPSEC stack for Mentat as well as having worked on a BITS implementation (involving both user and kernel pieces) I don't see any reason why a BITS implementation can't do a DNS lookup for its System name just as well as a "pure" IPSEC host or SG. In fact, part of the dynamic IP assignment (via DHCP perhaps) and DNS update may already have provided a BITS host with what it needs to do a DNS lookup. Our impression was that the community viewed the phrase "bump-in-the-stack" (BITS) as describing an implementation that typically would not have access to various system calls to higher portions of the protocol stack, e.g., DNS lookup. Nonetheless, Marc's comment is still reasonable, and whether or not to remove the sentence seems to depend on the connotations of the phrase "bump-in-the-stack". For now, we've added the word "some" in front of the phrase "Bump-in-the-stack implementations" so that the text now reads: "c. Security gateways -- integrate IPsec into the IP stack NOTE: The IPsec module will have access to the following selectors .... Unlike some Bump-in-the-stack implementations, security gateways may be able to look up the Source Address in the DNS to provide a System Name, e.g., in situations involving use of dynamically assigned IP addresses in conjunction with dynamically updated DNS entries.... ******************************************************************************* Part 2 -- Changes made to 3/13 drafts (as of 4/23). These are the changes Ted announced in his email of 4/28 "IPSEC standardization status" and posted to the Web. ******************************************************************************* ESP ONLY 1. Clarified when the padding computation takes into account the IV -- per private email of 3/24. Changed the text in 2.4 "Padding (for Encryption)", first paragraph after the 3 bullets (which explain the motivation for padding) from: The sender MAY add 0-255 bytes of padding. Inclusion of the Padding field in an ESP packet is optional, but all implementations MUST support generation and consumption of padding. The padding computation applies to the plaintext portion of the Payload Data, exclusive of the IV (if present). to: The sender MAY add 0-255 bytes of padding. Inclusion of the Padding field in an ESP packet is optional, but all implementations MUST support generation and consumption of padding. a. For the purpose of ensuring that the bits to be encrypted are a multiple of the algorithm's blocksize (first bullet above), the padding computation applies to the Payload Data exclusive of the IV, the Pad Length, and Next Header fields. b. For the purposes of ensuring that the Authentication Data is aligned on a 4-byte boundary (second bullet above), the padding computation applies to the Payload Data inclusive of the IV, the Pad Length, and Next Header fields. 2. Corrected and clarified the Outbound and Inbound processing sections -- per private email on 3/20. We now speak in terms of encryption always being applied (where no confidentiality is offered by using the NULL encryption algorithm) so as to avoid confusion about the following issues: o encapsulation and padding are always performed whether or not confidentiality is selected in order to preserve alignment and put the next protocol field in the right place. o encryption is always done before authentication Also corrected decryption to encryption in the Outbound section. Changed the beginning of (Outbound Processing) Section 3.3.2 "Packet Encryption" from: If confidentiality is selected, then the sender: 1. encapsulates.... 2. adds any necessary padding. 3. encrypts the result .... - If explicit cryptographic synchronization data, e.g., an IV, is indicated, it is input to the decryption algorithm per the algorithm specification and placed in the Payload field. - If implicit cryptographic synchronication data, e.g., an IV, is indicated, it is constructed and input to the decryption algorithm as per the algorithm specification. to: In this section, we speak in terms of encryption always being applied because of the formatting implications. This is done with the understanding that "no confidentiality" is offered by using the NULL encryption algorithm. Accordingly, the sender: 1. encapsulates... 2. adds any necessary padding. 3. encrypts the result.... - If explicit cryptographic synchronization data, e.g., an IV, is indicated, it is input to the encryption algorithm per the algorithm specification and placed in the Payload field. - If implicit cryptographic synchronication data, e.g., an IV, is indicated, it is constructed and input to the encryption algorithm as per the algorithm specification. Changed the beginning of (Inbound Processing) Section 3.4.5 "Packet Decryption" from: If confidentiality has been selected, then the receiver: to: As in section 3.3.2, "Packet Encryption", we speak here in terms of encryption always being applied because of the formatting implications. This is done with the understanding that "no confidentiality" is offered by using the NULL encryption algorithm. Accordingly, the receiver: =============================================================================== AH and ESP 1. Updated to use IKE instead of ISAKMP/Oakley. Added IKE to Reference section. 2. Clarified the text explaining the reason for having the receiver notify the sender if anti-replay is disabled -- per private email In both AH and ESP, changed Section 3.4.3 "Sequence Number Verification", paragraph 2 If the receiver does not enable anti-replay for an SA, no inbound checks are performed on the Sequence Number. The default for the sender is that the Sequence Number will be checked at the sender. Hence, if an SA establishment protocol such as ISAKMP/Oakley is employed, the receiver SHOULD notify the sender, during SA establishment, if the receiver will not provide anti-replay protection. to: If the receiver does not enable anti-replay for an SA, no inbound checks are performed on the Sequence Number. However, from the perspective of the sender, the default is to assume that anti-replay is enabled at the receiver. To avoid having the sender do unnecessary sequence number monitoring and SA setup (see section 3.3.2), if an SA establishment protocol such as IKE is employed, the receiver SHOULD notify the sender, during SA establishment, if the receiver will not provide anti-replay protection. Also, changed section 3.3.3 "Sequence Number Generation" to coordinate with the above change. Inserted the following text between paragraph 2 and paragraph 3. The sender assumes anti-replay is enabled as a default, unless otherwise notified by the receiver (see 3.4.3). Thus, if the counter has cycled, the sender will set up a new SA and key (unless the SA was configured with manual key management). =============================================================================== ARCHITECTURE 1. Section 4.2 "Security Association Functionality" -- clarified wording of per email from Bill Sommerfeld on 3/16: Changed "below" to "outside" in 5th sentence of 3rd paragraph which now reads: The scope of the authentication offered by ESP is narrower than for AH, i.e., the IP header(s) "outside" the ESP header is(are) not protected. 2. Section 4.2 "Security Association Functionality", paragraph 4 -- clarified Section to reflect the fact that encryption service in ESP is now optional -- per private email on 3/16. Changed: 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..... to: If confidentiality service is selected, then 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.... 3. Section 4.4 "Security Association Databases" -- clarified inbound/outbound terminology and model -- per various private and public email. Added the following paragraph at the end of Section 4.4 before 4.4.1: Each interface for which IPsec is enabled requires nominally separate inbound vs. outbound databases (SAD and SPD), because of the directionality of many of the fields that are used as selectors. Typically there is just one such interface, for a host or security gateway (SG). Note that an SG would always have at least 2 interfaces, but the "internal" one to the corporate net, usually would not have IPsec enabled and so only one pair of SADs and one pair of SPDs would be needed. On the other hand, if a host had multiple interfaces or an SG had multiple external interfaces, it might be necessary to have separate SAD and SPD pairs for each interface. 4. Sections 4.4 and 5 -- modified so that mention of the SPD having entries for inbound traffic, outbound traffic, and for each interface are brought up in the SPD section (4.4.1) rather than later on in Section 5 -- per email from Henry Spencer on 3/17 In Section 4.4.1 "The Security Policy Database (SPD)", added the following paragraph after the first paragraph: The SPD must be consulted during the processing of all traffic (INBOUND and OUTBOUND), including non-IPsec traffic. In order to support this, the SPD requires distinct entries for inbound and outbound traffic. One can think of this as separate SPDs (inbound vs. outbound). In addition, a nominally separate SPD must be provided for each IPsec-enabled interface. In Section 5. "IP Traffic Processing", first 2 paragraphs -- removed the text that is now redundant with Section 4.4.1 and combined them. So that the text changed from: The SPD must be consulted during the processing of all traffic (INBOUND and OUTBOUND), including non-IPsec traffic. Note that the SPD requires distinct entries for inbound and outbound traffic. One can think of this as separate SPDs (inbound vs. outbound). Note also that a nominally separate SPD must be provided for each IPsec-enabled interface. If no policy is found in the SPD that matches the packet (for either inbound or outbound traffic), the packet MUST be discarded. into the following text: As mentioned in Section 4.4.1 "The Security Policy Database (SPD)", the SPD must be consulted during the processing of all traffic (INBOUND and OUTBOUND), including non-IPsec traffic. If no policy is found in the SPD that matches the packet (for either inbound or outbound traffic), the packet MUST be discarded. 5. Section 4.4.1, "The Security Policy Database (SPD)" -- modified to reflect the reduced requirements for reuse of SAs (This was changed in the last draft in the Outbound Processing Section 5.1.1 "Selecting and Using and SA or SA Bundle" but not here) -- per email from Henry Spencer on 3/17 on private email on 4/13 Changed 2nd to last paragraph of Section 4.4.1 "The Security Policy Database (SPD)" from: Because a security policy may require that more than one SA be applied to a specified set of traffic, in a specific order, the policy entry in the SPD must preserve these ordering requirements.....For an inbound IPsec packet for which multiple IPsec SAs are to be applied, the lookup based on destination address, IPsec protocol, and SPI should identify a single SA. To allow minimization of the number of SAs, the linkage between the SPD and the SAD (at both the sender and the receiver) MUST allow an SA to be used in more than one bundle. to: Because a security policy may require that more than one SA be applied to a specified set of traffic, in a specific order, the policy entry in the SPD must preserve these ordering requirements.....For an inbound IPsec packet for which multiple IPsec SAs are to be applied, the lookup based on destination address, IPsec protocol, and SPI should identify a single SA. To allow minimization of the number of SAs, the linkage between the SPD and the SAD (at both the sender and the receiver) SHOULD allow an SA to be used in more than one bundle. Modified paragraph 5, last 2 bullets from: b. use the value associated with the policy entry -- if this were to be just a single value, then there would be no difference between (b) and (a). However, if the allowed values for the selector were a range, then (b) would enable use of the SA by any packet with a selector value within the range not just by packets with the selector value of the packet that triggered the creation of the SA. c. use a wildcard value -- this can be used to create an SA that can be shared by a broader set of SPD entries (vs (b)). to: b. use the value associated with the policy entry -- If this were to be just a single value, then there would be no difference between (b) and (a). However, if the allowed values for the selector are a range (for IP addresses) or a wildcard, then in the case of a range,(b) would enable use of the SA by any packet with a selector value within the range not just by packets with the selector value of the packet that triggered the creation of the SA. In the case of a wildcard, (b) would allow use of the SA by packets with any value for this selector. Changed paragraphs 6 and 7, from: For example, suppose there is an SPD entry where the allowed value for source address is any of a range of hosts (192.168.2.1 to 192.168.2.10).... source for the example of value to be new SAD used in the SA selector value --------------- ------------ a. packet 192.168.2.3 (one host) b. SPD entry 192.168.2.1 to 192.168.2.10 (range of hosts) c. wildcard * (any host) Case (c) permits the sharing of an SA (or SA bundle) by multiple SPD entries. Case (a) can be used to prohibit sharing, even among packets that match the same SPD entry. to: For example, suppose there is an SPD entry where the allowed value for source address is any of a range of hosts (192.168.2.1 to 192.168.2.10).... source for the example of value to be new SAD used in the SA selector value --------------- ------------ a. packet 192.168.2.3 (one host) b. SPD entry 192.168.2.1 to 192.168.2.10 (range of hosts) Note that if the SPD entry had an allowed value of wildcard for the source address, then the SAD selector value could be wildcard (any host). Case (a) can be used to prohibit sharing, even among packets that match the same SPD entry. Deleted the last sentence of next to last paragraph. It read: To allow minimization of the number of SAs, the linkage between the SPD and the SAD (at both the sender and the receiver) SHOULD allow an SA to be used in more than one bundle. 6. Section 4.4.2 "Selectors" -- defined term "opaque" -- per email from Bill Sommerfeld on 3/16 and Henry Spencer 3/17 Added definition of "opaque" to last sentence of Section 4.4.2 (also changed UserID to "Name") Note that in the case of receipt of a packet with an ESP header, e.g., at an encapsulating security gateway or BITW implementation, the transport layer protocol, source/destination ports, and UserID (if present) may be opaque. to: Note that in the case of receipt of a packet with an ESP header, e.g., at an encapsulating security gateway or BITW implementation, the transport layer protocol, source/destination ports, and Name (if present) may be "OPAQUE", i.e., inaccessible because of encryption or fragmentation. 7. Section 4.4.2 "Selectors", paragraphs on Source IP Address and Destination IP Address -- corrected text per email from Bill Sommerfeld on 3/16. o Changed text for "Source IP Address" to match "Destination IP Address" o Corrected text to list "address + mask", clarify what a range is, match DOI etc. o Added a note re: not specifying a mix of IPv4 and IPv6 IP addresses Changed paragraphs on Source and Destination IP Addresses from: - Source IP Address(es) (IPv4 or IPv6): this may be a single IP address, range of addresses, or a wildcard (mask) address. The latter 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).... - Destination IP Address (IPv4 or IPv6): this may be a single IP address (unicast, broadcast, or multicast group), a range of addresses, or a wildcard (mask) address. The latter 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)..... to: - Source IP Address(es) (IPv4 or IPv6): this may be a single IP address (unicast, broadcast, or multicast group), range of addresses (high and low values inclusive), address + mask, or a wildcard address. The last three are required to support more than one source system sharing the same SA (e.g., behind a security gateway or in a multihomed host).... - Destination IP Address (IPv4 or IPv6): this may be a single IP address (unicast, broadcast, or multicast group), a range of addresses (high and low values (inclusive), address + mask, or a wildcard address. The last three are used to support more than one destination system sharing the same SA (e.g., behind a security gateway).... Added the following text at the end of the first paragraph in Section 4.4.2 Selectors: Note also that both Source and Destination addresses should either be IPv4 or IPv6. 8. Section 4.4.2 Selectors, paragraph on "Source and Destination (e.g., TCP/UDP) Ports" -- Amend table to show that "Next Hdr" in SPD is the "Transport Layer Protocol" selector -- per private email of 3/18. Changed: Next Hdr Next Hdr Derived Port Selector Field in Packet in SPD Value in SPD and SAD -------- -------- --------------------------- to: Next Hdr Transport Layer Derived Port Selector Field in Packet Protocol in SPD Value in SPD and SAD -------- --------------- --------------------------- 9. Section 4.4.2 "Selectors" -- correct table near the end of the section to say that the destination address selector can have a value of a single address, a range, or a wildcard in the SAD -- per email from Padma Goli on 4/6/98. Changed the table near the end of Section 4.4.2 "Selectors" from: Field Traffic Value SAD Entry SPD Entry -------- ------------- ---------------- -------------------- src addr single IP addr single,range,wild single,range,wildcard --> dst addr single IP addr single IP addr single,range,wildcard .... to: Field Traffic Value SAD Entry SPD Entry -------- ------------- ---------------- -------------------- src addr single IP addr single,range,wild single,range,wildcard --> dst addr single IP addr single,range,wild single,range,wildcard ..... 10. Section 4.4.2 Selectors -- amended text for "Name" to note that support for name forms other than addresses is not required if manual keying is used -- per private email on 4/8. Changed the [REQUIRED section of the part on "Name" from: [REQUIRED for the following cases..... to: [REQUIRED for the following cases. Note that support for name forms other than addresses is not required for manually keyed SAs.... 11. Sections 4.4.3 "Security Association Database (SAD)" and 5.1.1 "Selecting and Using an SA or SA Bundle" -- corrected inconsistency between these sections on how to handle failure to find an SA that matches a given packet (for outbound processing) -- per mail from K. SrinivasRao on 3/16. Changed first paragraph from: In each IPsec implementation there is a nominal Security Association Database, in which each entry defines the parameters associated with one SA. Each SA has an entry in the SAD. For outbound processing, entries are pointed to by entries in the SPD. Note that if an SPD entry does not currently point to an SA that is appropriate for the packet, before it creates an SA, the implementation should check to see if the SAD already has an appropriate SA (created by some other SPD entry). to: In each IPsec implementation there is a nominal Security Association Database, in which each entry defines the parameters associated with one SA. Each SA has an entry in the SAD. For outbound processing, entries are pointed to by entries in the SPD. Note that if an SPD entry does not currently point to an SA that is appropriate for the packet, the implementation creates an appropriate SA (or SA Bundle) and links the SPD entry to the SAD entry (see Section 5.1.1). so that 4.4.3 matches the outbound processing steps in Section 5.1.1, step 2: 2. Match the packet's selector fields against those in the SA bundles found in (1) to locate the first SA bundle that matches. If no SAs were found or none match, create an appropriate SA bundle and link the SPD entry to the SAD entry. If no key management entity is found, drop the packet. 12. Section 4.4.3 "Security Association Database (SAD)" -- clarified to explain how wildcard might be used for IPsec protocol mode -- per private email in 3/98 Changed Section 4.4.3, paragraph on IPsec Protocol Mode from: o IPsec protocol mode: tunnel, transport or wildcard. Indicates which mode of AH or ESP is applied to traffic on this SA. [REQUIRED for all implementations, unless implicitly defined by context] to: o IPsec protocol mode: tunnel, transport or wildcard. Indicates which mode of AH or ESP is applied to traffic on this SA. Note that if this field is "wildcard" at the sending end of the SA, then the application has to specify the mode to the IPsec implementation. This use of wildcard allows the same SA to be used for either tunnel or transport mode traffic on a per packet basis, e.g., by different sockets. The receiver does not need to know the mode in order to properly process the packet's IPsec headers. [REQUIRED as follows, unless implicitly defined by context: - host implementations must support all modes - gateway implementations must support tunnel mode] NOTE: The use of wildcard for the protocol mode of an inbound SA may add complexity to the situation in the receiver (host only). Since the packets on such an SA could be delivered in either tunnel or transport mode, the security of an incoming packet could depend on which mode had been used to deliver it. If, as a result, an application cared about the SA mode of a given packet, then the application would need a mechanism to obtain this mode information. 13. Section 4.4.3 "Security Association Database (SAD)" -- clarified that the Anti-Replay Window is not used when anti-replay is disabled, e.g., for a manually keyed SA. -- per private email on 4/8. Changed the "REQUIRED" part of the paragraph on "Anti-Replay Window" from: [REQUIRED for all implementations but used only for inbound traffic.] to: [REQUIRED for all implementations but used only for inbound traffic. NOTE: If anti-replay has been disabled by the receiver, e.g., in the case of a manually keyed SA, then the Anti-Replay Window is not used.] 14. [Outbound] Section 5.1.1 "Selecting and Using an SA or SA Bundle" -- clarified that an attempt to create an ESP SA with both a NULL encryption and NULL authentication algorithm -- per private email discussion on 3/17. Added the following text at the end of the section: NOTE: A compliant implementation MUST not allow instantiation of an ESP SA that employs both a NULL encryption and a NULL authentication algorithm. An attempt to negotiate such an SA is an auditable event. 15. Section 5.1.2.2 "IPv6 -- Header Construction for Tunnel Mode" -- corrected "hop count" to "hop limit" -- per email from Peter Curran on 4/21. 16. [Inbound] Section 5.2.1 "Selecting and Using an SA or SA Bundle" -- clarified how/when to match packet selectors to the SA selectors -- per private email on 3/18 Changed step 2 from: ....Local policy determines the specificity of the SA selectors (single value, list, range, wildcard). In general, a packet's source address SHOULD match the SA selector value. (However, an AH or ESP-protected ICMP packet from a gateway may legitimately appear in a tunnel mode SA with a source IP address other than that bound to the SA, and thus such packets should be permitted as exceptions to this check. See Section 6.) Other packet fields MAY match the SA selector values as required by local policy. to: ....Local policy determines the specificity of the SA selectors (single value, list, range, wildcard). In general, a packet's source address MUST match the SA selector value. However, an ICMP packet received on a tunnel mode SA MAY have a source address other than that bound to the SA and thus such packets should be permitted as exceptions to this check. For an ICMP packet, the selectors from the enclosed problem packet (the source and destination addresses and ports should be swapped) should be checked against the selectors for the SA. Note that some or all of these selectors may be inaccessible because of limitations on how many bits of the problem packet the ICMP packet is allowed to carry or due to encryption. See Section 6. 17. Section 6.1.2 Path MTU Discovery (PMTU) -- Fixed parenthetical definition of IPv6 "Code 0" -- per private email of 3/18. Changed from: 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 to: IPv6 (RFC 1885): - Type = 2 (Packet Too Big) - Code = 0 (Fragmentation needed) - Next-Hop MTU in the 32 bit MTU field of the ICMP6 message 18. Appendix B.2 "Fragmentation" -- corrected number of cases from 24 to 20, fixed a couple of minor wording problems. 19. Appendix B.2 "Fragmentation" -- modified text to reflect changes previously made in the main body of the text: - remove TOS/Class from list of selectors (per comment in a private email) - add lookup of SPD entry in addition to look up of SA (caught as part of editing process). Changed the 5th paragraph, item (b) from: b. Hosts (Bump-in-the-stack) -- put IPsec between IP layer and network drivers... ..... 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). to: At the network layer, the IPsec module will have access to the following selectors from the packet -- SRC address, DST address, 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 Policy entry and Security Association(s). Changed the 5th paragraph, item (c) from: 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/Class, Next Protocol, and if there's a transport layer header --> 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). to: NOTE: The IPsec module will have access to the following selectors from the packet -- SRC address, DST address, Next Protocol, and if there's a transport layer header --> SRC port and DST port. It won't have access to the User ID (only Hosts have access to User ID information.) Unlike Bump-in-the-stack implementations, security gateways may be able to look up the Source Address in the DNS to provide a System Name, e.g., in situations involving use of dynamically assigned IP addresses in conjunction with dynamically updated DNS entries. 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 Policy entry and Security Association(s). 20. Corrected references in Section B.3.4 "Per Socket Maintenance of PMTU Data" -- per email from Rohit Aradhya on 3/21. Changed from: 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. to: Implementation of the calculation of PMTU (Section B.3.2) and support for PMTUs at the granularity of individual "communication associations" (Section B.3.3) is a local matter.
- Re: Latest AH/ESP/Arch drafts and changes Karen Seo
- Latest AH/ESP/Arch drafts and changes Karen Seo
- Re: Latest AH/ESP/Arch drafts and changes Peter Curran
- Re: Latest AH/ESP/Arch drafts and changes Theodore Y. Ts'o
- Re: Latest AH/ESP/Arch drafts and changes Thomas Narten
- Re: Latest AH/ESP/Arch drafts and changes Theodore Y. Ts'o
- Re: Latest AH/ESP/Arch drafts and changes Peter Curran
- Re: Latest AH/ESP/Arch drafts and changes Peter Curran