Re: tsvwg, preemption and rsvp: exposing characteristics of confidentialtraffic
<Black_David <at> emc.com>
2006-09-29 22:01:23 GMT
Sam,
The terminology in this space is confusing, and used in different
ways in different documents, so let's stick to this clarification
from Section 1 of the VPN Signaled Preemption draft:
For the purposes of the
present discussion, "priority" is a set of algorithms applied to
datagrams, where "precedence" is a policy attribute of sessions.
In other words, "priority" is about traffic handling (e.g., Diffserv)
whereas "precedence" is about admission control. Despite this, the
VPN Signaled Preemption draft then proceeds to use "Priority" (NB:
first letter capitalized) for things that are actually "precedence".
For example, in Section 1.3:
Preemption of a reservation is specified in the context,
in [RFC3181] which in essence specifies that a reservation installed
in the network using an Preemption Priority and retained using a
separate Defending Priority may be removed by the network via an RESV
Error signal that removes the entire reservation.
That's an unfortunate source of confusion. I would strongly encourage
the authors to clean this up, particularly their unfortunate use of
'"priority"' as a precedence level in Sections 2.3.3 and 2.3.4 (example
quoted below in this message).
In order to avoid further confusion, I will use the phrase "Diffserv
priority" to refer to priority for datagram traffic handling.
Nonetheless, on your concern:
> These drafts set up a model under which each precedence class of data
> from a preemption standpoint goes over its own SA and uses its own
> aggregate RSVP reservation. What that means is you expose on the
> unprotected side of the interface what fraction of your traffic is at
> each precedence level.
Actually, only the vpn-signaled-preemption draft appears to do this.
The rsvp-ipsec draft allows multiple reservations between the same
endpoints for the same DSCP, which would allow such traffic to use
different tunnels but if it requires traffic for different
reservations to use different tunnels, I was not able to find
a statement of that requirement.
OTOH, the vpn-signaled-preemption draft is quite clear that different
precedence levels for the same DSCP result in different IPsec tunnels.
Section 2.3.3 says:
Due to
the mechanics of preemption, however, this would not expand the
existing "routine" reservations in the interface and inner domains,
as doing this causes loss of information - how much of the
reservation is now "routine" and how much is "priority"? Rather,
this new reservation will open up a separate set of tunnels or
security associations for traffic of its application class at its
precedence between that aggregator and deaggregator.
Here, "priority" is being used in its "Priority" sense as a level of
precedence. The concern I have here is that the second sentence quoted
above does not immediately follow from the first - there's a missing
logical step in asserting that if the aggregate traffic for a DSCP
(single Diffserv priority level) exceeds the reserved and/or available
capacity then the policing of that traffic to the appropriate limit
MUST respect precedence (i.e., delay/drop/shape "routine" traffic before
"priority" traffic). That requirement should be asserted and defended
in the vpn-signaled-preemption draft, because it is what leads to
your concern. Meeting that requirement in general requires segregation
of traffic at each precedence level within a single Diffserv priority,
and because the reservation identity is not marked on the datagrams,
separate IPsec tunnels are needed to do this, thus making precedence
distinctions within a Diffserv priority visible to traffic analysis
between the VPN routers.
At least, that's what I think is going on (the confusing use of the
'priority' word doesn't help). I've added Fred Baker and Francois
LeFaucheur to the cc: line so that they can correct anything
I've gotten wrong. If my above explanation is correct, I can answer
your first question:
> First question: Is this new or something we have signed onto
> in the past?
I'm the author of RFC 2983, the initial source of the concepts
in the RFC 4301 text that Bill Sommerfeld quoted, and I was involved
in making sure that RFC 4301 covered that issue. IMHO, from a Diffserv
and IPsec standpoint, I believe this is new and (as stated above), I
think the vpn-signaled-preemption draft should state and defend this
precedence-aware-traffic-conditioning requirement. That discussion
could then be expanded to cover your second question:
> Obviously, it is sometimes desirable to set things up this way.
> However if this is new, are we happy with this being a requirement?
> Are there situations where the distribution of traffic precedences is
> sufficiently sensitive that we'd rather make ugly tradeoffs than
> expose it?
I share your concern about this being a requirement.
Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
black_david <at> emc.com Mobile: +1 (978) 394-7754
----------------------------------------------------
> -----Original Message-----
> From: saag-bounces <at> MIT.EDU [mailto:saag-bounces <at> MIT.EDU] On
> Behalf Of Sam Hartman
> Sent: Friday, September 29, 2006 2:34 PM
> To: saag <at> MIT.EDU; ipsec <at> ietf.org
> Cc: tsvwg-chairs <at> tools.ietf.org
> Subject: [saag] tsvwg,preemption and rsvp: exposing
> characteristics of confidentialtraffic
>
>
>
>
>
> There are two RSVP drafts before the IESG or in last call that affect
> the security community.
>
>
> The first is draft-ietf-tsvwg-rsvp-ipsec and the second is
> draft-ietf-tsvwg-vpn-signal-preemption.
>
>
> These drafts set up a model under which each precedence class of data
> from a preemption standpoint goes over its own SA and uses its own
> aggregate RSVP reservation. What that means is you expose on the
> unprotected side of the interface what fraction of your traffic is at
> each precedence level.
>
> First question: Is this new or something we have signed onto in the
> past?
>
> Obviously, it is sometimes desirable to set things up this way.
> However if this is new, are we happy with this being a requirement?
> Are there situations where the distribution of traffic precedences is
> sufficiently sensitive that we'd rather make ugly tradeoffs than
> expose it?
>
>
> I'd appreciate your input on these questions and any comments you have
> on the two drafts.
>
> Thanks,
>
> Sam Hartman
> Security Area Director
>
>
> _______________________________________________
> saag mailing list
> saag <at> mit.edu
> http://mailman.mit.edu/mailman/listinfo/saag
>
RSS Feed