On thing that sticks out from the Introduction is this:
| However, some applications (e.g. distributed file systems),
| most often those not designed for use with Compartmented Mode
| Workstations or other Multi-Level Secure (MLS) computers,
| multiplex different transactions at different sensitivity levels
| and/or with different privileges over a single IP communications
| session (e.g. with the User Datagram Protocol).
So far so good, and certainly true. But then:
| In order to
| maintain data Sensitivity Labeling for such applications, in
| order to be able to implement routing and Mandatory Access
| Control decisions in routers and guards on a per-IP-packet basis,
| and for other reasons, there is a need to have a mechanism for
| explicitly labeling the sensitivity information for each IPv6
| packet.
So if I understand correctly then this document would have an
implementation of, say, NFSv4[0] over TCP[1] send TCP packets for the
same TCP connection with different labels, *and* ensure that each packet
contains parts of no more than one (exactly one) NFSv4 RPC.
Surely that would have an enormous impact on transport protocol
implementations!
And all so that middle boxes can make labelled routing decisions at
100Gbps wire speed. And these are not simple labels either.
And the middle boxes have to trust the end nodes to get the labelling
right.
Call me a skeptic. I don't see this flying.
In any case, wouldn't it be easier to just use IPsec with labelled SAs
(with no outer packet labelling) and let the middle boxes be label
agnostic? The end nodes still have to be trusted to get the labelling
right, but this way you free the middle boxes to do what they're good at
(routing) and use crypto to provide integrity and confidentiality
protection over any public networks.
And if you really must have outer packet labelling for middle boxes to
inspect, why not modify NFSv4 clients to use a TCP connection per-local
{user, label}? That'd certainly be a lot less troublesome than to
modify TCP to keep track of labels in a PCB's buffers/arrange to send
each sub-buffer in a separate packet or train of packets!
The changes proposed in this I-D are non-trivial, but there are clearly
far simpler alternatives.
Nico
[0] "e.g. distributed file systems"? NFSv4 qualifies.
[1] "multiplex different transactions... over a single IP communications
session (e.g. with the User Datagram Protocol)"? NFSv4 qualifies,
though the mandatory-to- implement transport for NFSv4 is TCP, not
UDP.
--
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf