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
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
