[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fwd: IPsec AH-bis-- Last Call revisions
Title: Fwd: IPsec AH-bis-- Last Call
revisions
X-Sender: kseo@po2.bbn.com
Date: Tue, 15 Jul 2003 18:43:04 -0400
To: "Angelos D. Keromytis"
<angelos@cs.columbia.edu>
From: Karen Seo <kseo@bbn.com>
Subject: IPsec AH-bis-- Last Call revisions
Cc: Barbara Fraser <byfraser@cisco.com>, tytso@mit.edu,
skent@bbn.com,
clynn@bbn.com, kseo@bbn.com
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com /
mimedefang)
Status:
Angelos,
Here are the comments and their status
for AH.... Revisions have been made to address the comments and
the changes have been approved by the commenter. These cover all
the tickets for AHbis that are "Must Fix" or "Should
Fix" plus some other comments not listed in the ticket database.
My impression is that the working group agreed not to do the "MAY
FIX" cases.
Should I go ahead and submit the revised
draft to the IETF?
Karen
===============================================================================
Commenter: Russ
Housley
Date:
6/17/03
Status:
change approved by Russ on 7/9/03
Please delete the last line of the
Abstract. In my opinion, pointers to subsequent sections belong
in the Introduction, not the Abstract.
Abstract -- Moved last
line of Abstract to end of Introduction
"Section 7 provides a brief review
of the differences between
this document and RFC 2402."
===============================================================================
Commenter: Russ
Housley
Date:
6/17/03
Status:
change approved by Russ on 7/9/03
Please move the last two paragraphs of
the Introduction to the beginning. This will tell the reader the
material that the expected to be understood before they get too deep,
and it will define MAY. SHOULD, MUST, and so on before they are
used.
Introduction -- Moved the following text to the beginning
of
the
Introduction. These paragraphs are slightly reworded so
they
fit at
the beginning.
"This document assumes that the
reader is familiar with the
terms and concepts described in the "Security
Architecture
for the Internet Protocol" [KA98], hereafter referred to
as
the Security Architecture document. In particular, the
reader
should be familiar with the definitions of security
services
offered by the Encapsulating Security Payload (ESP) and
the
IP Authentication Header (AH), the concept of
Security
Associations, the ways in which ESP can be used in
conjunction
with the Authentication Header (AH), and the different
key
management options available for ESP and
AH."
"The
keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL
NOT,
SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when
they
appear in this document, are to be interpreted as
described
in RFC 2119 [Bra97]."
===============================================================================
Commenter: Russ
Housley
Date:
6/17/03
Status:
change approved by Russ on 7/9/03
There is a reference to [STD-2] in the
first paragraph of section 2, but [STD-2] is not listed in the
references.
Section 2. Authentication Header Format, first
paragraph,
first
sentence. Fixed reference:
From:
The protocol header (IPv4, IPv6, or IPv6 Extension)
immediately
preceding the AH header SHALL contain the value 51 in
its
Protocol (IPv4) or Next Header (IPv6, Extension) field
[STD-2].
To:
The protocol header (IPv4, IPv6, or IPv6 Extension)
immediately
preceding the AH header SHALL contain the value 51 in
its
Protocol (IPv4) or Next Header (IPv6, Extension) field
[DH98].
===============================================================================
Commenter: Russ
Housley
Date:
6/17/03
Status:
change approved by Russ on 7/9/03
The references need to be divided in to
normative and informative.
References -- divided into Normative and Informative and deleted
some
references that were no longer being used in the
text.
References
Normative
[Bra97] Bradner, S., "Key words for use in RFCs
to
Indicate Requirement Level", BCP 14, RFC 2119,
March
1997.
[DH98] Deering, S., and R. Hinden, "Internet
Protocol,
Version 6 (IPv6) Specification", RFC 2460,
December
1998.
[KA98a] Kent, S., and R. Atkinson,
"Security
Architecture for the Internet Protocol", RFC
2401,
November 1998.
Informative
[HC03] Holbrook, H., and Cain, B., "Source
Specific
Multicast for IP", Internet
Draft,
draft-ietf-ssm-arch-01.txt, November 3, 2002.
[HC98] Harkins, D., and D. Carrel, "The Internet
Key
Exchange (IKE)", RFC 2409, November 1998.
[KA98b] Kent, S., and R. Atkinson, "IP
Authentication
Header (AH)", RFC 2402, November 1998.
[Ken03] Kent, S., "IP Encapsulating Security
Payload
(ESP)", RFC ???,???? 2003.
[NBBB98] Nichols, K., Blake, S., Baker, F., Black,
D.,
"Definition of the Differentiated Services Field
(DS
Field) in the IPv4 and IPv6 Headers", RFC
2474,
December 1998.
[RFB01] Ramakrishnan, K., Floyd S., Black D.,
"The
Addition of Explicit Congestion Notification
(ECN)
to IP", RFC 3168, September 2001.
===============================================================================
Commenter: David
Black
Date:
6/16/03
Status:
change approved by David on 7/11/03
Section 3.3.3.1.1.1 describes the TOS
field in the IP
Header as mutable (that's correct) and says:
TOS -- This field is excluded
because some routers are known to
change the value of this field, even though the IP
specification
does not consider TOS to be a mutable header field.
That's no longer correct. The TOS field has now been
replaced by a 6 bit DS field (contains a Diffserv
codepoint) plus a 2 bit ECN field, and both are defined
to be mutable. RFC 2780 and RFC 3168 should be cited
as the basis for this, and possibly also RFC 2474. The
same 6 bit DS + 2 bit ECN structure applies to the IPv6
(Traffic) Class field (section 3.3.3.1.2.1), which
has always been mutable, as the same RFCs specify it.
1. Added references
[NBBB98] Nichols, K., Blake, S., Baker, F., Black,
D.,
"Definition of the Differentiated Services
Field
(DS Field) in the IPv4 and IPv6 Headers", RFC
2474,
December 1998.
[RFB01] Ramakrishnan, K., Floyd S., Black D.,
"The
Addition of Explicit Congestion Notification
(ECN)
to IP", RFC 3168, September 2001.
2. Section
3.3.3.1.1.1 Base Header Fields. Changed:
From:
Mutable (zeroed prior to ICV calculation)
Type
of Service (TOS)
To:
Mutable (zeroed prior to ICV calculation)
DSCP
(6 bits, see RFC2474 [NBBB98])
ECN
(2 bits, see RFC3168 [RFB01])
3. Section
3.3.3.1.2.1 Base Header Fields. Changed:
From:
Mutable (zeroed prior to ICV calculation)
Class
To:
Mutable (zeroed prior to ICV calculation)
DSCP
(6 bits, see RFC2474 [NBBB98])
ECN
(2 bits, see RFC3168 [RFB01])
===============================================================================
Commenter: Pekka
Nikander
Date:
7/8/03
Status:
change approved by Pekka on 7/11/03
2.2 Payload Length
This 8-bit field specifies the length of AH in
32-bit words (4-byte
units), minus "2". (This means of
expressing the length of AH was
selected to allow its use as an IPv6 extension
header. Thus the
length computation is consistent with the algorithm
described in RFC
1883.) In the case of an integrity algorithm
that yields a 96-bit
authentication value, plus the 3 32-bit word fixed
portion, this
length field will be "4". See Section
2.6, "Integrity Check Value
(ICV)", for comments on padding of this field,
and Section 3.3.3.2.1
"ICV Padding".
Comments:
- Shouldn't the reference to RFC1883 be replaced with a
reference
to RFC2460, or better, to [DH95]?
- It is probably far too late to change this, but all the
other
IPv6 extension headers define the length in 8-octet
units,
not 4-byte units. If possible, it *would* be
desirable to
update this for IPv6. However, I fully understand
that such
a change may not be possible at this late in
standardization.
(This comment may be ignored, as it most probably has
been
extensively discussed in the past by the WG.)
- For IPv6, there should be a requirement that the length
MUST
be integral in 8-octet units, i.e., that the length must
be
evenly divisible by two.
The requirement for that does exist
in 3.3.3.2.1, but it would be good to briefly repeat it
here.
Suggestion: Insert the following text before
"See Section 2.6"
For IPv6, the total length of the header must
be a multiple of
8-octet
units.
1. References -- Updated IPv6
reference...
From:
[DH95] Deering, S., and R. Hinden,
"Internet Protocol,
Version
6 (IPv6) Specification", RFC 1883, December 1995.
To:
[DH98] Deering, S., and R. Hinden,
"Internet Protocol,
Version
6 (IPv6) Specification", RFC 2460, December 1998.
Also changed references in
the text from [DH95] to [DH98].
2. Added sentence shown above. Such
that 2.2. Payload Length now reads:
2.2
Payload Length
This 8-bit field specifies the length of AH in 32-bit
words (4-byte
units), minus "2". (This means of
expressing the length of AH was
selected to allow its use as an IPv6 extension header.
Thus the
length
computation is consistent with the algorithm described in
RFC
2460
[DH98].) In the case of an integrity algorithm that yields
a
96-bit
authentication value, plus the 3 32-bit word fixed
portion,
this
length field will be "4". For IPv6, the total length of
the
header
must be a multiple of 8-octet units. See Section
2.6,
"Integrity Check Value (ICV)", for comments on padding of
this field,
and
Section 3.3.3.2.1 "ICV Padding".
3. Did not make any
changes re: going from 4-byte units to 8-octet
units.
===============================================================================
Commenter: Pekka
Nikander
Date:
7/8/03
Status:
change approved by Pekka on 7/11/03
2.3 Reserved
This 16-bit field is reserved for future use.
It MUST be set to
"zero." (Note that the value is included
in the ICV calculation, but
is otherwise ignored by the
recipient.)
Comments:
- Why is the value of the field defined as it is? The more
usual
wording seems to be 'MUST be set to "zero" by
the sender, and
SHOULD be ignored by the recipient'. The effect of
the text above
is the same, but someone may try to read it is the value
must
always be zero, and e.g. implement a firewall that drops
packets
where it is non-zero.
Suggestion: Replace with the following text.
This 16-bit field is reserved for future
use. It MUST be set to
"zero" by the sender, and it SHOULD
be ignored by the recipient.
(Note that the value is included in the ICV
calculation, but is
currently otherwise ignored by the
recipient.)
Section 2.3 Reserved.
Changed:
From:
This
16-bit field is reserved for future use. It MUST
be set
to "zero." (Note that the value is included in
the ICV
calculation, but is otherwise ignored by the
recipient.)
To:
This
16-bit field is reserved for future use. It MUST be set
to
"zero" by the sender, and it SHOULD be ignored by
the recipient.
(Note
that the value is included in the ICV calculation, but is
currently otherwise ignored by the recipient.)
===============================================================================
Commenter: Pekka
Nikander
Date:
7/8/03
Status:
change approved by Pekka on 7/11/03
3.3.3.1.2.1 Base Header
Fields
The IPv6 base header fields are classified as
follows:
Immutable
Version
Payload Length
Next Header (This should be the value for
AH.)
Comments:
- The note in the paranthesis is both unnecessary and
misleading,
as there may well be intevening extension
headers.
Suggestion: Remove the
text in paranthesis.
Section 3.3.3.1.2.1 Base
Header Fields. Changed:
From:
The IPv6
base header fields are classified as follows:
Immutable
Version
Payload Length
Next Header (This should be the value for AH.)
To:
The IPv6 base header fields are
classified as follows:
Immutable
Version
Payload Length
Next
Header
===============================================================================
Commenter: Pekka
Nikander
Date:
7/8/03
Status:
change approved by Pekka on 7/14/03
3.3.3 Integrity Check Value
Calculation
....
o the AH header (Next Header,
Payload Len, Reserved, SPI, Sequence
Number (low order 32
bits), and the Authentication Data (which is
set to zero for this
computation), and explicit padding bytes (if
any))
s/Authentication Data/Integrity Check
Value/
Done
===============================================================================
Commenter: Pekka
Nikander
Date:
7/8/03
Status:
change approved by Pekka on 7/14/03
3.3.3.1 Handling Mutable
Fields
.....
calculation. The Authentication Data field is
also set to zero in
s/Authentication Data/Integrity Check
Value/
Done
===============================================================================
Commenter: Pekka
Nikander
Date:
7/8/03
Status:
change approved by Pekka on 7/14/03
Appendix A -- Mutability of IP
Options/Extension Headers
A2. IPv6 Extension Headers
This table shows how the IPv6 Extension Headers are
classified with
regard to "mutability".
Option/Extension
Name Reference
----------------------------------- ---------
MUTABLE BUT PREDICTABLE --
included in ICV calculation
Routing (Type
0) [RFC1883]
BIT INDICATES IF OPTION IS
MUTABLE (CHANGES UNPREDICTABLY DURING
TRANSIT)
Hop by Hop
options [RFC1883]
Destination
options [RFC1883]
NOT APPLICABLE
Fragmentation [RFC1883]
s/[RFC1883]/[DH95]/
Changed to
DH98
Option/Extension
Name Reference
-----------------------------------
---------
MUTABLE BUT PREDICTABLE -- included in ICV
calculation
Routing (Type
0) [DH98]
BIT INDICATES IF OPTION IS MUTABLE (CHANGES
UNPREDICTABLY DURING
TRANSIT)
Hop by Hop
options [DH98]
Destination
options [DH98]
NOT APPLICABLE
Fragmentation [DH98]
===============================================================================
Commenter: Pekka
Nikander
Date:
7/8/03
Status:
change approved by Pekka on 7/14/03
Routing (Type 0) -- The IPv6 Routing Header "Type 0"
will
rearrange the address fields within the packet
during transit from
source to destination. However, the contents
of the packet as it
will appear at the receiver are known to the sender
and to all
intermediate hops. Hence, the IPv6 Routing
Header "Type 0" is
included in the Authentication Data calculation as
mutable but
predictable. The sender must order the field
so that it appears as
it will at the receiver, prior to performing the
ICV computation.
s/Authentication Data/Integrity Check
Value/
Done
===============================================================================