RE: QoS and IKEv2

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

Hi,
Thanks for your response,

> Actually, it should be PHB information.  For more discussion of QoS
> and tunnels, see RFC 2983.  RFC 3308 contains a worked solution to
> this sort of problem for L2TP.

RFC 2983 specifies:
   "If reordering-based differentiation is desired within
   such tunnels, multiple parallel tunnels between the same endpoints
   should be used."

I was merely saying that the IKEv2 draft does not seem to support this,
since there is no way to indicate to the responder what the tunnels are
going to be used for (see my original message below). Indeed the responder
is advised to "wait a random amount of time before closing a redundant SA"
[ikev2-05] - which would seem to prevent creation of multiple IPsec tunnels
differing only by PHB information.

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




-----Original Message-----
From: owner-ipsec@lists.tislabs.com
[mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Black_David@emc.com
Sent: Wednesday, March 05, 2003 8:13 PM
To: jalpert@CheckPoint.com; ipsec@lists.tislabs.com
Subject: RE: QoS and IKEv2


> It seems to me it may be easier to explicitly include this (ToS)
> information in the TS payload.

Actually, it should be PHB information.  For more discussion of QoS
and tunnels, see RFC 2983.  RFC 3308 contains a worked solution to
this sort of problem for L2TP.

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@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: Jesse Alpert [mailto:jalpert@CheckPoint.com]
> Sent: Wednesday, March 05, 2003 4:36 AM
> To: ipsec@lists.tislabs.com
> Subject: QoS and IKEv2
>
>
> 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
>