Skip to main content

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)