Subject: QoS and IKEv2

From: "Jesse Alpert" <[email-masked]>
Date: Wed, 5 Mar 2003 11:36:08 +0200

Hi,

If I understood correctly one of the reasons for supporting "fast" creation
of multiple SAs between a single pair of entities (via the CREATE_CHILD_SA
exchange) was to allow support for QoS. The theory was that data streams
requiring different QoS levels are to be sent over separate tunnels to avoid
problems with the replay counter which arise when some packets are tunneled
faster than others.

The original requirements document (draft-ietf-ipsec-sonofike-rqts-00.txt)
stated that:
  "negotiation of IPsec tunnels needs to accommodate QoS
   information, predominantly in the set of selectors used to identify
   the contents of any particular IPsec tunnel"

I can not find any reference to this in the current IKEv2 draft (ikev2-05).
A peer may need to create multiple tunnels with the exact same traffic
selectors but with different QoS levels (ToS). How does one peer inform the
other what type of traffic is to pass in each tunnel. Theoretically this
information does not have to be negotiated as the initiator can establish a
few tunnels and send the data over them any way he wishes, but the responder
should at least expect this behavior and be willing to keep multiple
identical SAs for an extended period of time (the draft currently states
that "An endpoint SHOULD wait a random amount of time before closing a
redundant SA to prevent cycling"). In addition if the traffic is
bi-directional, the responder will have to somehow select a different tunnel
for every different QoS level of the packets it is sending. It seems to me
it may be easier to explicitly include this (ToS) information in the TS
payload.

Am I missing something?

Jesse

---

From: [email-masked]
Date: Mon, 10 Mar 2003 11:27:30 -0500

Radia and Jesse,

Comments embedded ...

Thanks, --David

> >Again, it seems to me it might be easier to explicitly include this (PHB)
> >information in the TS payload. This requires modifications to the IKEv2
> >draft.
> >
> >Thanks again,
> >Jesse
> 
> Thank you for noticing that, Jesse. The problem (to summarize
> without diffserv acronyms) is that IKEv2 says that two
> child-SAs with the same traffic selectors are redundant,
> and extra ones should be closed. But it also says that
> you might want several between the same endpoints with
> the same traffic selectors for different QOS.
> 
> I'd propose that there should be some way to create
> multiple SAs with the same traffic selectors, and
> that it's not necessary to negotiate what QOS things
> go over which ones. It's up to the sender to
> decide that. And there might in the future be
> other reasons to create multiple SAs and
> we wouldn't be able to tell the difference
> based solely on the fields in the traffic
> selector (protocol type, address, and port).

Part of the sender deciding that might involve some
sort of QoS protocol or protocol feature run through the
SA to get some sort of agreement between the ends.  Two
examples are RSVP using the DCLASS object (RFC 2996) and
L2TP using its DiffServ Extension (RFC 3308); these function
in somewhat different fashions to achieve similar ends.
This functional difference is among the reasons for keeping
IKE out of this QoS negotiation area.

Some discussion of leaving QoS negotiation and the like
to protocols that run through the CHILD SA after
it's been created would be a good thing for the IKEv2
draft, including these two examples.  

> So I'd propose one more field in the traffic
> selector for "uniquifier". Alice can create
> multiple child-SAs to Bob with the same
> traffic selectors, as long as they have different
> uniquifiers.
> 
> The only function of the uniquifier is so that
> the multiple SAs won't look redundant to Bob.
> Which traffic gets sent over which SA is up
> to the sender.
> 
> Radia