QoS and IKEv2

["Jesse Alpert" <jalpert@CheckPoint.com>]

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