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