Subject: [Gen-art] Gen-ART review of draft-ietf-tsvwg-vpn-signaled-preemption-01

From: "Sharon Chisholm" <[email-masked]>
Date: Sun, 1 Oct 2006 21:13:04 -0400

I am the the assigned General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). 

	Please resolve these comments along with any other Last Call
comments you may receive. 

Document: 
--------

            QoS Signaling in a Nested Virtual Private Network
      <draft-ietf-tsvwg-vpn-signaled-preemption-01.txt>

Summary:
-------

	This draft is not quite ready for publication. 

Comments: 
--------- 

As this was a -00 version of the document (then published a few days ago
with minor changes as -01) I was curious as to how much review it
received from the working group. I reviewed the mailing list and only
saw one reply to working group last call on the document to make some
minor updates. It might be worthwhile to solicit the working group for
further review.

I expect that once some of these scope and organization issues are
addressed, the document will be a bit easier to review to find more
specific problems.

1. The document doesn't seem to agree on its purpose. In the abstract it
claims
"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 note seeks to outline the
   issues and the nature of the proposed solutions."
But later on the document claims "The key question this document
explores is "how do reservations, and
   preemption of reservations, work in such an environment?", where such
an environment is nested VPNs. The document does seem to talk about both
and they seem related, but still this needs to be clarified.

2. The abstract says 'This note seeks to outline the issues and the
nature of the proposed solutions.', it would be good to refer to what
the specific solution are.

3. Section 1 is titled 'QoS in a VPN domain', but is actually a mishmash
of topics. It contains a reiteration of the purpose of the document with
respect to interior/exterior, tutorial on a number of topics, and some
clarification of term usage specific to this document. The title of the
section seems a bit off and the information within the section would be
better organized into the sections I mentioned or some other form to
reduce the feeling of 'here is some information' and 'here is some more
information' that this document has on occasion. 

4. Figure 2 is barely a figure and doesn't really demonstrate
communication between the three entities listed.

5. In section 1.1, titled 'Nested VPNs', we get three quarters of the
way through, in the paragraph just before figure 3, before we finally
start talking about nesting VPNs.

6. Figure 5 is very ambitious for ASCII art and I don't find it terribly
readable. This figure is then referenced through very long examples
walking through its H5 and R4 type labels. I wonder if this is a simpler
way to convey the same information?

7. Is DSCP corollary a well-known term? I googled and didn't find it
used. I also didn't see it defined in the document.

8. In section 2.1, second set of bullets it says "The Preemption
Priority of a tunnel reservation is identical to that of the individual
reservations it aggregates.", which implies that only reservations of
the same priority level can be put into an association. Is that correct?

9. In section 5, the fourth paragraph does not seem to be discussing a
security consideration.

10. Section 3 claims that it 'details the data flows within a VPN
Router, in the context of sessions as described in Section 2.', which
isn't that helpful. If we mean some of the nested VPNs discussed, we
should clearly say this rather then using a cryptic cross references. 

Nits
----

1. In section 1, first sentence, it says 'guarantee secure transmission
of IP traffic for across public LANs or WANs'. Delete the 'for'

2. Figure 1 is not readable because there is not sufficient space
between it and the preceding text.

3. Section 1.3, second paragraph says "Preemption of a reservation is
specified in the context,
   in [RFC3181]", which perhaps should read 'this context'.

4. In section 2.1, first sentence it says 'A reservation in a nest VPN'.
I believe that should be 'nested'.

5. In section 2.1, just before the bullets it says 'If the VPN Tunnel is
an IPSec Security Association between the VPN Routers and the IP packet
is entirely contained within ', which doesn't really parse.

6. In section 3.1.1., it says 'RESV Confirm:  This indicates that a RESV
message received as data
      and forwarded into the enclave, and is now being confirmed.',
which doesn't parse.

7. Section 3.2.1 first paragraph talks about 'th cipher', which should
be 'the cipher'.

8. Section 5, second paragraph says "One of the reasons cited for the
nesting of VPN routes in Section 1.1 are the different levels ", when
that should be 'is the different levels'. 

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Fred Baker <[email-masked]>
Date: Mon, 2 Oct 2006 11:56:50 -0700

I get the impression that you didn't like the document :-)

On Oct 1, 2006, at 6:13 PM, Sharon Chisholm wrote:
> As this was a -00 version of the document (then published a few  
> days ago with minor changes as -01) I was curious as to how much  
> review it received from the working group. I reviewed the mailing  
> list and only saw one reply to working group last call on the  
> document to make some minor updates. It might be worthwhile to  
> solicit the working group for further review.

Note that this lived for a long time as an individual submission  
before being picked up as a working group item, and the individual  
submission was in fact discussed both on the working group list and  
face to face. The working group's specific comments on it were along  
the lines that some felt the IETF should no longer be working on the  
Integrated Services Architecture, while others felt that it should be  
worked on, and in general the ADs wanted to slow roll the thing to  
make time for NSIS to catch up with RSVP - a matter that the authors  
considered appealing. This has now sat in the IESG queue for the  
better part of a year without review, which may also be appealable.

> addressed, the document will be a bit easier to review to find more

We're very willing to work with you on technical and editorial  
issues. We do hope to achieve closure within our lifetime.

> 1. The document doesn't seem to agree on its purpose. In the  
> abstract it claims "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  
> note seeks to outline the issues and the nature of the proposed  
> solutions." But later on the document claims "The key question this  
> document
> explores is "how do reservations, and preemption of reservations,  
> work in such an environment?", where such an environment is nested  
> VPNs. The document does seem to talk about both and they seem  
> related, but still this needs to be clarified.

OK, we'll see if can tighten language on the purpose of the document.  
Bottom line, it is about implementing the Integrated Services  
architecture as described in RFC 2998 across a type of VPN in which  
not only the connected enclaves don't share knowledge with the  
network they run over, but that network doesn't share knowledge with  
them. Examples might include a military network that runs over a  
commercial network (yes, that happens), or a civilian first responder  
call that is crossing a military network (yes, that happens).

> nature of the proposed solutions.', it would be good to refer to  
> what the specific solution are.

Given the substance of the document, what would you think the  
proposed solutions are? We thought that section 2 gave a pretty  
complete overview, description, and example. Specifically what are  
you looking for here?

> 3. Section 1 is titled 'QoS in a VPN domain', but is actually a  
> mishmash of topics. It contains a reiteration of the purpose of the  
> document with respect to interior/exterior, tutorial on a number of  
> topics, and some clarification of term usage specific to this  
> document. The title of the section seems a bit off and ...

Would it help if we renamed the section "Introduction"? It seems that  
the idnits tool complains that we don't follow the boilerplate in  
that regard.

> ...the information within the section would be better organized  
> into the sections I mentioned or some other form to reduce the  
> feeling of 'here is some information' and 'here is some more  

Telling me that you want the organization different without telling  
me in what way isn't all that helpful. Specifically how would you  
suggest we organize the information to improve your comprehension of it?

> communication between the three entities listed.

Yes. Something seems to have gotten lost there.

> 5. In section 1.1, titled 'Nested VPNs', we get three quarters of  
> the way through, in the paragraph just before figure 3, before we  
> finally start talking about nesting VPNs.

This comment really throws me. The text starts out with the sentence  
"One could describe such a network in terms of three network  
diagrams." We try to show a VPN and then show how VPNs can be nested,  
and comment that our requirements deal with both structures. In the  
ASCII version, this is a two pages of text, with the diagram that one  
wishes was on the second page on a third due to the editing tool. It  
seems that we're not being allowed to introduce the topic - and I  
guarantee that if we are not, the discussion of its solution won't  
make any sense either.

> 6. Figure 5 is very ambitious for ASCII art and I don't find it  
> terribly readable. This figure is then referenced through very long  
> examples walking through its H5 and R4 type labels. I wonder if  
> this is a simpler way to convey the same information?

It is indeed complex. It is a fairly complex problem. Now, I could if  
you like break it up the way I broke up section 1.1, which you  
complained about. We could discuss handling the problem of preemption  
in a VPN, and then separately discuss nesting the VPNs. Would that  
help? Would you then complain about that level of complexity?

> 7. Is DSCP corollary a well-known term? I googled and didn't find  
> it used. I also didn't see it defined in the document.

I think I meant "DSCP corollary to". The point is that the DSCP  
should correspond to the reservation and the data it should carry -  
either be the same DSCP, or use a value that maps to the DSCP, as  
discussed in the security considerations.

If I change that to "corollary to", does that work for you?

> Priority of a tunnel reservation is identical to that of the  
> individual reservations it aggregates.", which implies that only  
> reservations of the same priority level can be put into an  
> association. Is that correct?

Yes, that is correct. One could imagine aggregation of reservation  
precedences as well, but that is a separate discussion - the various  
precedences are in that case at the same numeric priority.

> 9. In section 5, the fourth paragraph does not seem to be  
> discussing a security consideration.

You're talking about this, right?

    VPN Routers encapsulate encrypted IP packets and prepend an extra
    header on each packet.  These packets, whether used for signaling or
    data, should be identifiable, at a minimum by the IP addresses and
    DSCP value.  The prepended header, therefore, should contain at a
    minimum the DSCP value corresponding to the signaled reservation in
    each packet.  This may literally be the same DSCP as is used for the
    data (forcing control plane traffic to receive the same QoS  
treatment
    as its data), or a different DSCP that is routed identically
    (separating control and data plane traffic QoS but not routing).

Specifically, this paragraph was requested by the people who specify  
the encryptors in question. They view the idea that the encryptor  
might allow the DSCP through to be a security vulnerability. Russ  
Housley might be in a position to advise us here.

> Router, in the context of sessions as described in Section 2.',  
> which isn't that helpful. If we mean some of the nested VPNs  
> discussed, we should clearly say this rather then using a cryptic  
> cross references.

Again, this was requested by the folks who specify the encryptors in  
question. They want to be able to identify exactly what information  
crosses the boundary and what does not.

I'm not sure whether you are saying that section 3 isn't helpful to  
you, or whether you are saying section 2 didn't help. Please say more.

> Nits
> ----
>
> 1. In section 1, first sentence, it says 'guarantee secure  
> transmission of IP traffic for across public LANs or WANs'. Delete  
> the 'for'
>
> 3. Section 1.3, second paragraph says "Preemption of a reservation  
> is specified in the context,    in [RFC3181]", which perhaps should  
> read 'this context'.
>
> 4. In section 2.1, first sentence it says 'A reservation in a nest  
> VPN'. I believe that should be 'nested'.
>
> 5. In section 2.1, just before the bullets it says 'If the VPN  
> Tunnel is an IPSec Security Association between the VPN Routers and  
> the IP packet is entirely contained within ', which doesn't really  
> parse.
>
> 6. In section 3.1.1., it says 'RESV Confirm:  This indicates that a  
> RESV message received as data       and forwarded into the enclave,  
> and is now being confirmed.', which doesn't parse.
>
> 7. Section 3.2.1 first paragraph talks about 'th cipher', which  
> should be 'the cipher'.
>
> 8. Section 5, second paragraph says "One of the reasons cited for  
> the nesting of VPN routes in Section 1.1 are the different levels  
> ", when that should be 'is the different levels'.

---

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 2 Oct 2006 15:47:10 -0400

hi 

<Fred>
</Fred>

I wouldn't go that far. It's just that I felt I kept getting lost in it.
There seemed to be a lot of good information, I think it just needs to
be reworked a bit.

<Fred>
> 1. The document doesn't seem to agree on its purpose. In the abstract 
> it claims "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 note seeks to 
> outline the issues and the nature of the proposed solutions." But 
> later on the document claims "The key question this document explores 
> is "how do reservations, and preemption of reservations, work in such 
> an environment?", where such an environment is nested VPNs. The 
> document does seem to talk about both and they seem related, but still

> this needs to be clarified.

OK, we'll see if can tighten language on the purpose of the document.  
Bottom line, it is about implementing the Integrated Services
architecture as described in RFC 2998 across a type of VPN in which not
only the connected enclaves don't share knowledge with the network they
run over, but that network doesn't share knowledge with them. Examples
might include a military network that runs over a commercial network
(yes, that happens), or a civilian first responder call that is crossing
a military network (yes, that happens).

</Fred>

That would be very helpful. This description is also more helpful then
what is currently in the draft. Deciding a single statement of problem
and propagating it through the document would be helpful. Is the
interior/exterior the problem focus, the nesting of VPNs or both in
combination, for example.

<Fred>
> the specific solution are.

Given the substance of the document, what would you think the proposed
solutions are? We thought that section 2 gave a pretty complete
overview, description, and example. Specifically what are you looking
for here?
</Fred>

Is there a succinct way of summarizing the 'specific solution'?

<Fred>

Would it help if we renamed the section "Introduction"? It seems that
the idnits tool complains that we don't follow the boilerplate in that
regard.

> ...the information within the section would be better organized into 
> the sections I mentioned or some other form to reduce the feeling of 
> 'here is some information' and 'here is some more information' that 
> this document has on occasion.

Telling me that you want the organization different without telling me
in what way isn't all that helpful. Specifically how would you suggest
we organize the information to improve your comprehension of it?
</Fred>

Actually, I did make a suggestion. I suggested organizing things as
problem statement, background information and terminology. Calling the
entire thing Introduction sounds good.

<Fred>

This comment really throws me. The text starts out with the sentence
"One could describe such a network in terms of three network diagrams."
We try to show a VPN and then show how VPNs can be nested, and comment
that our requirements deal with both structures. In the ASCII version,
this is a two pages of text, with the diagram that one wishes was on the
second page on a third due to the editing tool. It seems that we're not
being allowed to introduce the topic - and I guarantee that if we are
not, the discussion of its solution won't make any sense either.
</Fred>

My point was, aside from the first sentence that says 'such' a network
(and you should clarify what 'such' a network is since this is
potentially ambiguous given this is a new section), the next page or so
goes on to describe the steps performed by a (non-nested) VPN router.

<Fred>
> examples walking through its H5 and R4 type labels. I wonder if this 
> is a simpler way to convey the same information?

It is indeed complex. It is a fairly complex problem. Now, I could if
you like break it up the way I broke up section 1.1, which you
complained about. We could discuss handling the problem of preemption in
a VPN, and then separately discuss nesting the VPNs. Would that help?
Would you then complain about that level of complexity?
</Fred>

My complaint with section 1 wasn't that it was broken down into
sections, it that it could be better organized. I don't know what the
best way to help figure 5 would be. If it is describing two different
concepts it might be helpful to represent it separately. Or perhaps
since each enclave seems to have the same thing in it, we could hide
those details in the figure. The contents of an enclave could be shown
in a separate picture. And that way, there might be room to refer
instead to Router 1, Router 2, Host 1, Host 2, VPN 1, VPN 2 in the
figure as well as in the text. I think that would be an improvement.

<Fred>
> used. I also didn't see it defined in the document.

I think I meant "DSCP corollary to". The point is that the DSCP should
correspond to the reservation and the data it should carry - either be
the same DSCP, or use a value that maps to the DSCP, as discussed in the
security considerations.

</Fred>

Well, you wouldn't then we introducing a new term, so that solves the
issue but the way you explained it here is much more understandable.

<Fred>

Specifically, this paragraph was requested by the people who specify the
encryptors in question. They view the idea that the encryptor might
allow the DSCP through to be a security vulnerability. Russ Housley
might be in a position to advise us here.
</Fred>

So, this is intended to be identifying requirements to prevent a
specific security vulnerability? Some discussion on the security
vulnerability would help put it in context. Otherwise it reads like a
bit of oddly placed tutorial.

<Fred>

I'm not sure whether you are saying that section 3 isn't helpful to you,
or whether you are saying section 2 didn't help. Please say more.
</Fred>

The criticism is that the introduction to section 3 does not introduce
section 3 terribly well.  

Sharon