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