IP Encapsulating Security Payload (ESP)
draft-ietf-ipsec-esp-v3-10

[Ballot comment]
Sorry it took me a while to reconcile to the limited degree of
support of my Discuss in the new text...I did speak with an
ALC (single-source large scale multicast) person about the
issue of IPSec in that scenario.  Not clear actually what does give
key management help at the scales of end-users - 1 sender,
10,000 or more receivers.

[Ballot discuss]
There are one to many applications (multicast, SSM) which can't use IKE but for which anti-replay
protection is very important.  A significant example is a FLUTE (RFC 3926) server, either one that
would use ESN or not  Even a one-to-one application with ESN may not have access to IKE,
for instance a hardware-IPsec MPEG4 server, and it probably has less reason to fear the issues
about sequence number rollover in Section 5.  So my Discuss is to request lessening the SHOULD
NOT against anti-replay protection for systems using manual key management.  This is pertinent
to Section 5, and also to the passage in 3.3.3 where it is stated

  The sender assumes anti-replay is enabled as a default, unless
  otherwise notified by the receiver (see 3.4.3) or if the SA was
  configured using manual key management. [3.3.3]

[Ballot discuss]
Cause for concern:

I'm a bit concerned that there are backwards-incompatible
requirements (e.g. new padding support) but no version number.
For product support and widespread deployment, this looks
like a nightmare. In fact, I don't see how to handle it if
a server has to talk to some unknown clients that support v3
and some that don't. Since the clients are unknown,
configuration is impossible. It puts an even bigger burden on IKE.

Me:

We have had previous instances where a specification was depending on IKE for negotation, and IKE did not support negotating that feature. Is IKE compatible with this specification?

[Ballot comment]
Reviewed by Brian Carpenter, Gen-ART

Full review in comments.

Cause for concern:

I'm a bit concerned that there are backwards-incompatible
requirements (e.g. new padding support) but no version number.
For product support and widespread deployment, this looks
like a nightmare. In fact, I don't see how to handle it if
a server has to talk to some unknown clients that support v3
and some that don't. Since the clients are unknown,
configuration is impossible. It puts an even bigger burden on IKE.

Me:

We have had previous instances where a specification was depending on IKE for negotation, and IKE did not support negotating that feature. Is IKE compatible with this specification?

Review by Brian Carpenter, Gen-ART

His review:

I think this is ready, but I do have two concerns and there are nits.

> 2.  Encapsulating Security Payload Packet Format
...
>    ESP does not contain a version number, therefore if there are
>    concerns about backward compatibility, they MUST be addressed by
>    using a signaling mechanism between the two IPsec peers to ensure
>    compatible versions of ESP, e.g., IKE or an out-of-band
> configuration
>    mechanism.

I'm a bit concerned that there are backwards-incompatible
requirements (e.g. new padding support) but no version number.
For product support and widespread deployment, this looks
like a nightmare. In fact, I don't see how to handle it if
a server has to talk to some unknown clients that support v3
and some that don't. Since the clients are unknown,
configuration is impossible. It puts an even bigger burden on IKE.


I'm naive about cryptography, but this paragraph in section 2.4
raises a question in my mind:

>    If Padding bytes are needed but the encryption algorithm does not
>    specify the padding contents, then the following default processing
>    MUST be used.  The Padding bytes are initialized with a series of
>    (unsigned, 1-byte) integer values.  The first padding byte appended
>    to the plaintext is numbered 1, with subsequent padding bytes making
>    up a monotonically increasing sequence: 1, 2, 3, ...  When this
>    padding scheme is employed, the receiver SHOULD inspect the Padding
>    field.  (This scheme was selected because of its relative
> simplicity,
>    ease of implementation in hardware, and because it offers limited
>    protection against certain forms of "cut and paste" attacks in the
>    absence of other integrity measures, if the receiver checks the
>    padding values upon decryption.)

I thought it was considered a Bad Thing cryptographically to have
any kind of predictable sequence in the plaintext - yet this mandates
a highly predictable sequence.

Nits:

idnits 1.58

tmp/draft-ietf-ipsec-esp-v3-09.txt:

  Checking nits according to http://www.ietf.org/ID-Checklist.html :

  * The document seems to lack an IANA Considerations section.
    Checking conformance with RFC 3667/3668 boilerplate...
  * The document claims conformance with section 10 of RFC 2026, but
uses
    some RFC 3667/3668 boilerplate.  As RFC 3667/3668 replaces section
10 of RFC
    2026, you should not claim conformance with it if you have changed
to using
    RFC 3667/3668 boilerplate.
  * The document seems to lack an RFC 3668 Section 5, para 1 IPR
Disclosure
    Acknowledgement -- however, there's a paragraph with a matching
beginning.
    Boilerplate error?
  * The document seems to lack an RFC 3668 Section 5, para 2 IPR
Disclosure
    Acknowledgement.
  * The document seems to lack an RFC 3668 Section 5, para 3 IPR
Disclosure
    Invitation -- however, there's a paragraph with a matching
beginning.
    Boilerplate error?
    ( - It does however have an RFC 2026 Section 10.4(B) IPR Disclosure
    Invitation.)
  * There are 35 instances of too long lines in the document, the
longest
    one being 4 characters in excess of 72.

  Checking nits according to
http://www.ietf.org/ietf/1id-guidelines.txt :

  * The document seems to lack a 1id_guidelines paragraph about
    Internet-Drafts being working documents.
  * The document seems to lack a 1id_guidelines paragraph about 6 months
    document validity.
  * The document seems to lack a 1id_guidelines paragraph about the
list of
    current Internet-Drafts -- however, there's a paragraph with a
matching
    beginning. Boilerplate error?

  Miscellaneous warnings:

  - There are 9 instances of lines with hyphenated line breaks in the
    document.
  - Line 347 has weird spacing: '...t Integ    is...'
  - Line 376 has weird spacing: '...t Integ    is...'
  - Line 380 has weird spacing: '...  plain    p...'
  - Line 386 has weird spacing: '... cipher  d...'

    Run idnits with the --verbose option for more detailed information.

[Ballot discuss]
This document states that mandatory-to-implement security algorithms are described in a separate draft; however, there is no normative reference to that draft given in this document. This document needs to block until the "algorithms" draft is available.

[Ballot discuss]
- Is this a doc going to OBSOLETE 2406? If so, then I believe
  we want the abstract to say so (so that it is very clear).
- It says (in abstract):
    Comments should be sent to Stephen Kent (kent@bbn.com).
  Mmm... not to ipsec mailing list?
- missing IPR section
- Strange disclaimer on page 35 (do we do such things?):

    Disclaimer

    The views and specification here are those of the authors and are not
    necessarily those of their employers.  The authors and their
    employers specifically disclaim responsibility for any problems
    arising from correct or incorrect implementation or use of this
    specification.

[Ballot comment]
Section 3.2.1 mentions FIPS 140-2, but it is not included in
the informative references.

The logic in A.3 for the unlikeliness of the loss of 2^32
consecutive packets over a single SA seems compelling,
but in reading it I was struck it seems to assume that
at least one of the two sides is a host. In an association
between two security gateways, are there conditions
in which the same assumptions might not hold? If so,
would it be valuable to mention those conditions? I note
that the document provides a mechanism for handling
the loss when it does occur, so going into the different
conditions may not be worth the extra effort.

[Ballot discuss]
2.6 says that the transmitter MUST be capable of generating dummy
packets. Without saying how this is controlled, that's meaningless.
Must there be some API to control generation of dummy packets?

2.7: The UDP header contains an explicit length, and thus can be used
with TFC in transport mode. To be sure, the document says "e.g." when
I think it means "i.e.", but the implication of the text is clear: TFC
is for tunnel mode only. But given UDP (and given other possible next
protocols), the spec should state the tunnel mode-only restriction
explicitly.

Section 6 can't be evaluated until 2401bis shows up