Security Architecture for the Internet Protocol
draft-ietf-ipsec-rfc2401bis-06
Yes
No Objection
(Allison Mankin)
(Bert Wijnen)
(Bill Fenner)
(David Kessens)
(Jon Peterson)
(Margaret Cullen)
(Scott Hollenbeck)
(Thomas Narten)
Abstain
Note: This ballot was opened for revision 06 and is now closed.
Russ Housley Former IESG member
(was Discuss, Yes)
Yes
Yes
(2004-12-08)
Unknown
Section 4.1: s/Memory (TCAM0 features/Memory (TCAM) features/ Section 4.4.1: s/SPD-SPD-S, SPD-SPD-I, SPD-SPD-O/SPD-S, SPD-I, SPD-O/ s/The SPD-SPD-S/The SPD-S/ Section 4.4.2: s/Database(SAD),/Database (SAD),/ Section 8.2.1: s/SAD entry When/SAD entry. When/
Allison Mankin Former IESG member
No Objection
No Objection
()
Unknown
Bert Wijnen Former IESG member
No Objection
No Objection
()
Unknown
Bill Fenner Former IESG member
No Objection
No Objection
()
Unknown
David Kessens Former IESG member
No Objection
No Objection
()
Unknown
Harald Alvestrand Former IESG member
No Objection
No Objection
(2005-01-06)
Unknown
Reviewed by Brian Carpenter, Gen-ART There are nits and small comments (review in document log), but no show-stoppers.
Jon Peterson Former IESG member
No Objection
No Objection
()
Unknown
Margaret Cullen Former IESG member
No Objection
No Objection
()
Unknown
Sam Hartman Former IESG member
(was Discuss)
No Objection
No Objection
(2005-01-06)
Unknown
Section 6.1.2 creates requirements for incoming ICMP packets on the protected side of the IPsec boundary. As best I can tell the attacks described in that section are potential problems for any Internet gateway and have nothing to do with IPsec. If so, why should the IPsec architecture add requirements for additional administrative controls to mitigate these attacks? (I think the administrative controls are a good idea; I'm just unsure why this specification is the right place for them.)
Scott Hollenbeck Former IESG member
No Objection
No Objection
()
Unknown
Ted Hardie Former IESG member
No Objection
No Objection
(2005-01-04)
Unknown
This seems to have a mix of RFC 2026 and RFC 3668 boilerplates. In Section 4.1, the draft says: In many secure multicast (or anycast) architectures, e.g., [RFC3740], a central Group Controller/Key Server unilaterally assigns the Group Security Association's (GSA's) SPI. 3740 does not seem to mention anycast. Is there a similar reference for anycast? Section 4.4.1 uses 192.168 addresses, rather than the example prefix 192.0.2.x/24 I found the use of "road warrior" in section 4.5.2 distracting.
Thomas Narten Former IESG member
No Objection
No Objection
()
Unknown
Alex Zinin Former IESG member
(was Discuss)
Abstain
Abstain
(2005-04-11)
Unknown
The document attempts to cover certain VPN-related issues, but the routing- related part is not adequate. It would take a lot of time and effort to improve the document from that perspective. Hence changing to ABSTAIN.