[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Minor comments to draft-ietf-ipsec-esp-v3-05.txt
- To: email@example.com
- Subject: Minor comments to draft-ietf-ipsec-esp-v3-05.txt
- From: Pekka Nikander <firstname.lastname@example.org>
- Date: Mon, 16 Jun 2003 10:31:13 +0300
- In-Reply-To: <email@example.com>
- References: <firstname.lastname@example.org>
- Sender: email@example.com
- User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312
[Resending to the list, the original did not get through.]
Barbara Fraser wrote:
> This is a working group last call for comments on the following drafts,
> for progression to Proposed Standard:
Enclosed a set of minor comments to the rfc2402bis draft.
I am reviewing the draft from the SEND WG point of view, and
these comments are ones that do involve any SEND specific issues.
However, even though these are really minor, they are not purely
editorial, and may have some WG interest.
I will shortly send another set of comments, more from the SEND WG
point of view.
SEND WG co-chair
> 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 220.127.116.11.1
> "ICV Padding".
- 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 18.104.22.168.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
> 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.)
- 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.)
> 22.214.171.124.2.1 Base Header Fields
> The IPv6 base header fields are classified as follows:
> Payload Length
> Next Header (This should be the value for AH.)
- The note in the paranthesis is both unnecessary and misleading,
as there may well be intevening extension headers.
Suggestion: Remove the text in paranthesis.
> [DH95] Deering, S., and B. Hinden, "Internet Protocol version 6
> (IPv6) Specification", RFC 1883, December 1995.
- Should this be replaced with a reference to RFC 2460?
Suggestion: Replace with a reference to RFC2460.