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 <paulsimo...@gmail.com<mailto:paulsimo...@gmail.com>> wrote: 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 <y...@checkpoint.com<mailto:y...@checkpoint.com>> wrote: 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<mailto:mcr%2bi...@sandelman.ca>> wrote: > > Yoav Nir <y...@checkpoint.com<mailto: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<mailto:m...@sandelman.ca> http://www.sandelman.ca/ > | ruby on rails [ _______________________________________________ IPsec mailing list IPsec@ietf.org<mailto:IPsec@ietf.org> https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
