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 protected]<mailto:[email protected]>> 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 protected]<mailto:[email protected]>> 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 On Nov 4, 2013, at 1:06 AM, Paul Simon <[email protected]<mailto:[email protected]>> 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. > > so can any one throw some light on the issue ? > > > Thanks and Regards, > Paul Simon _______________________________________________ IPsec mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
