Quality of Service (QoS) Signaling in a Nested Virtual Private Network
RFC 4923

[Ballot comment]
My Discuss was resolved through text that Patrik Bose
sent in an e-mail on Jan 24, 2007. I expect the text
to appear in the new revision and leave it to the
responsible AD to ensure this.

[Ballot discuss]
I received the following from L3VPN Chair, Ron Bonica. I think that the separation of "nested" networks Ron points to is important. What I would like to discuss is whether or not the document goes far enough to point out that, in some VPN envrionments, it is impossible/undesirable to allow signalling between the nested VPNs in order to setup a reservation.

It seems that there might be room to mention L1VPNs as well, as at one level their whole purpose is to signal paths in a nested vpn of sorts using RSVP. This may boil down to some paragraphs on where the special relationships between customers and providers exist in the (G)MPLS world of VPNs vs. the IPsec VPNs that the text seems to focus on.

Ron's text follows:

I have seen this document before and let it go without comment, but now
that I think of it, I do have a couple of questions.

First, I don't see how this proposal fits into the L3VPN framework. Of
the three L3VPN solutions (BGP/MPLS, VR, CE-based) this proposal most
closely resembles a CE-based solution. This is because:

- the "VPN router" is in the customer's administrative domain
- the "VPN router" is in the customer's cryptographic domain
- no SP router carries any customer routing information, not even in a
VRF or Virtual Routing instance.

However, this proposal breaks the CE-based model in one very significant
way: The "VPN router" can create and destroy state on SP routers. It can
do this by using RSVP to signal bandwidth reservations between VPN routers.

This is all well and good so long as the VPN router can be trusted not
to do anything harmful to the SP network. However, L3VPNs are generally
designed so that there is nothing that a customer can do to harm the SP
network. I am a little concerned about exchanging RSVP signaling between
the VPN routers and SP edge router because there is little that the SP
edge can do to protect itself from irresponsible behavior on the part of
the VPN router. So, the L3VPN trust model is kind of turned on its head.

The second thing that bothers me has to do with the level of aggregation
between the plain-text and cipher-text network. There is a trade-off
between efficient use of bandwidth and security. In order to use
bandwidth efficiently, the aggregate reservation must closely track the
sum of end-to-end reservations. However, if you do this, you allow
traffic analysis in the cipher-text network. (For example, an enemy
monitoring the cipher-text network might know whenever the volume of
urgent calls increases.)

                                  Ron

[Ballot comment]
It might be worth mentioning in the security section about how this leaks information about priorities levels and the cases where it would be inappropriate to use it.

[Ballot discuss]
This document requires that a security association contain traffic of
only one priority/precedence (I've lost track of what term means what).
That is a new change and there does not seem to be sufficient
consensus to make that change.

Instead, I propose that this document say that in order to get the
benefits proposed by this mechanism, only one priority of traffic can
be carried over a SA, but clearly indicate that the standards allow an
implementation to make other tradeoffs.

[Ballot discuss]
Hi.  I believe it is inappropriate to consider this document before
draft-ietf-tsvwg-rsvp-ipsec comes to the IESG.  As I understand it,
the ability to have two reservations between the same
source-destination pair at the same DSCP value is new in that draft.
That seems rather central to the ability to have different aggregate
reservations for each precedence level.

I guess this also means that this document is the first time we've
discussed how to handle the preemption issue with the security/IPSec
community.  I suspect you will get some pushback to language in this
document.

I'm working on getting that review, but I expect the discussion to get
all tangled in draft-ietf-tsvwg-rsvp-ipsec, so another reason I don't
think we can consider one without the other.

[Ballot discuss]
> This means that the
> Guard must somehow receive and respond to, on behalf of the VPN
> Router, messages that are not directed to it.  There are several
> possible solutions:
>
> o  The two devices could use a common MAC and IP address, so that
>    traffic destined to one is also received by the other

This appears problematic, e.g., I do not understand
how it would work with IPv6 and DAD.

I do realize that the authors are stating earlier
that there are several problems with these approaches.
Nevertheless, the listing of such solutions without
actually describing the problems appears potentially
dangerous. Since the authors recommend another alternative
anyway, I wonder if the list could be changed to
simply talk about the problems and then recommend
the other solution that is currently recommended.

(And I'm not quite sure why this document needs
to discuss the separation to begin with. This
seems to be an implementation issue.)

[Ballot comment]
Section 1., paragraph 10:
>    interface; a priority scheduler always chooses a datagram from the
>    highest priority class (queue) that is occupied, shielding one class
>    of traffic from jitter by passing jitter it would otherwise have
>    experienced to another class.

  "from most of the jitter" - because packet transmission is not
  preemtable, priority inversion through head-of-line blocking by
  lower-priority packets can occur

Further editing nits mailed to the authors, chairs and shepherds.

PROTO Write-up

1.a) Have the chairs personally reviewed this version of the Internet
Draft (ID), and in particular, do they believe this ID is ready
to forward to the IESG for publication? Which chair is the WG
Chair Shepherd for this document?

Yes, Shepherd is James Polk (jmpolk@cisco.com), TSVWG co-chair

1.b) Has the document had adequate review from both key WG members
and key non-WG members? Do you have any concerns about the
depth or breadth of the reviews that have been performed?

Yes. no concerns

1.c) Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, internationalization,
XML, etc.)?

No.

1.d) Do you have any specific concerns/issues with this document that
you believe the ADs and/or IESG should be aware of? For
example, perhaps you are uncomfortable with certain parts of the
document, or have concerns whether there really is a need for
it. In any event, if your issues have been discussed in the WG
and the WG has indicated it that it still wishes to advance the
document, detail those concerns in the write-up.

No.

1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There was solid consensus. It has been reviewed by a number of people.

1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in
separate email to the Responsible Area Director. (It should be
separate email because this questionnaire will be entered into
the tracker).

No, there are no threats of an appeal or extreme discontent wrt this
document's progression.

1.g) Have the chairs verified that the document checks out against
all the ID nits? (see http://www.ietf.org/ID-Checklist.html).
Boilerplate checks are not enough; this check needs to be
thorough.

Yes, this document has a single extra space character as its only
nit. This will be fixed, but should not impede the review progress in the
short term.

1.h) Has the document split its references into normative and
informative? Are there normative references to IDs, where the
IDs are not also ready for advancement or are otherwise in an
unclear state? The RFC Editor will not publish an RFC with
normative references to IDs (will delay the publication until
all such IDs are also ready for RFC publication). If the
normative references are behind, what is the strategy for their
completion? On a related matter, are there normative references
that are downward references, as described in BCP 97, RFC 3967
RFC 3967 [RFC3967]? Listing these supports the Area Director in
the Last Call downref procedure specified in RFC 3967.

References split. There are 3 normative references that are Internet
Drafts. Since this document's submission in Feb 06, two of these within
this ID have become RFCs (RFC 4495 and RFC 4542), and the other is should
progress at the same time through IESG review and the RFC-Editor
(draft-ietf-tsvwg-rsvp-ipsec-01.txt). as a dependent reference.

1.i) For Standards Track and BCP documents, the IESG approval
announcement includes a write-up section with the following
sections:

* Technical Summary

More and more networks wish to guarantee secure transmission of IP traffic
for across public LANs or WANs and therefore use Virtual Private
Networks. Some networks require communication between an interior and
exterior portion of a VPN, but have sensitivities about what information is
communicated across the boundary. This document seeks to outline the
issues and the nature of the proposed solutions. The outline of the QoS
solution for real-time traffic has been described at a high level in RFC
4542.

The thrust of this document involves VPNs that use encryption in some form,
such as IPsec. As a result, this document will discuss the VPN Router
supporting "plaintext" and "ciphertext" interfaces. However, the concept
extends readily to any form of aggregation, including the concept proposed
in [RFC3175] of the IP traffic entering and leaving a network at identified
points, and the use of other kinds of tunnels including GRE, IP/IP, MPLS,
and so on.

* Working Group Summary

There is strong consensus in the WG to publish this document. It has been
reviewed by several people prior to and in the WG last call. Comments
raised have been addressed.

* Protocol Quality

This document does not propose any protocol extension.

This document has been well reviewed in the WG and comments raised have
been addressed.