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: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Paul Simon Sent: Tuesday, November 05, 2013 1:54 AM To: Yoav Nir Cc: <ipsec@ietf.org>; Michael Richardson Subject: Re: [IPsec] Query regarding Qos with IKE 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 <y...@checkpoint.com<mailto:y...@checkpoint.com>> 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 <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
