Security Architecture for the Internet Protocol
RFC 4301
Note: This ballot was opened for revision 06 and is now closed.
(Russ Housley) (was Discuss, Yes) Yes
Comment (2004-12-08)
No email
send info
send info
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/
(Harald Alvestrand) No Objection
Comment (2005-01-06 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
send info
Reviewed by Brian Carpenter, Gen-ART There are nits and small comments (review in document log), but no show-stoppers.
(Margaret Cullen) No Objection
(Bill Fenner) No Objection
(Ted Hardie) No Objection
Comment (2005-01-04 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
send info
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.
(Sam Hartman) (was Discuss) No Objection
Comment (2005-01-06)
No email
send info
send info
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) No Objection
(David Kessens) No Objection
(Allison Mankin) No Objection
(Thomas Narten) No Objection
(Jon Peterson) No Objection
(Bert Wijnen) No Objection
(Alex Zinin) (was Discuss) Abstain
Comment (2005-04-11)
No email
send info
send info
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.