Re: [IPsec] WGLC of draft-ietf-ipsecme-labeled-ipsec

[Paul Wouters <[e-mail]>]

On Thu, 9 Dec 2021, Tobias Brunner wrote:

> In the SELinux case, and using your example, could the client actually 
> propose "nfs-client in TSi and "nfs-server" in TSr?  So the server could set 
> "nfs-client" on the inbound SA/policy and "nfs-server" on the corresponding 
> outbound SA/policy of the CHILD_SA (and vice-versa on the client)?  Or won't 
> that work?  If it's a valid use case, should the document specify which of 
> the two labels is to be applied to what SA/policy?  Or is that an 
> implementation aspect that you explicitly want to keep out of it?

I was trying to keep that out of the draft. Because for example if the
label is TOP_SECRET vs SECRET, then you might not want to allow this.
Also, IKE daemons might not know how to interpret the label at all.

> Also, I don't fully get the multiple label in TSi part.  If multiple labels 
> are allowed/supported per SA by the implementation (not sure how that would 
> work inbound, but let's assume there is a way to mark packets with some kind 
> of meta label that covers multiple negotiated ones), why would any narrowing 
> take place for TSr?

Whether or not a label could be narrowed is something that is outside of
the scope of IKE. We don't want to require labels properties that might not
be compatible with a labeling structure we haven't thought or (or aren't
allowed to know about :)

I wanted to leave the option open of being able to suggest multiple
labels to support potential migrations or 'narrowing' or 'widening'.
I also assumed that if the labeling system supports label A and B,
i could also support a different label with the meaning of A|B or A&B.

I guess we could extend the mechanism to allow selecting multiple
labels, but it just seemed a complexity that was likely not to be used
in practise (AFAWK). In fact, I'd much rather remove allowing multiple
labels to be selected, than add complexity to allow multiple labels to
be negotiated.

> On the other hand, if multiple labels are not supported, in what situation 
> could proposing multiple labels be useful?

One reason could be to try and get the most secure label we both support
(or are allowed to use) in place. Eg if the information is SECRET, but
perhaps you and I have TOP_SECRET, by sending both we could end up on
the more secure TOP_SECRET. But if you only have SECRET, I might be
willing to allow SECRET for this as well.

Another example is migration. Perhaps we introduce a new TOPPEST_SECRET,
and I don't know if you upgraded to support this level yet, so I can
send TOPPEST_SECRET and TOP_SECRET and you pick TOP_SECRET when nog yet
upgraded and TOPPEST_SECRET when already upgraded.

>  Wouldn't traffic with the omitted 
> labels just get dropped afterwards?  Or is the assumption that this triggers 
> a new acquire/SA?

Not all labeling systems might be assigned labels based on IP trafic
properties. We would want to avoid things just "not working". Eg if
you don't support TOPPEST_SECRET, we wouldn't want to get stuck with
not being able to exchange traffic at all.

> If so, would the request not contain multiple labels again 
> and, if that's the case, what prevents the peer from selecting the same label 
> as before?  Is it to keep track of what label it selected previously and that 
> the intention of the initiator now might be that another should get selected?

I dont have expectations that using the wrong label or omitting a label
would result in a new working SA. It might or it might not.

> Or is it up to the initiator not to propose multiple labels the second time 
> around (or just omit the ones it already has an SA for)?  If so, why would it 
> send multiple the first time (in particular if the SA was triggered by an 
> acquire)?

I think you are thinking too much about actual packet properties, and
not take organizational / administratie labels into account ?

> I think either the narrowing to a single label should be optional, or sending 
> multiple labels in TSi should be prohibited in the first place.

That would complicate the migration example I explained above. A labeling
system might not accept multiple labels?

Although I am okay with making narrowing to a single label optional.

Note again that for our use case of SElinux, this does not matter as we
do not support more than one label in the IKE negotiation ever at this
point.

Paul