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

[Bill Sommerfeld <sommerfeld@xxxxxxx>]

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
Ipsec@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ipsec