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 On Nov 4, 2013, at 3:18 PM, Michael Richardson <mcr+i...@sandelman.ca> wrote: > > Yoav Nir <y...@checkpoint.com> wrote: >> 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. > > 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 > [ > ] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails > [ _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
