Skip to main content

Framework for Layer 2 Virtual Private Networks (L2VPNs)
draft-ietf-l2vpn-l2-framework-05

Revision differences

Document history

Date Rev. By Action
2012-08-22
05 (System) post-migration administrative database adjustment to the No Objection position for Bert Wijnen
2012-08-22
05 (System) post-migration administrative database adjustment to the No Objection position for Allison Mankin
2012-08-22
05 (System) post-migration administrative database adjustment to the No Objection position for Steven Bellovin
2004-08-18
05 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2004-08-18
05 Amy Vezza IESG state changed to Approved-announcement sent
2004-08-18
05 Amy Vezza IESG has approved the document
2004-08-18
05 Amy Vezza Closed "Approve" ballot
2004-08-18
05 Thomas Narten State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Thomas Narten
2004-08-18
05 Thomas Narten Note field has been cleared by Thomas Narten
2004-08-06
05 Allison Mankin
[Ballot comment]
I cleared my Discuss because charter work was added.  I believe there remain questions that the protocol developed will be the simplest one, …
[Ballot comment]
I cleared my Discuss because charter work was added.  I believe there remain questions that the protocol developed will be the simplest one, just for the IP supporting heterogeneous PW, and that
its applicability domain will be clearly stated.

Here is my original Discuss note, which I removed:  WG did not have consensus of community to work on IP over heterogeneous L2 VPNs (not translation among the L2s, but heterogenous ARP, MTUs, multicast, etc.), which is why the task is not on the charter.  We discussed in the telechat and there could be a charter-related discussion in the WG before going forward.
2004-08-06
05 Allison Mankin [Ballot Position Update] Position for Allison Mankin has been changed to No Objection from Discuss by Allison Mankin
2004-08-06
05 Steven Bellovin [Ballot Position Update] Position for Steve Bellovin has been changed to No Objection from Discuss by Steve Bellovin
2004-06-28
05 (System) Sub state has been changed to AD Follow up from New Id Needed
2004-06-28
05 (System) New version available: draft-ietf-l2vpn-l2-framework-05.txt
2004-05-20
05 Thomas Narten [Note]: '2004-05-18: 04 is out, but smb''s issue was apparently not addressed or responded to.' added by Thomas Narten
2004-05-20
05 Thomas Narten State Change Notice email list have been change to rick@rhwilder.net, vkompella@timetra.com, loa@pi.se, erosen@cisco.com from , ,
2004-05-12
05 Bert Wijnen [Ballot Position Update] Position for Bert Wijnen has been changed to No Objection from Discuss by Bert Wijnen
2004-03-23
04 (System) New version available: draft-ietf-l2vpn-l2-framework-04.txt
2004-01-08
05 Amy Vezza Removed from agenda for telechat - 2004-01-08 by Amy Vezza
2004-01-08
05 Amy Vezza State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza
2004-01-08
05 Allison Mankin
[Ballot discuss]
WG did not have consensus of community to work on IP over heterogeneous L2 VPNs (not translation among the L2s, but heterogenous ARP, …
[Ballot discuss]
WG did not have consensus of community to work on IP over heterogeneous L2 VPNs (not translation among the L2s, but heterogenous ARP, MTUs, multicast, etc.), which is why the task is not on the charter.  We discussed in the telechat and there could be a charter-related discussion in the WG before going forward.
2004-01-08
05 Allison Mankin [Ballot Position Update] New position, Discuss, has been recorded for Allison Mankin by Allison Mankin
2004-01-08
05 Margaret Cullen [Ballot Position Update] New position, No Objection, has been recorded for Margaret Wasserman by Margaret Wasserman
2004-01-08
05 Bert Wijnen
[Ballot comment]
From OPS Directorate (Pekka):

Semi-editorials:
================

==> I'd "flatten out" the structure of the document.  Basically all
the main content is in one …
[Ballot comment]
From OPS Directorate (Pekka):

Semi-editorials:
================

==> I'd "flatten out" the structure of the document.  Basically all
the main content is in one section 3.  The document might be more
balanced if this was split to multiple sections.  Some of these (e.g.
the stuff under current section 3.1) might be better placed before the
reference model section, because they seem to be rather introductory. 
However, this is not a huge issue..

==> The document is rather light on references, e.g. LDP, BGP, L2TP,
MPLS, etc. which are all used in the body.  These could be referred to
using informative references but I don't think this is really
necessary.

==> it might be a good idea to include an "abbreviations" (P, PE, CE,
SP, etc.) section up front, but defer the actual terms and their
background to the terminology document -- especially if the ref to the
terminology is not normative.

  A VPLS is an L2 service that in all emulates LAN service across a
  Wide Area Network (WAN). Thus it also has all the scaling
  characteristics of a LAN. Other scaling issues might arise from the
  number of end-points that can be supported on a particular PE.

==> uhh, actually, this has much worse scaling characteristics.  It's
equal from the perspective of a host or a broadcast domain, but
entirely different from the perspective of the underlying network glue
providing the VPLS service.

3.1.3. IP-only LAN-like Service (IPLS)
                                                                                                     
  An IPLS is very like a VPLS, except that:
[...]
    - it is assumed that the service will only carry IP packets, and
      supporting packets such as ICMP and ARP; Layer2 packets which do
      not contain IP are not supported.

==> one should probably do some rather trivial rewording to clarify
that IPLS works for either IPv4, IPv6 or both. Use of "IP" and "ICMP"
is a bit ambiguous, and ARP is replaced by NDP.

  Multipoint-to-point PWs can be used only when the PE receiving a
  frame from the PW does not need to know where the frame came from.

==> this sentence may be misleading -- does that imply that the PE
might not check the frames or the multiple senders at all?  Does it
exclude the implementation technique where the multipoint-to-point
-terminating PE would have a list of senders to that PW.

    - L2TP
                                                                                                     
      L2TP can be used for pseudowire signaling, resulting in
      pseudowires that are carried as "sessions" within L2TP tunnels.
      Pseudowire-specific extensions to L2TP may also be needed.

==> afaik, L2TP does not include *signalling* as such, so why L2TP
would be a P-t-P signalling protocol might need a bit of more
elaboration?

Editorials:
- spell out L2VPN in the document title
- section 2.4, s/the they both/they both/, s/differences is/difference is/ ?
2004-01-08
05 Bert Wijnen
[Ballot discuss]
From OPS Directorate (Pekka):

Bigger issues:

1) There are informational references to L2VPN requirements.  But as
this document describes the architecture, isn't it …
[Ballot discuss]
From OPS Directorate (Pekka):

Bigger issues:

1) There are informational references to L2VPN requirements.  But as
this document describes the architecture, isn't it a bit premature to
go forward with the architecture until the requirements are finished? 
(Note: a large part of the document appears to be rather independent
of the requirements, but especially some cases, with regard to
security (mostly) might be a bit unfinished.)

Similarly, PWE3-ARCH should probably also be a normative reference. 
Heck, all of them should -- the terminology is probably pretty
critical for understanding the document (and is just referred to in
sect 1.4)?

This issue could be "fixed" by stalling the publication of this
document until the others are finished, but I'm not sure how
appropriate that would be, as I guess there could be changes to the
architecture if there are changes (or shift of balance, or whatever)
in the requirements.

2) There seem to be a lurking issue with heterogenous pseudo-wires, if
the AC's use technologies with different MTU values.  A long time ago,
e.g. FDDI<->Ethernet bridging caused a lot of mess. Is there a
potential for the same to be happening again?  Does this place
requirements to the framework?

3) There is a dangerous snippet in the security considerations
section:

====
4.2. Provider-Customer Network Security Issues
                                                                                                 
  There are a number of security issues related to the access network
  between the provider and the customer.  This is also traditionally a
  network that is hard to protect physically.
                                                                                                 
  Typical security issues on the provider-customer interface include
  the following:
                                                                                                 
    - Preventing unauthorized members joining an L2VPN
[...]
=====

This would make one believe, that the members on the customer link
would be able to join L2VPN's (read: without the management by the
operator), and that there would be some signalling protocols running
at CE which would make them able to do something.

This seems like a very dangerous model if so, which -- I believe --
hasn't been explicitly discussed.  Of course, this could also be a bit
careless wording choice..

4) Section 4.3 describes my biggest concerns with VPN-like services
rather well, but gives an impression, "we know L2VPNs are insecure,
here are some ways to fix some of the models but not all of them, but
who cares?".  Except for VPWS case, I believe the situation is
actually quite a bit like, "if the customer wants any security, he has
to provide it on his own" -- which isn't really satisfying because the
customers who want VPLS services in the first place aren't typically
equipped/capable/knowledgeable to do it in the first place!!

I'm not sure what I'm proposing (or not) here, but it seems like
especially VPLS services does not provide sufficient security.  At
minimum, these issues should be subject to heavy IESG consideration.

5) One another big issue I'm particularly worried of is the potential
interaction with multiple providers ("providing inter-AS VPxx
service"), which was referred to a couple of times.  This should
probably be considered explicitly in Security Considerations - at
least - as a subsection of its own, like "Provider-Provider Security
Issues".  This is particularly tough issue to settle if you run the
same or similar signalling protocols across providers, as you're
crossing trust boundaries, and the integrity of a customer's VPxx
service would be very much more in question than the normal "trusted
operator" case.

As above, this requires more though.  Myself, I'm not sure if
provider-provider VPxx services (esp. signalled ones) are really
necessary at all.. but then again, I personally don't see much need
for regular VPxx services either :-)

...

As these last points show, it might be useful to try to create some
kind of "trust model" for the different VPxx services (with or without
the customer's own security additions), and attack that trust model by
providing a threat model for these services.

Semi-editorials:
================

==> I'd "flatten out" the structure of the document.  Basically all
the main content is in one section 3.  The document might be more
balanced if this was split to multiple sections.  Some of these (e.g.
the stuff under current section 3.1) might be better placed before the
reference model section, because they seem to be rather introductory. 
However, this is not a huge issue..

==> The document is rather light on references, e.g. LDP, BGP, L2TP,
MPLS, etc. which are all used in the body.  These could be referred to
using informative references but I don't think this is really
necessary.

==> it might be a good idea to include an "abbreviations" (P, PE, CE,
SP, etc.) section up front, but defer the actual terms and their
background to the terminology document -- especially if the ref to the
terminology is not normative.

  A VPLS is an L2 service that in all emulates LAN service across a
  Wide Area Network (WAN). Thus it also has all the scaling
  characteristics of a LAN. Other scaling issues might arise from the
  number of end-points that can be supported on a particular PE.

==> uhh, actually, this has much worse scaling characteristics.  It's
equal from the perspective of a host or a broadcast domain, but
entirely different from the perspective of the underlying network glue
providing the VPLS service.

3.1.3. IP-only LAN-like Service (IPLS)
                                                                                                     
  An IPLS is very like a VPLS, except that:
[...]
    - it is assumed that the service will only carry IP packets, and
      supporting packets such as ICMP and ARP; Layer2 packets which do
      not contain IP are not supported.

==> one should probably do some rather trivial rewording to clarify
that IPLS works for either IPv4, IPv6 or both. Use of "IP" and "ICMP"
is a bit ambiguous, and ARP is replaced by NDP.

  Multipoint-to-point PWs can be used only when the PE receiving a
  frame from the PW does not need to know where the frame came from.

==> this sentence may be misleading -- does that imply that the PE
might not check the frames or the multiple senders at all?  Does it
exclude the implementation technique where the multipoint-to-point
-terminating PE would have a list of senders to that PW.

    - L2TP
                                                                                                     
      L2TP can be used for pseudowire signaling, resulting in
      pseudowires that are carried as "sessions" within L2TP tunnels.
      Pseudowire-specific extensions to L2TP may also be needed.

==> afaik, L2TP does not include *signalling* as such, so why L2TP
would be a P-t-P signalling protocol might need a bit of more
elaboration?

Editorials:
- spell out L2VPN in the document title
- section 2.4, s/the they both/they both/, s/differences is/difference is/ ?

Bigger issues:

1) There are informational references to L2VPN requirements.  But as
this document describes the architecture, isn't it a bit premature to
go forward with the architecture until the requirements are finished? 
(Note: a large part of the document appears to be rather independent
of the requirements, but especially some cases, with regard to
security (mostly) might be a bit unfinished.)

Similarly, PWE3-ARCH should probably also be a normative reference. 
Heck, all of them should -- the terminology is probably pretty
critical for understanding the document (and is just referred to in
sect 1.4)?

This issue could be "fixed" by stalling the publication of this
document until the others are finished, but I'm not sure how
appropriate that would be, as I guess there could be changes to the
architecture if there are changes (or shift of balance, or whatever)
in the requirements.

2) There seem to be a lurking issue with heterogenous pseudo-wires, if
the AC's use technologies with different MTU values.  A long time ago,
e.g. FDDI<->Ethernet bridging caused a lot of mess. Is there a
potential for the same to be happening again?  Does this place
requirements to the framework?

3) There is a dangerous snippet in the security considerations
section:

====
4.2. Provider-Customer Network Security Issues
                                                                                                 
  There are a number of security issues related to the access network
  between the provider and the customer.  This is also traditionally a
  network that is hard to protect physically.
                                                                                                 
  Typical security issues on the provider-customer interface include
  the following:
                                                                                                 
    - Preventing unauthorized members joining an L2VPN
[...]
=====

This would make one believe, that the members on the customer link
would be able to join L2VPN's (read: without the management by the
operator), and that there would be some signalling protocols running
at CE which would make them able to do something.

This seems like a very dangerous model if so, which -- I believe --
hasn't been explicitly discussed.  Of course, this could also be a bit
careless wording choice..

4) Section 4.3 describes my biggest concerns with VPN-like services
rather well, but gives an impression, "we know L2VPNs are insecure,
here are some ways to fix some of the models but not all of them, but
who cares?".  Except for VPWS case, I believe the situation is
actually quite a bit like, "if the customer wants any security, he has
to provide it on his own" -- which isn't really satisfying because the
customers who want VPLS services in the first place aren't typically
equipped/capable/knowledgeable to do it in the first place!!

I'm not sure what I'm proposing (or not) here, but it seems like
especially VPLS services does not provide sufficient security.  At
minimum, these issues should be subject to heavy IESG consideration.

5) One another big issue I'm particularly worried of is the potential
interaction with multiple providers ("providing inter-AS VPxx
service"), which was referred to a couple of times.  This should
probably be considered explicitly in Security Considerations - at
least - as a subsection of its own, like "Provider-Provider Security
Issues".  This is particularly tough issue to settle if you run the
same or similar signalling protocols across providers, as you're
crossing trust boundaries, and the integrity of a customer's VPxx
service would be very much more in question than the normal "trusted
operator" case.

As above, this requires more though.  Myself, I'm not sure if
provider-provider VPxx services (esp. signalled ones) are really
necessary at all.. but then again, I personally don't see much need
for regular VPxx services either :-)

...

As these last points show, it might be useful to try to create some
kind of "trust model" for the different VPxx services (with or without
the customer's own security additions), and attack that trust model by
providing a threat model for these services.
2004-01-08
05 Bert Wijnen [Ballot Position Update] New position, Discuss, has been recorded for Bert Wijnen by Bert Wijnen
2004-01-07
05 Ted Hardie
[Ballot comment]
The draft says:

3.2.6.3. Inter-AS Considerations

  Pseudowires may need to run from a PE in one Service Provider's
  network to a …
[Ballot comment]
The draft says:

3.2.6.3. Inter-AS Considerations

  Pseudowires may need to run from a PE in one Service Provider's
  network to a PE in another Service Provider's network. This means
  that the signaling to set up the PEs must be able to cross network
  boundaries. All known proposals for signaling are able to do this. It
  is especially advisable to use some form of authentication between
  the two PW endpoints in this case.


This looks a wee bit inadequate to me.  For starters "All known proposals
for signaling are able to do this" seems to mean "anything under consideration
by the working group" rather than *all known*.  Secondly, "some form of
authentication between the two PW endpoints" doesn't really cover the
ground; as was pointed out on a previous document on this ballot, making
sure that the two PW endpoints are configured with the same trust anchors
can bite you in cases where you are relying on something fancier than
a shared secret.

I'm putting a no-ob on this, but I have to say that seeing all the different
l2vpn stuff thrown together made me revisit those old "are we being
tunnelled to death" nightmares.  The bland "use hierarchy to solve
the n*(n-1) scaling problem" scares me in particular, as a hierarchy of
these tunnels can easily lose the properties of a classic IP network.
2004-01-07
05 Ted Hardie [Ballot Position Update] Position for Ted Hardie has been changed to No Objection from Undefined by Ted Hardie
2004-01-07
05 Ted Hardie
[Ballot comment]
The draft says:

3.2.6.3. Inter-AS Considerations

  Pseudowires may need to run from a PE in one Service Provider's
  network to a …
[Ballot comment]
The draft says:

3.2.6.3. Inter-AS Considerations

  Pseudowires may need to run from a PE in one Service Provider's
  network to a PE in another Service Provider's network. This means
  that the signaling to set up the PEs must be able to cross network
  boundaries. All known proposals for signaling are able to do this. It
  is especially advisable to use some form of authentication between
  the two PW endpoints in this case.


This looks a wee bit inadequate to me.  For starters "All known proposals
for signaling are able to do this" seems to mean "anything under consideration
by the working group" rather than *all known*.  Secondly, "some form of
authentication between the two PW endpoints" doesn't really cover the
ground; as was pointed out on a previous document on this ballot, making
sure that the two PW endpoints are configured with the same trust anchors
can bite you in cases where you are relying on something fancier than
a shared secret
2004-01-07
05 Ted Hardie [Ballot Position Update] New position, Undefined, has been recorded for Ted Hardie by Ted Hardie
2004-01-07
05 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley by Russ Housley
2004-01-07
05 Steven Bellovin
[Ballot discuss]
The Security Considerations section should mention denial of service issues for LAN emulation from too many broadcast packets and from MAC addresses that …
[Ballot discuss]
The Security Considerations section should mention denial of service issues for LAN emulation from too many broadcast packets and from MAC addresses that appear to move around or that don't exist.

The IP LAN service is v4-specific; at least some mention should be made of IPv6.
2004-01-07
05 Steven Bellovin [Ballot Position Update] New position, Discuss, has been recorded for Steve Bellovin by Steve Bellovin
2004-01-07
05 Thomas Narten [Ballot Position Update] New position, Yes, has been recorded for Thomas Narten
2004-01-07
05 Thomas Narten Ballot has been issued by Thomas Narten
2004-01-07
05 Thomas Narten Created "Approve" ballot
2004-01-07
05 (System) Last call text was added
2004-01-07
05 (System) Ballot approval text was added
2004-01-02
05 Thomas Narten State Changes to IESG Evaluation from Publication Requested by Thomas Narten
2004-01-02
05 Thomas Narten [Note]: 'Responsible: Working Group' has been cleared by Thomas Narten
2004-01-02
05 Thomas Narten Placed on agenda for telechat - 2004-01-08 by Thomas Narten
2003-12-18
05 Alex Zinin reassigning to Thomas--he's the one now.
2003-12-18
05 Alex Zinin Shepherding AD has been changed to Thomas Narten from Alex Zinin
2003-12-16
05 Dinara Suleymanova State Changes to Publication Requested from AD is watching by Dinara Suleymanova
2003-12-16
05 Dinara Suleymanova Intended Status has been changed to Informational from None
2003-10-23
03 (System) New version available: draft-ietf-l2vpn-l2-framework-03.txt
2003-10-02
02 (System) New version available: draft-ietf-l2vpn-l2-framework-02.txt
2003-09-09
01 (System) New version available: draft-ietf-l2vpn-l2-framework-01.txt
2003-07-22
00 (System) New version available: draft-ietf-l2vpn-l2-framework-00.txt
2003-05-01
05 Alex Zinin Shepherding AD has been changed to Zinin, Alex from Bradner, Scott
2002-08-29
05 Scott Bradner Draft Added by sob