Hi,
I rereviewed this draft, and have a few comments:
* As the draft is written, the administrator can specify that (for example)
traffic with DSCP=3 must be protected, but other traffic is not. I don't
believe giving administrators this option is a good idea, it can likely result
in a security foot gun.
The current selectors (protocol, IP addresses, ports) specify the traffic type,
where it is coming from or where it is going to - that is, things that the
application may check. For example, if the SPD specifies that TCP traffic to
port 22 MUST be protected, then someone cannot trick the system into accepting
a TCP packet to port 22 (without going through authentication).
DSCP, on the other hand, doesn't specify the traffic type or
source/destination, but instead how the traffic should be treated. And,
receiving applications do not verify themselves if the DSCP value is what they
expect (because network devices are free to modify the DSCP value in transit).
Hence, in the above scenario where only DSCP=3 traffic is protected, the
adversary can inject any traffic they like (and just set the DSCP setting to
something else).
It would appear to me that this draft would need to mandate that, if you do
have a DSCP-specific SPD entry, that traffic that matches that (except for the
DSCP) must also be protected (either encrypted or discarded).
* I'm going through the introduction, and quite frankly I don't understand
some of the arguments. For example, consider this text:
If DSCP values are
not agreed and between (for example) 2 SAs, it is unlikely the
initiator and the responder miraculously select the same subset of
DSCP values over the same SAs. Instead each peer is likely that
inbound and outbound traffic take different SA and as such does not
solve the issue of discarding lower priority packets associated to
different class of traffic sharing a given SA.
I'm completely missing the issue that is being brought up in this text. If we
have two peers Alice and Bob, and they negotiate two pairs of Sas (SA1, SA3 for
Alice to Bob traffic, SA2, SA4 for Bob to Alice traffic), and Alice decides to
send DSCP=2 traffic via SA1, DSCP=4 traffic via SA3, and Bob decides to send
DSCP=2 traffic via SA4, DSCP=4 traffic via SA2, why is that an issue? The
original issue being addressed is for traffic in one direction (Alice to Bob)
where sending different DSCP values over the same SA may cause drops; I do not
believe there is any interaction between SAs going in different directions (or
the differing decisions being made by Alice and Bob)
* One omission in this draft is any discussion of the decapsulation
procedure. According to 4301, we're supposed to do a check of the decrypted
packet against the SAD selectors - is the DSCP included in that? How is this
handled in transport mode (where the original DSCP value would not be
available)? Or, is transport mode forbidden to these SAs?
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
