Daniel Migault writes:
> 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.
Yes, it would be also ok to have the responder to send the N(DSCP) to
indicate it will also be using this SA for those DSCP values. On the
other hand it is also possible that the responder does not support
this new notification and the initiator has to be able to cope with
situation still, thus it could be enough if we say that
implementations supporting this draft SHOULD send matching DSCP values
sent by the initiator to the SA created in other direction.
Or we can simply say that this N(DSCP) is sent by either end along
with the SA payload and it indicates that sender of that notification
tries to put packets with those DSCP values to the SA negotiated using
that SA payload.
I.e., the N(DSCP) values does not need to match, both ends will simply
indicate which DSCP values they are putting to that SPI indicated
inside the SA payload:
Initiator Responder
-------------------------------------------------------------------
HDR, SK {SA, Ni, KEi, N(DSCP, 1, 4)} -->
<-- HDR, SK {SA, Nr, KEr, N(DSCP, 1, 4)}
or responder could also answer:
<-- HDR, SK {SA, Nr, KEr, N(DSCP, 1)}
if it is not using DSCP value 4 at all, but it could also use:
<-- HDR, SK {SA, Nr, KEr, N(DSCP, 8)}
if its policy says that initiators DSCP values 1 and 4, are not used
in its network, but DSCP value 8 has similar meaning, and thats why it
is using that instead.
So the N(DSCP) notification will tell that the sender of the
notification will put those DSCP values to the SA indicated by the SPI
inside the SA payload. There is no agreement, simply a statement from
the sender of that notify.
> 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.
Yes. I agree that 4301 is not exactly clear about that, but we can say
it in this draft.
> 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.
We do not really need negotiation (i.e., where both end propose things
and after few round trips they negotiate common situation), it is
enough to have agreement (i.e., both ends knows what other end is
going to do). If we say that responder can also use the N(DSCP)
notification along its SA payload then we get this agreement, i.e.,
both ends will know which SAs are used for which DSCP values.
> 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.
If the other end claims to support RFC4301 it will support putting
DSCP partition :-)
On the other hand initiator does not know whether responder's policy
will consider DSCP values important enough to cause them to use
separate SAs, but initiator knows that it can create multiple
overlapping SAs and use them to send different DSCP values over them,
and responder will process them correctly.
The question is what can the initiator do if the responder policy does
not put different DSCP values to different SAs? There is nothing it
can do to fix the situation, the only thing it can really do is to
tear down the SA and refuse to talk to that peer, but I do not think
that is something we want to do.
In IKEv1 we had lots of cases where policy must be exactly same in
both ends, and if there was any difference in the policy (for example
other end had SA life time of 3600 seconds, and other end had 3599
seconds), then SA creation failed, and adminstrators needed to go and
update the policy to match.
In IKEv2 we removed lots of those cases, i.e., we do not even try to
enforce same policy, we simply say that sender will enforce the policy
it wants, and it can announce its policy to the other end and other
end will have to work with that...
> 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.
Initiator will need to two SAs regardless whether the responder
support splitting different DSCP values to different SAs, as the idea
is to split packets sent by the initiator to two different SAs so they
will get different replay windows.
> 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.
Yes. And if we add the N(DSCP) notify to the responders message, then
initiator will even be notified about the situation.
> 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.
It is not backup SA. It is the main SA for normal traffic that does
not require special processing based on the DSCP values. Creating it
first makes things easier, as we might have traffic flowing between
peers while we are setting up the SAs, and if we have the main SA set
up for all traffic in the beginning, then there is no question which
SAs should be used for that traffic.
So when the main SA is created first then either end that sees traffic
using one of those special DSCP values requiring separate SA can
create SA for that DSCP value when it sees the first packet using that
DSCP value. This will allow dynamically create DSCP values when they
are being used in the network.
Even if there is 4 different classes of traffic in network defined,
that does not mean all of the them are in use all the time, and create
4 extra SAs just in case they are needed is wasting resources.
Creating them only after they are being used is better way.
> Overall the question is whether the responder should send a N(DSCP)
> to confirm or refine the DSCP range.
I think it might be better that both ends indicate which DSCP values
they put in the SA, thus both of them should indicate N(DSCP) in IKEv2
exchange. But note, that the N(DSCP) values sent by the responder is
matching its policy and it might not be same as what was sent by the
initiator.
And we most likely need to say that empty N(DSCP) (i.e., without any
values) means there is no DSCP filter for that SA, i.e., that is the
main SA that is used for all other traffic. This is same as not
including the N(DSCP) value at all, but at the same time this will
indicate the other end that sender of that notification will support
this draft...
--
[email protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
