Revised drafts -- Arch, AH, ESP
Karen Seo <kseo@bbn.com> Thu, 02 July 1998 21:02 UTC
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA00519 for ipsec-outgoing; Thu, 2 Jul 1998 17:02:46 -0400 (EDT)
Message-Id: <199807022114.RAA18455@relay.hq.tis.com>
Date: Thu, 02 Jul 1998 17:08:28 -0400
From: Karen Seo <kseo@bbn.com>
To: ipsec@tis.com
cc: rgm-sec@htt-consult.com, tytso@MIT.EDU, skent@bbn.com, clynn@bbn.com, kseo@bbn.com
Subject: Revised drafts -- Arch, AH, ESP
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Folks, In follow-up to Thomas Narten's (IESG) feedback (see Ted Ts'o's email of 5/22/98) and subsequent email, we have submitted to the IETF secretariat 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 A summary of the changes that were made is attached below. Karen Architecture ------------ 1. Section 3.1 "What IPsec Does" and Section on "References" -- updated to reflect the progress of the IETF working group IP Payload Compression Protocol (ippcp) and make it easier for the RFC editor to insert the RFC number for ippcp. Changed Section 3.1, last paragraph, from: The IPsec DOI supports negotiation of IP compression, motivated in part by the observation that when encryption is employed within IPsec, it prevents effective compression by lower protocol layers. 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." To: The IPsec DOI also supports negotiation of IP compression [SMPT98], motivated in part by the observation that when encryption is employed within IPsec, it prevents effective compression by lower protocol layers. Added to References section: [SMPT98] A. Shacham, R. Monsour, R. Pereira, M. Thomas, "IP Payload Compression Protocol (IPComp)", Internet Draft, May 1998. 2. Section 4.4.3 Security Association Database (SAD) -- clarified issues relating to handling/calculating SA lifetime if a byte count is used. Changed from: o Lifetime of this Security Association: .... (a) If byte count is used, then the implementation SHOULD count the number of bytes to which the IPsec algorithm is applied. To: o Lifetime of this Security Association: .... (a) If byte count is used, then the implementation SHOULD count the number of bytes to which the IPsec algorithm is applied. For ESP, this is the encryption algorithm (including Null encryption) and for AH, this is the authentication algorithm. This includes pad bytes, etc. Note that implementations SHOULD be able to handle having the counters at the ends of an SA get out of synch, e.g., because of packet loss or because the implementations at each end of the SA aren't doing things the same way. 3. Section 5.1.2.1 IPv4 -- Header Construction for Tunnel Mode -- added note to clarify decrementing of TTL. After the following paragraph: 2. The TTL in the inner header is decremented by the encapsulator prior to forwarding and by the decapsulator if it forwards the packet. (The checksum changes when the TTL changes.) we added: Note: The decrementing of the TTL is one of the usual actions that takes place when forwarding a packet. Packets originating from the same node as the encapsulator do not have their TTL's decremented, as the sending node is originating the packet rather than forwarding it. 4. Section 6.1.2.1 Propagation of PMTU, second bullet in paragraph 1; and Section B.3.1 "Identifying the Originating Host(s)" -- removed reference to IPv6/ICMP 576 byte minimum. Changed Section 6.1.2.1 from: 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 non-opaque information to immediately determine to which host to propagate the ICMP/PMTU message.... To: o PMTU message with >64 bits of IPsec header -- If the ICMP message contains more information from the original packet then there MAY be enough non-opaque information to immediately determine to which host to propagate the ICMP/PMTU message.... Changed Section B.3.1, 2nd paragraph, from: 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 To: 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 Changed Section B.3.1, last paragraph, from: 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....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. To: 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, then there MAY be enough information to... NOTE: The Next Protocol field MAY not be contained in the ICMP message and the use of ESP encryption MAY hide the selector fields that have been encrypted. AH only ------- 1. Section 3.3.3.1 Handling Mutable Fields, 2nd paragraph -- clarified issue of which IP headers have a flag indicating mutability. This was related to confusion over the term "options". The "fixed" paragraph below was in the version distributed/posted by the secretariat on May 12/13. Changed from: As a new extension header or IPv4 option is created, it will be defined in its own RFC and SHOULD include (in the Security Considerations section) directions for how it should be handled when calculating the AH ICV. 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: As a new extension header or IPv4 option is created, it will be defined in its own RFC and SHOULD include (in the Security Considerations section) directions for how it should be handled when calculating the AH ICV. 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. AH and ESP ---------- 1. AH section 3.3.2 Sequence Number Generation, last paragraph; ESP section 3.3.3 Sequence Number Generation, last paragraph -- clarified the handling of the sequence number by the sender when anti-replay has been disabled. Changed from: If anti-replay has been disabled, the sender does not need to monitor or reset the counter, e.g., in the case of manual key management. To: If anti-replay is disabled, the sender does not need to monitor or reset the counter, e.g., in the case of manual key management (see Section 5). However, the sender still increments the counter and when it reaches the maximum value, the counter rolls over back to zero.
- Revised drafts -- Arch, AH, ESP Karen Seo
- Re: Revised drafts -- Arch, AH, ESP FUKUMOTO Atsushi
- Re: Revised drafts -- Arch, AH, ESP Karen Seo
- Re: Revised drafts -- Arch, AH, ESP FUKUMOTO Atsushi
- Re: Revised drafts -- Arch, AH, ESP William Allen Simpson
- Re: Revised drafts -- Arch, AH, ESP C. Harald Koch
- Re: Revised drafts -- Arch, AH, ESP Karen Seo
- Re: Revised drafts -- Arch, AH, ESP William Allen Simpson
- Re: Revised drafts -- Arch, AH, ESP Harald Koch
- Re: Revised drafts -- Arch, AH, ESP William Allen Simpson
- Re: Revised drafts -- Arch, AH, ESP Pyda Srisuresh
- Re: Revised drafts -- Arch, AH, ESP Stephen Kent
- Re: Revised drafts -- Arch, AH, ESP Pyda Srisuresh
- Re: Revised drafts -- Arch, AH, ESP Stephen Kent
- Re: Revised drafts -- Arch, AH, ESP Pyda Srisuresh
- Re: Revised drafts -- Arch, AH, ESP Stephen Kent