Thanks for the comments. 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 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 ? 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 ? Yours, Daniel On Wed, Jul 26, 2023 at 1:40 PM Tero Kivinen <[email protected]> wrote: > Daniel Migault writes: > > 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. > > Note, that RFC4301 already describes how to handle DSCP, and your > draft would actually change mandatory features of RFC4301: > > In section 4.1 Definition and Scope of RFC4301 says: > > If different classes of traffic (distinguished by Differentiated > Services Code Point (DSCP) bits [NiBlBaBL98], [Gro02]) are sent on > the same SA, and if the receiver is employing the optional > anti-replay feature available in both AH and ESP, this could result > in inappropriate discarding of lower priority packets due to the > windowing mechanism used by this feature. Therefore, a sender > SHOULD put traffic of different classes, but with the same selector > values, on different SAs to support Quality of Service (QoS) > appropriately. To permit this, the IPsec implementation MUST permit > establishment and maintenance of multiple SAs between a given > sender and receiver, with the same selectors. Distribution of > traffic among these parallel SAs to support QoS is locally > determined by the sender and is not negotiated by IKE. The receiver > MUST process the packets from the different SAs without prejudice. > These requirements apply to both transport and tunnel mode SAs. In > the case of tunnel mode SAs, the DSCP values in question appear in > the inner IP header. In transport mode, the DSCP value might change > en route, but this should not cause problems with respect to IPsec > processing since the value is not employed for SA selection and > MUST NOT be checked as part of SA/packet validation. However, if > significant re-ordering of packets occurs in an SA, e.g., as a > result of changes to DSCP values en route, this may trigger packet > discarding by a receiver due to application of the anti-replay > mechanism. > > I.e., it already says senders SHOULD use different SAs, and MUST > permit SAs with same selectors, and MUST process from each SA in same > way. > > > In section 4.4.1.2 Structure of an SPD Entry of RFC4301: > > - Bypass DSCP (T/F) or map to unprotected DSCP values > (array) if needed to restrict bypass of DSCP values > -- applicable to tunnel mode SAs > > I.e., SPD has option to specify whether DSCP is copied from inner to > outer or whether it is mapped using mapping array. > > In section 4.4.2.1 Data Items in the SAD of RFC4301: > > o DSCP values -- the set of DSCP values allowed for packets > carried over this SA. If no values are specified, no > DSCP-specific filtering is applied. If one or more values are > specified, these are used to select one SA among several that > match the traffic selectors for an outbound packet. Note that > these values are NOT checked against inbound traffic arriving on > the SA. > > o Bypass DSCP (T/F) or map to unprotected DSCP values (array) if > needed to restrict bypass of DSCP values -- applicable to tunnel > mode SAs. This feature maps DSCP values from an inner header to > values in an outer header, e.g., to address covert channel > signaling concerns. > > describes that each SAD entry already has an entry telling which DSCP > values are allowed for this SA, i.e., the sender will sue this item to > put packets with given DSCP values to speific SA, but it also says > that receiver does NOT check those values. > > RFC4301 describes the behavior to work when DSCP is not part of the TS, that is in the absence of ts_dscp. When ts_dscp is supported and used, that behavior is changed, but I do not see this as updating the default behavior. > > 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. > > Reading the text below, I think you are trying to more than just keep > same DSCP values for both directions. We want to be able to ensure that a bidirectional flow characterized by DSCP values takes a given pair of SA. > > > > 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. > > Having such check is not needed to keep DSCP values inside the same SA > pairs. > > What we want is that when we agree that some DSCP values are assigned to a given SA, that SA does not carry other DSCP values. I do not see how we can have such property without checking the DSCP. > > 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. > > If your drat mandates that if peer A sends and peer B confirms that > this SA pair is used for these DSCP pairs using notifies, then if > either peer then sends some traffic that other end does not like it is > not followin the protocol. Doing so will not really cause security > issues, but if you want to do extra checks to make sure other end > works correctly you are free to do so, but I do not think we need to > mandate such checks. > > We may soften the requirement, but you can only be sure the peer respects the protocol if you check, which is the reason we also check the SPD. In my opinion introducing different types of traffic may disrupt the traffic so I would consider this as a security issue.... Similarly, anything happening differently from what is expected is a potential issue. That said we may potentially soften the need to check. > > Currently DSCP is already part of the DSCP so what the document is > > introducing is really a check - validation with the inner traffic. > > What is that check trying to do? Note, that you always have option to > map unwanted DSCP values to some other values. Routers are allowed to > do that, and that is completely logical thing to do when you are > entering different adminstrative domain where DSCP values might be > different. > > So instead of dropping the packet because of the unwanted DSCP values, > map them to something else. > What I wanted to say is that DSCP is already something considered by IPsec. That said, I agree that the gateway could change the DSCP value just before the SAD lookup to inject traffic. This would also get unnoticed by the peer. > > 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 you use the notification to tell which DSCP values are supposed to > be usd with certain SAs, then you can also add text saying that other > end should try to use same SA pair for reverse traffic. Sure, but since TS does this by design. Why should we build something that works like a TSbis ? > > > > 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. > > As the list of DSCP values for that SA which was stored in the SAD > gets removed while the SA is deleted, then most likely the sender will > simply pick some other SA to be used for this purposes. If it does not > find suitable SA for the traffic (i.e., it wants to keep different > DSCP values on different SAs and there is no SA that is able to use), > then it will create new one. If the other end already created a new SA > pair for its traffic, then the other SA in that pair is most likely > not used yet, thus peer can switch to that. > > All of these are implementation details which we do not need to > specify here, they do not really affect interoperability. How well you > do that will tell how much you care about issue, and might make your > implementation better than some other implementation on such use > cases. > > sure. what we want is firstly to avoid traffic to be discarded. Secondly we want to limit the number of created SA. If I am correct in the scenario described above, we either result in having a pair of SA being unused or a pair of SA being removed without the other peer being aware of it. Of course, if you delete an outbound SA that can be done. > > 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. > > So looking about this it seems it would be enough to have notify that > will tell I am putting these DSCP values in this Child SA when I am > creating it, and when initiator sends that during CREATE_CHILD_SA, it > can assume that if other end cares about DSCP values it will try to > match same DSCP values for the return traffic and send similar > list back. > > There is no need to actually check that no other DSCP valeus goes > through that SA pair, and this will also make it backwards compatible, > i.e., if the responder does not support this it will ignore the > notify, and will not send it back, and then we will end up with old > behavior. > -- > [email protected] > -- Daniel Migault Ericsson
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
