Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs)
draft-ietf-l3vpn-security-framework-03
Discuss
No Objection
(David Kessens)
(Sam Hartman)
(Ted Hardie)
No Record
Note: This ballot was opened for revision 03 and is now closed.
Steven Bellovin Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2004-11-01)
Unknown
(29 March 2004) Good job eight authors 5.1.4 -- Config 1 and 4 are *not* equivalent -- there's a risk of compromise of the PE device. Since many customers are served by each PE, there is more need for access to the PE, perhaps by customer-specific technicians. Also, a typical PE will serve non-encrypted links as well, which makes for easy export of data. (Think of the "clone traffic" feature of some routers.) Not at all clear to me that complexity is best reduced by config 4 -- more knobs on each PE device, compared to the few knobs on each CE. Consider the greater likelihood of inadvertent cross-connection
Allison Mankin Former IESG member
No Objection
No Objection
(2004-04-02)
Unknown
Why does the section on filtering have specifics about fields to filter and rates management to DDos etc? It's pretty weak, for instance, the discussion of CoS, whatever that is. Rate filtering as described would probably render most TCP connections congestive because it would drop enough packets to cause them all to go into backoff.
David Kessens Former IESG member
No Objection
No Objection
()
Unknown
Harald Alvestrand Former IESG member
No Objection
No Objection
(2004-04-01)
Unknown
Reviewed by Scott Brim, Gen-ART
Russ Housley Former IESG member
(was Discuss)
No Objection
No Objection
(2004-04-02)
Unknown
Very good job. 8 authors! This is too many. Many non-ASCII characters. They appear to by Microsoft special characters. Section 3 says: "This document defines each PPVPN as a trusted zone, and the PPVPN core as another trusted zone." However the document does not say what these zones are trusted to do, or trusted not to do. An additional sentence in each case would add clarity. Section 4.1.5 should recognize that it is impossible to completely hide traffic patterns. For example, the amount of traffic between two PPVPN user sites can be determined, even if the observer cannot determine which machines within the PPVPN user sites are exchanging traffic. Section 5.1 says: "... these techniques can provide privacy (encryption) of communication between devices ..." Please see RFC 2828 for the difference between confidentiality and privacy. Confidentiality is provided by encryption. Section 7.1 correctly explains the notion of virtual "private" networks. Section 5.1.1 should also cover authenticated encryption algorithms. AES-CCM is one example which is in the RFC Editor queue. AES-GCM is another example that has some performance advantages, but it is not as far along in the standard process. The "Nce^^2" notation needs explanation or changed to a more standard notation. Suggestions: Nce**2 or Nce^2.
Sam Hartman Former IESG member
No Objection
No Objection
()
Unknown
Scott Hollenbeck Former IESG member
No Objection
No Objection
(2004-03-25)
Unknown
8 authors? ID-Nits says there should be no more than 5 listed. RFC 2119 is listed as reference [1] in the section titled "Conventions used in this document", but it's not listed in the references section. The references need to be split into normative and informative sections.
Ted Hardie Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Thomas Narten Former IESG member
(was Discuss, Yes)
No Objection
No Objection
(2004-03-23)
Unknown
Editorial: > DOS attacks of the resource exhaustion type can be mounted against > the data plane of a particular PPVPN by inserting an overwhelming > quantity of non-authentic data into the VPN. > Is the above a DOS attack intitiated within the PPVPN? I thought these attacks were out-of-scope for this document? > This includes unauthorized access to service provider > infrastructure equipment, which access can be used to reconfigure > the equipment, or to extract information (statistics, topology, > etc.) about one or more PPVPNs. sentence doesn't really parse. > - If some part of the backbone network is not trusted, > particularly in implementations where traffic may travel across > the Internet or multiple provider networks, then the PE-PE > traffic may encrypted. s/may/may need to be/ ? > There are several widely used standards-based protocols to support > remote access authentication. These include RADIUS [ref] and > DIAMETER [ref]. Digital certificate systems also provide > authentication. In addition there has been extensive development > and deployment of mechanisms for securely transporting individual > remote access connections within tunneling protocols, including > L2TP [ref] and IPsec. need proper references > Within a PPVPN service, a given PPVPN can use the full Internet > address range, including private address ranges [RFC1918], without > interfering with other PPVPNs that use the same PPVPN service. When > using Internet access through the PPVPN core a NAT functionality > can be implemented. Don't understand the comment about NAT. What does it have to do with this document? > 6.2. Protection > > The perception of a completely separated, "private" network is that > it has defined entry points, and only over those is can be attacked > or intruded. By sharing a common core a PPVPN appears to lose some parsing problem? > Normal TTL propagation may be altered to make the backbone look > like one hop from the outside, but caution needs to be taken for > loop prevention. This prevents the backbone addresses to be exposed s/to be/from being/ > through trace route, however this must also be assessed against
Bert Wijnen Former IESG member
No Record
No Record
(2004-04-02)
Unknown
Page 27 talks about "SNMP traps". The proper terminology is "SNMP notifications" which can be sent as traps (unconfirmed) or informs (confirmed)