Scott, thank you for your review. Here are the responses to your comments, see inline for details.
Brs From: IPsec <ipsec-boun...@ietf.org> On Behalf Of Scott Fluhrer (sfluhrer) Sent: Thursday, July 13, 2023 2:58 AM To: ipsec@ietf.org 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 IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
