Generic Requirements for Provider Provisioned Virtual Private Networks (PPVPN)
draft-ietf-l3vpn-generic-reqts-03

[Ballot comment]
Reviewed by Lucy Lynch, Gen-ART
Her summary:

* This draft is on the right track but has open issues,
  described in the review.

Well, not so much open issues as squishy language. The document
has multiple instances of "SHOULDS" followed by exceptional cases
or qualifiers (at least for multi-provider). I found it confusing.
I think such a requirements document would be useful, but this may be
TOO generic. Given the number of drafts listed as informative, I
wonder if this document is premature? Prehaps it would be useful to
seperate single-provider from multi-provider?

Still, this is the document's second round through the IESG. I'll let it pass.

[Note]: '2004-03-23: -03 is out and should address bellovin''s discuss as well as the other comments. IESG: one change that was made in response to the comment that "2119 was cited, but no terms were used" was that some of the should/must wording was changed to SHOULD/MUST wording. I''ve reviewed these changes, and don''t have a problem with them. However, I wanted to make the IESG aware of these changes in case anyone wanted to re-review these changes.' added by Thomas Narten

[Note]: '2004-03-23: -03 is out and should address bellovin''s discuss and the other comments.

IESG: one change that was made in response to the comment that 2119 was cited, but no terms were used, was that some of the should/must wording was changed to SHOULD/MUST wording. I''ve reviewed these changes, and don''t have a problem with them. However, I wanted to make the IESG aware of these changes in case anyone wanted to re-review these changes.' added by Thomas Narten

[Ballot comment]
The figure on page 7 has some text underneath it that I think is
out of sync with the figure. The text says:
  The figure above presents a taxonomy of PPVPN technologies.  Although
  the above figure shows the classification for PE-based Layer 2 VPNs,
  it should be noted that CE-based Layer 2 PPVPNs may also be further
  classified as point-to-point (P2P) or point-to-multipoint (P2MP). It
Whereas the figure (I believe) shows that not the CE-based, but instread
the PE-based L2 PPVPNS can be classified as  P2P or P2MP.

Does Section 5.2.1 (as included here) belong in an IETF requirements
document? Who are we to decide that a customer must be able to do
these things. Is that not part of the business model/oeprational model?

5.2.1. Customer Management of a VPN

  A customer must have a means to view the topology, operational state,
  service order status, and other parameters associated with his or her
  VPN.

  All aspects of management information about CE devices and customer
  attributes of a PPVPN manageable by an SP should be capable of being
  configured and maintained by the customer after being authenticated
  and authorized.

  A customer should be able to make dynamic requests for changes to
  traffic parameters. A customer should be able to receive real-time
  response from the SP network in response to these requests.  One
  example of such as service is a "Dynamic Bandwidth management"
  capability, that enables real-time response to customer requests for
  changes of allocated bandwidth allocated to their VPN(s). A possible
  outcome of giving customers such capabilities is Denial of Service
  attacks on other VPN customers or Internet users. This possibility is
  documented in the Security Considerations section.

[Ballot comment]
The figure on page 7 has some text underneath it that I think is
out of sync with the figure. The text says:
  The figure above presents a taxonomy of PPVPN technologies.  Although
  the above figure shows the classification for PE-based Layer 2 VPNs,
  it should be noted that CE-based Layer 2 PPVPNs may also be further
  classified as point-to-point (P2P) or point-to-multipoint (P2MP). It
Whereas the figure (I believe) shows that not the CE-based, but instread
the PE-based L2 PPVPNS can be classified as  P2P or P2MP.

[Ballot comment]
Is the discussion of splitting the PPVPN WG into two WGs really something
  we want to publish in the RFC.  Will anyone care two years from now?
  Of course, it is important to keep the distinction between L2 and L3 VPNs.

  The document references RFC 2119, and then fails to use the key words.
  "MUST" is never used, but "MUST NOT" is used once.

[Ballot discuss]
Most of my earlier DISCUSS comments were satisfactorily addressed.  One wasn't:

        5.1.2.2: Ditto 10^2 sites per VPN

That number strikes me as too low for a large corporation, where each branch sales office may be a site on the corporate VPN.  Is there some justification for this number?

[Note]: '2004-02-03: -02 is out and should address IESG comments from January, 2003 (sigh) [attention: smb and alex]. I''ve added their comments to tracker under my name under the ballots. Those are the only comments I could find.' added by Thomas Narten

[Ballot comment]
From: Steve Bellovin
To: iesg@ietf.org
Date: Wed, 22 Jan 2003 23:29:23 -0500
Subject: draft-ietf-ppvpn-generic-reqts

        Doesn't seem to use 2119 language, even though it says it does
        4.4: disclosure of signaling info needs to be filtered per
                extranet agreement
        4.5: DoS includes CPU attacks on CPE/PPE
        4.5.2: Does access control include cryptographic mechanisms?
        4.7: Does "support overlapping addresses" mandate NAT?  Do we
                really want to mandate that?
        5.1.1: I find some of the scaling numbers dubious.  10^5
                routes in a single VPN?  I find that implausible.
        5.1.2.1: By contrast, I find 10^3 users per site to be too low.
        5.1.2.2: Ditto 10^2 sites per VPN
        5.1.2.6: Ditto 100 sites/customer.
                Note:  I'm thinking of a large company with many sites,
                which uses a VPN fors its primary intrasite connectivity.
                Wal-Mart is an extreme case, but have a look at
                http://www.business2.com/articles/mag/0,1640,37760,FF.html
                for some figures.
        5.1.3: I don't understand how "PE-based VPNs scale better than
                CE-based VPNs".  We're told that a PE must support 10^4
                sites, implying that there's a need for huge boxes.
                Can they be built that large, economically?  By
                contrast, a CE only needs to support its fanout,
                and they say 100 sites/customer.  (Btw -- there's no
                expansion of CE or PE in the document.)
                There's no discussion of hybrid solutions, such as
                a star with a PE center and CE edge nodes.
        7: There needs to be a lot more discussion of the "P" property
                of VPNs.  Different choices of VPN technology have
                different assurance levels of the privacy of
                a customer's network.  For example, CE-based
                solutions are probably more private than PE-based
                solutions if there's any sort of authentication of
                the remote end of the tunnel (even non-cryptographic),
                since it's hard for a mistake or equipment bug to send
                traffic to the wrong place.  In a PE node with 10K sites,
                half of which are using 1918 addresses, provisioning
                mistakes and PE software bugs seem very plausible.


--Steve Bellovin, http://www.research.att.com/~smb (me)
http://www.wilyhacker.com (2nd edition of "Firewalls" book)

From: Alex Zinin
To: iesg@ietf.org
Date: Mon, 3 Feb 2003 14:41:32 -0800
Subject: comments on draft-ietf-ppvpn-generic-reqts
Reply-To: Alex Zinin


4.10

  Should be more explicit about the difference in data-plane and
  control-plane resources of the network.

  As with data-plane resource sharing, should talk about SLAs for
  control-plane for the cases where the SP's control plane is used to
  distribute customer's routes, i.e., how does addition of another 100
  VPN sites to a PE not mean slower convergence of those 10 connected
  to it before. I.e., it doesn't seem to be enough to talk about
  failures... isn't control-plane service degradation not a concern?
  What about affects on the Internet routing from this perspective
  (i.e., routing instabilities in a VPN with thousands of sites
  affecting the Internet because of lousy job with resources
  separation in the PEs that also run INET BGP)?

  These considerations should also be reflected in the Security
  Considerations section--DoS attacks on PE control plane CPU are
  possible.

5.1.3:

>    The following example applies to the number of tunnels necessary in
>    various devices in the network. In a PE-based VPN, edge-to-edge
>    tunnels (PE-to-PE)  need to be established, while in a CE-based VPN,
>    end-to-end tunnels between  pairs of CEs are necessary. Therefore,in
>    general, PE-based VPNs scale better than CE-based VPNs, although the
>    scalability of CE-based VPNs may be improved by tunnel aggregation
>    between PEs.

This example presupposes MPLS as the tunneling technology. If the
network does not have to maintain state for tunnels (as it doesn't for
TCP connections, for instance), one could argue that the CE-based
solution actually scales better, since a given CE needs to terminate
only a limited set of tunnels within the VPN it belongs to, while in
the PE-based case, each PE serves a high number of VPNs, and hence
potentially several orders of magnitude more tunnels.

>    A scalable PE-based solution should quantify the amount of state that
>    a PE and P device must support. This should be stated in terms of the
>    total  number of VPNs and site interfaces supported by the service
>    provider.

The second sentence seemed a bit strange. Wasn't a O()-style function
of those meant instead?

>    A CE-based solution should quantify the state and scaling limits.
>    This should be stated in terms of the number of tunnels supported,
>    how these tunnels are provisioned and maintained (e.g., key
>    exchange), how routing occurs across these tunnels, and what the
>    impact of changes in the network topology do to the convergence
>    performance of such a solution.

Why is this for CE-based solutions only? I'd say same questions are
valid for PE-based scenarios too.

5.2.1.

>    A customer should be able to make dynamic requests for changes to
>    traffic parameters. A customer should be able to receive real-time
>    response from the SP network in response to these requests.  One
>    example of such as service is a "Dynamic Bandwidth management"
>    capability, that enables real-time response to customer requests for
>    changes of allocated bandwidth allocated to their VPN(s).

DoS discussion in Security Considerations on this?

6.2.

>    The plug and play feature of a VPN solution with minimum
>    configuration requirements is an important consideration. The VPN
>    solutions should have mechanisms for protection against customer
>    interface and/or routing instabilities so that they do not impact
>    other customers' services.

"...or interfere with the Internet routing"

--
Alex

2003-01-03 - comments from Alex
4.10

  Should be more explicit about the difference in data-plane and
  control-plane resources of the network.

  As with data-plane resource sharing, should talk about SLAs for
  control-plane for the cases where the SP's control plane is used to
  distribute customer's routes, i.e., how does addition of another 100
  VPN sites to a PE not mean slower convergence of those 10 connected
  to it before. I.e., it doesn't seem to be enough to talk about
  failures... isn't control-plane service degradation not a concern?
  What about affects on the Internet routing from this perspective
  (i.e., routing instabilities in a VPN with thousands of sites
  affecting the Internet because of lousy job with resources
  separation in the PEs that also run INET BGP)?

  These considerations should also be reflected in the Security
  Considerations section--DoS attacks on PE control plane CPU are
  possible.

5.1.3:

>    The following example applies to the number of tunnels necessary in
>    various devices in the network. In a PE-based VPN, edge-to-edge
>    tunnels (PE-to-PE)  need to be established, while in a CE-based VPN,
>    end-to-end tunnels between  pairs of CEs are necessary. Therefore,in
>    general, PE-based VPNs scale better than CE-based VPNs, although the
>    scalability of CE-based VPNs may be improved by tunnel aggregation
>    between PEs.

This example presupposes MPLS as the tunneling technology. If the
network does not have to maintain state for tunnels (as it doesn't for
TCP connections, for instance), one could argue that the CE-based
solution actually scales better, since a given CE needs to terminate
only a limited set of tunnels within the VPN it belongs to, while in
the PE-based case, each PE serves a high number of VPNs, and hence
potentially several orders of magnitude more tunnels.

>    A scalable PE-based solution should quantify the amount of state that
>    a PE and P device must support. This should be stated in terms of the
>    total  number of VPNs and site interfaces supported by the service
>    provider.

The second sentence seemed a bit strange. Wasn't a O()-style function
of those meant instead?

>    A CE-based solution should quantify the state and scaling limits.
>    This should be stated in terms of the number of tunnels supported,
>    how these tunnels are provisioned and maintained (e.g., key
>    exchange), how routing occurs across these tunnels, and what the
>    impact of changes in the network topology do to the convergence
>    performance of such a solution.

Why is this for CE-based solutions only? I'd say same questions are
valid for PE-based scenarios too.

5.2.1.

>    A customer should be able to make dynamic requests for changes to
>    traffic parameters. A customer should be able to receive real-time
>    response from the SP network in response to these requests.  One
>    example of such as service is a "Dynamic Bandwidth management"
>    capability, that enables real-time response to customer requests for
>    changes of allocated bandwidth allocated to their VPN(s).

DoS discussion in Security Considerations on this?

6.2.

>    The plug and play feature of a VPN solution with minimum
>    configuration requirements is an important consideration. The VPN
>    solutions should have mechanisms for protection against customer
>    interface and/or routing instabilities so that they do not impact
>    other customers' services.

"...or interfere with the Internet routing"

comment from steve bellovin

        Doesn't seem to use 2119 language, even though it says it does
        4.4: disclosure of signaling info needs to be filtered per
                extranet agreement
        4.5: DoS includes CPU attacks on CPE/PPE
        4.5.2: Does access control include cryptographic mechanisms?
        4.7: Does "support overlapping addresses" mandate NAT?  Do we
                really want to mandate that?
        5.1.1: I find some of the scaling numbers dubious.  10^5
                routes in a single VPN?  I find that implausible.
        5.1.2.1: By contrast, I find 10^3 users per site to be too low.
        5.1.2.2: Ditto 10^2 sites per VPN
        5.1.2.6: Ditto 100 sites/customer.
                Note:  I'm thinking of a large company with many sites,
                which uses a VPN fors its primary intrasite connectivity.
                Wal-Mart is an extreme case, but have a look at
                http://www.business2.com/articles/mag/0,1640,37760,FF.html
                for some figures.
        5.1.3: I don't understand how "PE-based VPNs scale better than
                CE-based VPNs".  We're told that a PE must support 10^4
                sites, implying that there's a need for huge boxes.
                Can they be built that large, economically?  By
                contrast, a CE only needs to support its fanout,
                and they say 100 sites/customer.  (Btw -- there's no
                expansion of CE or PE in the document.)
                There's no discussion of hybrid solutions, such as
                a star with a PE center and CE edge nodes.
        7: There needs to be a lot more discussion of the "P" property
                of VPNs.  Different choices of VPN technology have
                different assurance levels of the privacy of
                a customer's network.  For example, CE-based
                solutions are probably more private than PE-based
                solutions if there's any sort of authentication of
                the remote end of the tunnel (even non-cryptographic),
                since it's hard for a mistake or equipment bug to send
                traffic to the wrong place.  In a PE node with 10K sites,
                half of which are using 1918 addresses, provisioning
                mistakes and PE software bugs seem very plausible.