Subject: [IPsec] Query regarding Qos with IKE

From: Paul Simon <[email-masked]>
Date: Mon, 4 Nov 2013 14:36:05 +0530

Hi,

We are having a requirement to have Qos per CHILD SA inside one IKE SA or
to have Qos per IKE SA. Is it possible to communicate the Qos in IKE
handshake ? Or else how can we achieve to use different Qos, atleast per
IKE SA.

To give a background on the issue we are working on. In usual LTE and 3G
mobile networks before establishing a connection, the UE would sent out the
desired Qos details to the mobile network. The network will then decide on
what Qos can be granted and then communicate this information to UE.
Now people are increasingly using WiFi to connect to mobile network. So we
need a secure connection from WiFi UE to network. For this IPsec is being
recommended in the standards. So here comes the issue how can the mobile
communicate what Qos is preferred to network in IKE handshake.

so can any one throw some light on the issue ?

Thanks and Regards,
Paul Simon

---

From: Yoav Nir <[email-masked]>
Date: Mon, 4 Nov 2013 09:42:56 +0000

Hi, Paul

I'm not sure I understand the issue. IPsec is carrying some IP-based protocol from the UE, through some gateway to a host in the service provider's network. Those IP packets can have QoS indication like any other IP packets, through the TOS field in IPv4 or the Traffic Class field in IPv6. Those fields get encrypted and encapsulated with the entire IP packet and come out the same at the other side, so they go into the provider network with the same properties.

According to RFC 4301, the IPsec packet inherits the ECN and DS fields from the inner packet.  See sections 5.1.2.1 and 5.1.2.2. So the DS field set by the UE is propagated throughout the packet's path.

Hope this helps

Yoav

On Nov 4, 2013, at 1:06 AM, Paul Simon <[email-masked]> wrote:

> Hi,
>  
>  
> We are having a requirement to have Qos per CHILD SA inside one IKE SA or to have Qos per IKE SA. Is it possible to communicate the Qos in IKE handshake ? Or else how can we achieve to use different Qos, atleast per IKE SA.
>  
> To give a background on the issue we are working on. In usual LTE and 3G mobile networks before establishing a connection, the UE would sent out the desired Qos details to the mobile network. The network will then decide on what Qos can be granted and then communicate this information to UE.
> Now people are increasingly using WiFi to connect to mobile network. So we need a secure connection from WiFi UE to network. For this IPsec is being recommended in the standards. So here comes the issue how can the mobile communicate what Qos is preferred to network in IKE handshake.
>

---

From: Paul Simon <[email-masked]>
Date: Mon, 4 Nov 2013 23:09:41 +0530

Hi,

Thanks for the answer.

I would like to know if there is any possibility to negotiate Qos through
IKE procedures, so that both the end apply the agreed Qos.

In RFC 5996, section 2.8
 "Note that IKEv2 deliberately allows parallel SAs with the same
   Traffic Selectors between common endpoints.  One of the purposes of
   this is to support traffic quality of service (QoS) differences among
   the SAs (see
[DIFFSERVFIELD<http://tools.ietf.org/html/rfc5996#ref-DIFFSERVFIELD>],
[DIFFSERVARCH <http://tools.ietf.org/html/rfc5996#ref-DIFFSERVARCH>], and
Section 4.1 of
   [DIFFTUNNEL <http://tools.ietf.org/html/rfc5996#ref-DIFFTUNNEL>]). "

But I have not seen any Qos parameter in the IKE messages. So how the Qos
is negotiated between end parties using IKE SAs ?
Can you explain little bit on Qos agreement.

Thanks,
Paul

On Mon, Nov 4, 2013 at 3:12 PM, Yoav Nir <[email-masked]> wrote:

> Hi, Paul
>
> I'm not sure I understand the issue. IPsec is carrying some IP-based
> protocol from the UE, through some gateway to a host in the service
> provider's network. Those IP packets can have QoS indication like any other
> IP packets, through the TOS field in IPv4 or the Traffic Class field in
> IPv6. Those fields get encrypted and encapsulated with the entire IP packet
> and come out the same at the other side, so they go into the provider
> network with the same properties.
>
> According to RFC 4301, the IPsec packet inherits the ECN and DS fields
> from the inner packet.  See sections 5.1.2.1 and 5.1.2.2. So the DS field
> set by the UE is propagated throughout the packet's path.
>
> Hope this helps
>
> Yoav
>
> > We are having a requirement to have Qos per CHILD SA inside one IKE SA
> or to have Qos per IKE SA. Is it possible to communicate the Qos in IKE
> > Now people are increasingly using WiFi to connect to mobile network. So
> we need a secure connection from WiFi UE to network. For this IPsec is
> being recommended in the standards. So here comes the issue how can the
> mobile communicate what Qos is preferred to network in IKE handshake.
> >

---

From: Yoav Nir <[email-masked]>
Date: Mon, 4 Nov 2013 17:50:40 +0000

There are currently no attributes in IKE to negotiate QoS.

The reason for that text in 5996 is the issue of IPsec packet re-ordering. If we use the same SA for packets with different QoS characteristics, then the QoS could then re-order them. This means that replay protection would drop legitimate packets simply because they arrived late. To avoid this, the sender may use several SAs so as to send packets with different QoS characteristics in different tunnels. This requires no negotiation of QoS characteristics between the peers, only negotiation of enough SAs for all the different QoS classes.

If I'm missing something, and there is a need to negotiate this, you can always submit an I-D.

Yoav

On Nov 4, 2013, at 9:39 AM, Paul Simon <[email-masked]<mailto:[email-masked]>>
 wrote:

Hi,

Thanks for the answer.

I would like to know if there is any possibility to negotiate Qos through IKE procedures, so that both the end apply the agreed Qos.

In RFC 5996, section 2.8
 "Note that IKEv2 deliberately allows parallel SAs with the same
   Traffic Selectors between common endpoints.  One of the purposes of
   this is to support traffic quality of service (QoS) differences among
   the SAs (see [DIFFSERVFIELD<http://tools.ietf.org/html/rfc5996#ref-DIFFSERVFIELD>], [DIFFSERVARCH<http://tools.ietf.org/html/rfc5996#ref-DIFFSERVARCH>], and Section 4.1 of
   [DIFFTUNNEL<http://tools.ietf.org/html/rfc5996#ref-DIFFTUNNEL>]). "

But I have not seen any Qos parameter in the IKE messages. So how the Qos is negotiated between end parties using IKE SAs ?
Can you explain little bit on Qos agreement.

Thanks,
Paul

On Mon, Nov 4, 2013 at 3:12 PM, Yoav Nir <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Paul

Hope this helps

Yoav

> so can any one throw some light on the issue ?

_______________________________________________
IPsec mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Michael Richardson <[email-masked]>
Date: Mon, 04 Nov 2013 18:18:09 -0500

> The reason for that text in 5996 is the issue of IPsec packet
    > re-ordering. If we use the same SA for packets with different QoS
    > characteristics, then the QoS could then re-order them. This means that
    > replay protection would drop legitimate packets simply because they
    > arrived late. To avoid this, the sender may use several SAs so as to
    > send packets with different QoS characteristics in different
    > tunnels. This requires no negotiation of QoS characteristics between
    > the peers, only negotiation of enough SAs for all the different QoS
    > classes.

    > can always submit an I-D.

I think you are missing the point.

Paul said:
> We are having a requirement to have Qos per CHILD SA inside one IKE SA or to
> have Qos per IKE SA. Is it possible to communicate the Qos in IKE handshake ?
> Or else how can we achieve to use different Qos, atleast per IKE SA.

so, you'd see that actually he wants to have multiple CHILD SAs already.
The point is that the packets coming into the tunnel may not be marked in any
particular way, and the "network" (as Paul calls it. I assume he means
some more specific LTE element) needs to inform the UE what markings to use.

4301, section 5.1.2 includes:
      > Another will allow the outer DS field to be mapped to a
      > fixed value, which MAY be configured on a per-SA basis. (The value
      > might really be fixed for all traffic outbound from a device, but
      > per-SA granularity allows that as well.) This configuration option

and this is what Paul wants to do.  The "network" (i.e. the access
concentrator) needs to tell the UE located at the client/device what DS to
use on that network.

My suggestion is, since this is not something is subject to negotiation, that 
simply defining a new notification value.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Yoav Nir <[email-masked]>
Date: Mon, 4 Nov 2013 23:34:36 +0000

Like I said, Paul can submit an I-D. 

But if the UE applies the diffserv to the clear packet, 4301 says that these attributes are copied to the ESP packet. There has to be some handshake at the application layer to pass this information, no?  And you really need to do this for the clear packet anyways, because it needs to be handled with QoS at the provider network too. If you do it in the app layer, it doesn't require any modifications to IKE.

Yoav

---

From: Paul Simon <[email-masked]>
Date: Tue, 5 Nov 2013 12:04:33 +0530

As indicated by Richardson [ The "network" (i.e. the access
concentrator) needs to tell the UE located at the client/device what DS to
use on that network. ]

This is exactly I need. The UE tells the network element what is the
desired Qos that UE is willing to use for an SA and Network in turn replies
to UE what Qos can really be used. (because finally it is the network which
decides what characteristics the traffic can hold).

So as I understand currently Qos cannot be indicated through IKE messages
and it has to be done through some application level protocols.

But since the Qos based traffic is gaining more importance these days, it
would be better if we can accommodate Qos as one of the parameter in IKE
negotiation messages.

Thanks,
Paul

On Tue, Nov 5, 2013 at 5:04 AM, Yoav Nir <[email-masked]> wrote:

> But if the UE applies the diffserv to the clear packet, 4301 says that
> these attributes are copied to the ESP packet. There has to be some
> handshake at the application layer to pass this information, no?  And you
> really need to do this for the clear packet anyways, because it needs to be
> handled with QoS at the provider network too. If you do it in the app
> layer, it doesn't require any modifications to IKE.
>
> Yoav
>
> or to

---

From: Yoav Nir <[email-masked]>
Date: Tue, 5 Nov 2013 06:45:25 +0000

Is what you're looking for multiple DS for the same selectors, or just a single DS for each set of selectors, that is determined by the AC?

On Nov 4, 2013, at 10:34 PM, Paul Simon <[email-masked]<mailto:[email-masked]>> wrote:

This is exactly I need. The UE tells the network element what is the desired Qos that UE is willing to use for an SA and Network in turn replies to UE what Qos can really be used. (because finally it is the network which decides what characteristics the traffic can hold).

So as I understand currently Qos cannot be indicated through IKE messages and it has to be done through some application level protocols.

But since the Qos based traffic is gaining more importance these days, it would be better if we can accommodate Qos as one of the parameter in IKE negotiation messages.

Thanks,
Paul

On Tue, Nov 5, 2013 at 5:04 AM, Yoav Nir <[email-masked]<mailto:[email-masked]>> wrote:
Like I said, Paul can submit an I-D.

Yoav

On Nov 4, 2013, at 3:18 PM, Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

>
> Yoav Nir <[email-masked]<mailto:[email-masked]>> wrote:
> ]     [email-masked]<mailto:[email-masked]>  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Jyoti Ranjan Senapati <[email-masked]>
Date: Tue, 5 Nov 2013 06:48:58 +0000

Hi ,,

I want to unfriend from this group. Can you please help .

Thanks and Regards,
Jyoti Ranjan Senapati

*****************************************************************************************************************************************************************************************
This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
************************************************************************************************************************************************************************************

From: [email-masked] [mailto:[email-masked]] On Behalf Of Yoav Nir
Sent: Tuesday, November 05, 2013 12:15 PM
To: Paul Simon
Cc: <[email-masked]>; Michael Richardson
Subject: Re: [IPsec] Query regarding Qos with IKE

Thanks,
Paul

Yoav

---

From: Paul Simon <[email-masked]>
Date: Tue, 5 Nov 2013 12:23:31 +0530

Hi,

I am looking for both the solutions.

But lets take the simpler case first, "single DS for each set of
selectors".
In this simple case as well, the DS should be negotiated (communicated )
from UE to Network Element and back from Network Element to UE before using
the DS.
Is it possible some way ?

My requirement is that both the end points agree on the DS before it is
getting used.

Thanks,
Paul

On Tue, Nov 5, 2013 at 12:15 PM, Yoav Nir <[email-masked]> wrote:

>  Is what you're looking for multiple DS for the same selectors, or just a
> single DS for each set of selectors, that is determined by the AC?
>
>  On Nov 4, 2013, at 10:34 PM, Paul Simon <[email-masked]> wrote:
>
>
> [email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Tue, 5 Nov 2013 07:31:24 +0000

We can't, but you can:

On Nov 4, 2013, at 10:48 PM, Jyoti Ranjan Senapati <[email-masked]<mailto:[email-masked]>> wrote:

Hi ,,

Thanks and Regards,
Jyoti Ranjan Senapati

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Yoav Nir
Sent: Tuesday, November 05, 2013 12:15 PM
To: Paul Simon
Cc: <[email-masked]<mailto:[email-masked]>>; Michael Richardson
Subject: Re: [IPsec] Query regarding Qos with IKE

Thanks,
Paul

Yoav

---

From: "Black, David" <[email-masked]>
Date: Tue, 5 Nov 2013 09:20:43 -0500

Be careful - if the IPsec SA or tunnel crosses diffserv domains, the outer DSCP won't have the same meaning at both ends.

The initial solution looks like it's single-domain - access concentrator to client on a single network.  Nonetheless, the solution needs to be designed for at least a couple of things beyond one DSCP and one domain, even if they won't be used initially:

- Detect Diffserv domain crossing that makes DSCP not usable by client
(e.g., transit over a second network happens between the client and access concentrator).
- Multiple DSCPs are involved, e.g., AF drop precedence with multiple DSCPs is being used with rate-based traffic shaping.

These don't have to fully work in the first solution, but the design needs to have some means to detect the first and accommodate the second in the future.  I would suggest looking at extending IKEv2's configuration support as a possible approach - see Section 3.15 in RFC 5996.

Thanks,
--David (an author of RFCs 2474, 2475 and 2983)

From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Simon
Sent: Tuesday, November 05, 2013 1:54 AM
To: Yoav Nir
Cc: <[email-masked]>; Michael Richardson
Subject: Re: [IPsec] Query regarding Qos with IKE

Hi,

But lets take the simpler case first, "single DS for each set of selectors".
In this simple case as well, the DS should be negotiated (communicated ) from UE to Network Element and back from Network Element to UE before using the DS.
Is it possible some way ?

My requirement is that both the end points agree on the DS before it is getting used.

Thanks,
Paul

On Tue, Nov 5, 2013 at 12:15 PM, Yoav Nir <[email-masked]<mailto:[email-masked]>> wrote:
Is what you're looking for multiple DS for the same selectors, or just a single DS for each set of selectors, that is determined by the AC?

Thanks,
Paul

Yoav

---

From: Michael Richardson <[email-masked]>
Date: Tue, 05 Nov 2013 12:33:55 -0500

Black, David <[email-masked]> wrote:
    > Be careful ? if the IPsec SA or tunnel crosses diffserv domains, the outer DSCP
    > won?t have the same meaning at both ends.

True, but let's no boil any oceans here.

    > The initial solution looks like it?s single-domain ? access concentrator to
    > client on a single network.  Nonetheless, the solution needs to be designed for
    > at least a couple of things beyond one DSCP and one domain, even if they won?t
    > be used initially:

Yes.

    > - Detect Diffserv domain crossing that makes DSCP not usable by client

How could one do this?

    > - Multiple DSCPs are involved, e.g., AF drop precedence with multiple DSCPs is
    > being used with rate-based traffic shaping.

I don't think that they need multiple DSCPs.
I think that they simply want to ask the UE to use a particular code point.

It seems like a very simple Notification would work fine, and I think that
the people doing this are in control of the IKE/IPsec stack on the UE, and
the IKE/IPsec stack on the peer, with the intervening network under their
influence, but not their control.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 05 Nov 2013 12:36:39 -0500

Yoav Nir <[email-masked]> wrote:
    > Is what you're looking for multiple DS for the same selectors, or just a single
    > DS for each set of selectors, that is determined by the AC?

For a given IPsec SA, they want to overwrite/force/set the DSCP to a
particular value.  It will not depend upon the traffic goes into it
(but, the SPD selectors may quite specificly pick the traffic).

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Praveen Sathyanarayan <[email-masked]>
Date: Tue, 5 Nov 2013 18:15:58 +0000

Hi Paul,

Extracts from 4301: Section 4.1

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.

DISCUSSION: Although the DSCP , Gro02 and Explicit
   Congestion Notification (ECN)  fields are not "selectors",
   as that term in used in this architecture, the sender will need a
   mechanism to direct packets with a given (set of) DSCP values to the
   appropriate SA.  This mechanism might be termed a "classifier".

[PRAVEEN] Does this answers your question? Looks like it was intentionally
not negotiated in IKE. And it looks like implementation decision on when
to negotiate multiple child SAs and how senders makes decision to put
which packet in which SA.

‹ Praveen

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 5 Nov 2013 20:41:28 +0200

> (but, the SPD selectors may quite specificly pick the traffic).

If I think RFC4301 already requires that. I.e. it requires
implementations to be able to map DSCP values to suitable value. If
the sender knows how to pick up suitable DSCP values and they are then
tunneled through the IPsec tunnel, then the receiving GW can use those
to map those values to the suitable values for the other domain.

As the IPsec processing is not affected by that mapping, there is no
point of negotiating it in the IKE. The DSCP can be used as classifier
which selects which packets are put to which SA, and this is required
because of the reordering problems, and this is already handled in the
IPsec.

I am missing how does the trasmitting this information from SGW to SGW
affect the IPsec processing? I do not think we should use IKE as
transmitting all kind of stuff that other end might be interested in.
It is better to use some protocol suitable for it. For example our
configuration payload tries to send only minimal set of parameters
which affect the IPsec processing (yes, there are some extra there
like DNS, and NBNS), and rest of the configuration parameters should
be gotten from the DHCP server (whose address is sent inside the
configuration payload).
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Tue, 05 Nov 2013 19:18:14 -0500

> to map those values to the suitable values for the other domain.

Yes, I did quote the part of 4301 that mandates that it be settable.

    > transmitting all kind of stuff that other end might be interested in.

It does not affect any processing. Who said that it did?

The question is, how does the UE know what DSCP to put on the ESP packet?
Yes, it could come from another protocol, but which?  IKE already did the
authentication, and so already established what entity is asking for service.
One might statically configure things, but if the UE moves around the exact
DSCP might change.  

As David Black pointed out, there might be Diffserv boundaries.  In that
case, the UE has to put the DSCP appropriate for the network the UE is
attached to, and for things to work, there either has to be DSCP rewriting
occuring at the diffserv boundary. But, all that matters is that the UE put
the DSCP in, the network takes care of the rest.h
The gateway might know where the diffserv boundaries are by special
knowledge, but there is no reason to need to tell the UE about it.

---

From: Paul Simon <[email-masked]>
Date: Wed, 6 Nov 2013 14:02:35 +0530

Yes now it is clear that IKE is not supposed to do DSCP negotiation
Thanks for the explanations.

Richardson's comment.

>>>influence, but not their control

[PAUL] I have gone through RFC 5996 section 3.10.1 notify message types.
But could not find a suitable message type to convey dscp information.
Can you suggest which notification message should be used here ?

Thanks,
Paul

---

From: Michael Richardson <[email-masked]>
Date: Wed, 06 Nov 2013 12:17:44 -0500

> Thanks for the explanations.

*negotiation* is the key word.
negotiation != notification

    > Can you suggest which notification message should be used here ?

Correct.
you'd have to write an ID on a new Notify type.

---

From: "Black, David" <[email-masked]>
Date: Wed, 6 Nov 2013 13:58:32 -0500

> you'd have to write an ID on a new Notify type.

Or on a new Configuration Attribute if that's more appropriate -
see section 3.15.1 of RFC 5996.

Thanks,
--David

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Michael Richardson
> Sent: Wednesday, November 06, 2013 12:18 PM
> To: Paul Simon
> Cc: <[email-masked]>; Tero Kivinen

---

From: Paul Simon <[email-masked]>
Date: Thu, 7 Nov 2013 14:53:57 +0530

ok thank you. I will try notification.