Hi Tero, Thanks for the comments, this matches how we envisioned to update the draft, except that we envisioned the responder sends a N(DSCP) and that we also indicated the support of the N(DSCP). I think you recommend not to have these two notifications, which could work for us.
Please see inline some other comments. Yours, Daniel On Tue, Aug 8, 2023 at 8:54 PM Tero Kivinen <[email protected]> wrote: > Daniel Migault writes: > > I am coming back to one comment that has been made during the > > presentation that DSCP values do not necessarily be associated with > > a pair of SA. > > > > We want to organise tunnels where DSCP values are partitioned > > between a subset of SAs. More specifically suppose that we have g1 = > > (DSCP_a, DSCP_b), g2 = (DSCP_c) and g3 = (remaining DSCP) that are > > spread over 3 distinct pairs of SAs (SA1, SA2, and SA3). > > > > As long as peer A and peer B have agreed on 3 distinct SAs, and on a > > way to group the DSCP code point, the repartition could be left to > > each peer. For example, peer A may steer traffic g1 to SA1, g2, to > > SA2 and g3 to SA3, while peer B may steer g1 to SA3, g2 to SA2 and > > g3 to SA1. The tunnel may be split over a distinct pair of SAs. > > The reason we want to provide each of those groups separate SA is > because we have some information from somewhere that something in the > network will process the outer DSCP values differently, and that will > cause issues for the replay window. > > Note, that RFC4301 "4.4.1.2. Structure of an SPD Entry", already > specifies that you can either bypass DSCP value from inner to outer IP > header or you can map inner DSCP value using a map stored in the SPD > to DSCP values for outer IP header. > > In most cases you will have external knowledge that someone will > process your specific DSCP values differently on the outer IP header, > so you should most likely use that DSCP mapping to map all those > groups to specific outer DSCP values. > > So now the question really is which DSCP values you want to tell the > other peer? The outer IP header values are only ones that affect the > processing of the packet over the internet, so those would be more > logical ones. On the other hand that would require you to agree with > peers a same mapping of the inner to outer values. > > If we agree on the inner DSCP values, but map them differently that > does not actually matter as long as we never bypass some DSCP values > while mapping others, as every packet in the tunnel will have same > outer DSCP value thus will receive same processing in the internet. > > So that means we most likely should agree on the inner DSCP values, > and assume that both peers do have common understanding of those > values. > > If you want to keep the group so that it uses the same SA pair, then > if both peers already have common understanding of the DSCP groups, > this is not an really an issue, as we can simply wait for the > initiator to send first packet and see which DSCP value that has, and > after that the responder will know to which group this SA should be. > > Other option is to send a Notify payload while creating SA, where you > list the DSCP values you will be sending in this SA, so the responder > can use that information to populate the SAD. The RFC4301 "4.4.2.1. > Data Items in the SAD" describes that each SAD entry has a list of > DSCP values that are put to this SA. > > > If the SA used for those DSCP values is deleted then SA which do not > list DSCP values will be used (i.e., the fall back SA). If there is no > SA that does not list DSCP values, then the RFC4301 does not really > specify which SA is used, but I would assume it could use any SA. > I think we need to clarify this. 4301 is not crystal clear and I thought no SA would be selected, but I think that is correct any SA can be selected. > > > We can also argue that this does not prevent managing tunnels. > > Suppose peer A Deletes the tunnel associated to g1. It deletes SA1 > > and in the same way it deletes the SA peer B is steering traffic g3 > > to. Since Peer B knows that Peer A has chosen SA1 for g1, it can > > notice that g1 does not need to be considered so the SA3 has one > > unused SA and that g3 may use instead SA3. > > The question I have why are the gateways deleting the SAs at randomly? > Usually you simply rekey the SA, not just randomly delete some SA. > Things are much easier if implementations do smart things. > > So the answer to this question is "please peer A, do not delete the > SA, rekey it"... > I was thinking of moving the traffic to another gateway as an example of tunnel management. > > > As a result, this makes it possible to partition DSCP values into m > > categories over m distinct pairs of SAs. It could be convenient if > > we could create m pairs of SAs in one shot in which case we could > > also provide the DSCP partition and let the two peer to select their > > favourite SA. However, things look more complex when we are creating > > SAs one by one, and only once we have created the SAs, we could > > mention the DSCP partition into m partition as well as the m (or 2 > > m) SPIs being considered. It also seems that each peer will need to > > monitor which DSCP is associated with which unidirectional SA. > > I think the easiest way of doing that is to add DSCP Status Notify and > use it like this: > > Initiator Responder > ------------------------------------------------------------------- > HDR, SK {IDi, [CERT,] [CERTREQ,] > [IDr,] AUTH, SAi2, > TSi, TSr} --> > > <-- HDR, SK {IDr, [CERT,] AUTH, > SAr2, TSi, TSr} > > This will create fall back SA for all traffic, meaning all traffic > regardless of DSCP values goes through this one. > > Initiator Responder > ------------------------------------------------------------------- > HDR, SK {SA, Ni, KEi, N(DSCP, 1, 4)} --> > > <-- HDR, SK {SA, Nr, KEr} > > This will create SA for DSCP values 1, and 4. After this is > created, the traffic using those DSCP values will move from the first > fall back SA to this SA, as it is has DSCP values filled in the SAD. > > > Initiator Responder > ------------------------------------------------------------------- > HDR, SK {SA, Ni, KEi, N(DSCP, 2)} --> > > <-- HDR, SK {SA, Nr, KEr} > > And this will create SA for DSCP value 2. > > I.e., the DSCP status notification indicates which DSCP values you are > going to put in that SA, and the receiver is recommended to put same > DSCP values to this same SA. > This does not give the possibility to negotiate the DSCP values, but I agree that sounds reasonable and easier. > Note, that if the recipient does not support this feature, it will > simply ignore that status notification and put pick suitable SAs for > each DSCP values based on its own policy. This means the initiator does not know if the responder supports the DSCP partition. One inconvenience I can see is that if the initiator does not check he will not be able to notice the responder does not support it and so two SAs may not be so necessary., On the other hand, the initiator benefits for himself of having two distinct SAs. If we take the symmetric case, a responder upon receiving a N(DSCP(1,4)) may be willing to set one SA for DSCP(1) and another one for DSCP(4). If that is the case, the responder becomes the initiator and creates an additional SA. I am wondering if the backup SA should be created first or last. When created last, it is clear for the responder that the SA is a backup SA. If the responder is willing to have another DSCP value, he may either send a N(DSCP(3)) for example, in which case the initiator may create the new SA with DSCP 3 and then recreate the backup SA. Or the responder just behaves as the initiator for the SA associated with DSCP value 3. Overall the question is whether the responder should send a N(DSCP) to confirm or refine the DSCP range. > > I have the impression that associating the DSCP group to each SA > > seems an easier approach. We are losing that independence between SA > > and DSCP, but I do not see the real benefit of it. One drawback I > > could see is that by providing a partition of DSCP values, we may be > > able to force that DSCP value be partitioned, while currently we > > leave that responsibility to the establishment of policies. > > Using notifies and not doing inbound checking will allow much easier > way of making things interoperable with old implementations and allows > more flexible way of doing things. > -- > [email protected] > -- Daniel Migault Ericsson
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
