Security Architecture for the Internet Protocol
RFC 4301
Yes
No Objection
Abstain
Note: This ballot was opened for revision 06 and is now closed.
(Russ Housley; former steering group member) (was Discuss, Yes) Yes
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 steering group member) No Objection
(Bert Wijnen; former steering group member) No Objection
(Bill Fenner; former steering group member) No Objection
(David Kessens; former steering group member) No Objection
(Harald Alvestrand; former steering group member) No Objection
Reviewed by Brian Carpenter, Gen-ART There are nits and small comments (review in document log), but no show-stoppers.
(Jon Peterson; former steering group member) No Objection
(Margaret Cullen; former steering group member) No Objection
(Sam Hartman; former steering group member) (was Discuss) No Objection
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 steering group member) No Objection
(Ted Hardie; former steering group member) No Objection
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 steering group member) No Objection
(Alex Zinin; former steering group member) (was Discuss) Abstain
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.