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