On Thu, 3 May 2018, Nico Williams wrote:
I think this is true. Especially now it seems there is no narrowing to
be done from one security label to another one.
It depends on the label system.
For something like MLS you can narrow a label since labels actually
represent label sets or ranges, the label being a bitmask of
compartments and a classification level: you can always remove bits
from the mask and reduce the classification level.
That is, for some systems the labels can be narrowed (but not broadened).
This might be technically possible, but seems to not be the case on how
MLS with the USG works.
Which kind of makes sense, overclassification is a problem as well as
underclassification (although only the latter one is punishable through
the legal system)
In this case, a TS or NOTIFY would only be usedo to narrow the label
range for an SA further than the two nodes' maximal label ranges. When
there is no need to do this, then there is no need for a TS or NOTIFY
payload to carry a label [range].
I don't understand why ou say that. Two nodes can still want to make
sure that any traffic for a specificly configured IPsec SA MUST only
happen with one single security context and you want both ends to reveal
to each other what security context it will set on decrypted packets.
I mentioned socket options before because, really, without them, it's
just too hard for applications to drive narrowing of SAs.
I'm really trying to stay away any of these concepts related to BTNS and
connection latching and sockets. We are really just talking about SPDs
that have another item in their ACQUIRE beyond the 5 tuple and how to
deal with that.
Two nodes would have some label range/set each and a credential each
asserting the node's label range.
The data that can be sent from one to the other has to be labeled with a
label that is in the recipient's label range.
A node could send more-classified data than its local labels to another
node that can accept it. Think of a military officer classifying a
memo at a higher level than they can read.
I don't think the IPsec labeling system should be a system where you can
modify the classification. This is all about applications using the
(encrypted) network while retaining the same classification. So this is
definately not in scope.
The nodes might also be running processes with reduced label ranges.
This should be a source of desire to narrow child SAs' label ranges.
Again, in the MLS system I'm aware of, this is not possible, as you
don't narrow in this way. The entire label is what you have and the
goal is to transport that traffic with the same label onto the other
host, so applications there can receive the traffic at the correct
label.
If narrowed SAs are used for some flow, then the label of the flow is
informative. If there is no need to deliver that information from IPsec
to the application, then there is not much point to labeling narrowed
SAs in transport mode, except that SA lifetimes and flow (connection)
lifetimes are not bound to each other...
Also note how I'm not making any differences for transport or tunnel
mode as I'm not binding this to any other layer. I'm not sure what
lifetimes have to do with labels either and would like to not talk
about those too :)
....If a connection ends and its 5-tuple is reused later and a packet
floating about is finally delivered, but with a now-incorrect label. My
spidey sense says that you want to narrow and label the SAs, but maybe
it's just a waste of resources.
The entire IPsec SA has the same label, regardless of 5-tuple. If you
need different security contexts for different tuples, you need to
negotiate those as separate IPsec SA's.
But if an application needs to know the label of a flow
Some might but most won't. For most, with the wrong label the application
will be prevented from ever seeing the packet by the kernel. Those
applications who will be able to do this will also be able to read the
label and act on it.
And what about SG use cases? Here, I think an SG needs to see narrowed
label choices for specific flows if it has multiple outbound routes for
a given destination at different label ranges.
I don't see why this is related to "narrowed labels". I do see you can
have multiple IPsec SA's installed with the same 5 tuple but with different
labels.
That seems a bit
unlikely to me, but I wouldn't know. Another possibility is that the
SG's route to some node has a different label range than another node
traversing the SA to the first node, in which case the SA needs to know
the individual traffic flows' labels, and we should assume that there's
no way to send those at the ULP, in which case we need narrowed SAs.
Again I don't see how this relates to narrowing at all. If there is a
chain from A <-> B <-> C then B better be allowed to install two IPsec
Sa's with that identical label that A and C are expecting. You wouldn't
want anyone in the middle changing that, although from a protocol level,
nothing stops B from NATing the packets to the same 5 tupple but with a
different label. It might be a feature.
If there are multiple SAs whose traffic selectors match the 5-tuple, but
at different labels, then a sender has to pick carefully. If we never
narrow SAs, then it's probably safe to assume this just doesn't happen
(why would it?), but narrowing SAs does happen, and is supported.
Narrowing happens on the 5 tuple. The question is, can a label narrow.
AFAIK, with the SElinux based MLS of the USG, this is not how the label
works. The question for this RFC is, should we specify it such that
another labelin system could use it? Even if the RFC allows narrowing,
the current USG MLS could simple not allow this and always require
exact matching. And if we allow this narrowing, then how much does IKE
need to know about this? Since if we design for this in general, we
could have wildly different systems. Eg one could be a label based on
DN's where "C=CA" could be narrows to "C=CA, S=ON, L=Toronto" or we
could have one where "slkd" could be narrows to "slkdhsalglfgds".
Presumbly therefor, we cannot specify generic narrowing in the document.
This all sounds to me a lot like labels are traffic selectors. Whether
they are represented as such on the wire in IKE is another story, but
their function really looks to me a lot like traffic selectors.
I agree. But see Tero's post on why he prefers NOTIFY.
This I don't like as much. I'd rather see a failure on the responder on
some critical flag payload it does not understand.
Yeah, but it's not that big a deal to not have that failure on the
responder. Presumably the initiator will just delete the then-useless
SA, else the responder will hold that resource for a while.
That's true.
But also, the initiator should not yet have Child SA's ? (but that might
be implementation specific)
In that case the parent IKE SA may have a broader label range/set than
the child SAs.
The labels we are talking about are for traffic flowing through IPsec
SA's. I don't understand why you now talk about IKE SA labels. In
general, all IKE traffic is holed specifically from any IPsec SA as to
ensure IKE can flow even in case of lost IPsec SA's. So there is no need
to consider the label of UDP (4)500 packets.
Assuming the label ranges/sets are carried by the nodes' credentials,
then there is no need for a label proposal unless the nodes wish to
narrow the resulting SAs' label ranges.
I think what you are saying here is that if both ends require a specific
label for traffic, it is defacto preconfigured and doesn't need to be
negotiated. But that limits things to preconfigured on a peer to peer
basic, and might not work well for Opportunistic IPsec, eg a mesh crypto
network. Peers might still want to 'announce' the label they will give
to the received decrypted traffic and nodes might accept multiple labels
so in that case there might be some kind of negotiation happening. But
even if the nodes just confirm the label configured to each other, that
would likely be useful for debugging - even if it is technically not a
negotiation of label.
I mean, it can work fine. Notionally, ISTM that a pack flow's 5-tuple
and label both are used to select SAs, therefore labels are -at least
notionally- traffic selectors.
Again, agreed. The question though, is whether it is worth doing it as a
traffic selector or should we use a notify?
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
