Hi Valery, Thanks for comments. Please see inline my responses.
On Wed, Jul 26, 2023 at 8:42 AM Valery Smyslov <[email protected]> wrote: > 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? > We only use DSCP in tunnel mode in which case these are protected. In our working version of the draft [1] the security consideration says: ``` One needs to consider that the DSCP field is a mutable field which means that the IP Authentication Header (AH) does not protect it. As a result, DSCP is only used in the Tunnel mode where the DSCP value considered for the traffic selectors - and specified in the SA - is in the inner packet and thus protected. ``` Let me know if that text addresses your concern or if you prefer a different wording. I believe I should add some more specific references to 4301. [1] https://github.com/mglt/draft-mglt-ipsecme-ts-dscp/blob/main/draft-mglt-ipsecme-ts-dscp.mkd > > 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. > > I think you are correct in what we are trying to achieve. First let me state that we are open to alternate design. The issue with the notification is that there is no check on the inbound SA. This means that peer A can mention he will send some specific DSCP traffic over that pair of SA to peer B but: 1) peer A can send other DSCP traffic which causes some issues on peer B receiving unexpected DSCP inner traffic. 2) peer B can also send different DSCP over the SA which causes the same issues to peer A. As a result, we need to check that the inner traffic is associated with expected DSCP value which seems very close to a TS. Currently DSCP is already part of the DSCP so what the document is introducing is really a check - validation with the inner traffic. There is also the situation raised by Scott where a given traffic associated with a DSCP value may take SA1 for inbound and SA2 for outbound. This could work **theoretically** but remain very impractical when managing tunnels. If a given flow needs to be moved to another gateway for example. You end up having SA1 and SA2 being unused. In theory you could remove the SA pair that contains SA1. The traffic that used to be carried by the counterpart of SA1 should take for example the counterpart of the SA2.... but that all depends on how the peer "classifier" dispatches the DSCP values to the SA and how dynamic that "classifier" is. We could specify the "selector" and notify the support of that mechanism. However this looks like implementing tunnel management facilities into IPsec. This seems to be a very hard path with no real operational benefits. Network admin are pretty used to handling tunnel management, and this mechanism makes it even harder for them. Network admin wants to be able to configure that THIS DSCP traffic is taking THAT IPsec tunnel and be able to manage the tunnel. We could consider directional DSCP traffic but that will double the IKEv2 negotiations and likely double the number of SAs - which is prohibitive for us. RFC2983 and RFC2475 provide a good description on differentiated services architecture and tunnel handling. 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 > -- Daniel Migault Ericsson
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
