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

From: Tobias Brunner <[email-masked]>
Date: Thu, 9 Dec 2021 14:42:12 +0100

Hi Paul,

>> 8. Section 3.2:
>>    It would be unlikely that the traffic for TSi and TSr would have a
>>    different Security Label, but this specification does allow this to
>>    be specified.
>>
>> Can you please provide some examples of possible semantics of
>> different TS_SECLABELs in TSi and TSr? Sending different
>> security labels in different directions? Just for curiosity.
> 
> I cannot, but I wanted to ensure not to accidentally forbid it. What
> we do see with our implementation though, that we end up with two
> IPsec Sa's where each is only used in one direction. For example,
> image you have an SElinux context for nfs-server and nfs-client. What
> happens is that the NFS client triggers one label on the outgoing
> connection, triggers ACQUIRE, sets up an IPsec SA with a label
> "nfs-client". The first packet hits the NFS server, which to reply
> hits a different SElinux context of "nfs-server". So it will trigger
> an ACQUIRE and setup a second IPsec SA with a label "nfs-server". Both
> IPsec SA's will only be used in one direction. I did not add any
> of this into the document, as it is very SElinux specific, where as
> the draft is agnostic on the meaning of SEC_LABEL and allows for
> other mechanisms that might not have this complexity.

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?

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?

On the other hand, if multiple labels are not supported, in what 
situation could proposing multiple labels be useful?  Wouldn't traffic 
with the omitted labels just get dropped afterwards?  Or is the 
assumption that this triggers a new acquire/SA?  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?  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 either the narrowing to a single label should be optional, or 
sending multiple labels in TSi should be prohibited in the first place.

Regards,
Tobias

---

From: Paul Wouters <[email-masked]>
Date: Wed, 15 Dec 2021 12:16:19 -0500 (EST)

On Thu, 9 Dec 2021, Tobias Brunner wrote:

> 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

---

From: Tobias Brunner <[email-masked]>
Date: Thu, 16 Dec 2021 11:27:07 +0100

> Also, IKE daemons might not know how to interpret the label at all.

Not sure I get your argument because if the local configuration allows 
what's proposed in TSi and TSr, why wouldn't we define on what 
SAs/policies the labels should get applied?  That doesn't require 
knowing anything about the labels.  Or maybe it's just obvious that the 
label in TSi is applied on the inbound SA/policy and the one in TSr on 
the outbound SA/policy on the responder of the CHILD_SA (and vice-versa 
on the initiator)?

> be compatible with a labeling structure we haven't thought or (or aren't

Not sure about that as for instance with SELinux, the IKE daemon, as 
responder, doesn't seem to be able to avoid interpreting labels to some 
degree as it usually won't have configurations for all possible labels 
that could get negotiated.  So it might have to do an SELinux policy 
check with the received label (I guess you could say the interpretation 
happens in the SELinux subsystem, but it has to at least interpret or 
convert the label to a null-terminated string).

> labels to be selected, than add complexity to allow multiple labels to

Did you mean "remove allowing multiple labels to be *proposed*" (not 
"selected")?  Otherwise, I'm not sure what you mean.

> upgraded and TOPPEST_SECRET when already upgraded.

It might help if those examples are documented as possible uses of the 
extension and as rationale for the design decisions.

> not take organizational / administratie labels into account ?

I guess I am, but they are negotiated as traffic selectors after all :)

If that's not really what they are, it might make more sense to 
negotiate the label (or labels) e.g. via notify that the responder could 
send back or ignore (in which case it's up to the initiator to delete 
the SA if it requires a label).

One aspect that makes negotiating labels via TS weird is that the TS of 
type TS_SECLABEL is merged with the other TS, which isn't the case with 
regular traffic selectors (it's like an outsourced property of all the 
other selectors).  This seems to violate section 3.13. of RFC 7296, 
which states:

   a packet matches a given TSi/TSr if it matches at least one of the
   individual selectors in TSi, and at least one of the individual
   selectors in TSr.

And the interpretation of asymmetric labels is again unclear.

Also, the draft currently sates that the label is applied as opaque 
value to the SPD.  However, the negotiated label might actually be more 
of a property of the SAD than the SPD.

Probably depends on the implementation, but for instance, with SELinux, 
I learned that the label on the triggering trap policy usually won't 
match the label on the packet that's included in the acquire and will be 
negotiated for the CHILD_SA.  So any IPsec policies derived from the 
traffic selectors with the negotiated label would usually not get used 
by the kernel i.e. their installation could just be avoided.  On the 
other hand, the label has to be applied to the SAs so only matching 
outbound traffic will use the outbound SA and it's applied to inbound 
traffic after decryption.  (I guess other implementations could handle 
this only via SPD, though.)

So again, negotiating labels as property of the CHILD_SA (like e.g. use 
of transport mode or compression) might make more sense.  It's then up 
to the implementation where/how they apply it.  That would also avoid 
issues with asymmetric labels as well as complicating traffic selector 
negotiation, because selectors of this type really can't be treated 
anything at all like the regular ones.

> do not support more than one label in the IKE negotiation ever at this

It would definitely be helpful to document the application of the 
extension in the context of SELinux as an example and guidance for 
developers.

Regards,
Tobias