WG Last Call: draft-ietf-ipsec-esp-v3-05

[Russ Housley <housley@vigilsec.com>]

I have a few comments on the updated ESP specification.

1.  Please delete the last line of the Abstract.  In my opinion, pointers 
to subsequent sections belong in the Introduction, not the Abstract.

2.  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.

3.  The last paragraph on page 4 includes:

    Typically this binding is effected through the use of a shared,
    symmetric key, but an asymmetric cryptographic algorithm also may be
    employed, e.g., to sign a hash.)

Digitally signing individual packets should not be encouraged.  The 
performance ramifications, both computational and packet bloat, are 
extreme.  I suggest dropping the second half of the sentence.  Just do not 
bring it up.

4.  The first full paragraph at the top of page 5 includes:

    Although confidentiality and integrity can be offered independently,
    most ESP use typically will employ both services, i.e., packets will
    be protected with regard to confidentiality and integrity.

s/use/uses/

5.  The following paragraph appears on the second half of page 7:

    When any combined mode algorithm is employed, the algorithm itself is
    expected to return both decrypted plaintext and a pass/fail
    indication for the integrity check. For combined mode algorithms, the
    ICV that would normally appear at the end of the ESP packet (when
    integrity is selected) is omitted. It is the responsibility of the
    combined mode algorithm to encode within the payload data an ICV-
    equivalent means of verifying the integrity of the packet.

I consider CCM (see draft-ietf-ipsec-ciph-aes-ccm-03) to be a combined 
mode.  The referenced specification makes use of the ICV field.  Therefore, 
I propose two changes:

    - Please replace "is omitted" to "may be omitted"

    - Please change "It is the responsibility of the combined mode 
algorithm ..." to "When the ICV is omitted and integrity is selected, it is 
the responsibility of the combined mode algorithm ..."

6.  Figure 2 include "IV (optional]. "
s/]/)/

7.  Below Figure 2, the following paragraph appears:

    If a combined algorithm mode is employed, the explicit ICV shown in
    Figures 1 and 2 is omitted (see Section 3.3.2.2 below). Since
    algorithms and modes are fixed when an SA is established, the
    detailed format of ESP packets for a given SA (including the Payload
    Data substructure) is fixed, for all traffic on the SA.

s/is omitted/may be omitted/

8.  In Table 2, the ICV row should be "O" in the "Requ'd" column.

9.  The first sentence in section 2.2.1, has the flavor of a new option 
that is under development, rather than one that is ready to be 
finalized.  I propose an alternative:

    To support high-speed IPsec implementations, extended sequence
    numbers SHOULD be implemented.

10.  At the beginning of section 2.4, the following sentence is followed by 
two bullets.  Something is not quite right.

    Three factors require or motivate use of the Padding field.

11.  Please reword the paragraph in section 2.8 to permit the ICV field to 
be present when a combined mode is employed, which is consistent with the 
wording used in section 3.2.3.

12. Please reword the 4th bullet following the paragraph numbered 3 in 
section 3.3.2.2 to permit the ICV field to be present when a combined mode 
is employed.

13.  I am confused by "DISCUSSION" in section 3.4.4.1.

Russ