Service Requirements for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs)
RFC 4031

[Ballot discuss]
Note: I only reviewed this document to see if my earlier issues were addressed.  A number still remain; in most cases, the wording is effectively unchanged from the previous version.

3.7: Keys MUST NOT be readable by management systems.

5.1: The requirements for who must approve requests by a new party to join an extranet are a business decision; this document can't specify them.  For example, a large company may set up an extranet for its suppliers, some of whom may be mutually competitive.  It's the decision of the large company whom it wishes to qualify as a supplier, and hence whom to add to the extranet; the other suppliers don't get a voice.  They are, of course, free to add their own protections against traffic coming in via that VPN, or to decline to join it because it offends their own security policy -- but it's a perfectly valid business practice for the large company to engage in, and this document can't ban it.

5.3: The document lists NAT as a MUST  Is this really the position of the IESG?

6.10.3 mandates extremely stringent QoS functions.  I don't think those are within the state of the art, especially inter-provider.

[Ballot discuss]
Note: I only reviewed this document to see if my earlier issues were addressed.  A number still remain; in most cases, the wording is effectively unchanged from the previous version.

3.7: Keys MUST NOT be readable by management systems.

4.4: The document lists NAT as a SHOULD.  Is this really the position of the IESG?

5.1: The requirements for who must approve requests by a new party to join an extranet are a business decision; this document can't specify them.  For example, a large company may set up an extranet for its suppliers, some of whom may be mutually competitive.  It's the decision of the large company whom it wishes to qualify as a supplier, and hence whom to add to the extranet; the other suppliers don't get a voice.  They are, of course, free to add their own protections against traffic coming in via that VPN, or to decline to join it because it offends their own security policy -- but it's a perfectly valid business practice for the large company to engage in, and this document can't ban it.

6.10.3 mandates extremely stringent QoS functions.  I don't think those are within the state of the art, especially inter-provider.

[Ballot comment]
I see some mangled text (?vider Provisioned VPN?PVPN, for example) in sections 3.1, 4.3.1, 10.1, 10.2, and 11.  A search for "?" should turn up all of the problems.

[Note]: '2004-07-01: Note: this is a returning document; the IESG reviewed it
back in 2002 and again in 2003 under the ID name
draft-ietf-ppvpn-requirements-06.txt. Please consult your archives for
previous review commments (if any). My notes say Steve, Russ, Bert had
issues with previous versions (which should now be addressed).
' added by Thomas Narten

[Note]: '2004-05-06: Chair says: I just spoke with Dave McDysan
about this. He is waiting on comments from Marco Carugi
and should have a new version ready in two weeks.

' added by Thomas Narten

had a conf call with IESG members and Loa to see if generic concerns from the IESG members could be formulated more specifically. Here's the summary:

1. Where needed, spell out that some VPN technologies
  work fine across the Internet, and some are targeted
  for the set of cooperating SPs case.

2. Split generic VPN requirements and those specific to
  particular technologies and deployment scenarios

3. NATs and FWs are required only in specific cases,
  do not imply they are always requires

4. Avoid encouraging modification of IPSec STDs

Loa and Alex will read the document again and will come
back to the authors with specific recommendations on how to fix the document.

got comments and concerns from IESG. Comments below:

> Forgive the Meta question but, what is the RFC that this
> becomes going to be used for?

> ...these requirements
> seem to have been written with the explicit caveat that they do not
> imply building of a new protocol or protocol mechanisms.  See:
>
>      The specification of any technical means to provide PPVPN services
>    is outside the scope of this document. Other documents, such as the
>    framework document [PPVPN-FR] and several sets of documents, one set
>    per each individual technical approach providing PPVPN services, are
>    intended to cover this aspect.
>
> A lot of the text seems to have implications that don't really help
> provide context for protocol development (see Section 5.6 and 5.7).
> If we're okay with this as a context setting exercise, that's fine.  If
> that's not the point,  more back story would help.
>
> Notes:
>
> There are several sets of "Editor's Notes" that need to be removed or
> resolved.
>
> The definition of "site" didn't make sense.  Recasting it in
> terms of topology would help (even if this is the overlay topology
> of the VPN).  This is especially important because the definition of
> VPN implies that a site must be a member of a VPN (and may be
> a member of many).  This is not a typical presumption in my
> experience.  If the topology language won't work, a strong marker
> that the text's use of "site" is not the typical use would help.
>
> Section 4.4 seems too vague to be useful, even as a service
> description "A range of security feature should be supported..."
> doesn't say anything.  Section 4.4.2 has a related problem, because
> it doesn't specify a timescale.  As written, a call to the NOC to
> ask for a drop-shipped firewall qualifies.  Explicitly indicating
> that type of timescale is or is not okay would help.


> This is a requirements document -- shouldn't it use SHOULD and MUST,
> instead of should and must?
>
> 3.7: Encryption keys need great care in handling, and should not be
> readable by management systems.
>
> 4.5: Why must VPNs imply NAT?  A VPN is, by definition, private;
> address space usage is thus among consenting parties.  If there are
> non-uniqe address clouds among them, some form of NAT may be needed,
> but why is that part of the VPN definition?  (Same for 5.3)
>
> 5.1:  That's out of scope -- it's business decision by the parties
> involved.
>
> 5.9: I don't understnd the text "Security services shall apply to...
> or, a subset of the VPN traffic between sites...".  Is that referring
> to customer use of IPsec, with add-on security by the provider?  Also,
> what is the "AH or ESP identifier"?  The IP protocol number for them?
>
> 6.9.1: Extending IPsec?  Not at this time; that WG needs to finish.
>
> 6.9.3: address-hiding?  Also, why is a firewall a necessary part of a
> PPVPN?
>
> 6.10.3: The mind boggles.  I didn't think we knew how to do some of
> that intra-provider, let alone inter-provider for multiple PPVPNs.

>    33 lines contain non-ASCII characters.
>
>    Section 1 (Introduction) says:
>
>      This document describes requirements for two types of network-based
>      L3 PPVPNs: aggregated routing VPNs [RFC2547bis] and virtual routers
>      [PPVPN-VR] and one type of CE-based PPVPN [IPsec-PPVPN].
>
>    Please reword.  It is not clear how to parse this sentence into two types.
>
>    The right hand side of Figure 3.2 is not quite right.

>> 2003-03-06 - bert comments
>>
>> RFC1777 is historic and reference shoudl be updated
>>
>> PROPOSED CHANGE: Replace reference to RFC 1777 with RFC 3377.
>>
> I still see RFC1777 in the text (in fact as a citation).
> What they did is that they removed it from the References section,
> so now [RFC1777] citation is a dangling pointer.
>
>
>> But should we really be "pushing" PIB for management?
>> i.e. change "(MIBs or PIBs)" to "(e.g. MIB modules)"
>>
>> PROPOSED CHANGE: In section 7.6, replace "management or
>> policy information
>> bases (MIBs or PIBS)" with "management information base (MIB) modules"
>>
> OK with me, but may offend "policy" people. Policy info can also
> be managed via MIB. And so I had left that piece of text in and
> changed "MIBs or PIBs" into "e.g. MIB modules" so as to not offend
> anyone. But as I said, OK with me.

2003-03-06 - bellovin comments

3.3    It might be worth clarifying that extranets often have port
number restrictions, as well as host restrictions.

4.5 strongly suggests NAT.  Do we really want to encourage that sort of
thing?  It even speaks of non-IP NAT, which is certainly not our
business.

5.9 There is text about how customer security measures must not hide
QoS information from the SP.  That's very wrong.  At least, if it's wrong
if they mean "you must show us port numbers".  But more fundamentally,
it says "a security solution deployed by a customer must not hide
information...".  I don't think this document should be specifying that
sort of requirements for customer behavior.

6.9.1  Replay protection has nothing to do with man-in-the-middle
attacks.

        DES is deprecated and shouldn't be suggested here.  AES should
        be listed.

2003-03-06 - bert comments

RFC1777 is historic and reference shoudl be updated

But should we really be "pushing" PIB for management?
i.e. change "(MIBs or PIBs)" to "(e.g. MIB modules)"

2003-03-06 - allison comments
4.6.1

  For TCP traffic, L3 PPVPN devices should support Random Early
  Detection (RED) to provide graceful degradation in the event of
  network congestion.

It would be very inappropriate for RED to work on TCP only!  This
must mean Internet traffic.

5.5.2

The document says that it goes with ITU Y.1311.1 in supporting
endpoint markings of DSCP to be preserved and not changed through
the SP network.  This is for genuine discussion:  how do we reconcile
this with the diffserv model?  We are raising two different models in
under the big IETF tent?  It seems potentially damaging to diffserv.

6.10.4 Security Considerations
  If a tunnel traverses multiple SP networks and it passes through an
  unsecured SP, POP, NAP, or IX, then security mechanisms must be
  employed.

This refers to the security requirements for QoS brokering inter-AS,
I believe.  It would be nice if the draft did not present the reader with
this empty statement but had some substantial suggestion about how to
provide an approach to securing the process, for instance by referencing
another part of the document.

State Changes to In WG                                            from New Version Needed (WG/Author)                    by sob

State Changes to New Version Needed (WG/Author)                    from Reading List                                      by sob

State Changes to Reading List                                      from In WG                                            by sob