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. 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. 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. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
