I am coming back to one comment that has been made during the presentation that DSCP values do not necessarily be associated with a pair of SA.
We want to organise tunnels where DSCP values are partitioned between a subset of SAs. More specifically suppose that we have g1 = (DSCP_a, DSCP_b), g2 = (DSCP_c) and g3 = (remaining DSCP) that are spread over 3 distinct pairs of SAs (SA1, SA2, and SA3). As long as peer A and peer B have agreed on 3 distinct SAs, and on a way to group the DSCP code point, the repartition could be left to each peer. For example, peer A may steer traffic g1 to SA1, g2, to SA2 and g3 to SA3, while peer B may steer g1 to SA3, g2 to SA2 and g3 to SA1. The tunnel may be split over a distinct pair of SAs. We can also argue that this does not prevent managing tunnels. Suppose peer A Deletes the tunnel associated to g1. It deletes SA1 and in the same way it deletes the SA peer B is steering traffic g3 to. Since Peer B knows that Peer A has chosen SA1 for g1, it can notice that g1 does not need to be considered so the SA3 has one unused SA and that g3 may use instead SA3. As a result, this makes it possible to partition DSCP values into m categories over m distinct pairs of SAs. It could be convenient if we could create m pairs of SAs in one shot in which case we could also provide the DSCP partition and let the two peer to select their favourite SA. However, things look more complex when we are creating SAs one by one, and only once we have created the SAs, we could mention the DSCP partition into m partition as well as the m (or 2 m) SPIs being considered. It also seems that each peer will need to monitor which DSCP is associated with which unidirectional SA. I have the impression that associating the DSCP group to each SA seems an easier approach. We are losing that independence between SA and DSCP, but I do not see the real benefit of it. One drawback I could see is that by providing a partition of DSCP values, we may be able to force that DSCP value be partitioned, while currently we leave that responsibility to the establishment of policies. I am wondering if I am missing anything or if we envision other ways to manage DSCP values. Yours, Daniel On Thu, Jul 27, 2023 at 10:49 AM Daniel Migault <[email protected]> wrote: > Thanks Tero, this is helpful and overall improves the design. Please see > inline additional comments/questions. We basically would like to know if > these DSCP selectors could be reasonably called "pseudo traffic selectors" > or if someone believes that will be confusing. Feel free to suggest other > alternatives. The other question we have is whether the Notify > payload should be generic to Pseudo TS or limited to DSCP. > > I will later address Scott comments on whether we need or not to bind the > DSCP value to a SA. > > Yours, > Daniel > > On Wed, Jul 26, 2023 at 11:20 PM Tero Kivinen <[email protected]> wrote: > >> Daniel Migault writes: >> > I am under the impression that if one wants to ensure that the >> agreed DSCP >> > value takes the right SA we need to check that. As a result, I am >> inclined to >> > have in any case a MUST be checked. I am wondering if we are expecting >> this >> > check to take a significant overhead ? >> >> I do not think there should be any need to check that agreed on DSCP >> values takes right SA. >> >> As the issue is that packets get dropped because of the replay window >> checks, then it does not matter which SA they use as long as the >> packets do not get dropped. >> >> I see, so this definitively implies all DSCP values have the same policy. > Now that DSCP is not a traffic selector can we consider that one cannot > have different policies for different DSCP values ? Is pseudo traffic > selector an appropriate terminology ? I am happy to get a better > designation. > > >> The sender has incentive to send them in best possible SA to make sure >> they do not get dropped, but even that does not guarantee that someone >> in the network does not decide to process the packets differently by >> for example modifying the outer DSCP values in some way. >> >> > I do not see a major change between using TS and a Notify. In both >> > cases if the ts_dscp or the notify is not sent or not supported we >> > fall back to the old case. So I do not expect that ts_dscp updates >> > 4301 (maybe I am wrong). As a result, I am wondering what are the >> > advantages of using a notification as opposed to a TS ? >> >> There is big difference using traffic selectors and notify. First of >> all that traffic selector would need special handling and coding in >> the implementations to be understood at all. Old implementations would >> at best return traffic selector set which do not include that new >> traffic selector. On the other hand implementations might not be that >> well written to handle unexpected traffic selectors. This was fine >> with labeled ipsec as there it is assumed that both ends know that >> both ends will support new traffic selectors. I would not be >> suprised to find out that some implementations would NOT do that >> narrowing properly when presented new traffic selector type, and >> instead would return some fatal error. >> >> I see. That makes sense. > >> All current implemetations of the IKEv2 already knows that they need >> ignore all unknown status notifications thus old implementations >> getting DSCP notify would simply ignre it and the SA would be created >> fine. >> >> > I do not see any and I am wondering if there are other reasons than >> > that DSCP is not commonly used for access control. I have the >> > impression this will be implemented the same way. In any case, if >> > that is the reason I am wondering if we should restrict the draft to >> > DSCP or consider that in the future additional parameters can be >> > added or do we want to limiit it to DSCP ? >> >> DSCP is not access control it is giving hints to the router what type >> of traffic is going through and what kind of QoS processing that type >> of traffic might need. >> > > I agree. My question was whether we believe it is better to define a > PSEUDO_TRAFFIC_SELECTOR Notify Payload with a type set to DSCP versus a > DSCP Notify Payload. In the first case we just get prepared if in 10 years > there is a sudden need for an additional pseudo traffic selector. > > Yours, > Daniel > >> -- >> [email protected] >> > > > -- > Daniel Migault > Ericsson > -- Daniel Migault Ericsson
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
