[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Revised drafts -- Arch, AH, ESP
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.
Follow-Ups: