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
  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 email
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 email
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
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
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.