Document: draft-ietf-ipsec-rfc2402bis-10.txt 
Trigger: IESG Discussion, 6 Januray 2005
Reviewer: Elwyn Davies
AD: Russ Housley
Review Date: 3 January 2005

Intended status: Proposed Standard (revised)

Summary: This document is essentially ready for recycling at Proposed
Standard.  There are a small number of nits that need to be addressed,
especially with respect to references and terminology, but it seems in
good shape.

Review: The document appears to be essentially ready as a recycled
Proposed Standard (updating RFC2402).

There are a small number of nits that should be addressed:

Throughout: Should we be using octets instead of bytes?

Section 1 and Informative Refs: The document is self-referential!
[Ken-AH] is {this document}.

Section 1: It would be useful to point out that the document uses the
terminology defined in the Security Architecture.  With this in mind,
one or two terms (especially 'next layer protocol' could be
capitalized to emphasise that they are defined in the Security
Architecture).

Section 2: In the figure: s/Integrity Check Value-ICV (variable)/
                            Integrity Check Value-ICV (variable
                            length)/
Also I found the table a little confusing on first reading.. takes
some time to realise that that the ESN and ICV padding are not
trailers but 'virtual fields' which are not transmitted.  Maybe this
could be emphasised a little earlier.

Section 2.5, para 1: s/anti-reply/anti-replay/

References:
- Arguably, the IKE ref [HC98] is normative
- IKEv2 should be referenced with the same same status as IKE
- The IPv6 Flow Label RFC should be referenced (normative)
- Arguably, the DiffServ [NBBB98] and ECN [RBF01] refs are normative

Appendix A2: It occurred to me when I read about mutable options in
IPv6 Destination Headers that these do not make much sense for
end-to-end Destination Headers and indeed there is a degree of
inconsistency between Section 3.1.1 (where at least some of the
destination headers are said to be immutable) and the Appendix
statement, quoting RFC2460.  I guess Destination Options associated
with routing headers could be mutable.  Some weasel words might be
useful.

Appendix A2: The main body (Section 3.1.1 etc) refer in general to
IPv6 Routing Headers.  The Appendix calls out explicitly Type 0
Routing Headers... however things have moved on and there is the Type
2 Routing Header for Mobile IPv6 now.  In practice, I would have
thought that the same arguments should apply to any routing header
(regarding predictability at the ultimate destination).  I think this
could be safely generalised.

Meta-criticism (General whinge): AH (and ESP) define the length of the
'extension header' in IPv6 packets in 32 bit units instead of the
default 64 bit unit.  The inconsistency in the L part of TLV format of
IPv6 extension headers is a blot on the landscape of IPv6, making it
harder for IPv6 hardware to work fast, and increasing the complexity
of software, as well as making it difficult to skip over headers (see
v6ops Security Overview draft).  Fragmentation headers are also part
of the problem.  It is almost surely too late to do anything about
this, but it should have been picked up in earlier reviews (had they
been being done!)