IP Encapsulating Security Payload (ESP)
RFC 4303

Note: This ballot was opened for revision 10 and is now closed.

(Harald Alvestrand) Discuss

Discuss (2005-01-06 for -)
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?
Comment (2005-01-06 for -)
No email
send info
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?

(Steven Bellovin) Discuss

Discuss (2004-03-24)
Section 6 can't be evaluated until 2401bis shows up

(Russ Housley) Yes

(Randy Bush) No Objection

(Brian Carpenter) No Objection

Comment (2005-03-16)
No email
send info
Changes agreed with the authors and Russ resolve Harald's DISCUSS, which was actually the result of my Gen-ART review.

(Margaret Cullen) No Objection

(Bill Fenner) No Objection

(Ned Freed) No Objection

(Ted Hardie) No Objection

Comment (2003-10-02)
No email
send info
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.

(Sam Hartman) No Objection

(Scott Hollenbeck) No Objection

(David Kessens) No Objection

(Allison Mankin) (was Discuss, No Objection) No Objection

Comment (2005-03-31)
No email
send info
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.

(Thomas Narten) No Objection

(Jon Peterson) (was Discuss) No Objection

(Mark Townsley) No Objection

Comment (2005-03-30)
No email
send info
Formatting for SAD lookup steps on page 11 and 12 seem to be off.

(Bert Wijnen) (was Discuss) No Objection

(Alex Zinin) No Objection