Hi Harold, I have a couple of comments (in addition to the good points made by Scott, which I support).
According to RFC 4302 DSCP value is not preserved end-to-end, i.e. intermediate routers are free to re-classify traffic and thus change DSCP. So, the situation is possible, that peers agree upon using an SA for a traffic with some DSCP, but in fact receiving end will get packets with a different DSCP (because it is changed in transit). What is the supposed behavior for the receiver in this case? Drop all traffic? And another concern. I think that this document tries to improperly use existing mechanism. Traffic selectors negotiated in IKE SA are part of IPsec access control mechanism - i.e. they are used to cryptographically separate different types of traffic (ftp, http, etc.) and to allow performing access control (based on network characteristics). In my understanding, DSCP doesn't specify any particular kind of traffic, so it's strange to me to separate traffic based on its value. That said, I seem to understand the problem that you are trying to solve (correct me if I'm wrong): you want to make sure that if peer A uses SA1 for, say, high priority traffic, then peer B also use this SA (and not, say, SA2) for high priority traffic. If this is the problem, then perhaps it's easier to just introduce a new notify that will inform peer that this SA is intended to be used for some traffic priority. If peer supports this extension, it is supposed to also use this SA for this kind of traffic (it if honors this proposal). So, move from strict negotiation to just announcing. Regards, Valery. > Scott, thank you for your review. Here are the responses to your comments, see > inline for details. > > Brs > > From: IPsec <[email protected]> On Behalf Of Scott Fluhrer (sfluhrer) > Sent: Thursday, July 13, 2023 2:58 AM > To: [email protected] > Subject: [IPsec] draft-mglt-ipsecme-ts-dscp > > Hi, > > I rereviewed this draft, and have a few comments: > > - As the draft is written, the administrator can specify that (for example) > traffic > with DSCP=3 must be protected, but other traffic is not. I don’t believe > giving > administrators this option is a good idea, it can likely result in a security > foot > gun. > The current selectors (protocol, IP addresses, ports) specify the traffic > type, > where it is coming from or where it is going to – that is, things that the > application may check. For example, if the SPD specifies that TCP traffic to > port > 22 MUST be protected, then someone cannot trick the system into accepting a > TCP packet to port 22 (without going through authentication). > DSCP, on the other hand, doesn’t specify the traffic type or > source/destination, > but instead how the traffic should be treated. And, receiving applications do > not verify themselves if the DSCP value is what they expect (because network > devices are free to modify the DSCP value in transit). Hence, in the above > scenario where only DSCP=3 traffic is protected, the adversary can inject any > traffic they like (and just set the DSCP setting to something else). > It would appear to me that this draft would need to mandate that, if you do > have a DSCP-specific SPD entry, that traffic that matches that (except for the > DSCP) must also be protected (either encrypted or discarded). > > <Harold> > When TS_DSCP is agreed, TS_DSCP is just refinement of existing selectors which > is always used in combination with other selectors and cannot be used "alone", > in section 3 (Traffic Selector negotiation). This prevents DSCP from inferring > with other traditional policies. It is also presumed that the IPsec subsystem > itself would install a REJECT/DISCARD rule in the SPD to prevent that traffic > from being transmitted without IPsec protection. > > We agree in MANDATING to have the same policy for different DSCP values in > the security consideration. The traffic that matches TS (except for the DSCP) > must also be handled and we prefer to have a discard for the default policy > that > is non defined DSCP values when at least one DSCP value has been defined > (This is because the "bypass" will bring security risks, and the "encryption" > will > cause packets to be encrypted regardless of the DSCP value, which makes > TS_DSCP lose its original meaning). > > I think the wording of current security consideration is bad, we will refine > it. > </Harold> > > - I’m going through the introduction, and quite frankly I don’t understand > some > of the arguments. For example, consider this text: > > If DSCP values are > not agreed and between (for example) 2 SAs, it is unlikely the > initiator and the responder miraculously select the same subset of > DSCP values over the same SAs. Instead each peer is likely that > inbound and outbound traffic take different SA and as such does not > solve the issue of discarding lower priority packets associated to > different class of traffic sharing a given SA. > > I’m completely missing the issue that is being brought up in this text. If we > have two peers Alice and Bob, and they negotiate two pairs of Sas (SA1, SA3 > for > Alice to Bob traffic, SA2, SA4 for Bob to Alice traffic), and Alice decides > to send > DSCP=2 traffic via SA1, DSCP=4 traffic via SA3, and Bob decides to send DSCP=2 > traffic via SA4, DSCP=4 traffic via SA2, why is that an issue? The original > issue > being addressed is for traffic in one direction (Alice to Bob) where sending > different DSCP values over the same SA may cause drops; I do not believe there > is any interaction between SAs going in different directions (or the differing > decisions being made by Alice and Bob) > > <Harold> > Firstly, TS_DSCP indicates that different types of traffic need to be spread > over > different SAs - i.e. not all DSCP values are grouped in a single SA, this can > avoid > sending different DSCP values over one SA cause packet drops. Meanwhile, > TS_DSCP indicates how the traffic is grouped (unless there is one SA per DSCP > value), i.e. which DSCP values can be grouped together. We group the DSCP > values to limit the number of SAs > > Another fundamental reason is that if we are trying to make sure e.g. EF > traffic > uses a separate child SA, we need that to apply in both directions. Sure, one > could configure both devices, and it probably wouldn't even matter if they > used different child SAs but if you do that, it is quite likely that we would > end > up with 3 child SAs instead of two, as each end would set up an extra one for > EF, and not realize they could use the one the other end had set up. It just > works better if it is actually negotiated. > </Harold> > > - One omission in this draft is any discussion of the decapsulation > procedure. According to 4301, we’re supposed to do a check of the decrypted > packet against the SAD selectors – is the DSCP included in that? How is this > handled in transport mode (where the original DSCP value would not be > available)? Or, is transport mode forbidden to these SAs? > > <Harold> > Regarding to tunnel mode，due to the DSCP value already has the > same/default policy (discard, if a packet that matches an SPD entry for all > components except the DSCP values would be treated as "not matching" on > encryption), we can further discuss if/how to check of decryption packet > against the SAD selectors. > > For transport mode, we prefer to say TS_DSCP doesn’t support transport mode > because we do not see the wide possibility of TS_DSCP being widely used in > transport mode. > </Harold> > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
