Skip to main content

Security Architecture for the Internet Protocol
RFC 4301

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 steering group member) (was Discuss, Yes) Yes

Yes (2004-12-08)
  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

No Objection ()

                            

(Bert Wijnen; former steering group member) No Objection

No Objection ()

                            

(Bill Fenner; former steering group member) No Objection

No Objection ()

                            

(David Kessens; former steering group member) No Objection

No Objection ()

                            

(Harald Alvestrand; former steering group member) No Objection

No Objection (2005-01-06)
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

No Objection ()

                            

(Margaret Cullen; former steering group member) No Objection

No Objection ()

                            

(Sam Hartman; former steering group member) (was Discuss) No Objection

No Objection (2005-01-06)
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

No Objection ()

                            

(Ted Hardie; former steering group member) No Objection

No Objection (2005-01-04)
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

No Objection ()

                            

(Alex Zinin; former steering group member) (was Discuss) Abstain

Abstain (2005-04-11)
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.