Subject: [Ipsec] Re: [saag] tsvwg, preemption and rsvp: exposing characteristics of confidential traffic

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 29 Sep 2006 14:46:59 -0400

On Fri, 2006-09-29 at 14:33 -0400, Sam Hartman wrote:
> 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?

it's something we've signed on to in the past in the context of
diffserv; the architecture is such that the actual
preemption/priority/etc mechanism is almost completely opaque to IPsec.

See rfc4301, halfway into section 4.1 (starting near the bottom of page
13):

   If different classes of traffic (distinguished by Differentiated
   Services Code Point (DSCP) bits [NiBlBaBL98], [Gro02]) are sent on
   the same SA, and if the receiver is employing the optional
   anti-replay feature available in both AH and ESP, this could result
   in inappropriate discarding of lower priority packets due to the
   windowing mechanism used by this feature.  Therefore, a sender SHOULD
   put traffic of different classes, but with the same selector values,
   on different SAs to support Quality of Service (QoS) appropriately.
   To permit this, the IPsec implementation MUST permit establishment
   and maintenance of multiple SAs between a given sender and receiver,
   with the same selectors.  Distribution of traffic among these
   parallel SAs to support QoS is locally determined by the sender and
   is not negotiated by IKE.  The receiver MUST process the packets from
   the different SAs without prejudice.  These requirements apply to
   both transport and tunnel mode SAs.  In the case of tunnel mode SAs,
   the DSCP values in question appear in the inner IP header.  In
   transport mode, the DSCP value might change en route, but this should
   not cause problems with respect to IPsec processing since the value
   is not employed for SA selection and MUST NOT be checked as part of
   SA/packet validation.  However, if significant re-ordering of packets
   occurs in an SA, e.g., as a result of changes to DSCP values en
   route, this may trigger packet discarding by a receiver due to
   application of the anti-replay mechanism.

seems obvious to extend this to rsvp or any other scheme which involves
intentional packet reordering by the network.

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: [email-masked]
Date: Fri, 29 Sep 2006 18:01:23 -0400

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.

> unprotected side of the interface what fraction of your traffic is at

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
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Sam Hartman
> Sent: Friday, September 29, 2006 2:34 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> 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.
> 
> 
> 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
> [email-masked]
> http://mailman.mit.edu/mailman/listinfo/saag
>