IP Encapsulating Security Payload (ESP)
draft-ietf-ipsec-esp-v3-10
Discuss
Yes
(Russ Housley)
No Objection
(Alex Zinin)
(Bert Wijnen)
(Bill Fenner)
(David Kessens)
(Jon Peterson)
(Margaret Cullen)
(Ned Freed)
(Randy Bush)
(Sam Hartman)
(Scott Hollenbeck)
(Thomas Narten)
Note: This ballot was opened for revision 10 and is now closed.
Harald Alvestrand Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2005-01-06)
Unknown
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 Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2004-03-24)
Unknown
Section 6 can't be evaluated until 2401bis shows up
Russ Housley Former IESG member
Yes
Yes
()
Unknown
Alex Zinin Former IESG member
No Objection
No Objection
()
Unknown
Allison Mankin Former IESG member
(was Discuss, No Objection)
No Objection
No Objection
(2005-03-31)
Unknown
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.
Bert Wijnen Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Bill Fenner Former IESG member
No Objection
No Objection
()
Unknown
Brian Carpenter Former IESG member
No Objection
No Objection
(2005-03-16)
Unknown
Changes agreed with the authors and Russ resolve Harald's DISCUSS, which was actually the result of my Gen-ART review.
David Kessens Former IESG member
No Objection
No Objection
()
Unknown
Jon Peterson Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Margaret Cullen Former IESG member
No Objection
No Objection
()
Unknown
Mark Townsley Former IESG member
No Objection
No Objection
(2005-03-30)
Unknown
Formatting for SAD lookup steps on page 11 and 12 seem to be off.
Ned Freed Former IESG member
No Objection
No Objection
()
Unknown
Randy Bush Former IESG member
No Objection
No Objection
()
Unknown
Sam Hartman Former IESG member
No Objection
No Objection
()
Unknown
Scott Hollenbeck Former IESG member
No Objection
No Objection
()
Unknown
Ted Hardie Former IESG member
No Objection
No Objection
(2003-10-02)
Unknown
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.
Thomas Narten Former IESG member
No Objection
No Objection
()
Unknown