Skip to main content

Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs)
draft-ietf-l3vpn-security-framework-03

Revision differences

Document history

Date Rev. By Action
2012-08-22
03 (System) post-migration administrative database adjustment to the No Objection position for Thomas Narten
2012-08-22
03 (System) post-migration administrative database adjustment to the No Objection position for Ted Hardie
2012-08-22
03 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2004-12-09
03 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2004-12-07
03 Amy Vezza IESG state changed to Approved-announcement sent
2004-12-07
03 Amy Vezza IESG has approved the document
2004-12-07
03 Amy Vezza Closed "Approve" ballot
2004-11-30
03 Thomas Narten State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Thomas Narten
2004-11-30
03 Thomas Narten [Ballot Position Update] Position for Thomas Narten has been changed to No Objection from Discuss by Thomas Narten
2004-11-30
03 Thomas Narten Note field has been cleared by Thomas Narten
2004-11-30
03 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley
2004-11-24
03 Sam Hartman [Ballot Position Update] New position, No Objection, has been recorded for Sam Hartman by Sam Hartman
2004-11-24
03 Thomas Narten State Change Notice email list have been change to luyuanfang@att.com ,rick@rhwilder.net,rcallon@juniper.net,rbonica@juniper.net from luyuanfang@att.com ,rick@rhwilder.net,rcallon@juniper.net,Ronald.P.Bonica@mci.com
2004-11-23
03 (System) New version available: draft-ietf-l3vpn-security-framework-03.txt
2004-11-01
03 Steven Bellovin
[Ballot discuss]
(29 March 2004)
        Good job
        eight authors
        5.1.4 -- Config 1 …
[Ballot discuss]
(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
2004-07-31
03 Russ Housley
[Ballot discuss]
Section 5.1.1 says:
  >
  > The currently recommended mechanism to provide a combination of
  > confidentiality, data origin authentication, and …
[Ballot discuss]
Section 5.1.1 says:
  >
  > The currently recommended mechanism to provide a combination of
  > confidentiality, data origin authentication, and connectionless
  > integrity is the use of AES in CCM (Counter with CBC-MAC) mode
  > (AES-CCM) [AES-CCM], with an explicit initialization vector (IV),
  > as the IPsec ESP.
  >
  While I really like AES-CCM, it requires automated key management to
  be secure.  This document does not require IKE or any other automated
  key management.  It needs to specify an automated key management
  mechanism or pick an encryption algorithm that does not require
  automated key management (such as AES-CBC with HMAC-SHA-1).
2004-07-28
03 Ted Hardie [Ballot Position Update] Position for Ted Hardie has been changed to No Objection from Discuss by Ted Hardie
2004-07-20
03 (System) Sub state has been changed to AD Follow up from New Id Needed
2004-07-20
02 (System) New version available: draft-ietf-l3vpn-security-framework-02.txt
2004-04-20
03 Thomas Narten [Note]: '2004-04-02: IESG telechat flushed out comments, WG is looking at them.' added by Thomas Narten
2004-04-03
03 (System) Removed from agenda for telechat - 2004-04-02
2004-04-02
03 Amy Vezza State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza
2004-04-02
03 Bert Wijnen [Ballot comment]
Page 27 talks about "SNMP traps".
The proper terminology is "SNMP notifications"
which can be sent as traps (unconfirmed) or informs (confirmed)
2004-04-02
03 Bert Wijnen [Ballot Position Update] New position, Undefined, has been recorded for Bert Wijnen by Bert Wijnen
2004-04-02
03 Russ Housley
[Ballot discuss]
Section 5.1.1 goes out of its way to not recommend an encryption
  algorithm, then it identifies a specific integrity algorithm.
  While …
[Ballot discuss]
Section 5.1.1 goes out of its way to not recommend an encryption
  algorithm, then it identifies a specific integrity algorithm.
  While it does not require the use of this algorithm, I find the
  unbalanced presentation concerning.  Either add a "such as"
  statement for AES encryption, or remove the "such as" statement
  for HMAC with SHA-1.

  Section 5.1.4 says: "If protection from wiretaps is most important,
  then configurations 1 and 4 are equivalent."  The use of "wiretap"
  is too narrow, or it is confusing (at least to me).  I am not trying
  to open a discussion about court ordered wiretaps, but it is a
  connotation that is raised by the current wording.  Most telephone
  wiretaps are not performed on the links themselves.  They are done
  at the central office, which are the points between the protected
  hops in this discussion, The number of places where plaintext can be
  viewed is much greater in configuration 4.  Links are not the only
  place where the data can be viewed.
2004-04-02
03 Russ Housley
[Ballot comment]
Very good job.

  8 authors!  This is too many.
 
  Many non-ASCII characters.  They appear to by Microsoft special
  characters. …
[Ballot comment]
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.
2004-04-02
03 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded for Russ Housley by Russ Housley
2004-04-02
03 Allison Mankin
[Ballot comment]
Why does the section on filtering have specifics about fields to filter and rates
management to DDos etc?  It's pretty weak, for instance, …
[Ballot comment]
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.
2004-04-02
03 Allison Mankin [Ballot Position Update] New position, No Objection, has been recorded for Allison Mankin by Allison Mankin
2004-04-01
03 David Kessens [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens
2004-04-01
03 Harald Alvestrand [Ballot comment]
Reviewed by Scott Brim, Gen-ART
2004-04-01
03 Harald Alvestrand [Ballot Position Update] New position, No Objection, has been recorded for Harald Alvestrand by Harald Alvestrand
2004-03-31
03 Ted Hardie
[Ballot discuss]
Both the l3vpn requirements document section 6.9 (Security) and the l3vpn framework document
section 3.1.1.2 (dynamic binding) have discussions about how mobility  will …
[Ballot discuss]
Both the l3vpn requirements document section 6.9 (Security) and the l3vpn framework document
section 3.1.1.2 (dynamic binding) have discussions about how mobility  will affect the real
time protocol interactions.  Reading this document, it was not clear to me whether it
was meant to cover the interaction of mobility with these security considerations (That is,
if the authors considered and rejected template items like "Security mechanism for method
$FOO works with mobile end points using protocol $BAR for mobility").  Additional text on
this topic would help ensure that the reader knows whether the template does not
contain such text as it is not needed because of some aspect of the problem space,
is not present because it is out of scope for the document, or is implicit in one of
the considerations.
2004-03-31
03 Ted Hardie [Ballot Position Update] New position, Discuss, has been recorded for Ted Hardie by Ted Hardie
2004-03-29
03 Steven Bellovin
[Ballot discuss]
(29 March 2004)
        Good job
        eight authors
        8 non-ascii characters
  …
[Ballot discuss]
(29 March 2004)
        Good job
        eight authors
        8 non-ascii characters
        4.2.4 -- mention that this is a logical concept, not just a
                physical one?
        5.1.1 -- DES not yet deprecated in RFCs
        5.1.2 -- TLS and SSL are not the same thing
                IPsec often inappropriate here
        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
        5.3.1, 5.3.2 -- mention the conflict between filtering and
                encryption
        8.2: Misnumbering of subsections as part of 7
2004-03-29
03 Steven Bellovin
[Ballot discuss]
Good job
        eight authors
        8 non-ascii characters
        4.2.4 -- mention that …
[Ballot discuss]
Good job
        eight authors
        8 non-ascii characters
        4.2.4 -- mention that this is a logical concept, not just a
                physical one?
        5.1.1 -- DES not yet deprecated in RFCs
        5.1.2 -- TLS and SSL are not the same thing
                IPsec often inappropriate here
        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
        5.3.1, 5.3.2 -- mention the conflict between filtering and
                encryption
        8.2: Misnumbering of subsections as part of 7
2004-03-29
03 Steven Bellovin [Ballot Position Update] New position, Discuss, has been recorded for Steve Bellovin by Steve Bellovin
2004-03-25
03 Scott Hollenbeck [Ballot Position Update] Position for Scott Hollenbeck has been changed to No Objection from Undefined by Scott Hollenbeck
2004-03-25
03 Scott Hollenbeck
[Ballot comment]
8 authors?  ID-Nits says there should be no more than 5 listed.

RFC 2119 is listed as reference [1] in the section titled …
[Ballot comment]
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.
2004-03-25
03 Scott Hollenbeck [Ballot comment]
8 authors?  ID-Nits says there should be no more than 5 listed.
2004-03-25
03 Scott Hollenbeck [Ballot Position Update] New position, Undefined, has been recorded for Scott Hollenbeck by Scott Hollenbeck
2004-03-23
03 Thomas Narten
[Note]: 'Note: incorporates comments from security review solicited by Russ. I''ve put in a Discuss on things that are editorial and formatting; Given that it …
[Note]: 'Note: incorporates comments from security review solicited by Russ. I''ve put in a Discuss on things that are editorial and formatting; Given that it took almost 4 months to get the (small number of) changes from the security review done, I want to go ahead and get the full IESG comments before going back to the WG/authors.' added by Thomas Narten
2004-03-23
03 Thomas Narten
[Ballot discuss]
The following are mostly borderline editorial/nits comments. But a couple of
of the items normally get taken care of before the document
reaches …
[Ballot discuss]
The following are mostly borderline editorial/nits comments. But a couple of
of the items normally get taken care of before the document
reaches the IESG.

>    Note: Even private networks do not necessarily meet the
>    requirements of confidentiality, integrity and anti-reply. Thus
>    when comparing private to "virtually private" PPVPN services these
>    requirements are only applicable if the comparable private service
>    also included these services.

this seems to be saying if an existing VPN (over say leased lines)
doesn't provide encryption and replay protection, a VPN over the
internet doesn't have to. But that is not true, since the fact that a
VPN is on the internet makes it trivially easier to attack the VPN.

>    - User control plane separation û routing isolation
>    - User address space separation û supporting overlapping addresses
>    - User data plane separation û one VPN traffic cannot be
>      intercepted by other VPNs or any other users.

non-ascii characters


>    - Techniques highlighted through this document identify
>      methodologies for the protection of PPVPN resources and
>      infrastructure. By following these approaches a secure VPN
>      service can be delivered without the absolute need for
>      cryptographic techniques

This comment seems dubious.

split references into normative/non-normative.
2004-03-23
03 Thomas Narten
[Ballot comment]
Editorial:

>    DOS attacks of the resource exhaustion type can be mounted against
>    the data plane of a particular PPVPN …
[Ballot comment]
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
2004-03-23
03 Thomas Narten
[Ballot discuss]
The following are mostly borderline editorial/nits comments. But a couple of
(last) items below normally get taken care of before the document
reaches …
[Ballot discuss]
The following are mostly borderline editorial/nits comments. But a couple of
(last) items below normally get taken care of before the document
reaches the IESG.

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

>    Note: Even private networks do not necessarily meet the
>    requirements of confidentiality, integrity and anti-reply. Thus
>    when comparing private to "virtually private" PPVPN services these
>    requirements are only applicable if the comparable private service
>    also included these services.

this seems to be saying if an existing VPN (over say leased lines)
doesn't provide encryption and replay protection, a VPN over the
internet doesn't have to. But that is not true, since the fact that a
VPN is on the internet makes it trivially easier to attack the VPN.

>    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


>    - User control plane separation û routing isolation
>    - User address space separation û supporting overlapping addresses
>    - User data plane separation û one VPN traffic cannot be
>      intercepted by other VPNs or any other users.

non-ascii characters


>    - Techniques highlighted through this document identify
>      methodologies for the protection of PPVPN resources and
>      infrastructure. By following these approaches a secure VPN
>      service can be delivered without the absolute need for
>      cryptographic techniques

This comment seems dubious.


split references into normative/non-normative.
2004-03-23
03 Thomas Narten [Ballot Position Update] Position for Thomas Narten has been changed to Discuss from Yes by Thomas Narten
2004-03-23
03 Thomas Narten State Change Notice email list have been change to luyuanfang@att.com ,rick@rhwilder.net,rcallon@juniper.net,Ronald.P.Bonica@mci.com from luyuanfang@att.com ,rick@rhwilder.net,
2004-03-23
03 Thomas Narten State Change Notice email list have been change to luyuanfang@att.com ,rick@rhwilder.net, from luyuanfang@att.com ,
2004-03-23
03 Thomas Narten State Change Notice email list have been change to luyuanfang@att.com ,"Rick Wilder" , Ross Callon , Ron Bonica from
2004-03-23
03 Thomas Narten State Change Notice email list have been change to "Rick Wilder" , Ross Callon , Ron Bonica ,luyuanfang@att.com from
2004-03-23
03 Thomas Narten
[Note]: 'Note: incorporates comments from security review solicited by Russ. I''ve put it a Discuss on things that are editorial and formatting; Given that it …
[Note]: 'Note: incorporates comments from security review solicited by Russ. I''ve put it a Discuss on things that are editorial and formatting; Given that it took almost 4 months to get the (small number of) changes from the security review done, I want to go ahead and get the full IESG comments before going back to the WG/authors.' added by Thomas Narten
2004-03-23
03 Thomas Narten
[Note]: 'Note: incorporates comments from security review solicited by Russ.

I''ve put it a Discuss on things that are editorial and formatting; Given that it …
[Note]: 'Note: incorporates comments from security review solicited by Russ.

I''ve put it a Discuss on things that are editorial and formatting; Given that it took almost 4 months to get the (small number of) changes from the security review done, I want to go ahead and get the full IESG comments before going back to the WG/authors.' added by Thomas Narten
2004-03-23
03 Thomas Narten [Ballot Position Update] New position, Yes, has been recorded for Thomas Narten
2004-03-23
03 Thomas Narten Ballot has been issued by Thomas Narten
2004-03-23
03 Thomas Narten Created "Approve" ballot
2004-03-23
03 (System) Ballot writeup text was added
2004-03-23
03 (System) Last call text was added
2004-03-23
03 (System) Ballot approval text was added
2004-03-23
03 Thomas Narten State Changes to IESG Evaluation from AD Evaluation::Revised ID Needed by Thomas Narten
2004-03-23
03 Thomas Narten State Change Notice email list have been change to "Rick Wilder" , Ross Callon , Ron Bonica from
2004-03-23
03 Thomas Narten Placed on agenda for telechat - 2004-04-02 by Thomas Narten
2004-03-23
03 Thomas Narten [Note]: 'Note: incorporates comments from security review solicited by Russ.' added by Thomas Narten
2004-03-11
01 (System) New version available: draft-ietf-l3vpn-security-framework-01.txt
2003-11-21
03 Thomas Narten State Changes to AD Evaluation::Revised ID Needed from Publication Requested by Thomas Narten
2003-11-21
03 Thomas Narten
2003-10-13: security review comments via Russ.

From: Russ Housley
To: rcallon@juniper.net, Ronald.P.Bonica@mci.com, rick@rhwilder.net
Cc: smb@research.att.com, narten@us.ibm.com, mrw@windriver.com, zinin@psg.com
Date: Mon, …
2003-10-13: security review comments via Russ.

From: Russ Housley
To: rcallon@juniper.net, Ronald.P.Bonica@mci.com, rick@rhwilder.net
Cc: smb@research.att.com, narten@us.ibm.com, mrw@windriver.com, zinin@psg.com
Date: Mon, 13 Oct 2003 11:26:09 -0400
Subject: draft-ietf-l3vpn-security-framework-00.txt

We finally dot a review from the Security Directorate.  I have divided the
comments into two categories, technical and editorial.  I hope the review
helps.

Russ


= = = = = =

Comments on draft-ietf-l3vpn-security-framework-00.txt

TECHNICAL

The document does not adequately address the end-to-end vs hop-by-hop
tradeoffs for encryption.

The security considerations section is weak.  The document does not seem to
discuss the real world threat environment.  It might go in the security
considerations section, or somewhere else.  What attacks have been seen in
the wild that this document is solving?  What other attacks are
theoretical?  You may want to also mention some of the non-technical/social
engineering attacks which are made easier by multiple-organization
structure (i.e., customer A impersonating a customer B to tech support and
human-engineering their way in).

EDITORIAL

The overall purpose of the document is unclear.  A strong motivation is
needed in the Introduction.

The document does not provide enough rationale/motivation for L3VPN.  It
assumes that the reader wants them; it does not help someone trying to
choose between provider-provisioned and user-provisioned VPNs.

A few terms need clear definitions at the front of the document  ("P",
"PE", and "SP" are examples).

Nit: inconsistent capitalization of IPsec.
2003-10-06
03 Dinara Suleymanova Draft Added by Dinara Suleymanova
2003-09-09
00 (System) New version available: draft-ietf-l3vpn-security-framework-00.txt