Subject: [IPsec] Labeled IPsec questions

From: Paul Wouters <[email-masked]>
Date: Tue, 1 May 2018 15:28:25 -0400 (EDT)

So during the last meeting when we discussed Labeled IPsec, a few
interesting items came up:

1) Is this actually a traffic selector ? Or is it a notify?
2) Is there a use case for "narrowing" on a security label ?
3) Can or should there be different labels in different directions ?
4) Can or should there be different labels for different address families?

I think whether to use a TS as part of the TSi/TSr's should follow the
answers to these questions.

I don't think anyone has seen a plausaible security label narrowing. It
was pointed out that my example in the draft was actually incorrect.
(also that things like "top secret" really should not include "secret",
just like "secret" does not include "top secret"). And SElinux based
labeles don't work with these kind of hierachies anyway.

While there could be different labels in different directions, it hardly
makes sense, for example a TCP connection. And where it might be possible,
I think such an IPsec SA really conflates two different IPsec SA's. For
example, a service on a port where the IPsec SA is both for incoming and
outgoing connections are really two security contexts that can be split
into two IPsec SAs one for client (any to port X) and one for server
(port Y to any)

So in a way, a NOTIFY might make sense. But then we do run the risk of
an IPsec SA being installed with the notify ignored using a default
security context instead of the security context required. Having it
as part of the TSi/TSr payloads makes that a lot more clear.

Thoughts?

Paul

---

From: Michael Richardson <[email-masked]>
Date: Tue, 01 May 2018 15:35:48 -0400

> Thoughts?

It has to be a traffic selector.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Nico Williams <[email-masked]>
Date: Tue, 1 May 2018 15:47:16 -0500

> Thoughts?

The following apply only to transport mode.  However, a lot of this
generalizes to gateway uses as well.

 - IPsec "state" should be more tightly bound to ULP state (PCBs)

   See RFC 5660 (by yours truly).

   For a TCP connection (or a BSD-style "connected" UDP socket) the
   IPsec state that should be bound with/into the PCB:

    - local name (from the IKE credentials)
    - peer name  (from its IKE credentials)
    - protection level (transforms)
    - labeling

   For an outgoing packet the ULP should ensure that ESP will pick a
   suitable IPsec SA.

   For an incoming packet the ULP should discard any where the SA used
   to protect it does not satisfy the bindings listed above.

   The bindings need to be established in some way.  Basically they
   should be taken from:

    - optional socket options
    - parameters of the first IKE SA to yield the child SAs needed to
      protect the flow's packets

 - Given this, labels can be carried in any of the following places:

    - IKE credentials (e.g., certificate extensions, side lookups, ...)

    - transported as IKE traffic selectors

      (these could only carry narrow labels than those of the
      credentials used to negotiate the IKE SAs, if any)

    - transported as TCP options in a SYN or SYN+ACK

      (these could only carry narrow labels than those of the SAs used
      to protect the flow, if any)

   All three should be supported.  If some ULP cannot support label
   assertions, then when it needs a narrower label it should use
   narrowed SA pairs.

 - There's two kinds of labeling:

    - assertions of label by the sender for some packet / packet flow

      Such an assertion carried as a TCP option, for example, would be
      dominated by the labels (if any) from the IKE negotiation, but
      could still further constrain what can be sent on a specific
      connection.

    - labels limiting what will be accepted for some packet / packet
      flow

Socket options should support:

 - setting acceptable transforms (ciphers, ...)

 - setting acceptable label ranges for the peer (for clients and
   servers)

 - setting a label for a connect() (client-only)

 - setting credentials to be used for the local side

 - setting the expected name of a peer

 - retrieving the actually bound IPsec parameters for a connection:

    - the local and peer names, including, preferably, all public parts
      of their credentials (e.g., certificates)

    - transforms

    - effective label

We should also construct a way to agree on and compute unique channel
bindings data for a connection.  But this is not related to labeling.

And we should construct end-point channel bindings from the local and
peer names.  Also not related to labeling.

Nico
--

---

From: Paul Wouters <[email-masked]>
Date: Wed, 2 May 2018 00:00:26 -0400 (EDT)

> - IPsec "state" should be more tightly bound to ULP state (PCBs)

For the implementation I'm working with (Linux with SElinux) we already
have the selinux label as part of the ACQUIRE message. So I don't think
there is a problem there. The input to the IKE daemon is the trigger
packet including its security context/label.

Also, the security context/label is part of the SAD/SPD as a selector
item as well.

>    - labels limiting what will be accepted for some packet / packet

I'm not sure how this relates here. There is of course a relationship
between the packet being created with the proper security context on
decryption, and there is the SPD entry that requires a packet to have
a certain security context/label before it matches to get encrypted.
These are all simple entries in tables with exact matching on the
security context/label.

These are usually (always?) the same label in both directions.

> Socket options should support:

I don't think I need to be at the socket level for this. Whatever
userland does to give or not give a packet a security context/label
is up to the system or application. To me it only becomes interesting
once it reaches an SPD in the kernel where it generates an ACQUIRE
or is (or is not) selected for encryption.

The question that I still don't feel your email answered is, should
this be a traffic selector kind or a notify message? I have heard
arguments both ways but I don't yet the WG having a clear preference
for one or the other based on some technical aspect.

Paul

---

From: Nico Williams <[email-masked]>
Date: Wed, 2 May 2018 01:07:20 -0500

> Also, the security context/label is part of the SAD/SPD as a selector

If you're not doing transport mode, then.. you can keep doing what
everyone always does: rely entirely on IPsec configuration.

It's tricky though.  If you have PAD entries that allow a range of IDs
to claim addresses from the same address ranges, then any one of those
peers can take over any of the others' flows with you if then can DoS
the victims off the network and then claim their addresses.  In practice
this is a very common configuration.

> These are all simple entries in tables with exact matching on the

Without connection latching you're stuck with the labels from the
credentials and the IKE child SA creations.  If you need to narrow a
label for some flow, you also need to narrow the related SAs.

> These are usually (always?) the same label in both directions.

I imagine so for the child SAs of one IKE SA.  But not necessarily for
different child SAs of different IKE SAs that are used to protect the
same flows.  Your policy has to be sane to prevent that.

> or is (or is not) selected for encryption.

Q: How does an application do that without socket options?
A: It edits the IPsec configuration.

nuts!  :)

But OK, that's not for _this_ thread, so I'll shut up about it now.  I
mentioned connection latching in the hopes of getting implementors
interested :)

> for one or the other based on some technical aspect.

It has to be a TS.

You need to be able to specify that the labels on the SAs must dominate
the labels on the flows.  To do this you must treat the labels as
traffic selectors.

A label assertion carried in an ULP, on the other hand, wouldn't be a TS
at all.  That's why I mentioned them.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 2 May 2018 01:07:20 -0500

nuts!  :)

It has to be a TS.

Nico
--

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 3 May 2018 16:19:07 +0300

Hi,

> It has to be a traffic selector.

I agree that it must be a traffic selector. However, in my opinion 
the way it is currently defined in the draft is wrong.

According to RFC7296 the individual TSs in TS payload are combined
using logical OR for the purpose of deciding whether given packet
matches the selector. In particular, Section 3.13 of RFC7296 says:

   ... 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.

The draft currently defines a new TS, that contains only security label
and no IP address, protocol and port information. Thus, it is impossible
with the current definition to express policy, that if packet is going
from IP1 to IP2 AND has a security label S, it must be protected 
using the negotiated SA. If you put IP1 and S in TSi and IP2 and S in TSr
it will mean that packet EITHER going from IP1 to IP2 (regardless
of its security label) or ANY packet having security label S (regardless 
of its IP addresses) is protected using the negotiated SA.

To fix this issue the draft should instead define two new traffic selectors - 
TS_IPV4_ADDR_RANGE_SECLABEL and TS_IPV6_ADDR_RANGE_SECLABEL,
that would contain IP range, protocol and ports range (as RFC7296 selectors),
 as well as the security label. This way the presence of the security label
will be an additional criteria for packet matching. 

Regards,
Valery.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 03 May 2018 13:18:38 -0400

> It has to be a traffic selector.

It has to be a traffic selector so that it can be selected (so do labeled
IPsec SA), or not selected (do not do it).  Any other mechanism
(notification) can not be unambiguously rejected by a responder.

---

From: Nico Williams <[email-masked]>
Date: Thu, 3 May 2018 13:57:07 -0500

On Thu, May 03, 2018 at 04:19:07PM +0300, Valery Smyslov wrote:
> I agree that it must be a traffic selector. However, in my opinion the
> way it is currently defined in the draft is wrong.
> 
> The draft currently defines a new TS, that contains only security
> label and no IP address, protocol and port information. Thus, it is
> impossible with the current definition to express policy, that if
> packet is going from IP1 to IP2 AND has a security label S, it must be
> protected using the negotiated SA. If you put IP1 and S in TSi and IP2
> and S in TSr it will mean that packet EITHER going from IP1 to IP2
> (regardless of its security label) or ANY packet having security label
> S (regardless of its IP addresses) is protected using the negotiated
> SA.

I wish RFC4306 carried multiple TS payloads, one for each type, and that
there were multiple types of them.  Of course, that is one possible
approach here: extend IKEv2 to allow multiple TS payloads (which would
have to be treated as a conjunction).

But if that route is not chosen, then you're correct that we'd need new
TS payload types:

> that would contain IP range, protocol and ports range (as RFC7296
> selectors), as well as the security label. This way the presence of
> the security label will be an additional criteria for packet matching. 

Cheers,

Nico
--

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 4 May 2018 02:44:47 +0300

> (notification) can not be unambiguously rejected by a responder.

Not true.

Traffic selectors in IKEv2 do have very strict processing rules, and
for most of the cases I do not think security labels will follow those
rules, or trying to force the security labels to follow those rules
will just cause confusion.

This includes ORing the different selectors together, narrowing any
traffic selectors to include any subset of the original selectors,
combining traffic selectors as long as the combined selectors are not
wider than what was originally proposed etc.

All of these will not really make traffic selectors suitable for the
security label use.

My understanding is that security labels are something that is
dictated by the one end, and other end must agree on that and then
both ends will be matching and marking the packets with suitable
security labels when it goes to the SA and comes out from the SA.

I.e., when kernel has packet going out to some IPsec SA tunnel, it
will check the security label associated with the packet (or socket,
or interface or whatever), and finds one IPsec SA which matches both
the security label and also allows the packet to be sent to that SA
(i.e., matches both traffic selector and the security label). When the
other end gets packet from the IPsec SA which is tied to certain
security label, it will do normal exit tunnel checks by checking the
traffic selectors, and then it will MARK the packet with security
label associated with the IPsec SA, so that when it is going forward
it will have correct security label associated to it.

To allow that is is completely possible to do this negotiation using
notify payloads. I.e., initiator sends SECURITY_LABEL status
notification to the other end which includes the security label to be
associated to this Child SA. If the other end agrees on the proposal,
it will reply with the SECURITY_LABEL notify payload containing
exactly same security label than what was proposed by the other end
(or simply empty data as actually the label does not matter here as
only thing that matters is that both ends agree on same security
label).

If other end does not understand SECURITY_LABEL notify at all, it will
ignore it and initiator will see this and can tear down the Child SA,
and indicate that other end does not support security labels. If other
end do support the security labels, but do not accept this policy, it
can either return NO_PROPOSAL_CHOSEN if it does not want to indicate
why proposal was unacceptable, or we might add new error notification
INVALID_SECURITY_LABEL which indicates that proposal was otherwise ok,
but security label was not unacceptable.

This is similar to how we negotiate transport mode in IKEv2, i.e.,
initiator includes USE_TRANSPORT_MODE notify, and responder confirms
it by sending it too. NON_FIRST_FRAGMENTS_ALSO does about same thing.
IPCOMP_SUPORTED does bit more complicated negotiation inside the
notify payloads, initiator proposes list, and responder picks one.
SIGNATURE_HASH_ALGORITHMS negotiation for RFC7427 does yet another
different type of negotiation inside notify payloads.
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Thu, 3 May 2018 20:45:15 -0400 (EDT)

> All of these will not really make traffic selectors suitable for the

I think this is true. Especially now it seems there is no narrowing to
be done from one security label to another one.

> security labels when it goes to the SA and comes out from the SA.

I would say "dictated by both ends", but yes :)

> it will have correct security label associated to it.

Exactly, except s/MARK/label because MARKing of packets is another
functionality of the (linux) kernel.

> and indicate that other end does not support security labels.

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.

But also, the initiator should not yet have Child SA's ? (but that might
be implementation specific)

> If other

That would work for me.

> it by sending it too.

Right.

Paul

---

From: Nico Williams <[email-masked]>
Date: Thu, 3 May 2018 22:46:11 -0500

> 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).

I expect that typically the maximal label ranges for each node will be
carried by their credentials (e.g., certificates) or be looked up in
directories.

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 mentioned socket options before because, really, without them, it's
just too hard for applications to drive narrowing of SAs.

And I mentioned connection latching because without that socket options
don't make much sense either.

Incidentally, Solaris/Illumos have a socket option by which an
application can request a narrowed SA...  Solaris/Illumos also have a
sort of minimal connection latching.

Without APIs, there's almost no point to narrowing the label ranges of
SAs as applications then have to resort to modifying IPsec policy, and
often that's just ETOOHARD.  Connection latching is essentially a way of
delegating IPsec configuration changes to the ULP.

> I would say "dictated by both ends", but yes :)

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.

In general communication will be within the intersection of the two
nodes' label ranges, but it can be asymmetric.

The nodes might also be running processes with reduced label ranges.
This should be a source of desire to narrow child SAs' label ranges.

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...

...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.

But if an application needs to know the label of a flow, and without the
ULP or application protocol being able to carry it, then the only way to
get at it is from the SAs used to protect the flow (see my comments
about connection latching and socket options), in which case narrowing
the SAs would help.  In this case, too, APIs would be rather handy.

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.  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.

(I'll note that SGs are the sort of application that can be expected to
modify IPsec configuration on the fly as needed.)

> >it will have correct security label associated to it.

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.

If there is no matching SA, then one will have to be negotiated that
matches the 5-tuple, including the flow's label.

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.

> 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.

> be implementation specific)

In that case the parent IKE SA may have a broader label range/set than
the child SAs.  If the responder can't handle the label the particular
packet flow needs and the initiator knows it, then the initiator should
not even bother creating a child SA pair for that flow.  Again, this
could only happen if the application somehow conveyed the narrowed label
range to the IPsec layer...

> >but security label was not unacceptable.

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.  An empty intersection of the
two nodes' label ranges would be an error in a MAC system, and the IKE
SA establishment will not complete, let alone the child SA
establishments.

> >initiator includes USE_TRANSPORT_MODE notify, and responder confirms

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.

Nico
--

---

From: Paul Wouters <[email-masked]>
Date: Mon, 7 May 2018 00:40:08 -0400 (EDT)

> 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)

> 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.

> 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.

> 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.

> 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.

> 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

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.

> 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

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.

> (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.

> their function really looks to me a lot like traffic selectors.

I agree. But see Tero's post on why he prefers NOTIFY.

> SA, else the responder will hold that resource for a while.

That's true.

> 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.

> 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.

> 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

---

From: Nico Williams <[email-masked]>
Date: Wed, 30 May 2018 14:05:50 -0500

> I agree. But see Tero's post on why he prefers NOTIFY.

I mean, as long as it works, that's fine.

> >SA, else the responder will hold that resource for a while.

So, NOTIFY works.  But notionally, to me, it's a traffic selector.  The
specific details of how it's carried in IKE are not as interesting.

> to consider the label of UDP (4)500 packets.

I'd expect labeled IKE SAs to be a use case too (where the labels/label
sets are obtained from credentials such as PKIX certificates or from the
local PAD).

> negotiated. But that limits things to preconfigured on a peer to peer

No, that's just one use case.

You could create child SA pairs with different labels from the parent
IKE SAs, provided the parent label range dominates the child labels.

> network. Peers might still want to 'announce' the label they will give

Yes, absolutely.  I don't want to preclude that!  I hope that's clear.

> traffic selector or should we use a notify?

As long as a) the protocol (IKE) can carry the labels, b) IKE SAs can be
labeled, c) child/manual SAs can be labeled, I'm OK with it.

I would mostly leave label dominance semantics out of the spec, but some
security considerations text should discuss that.

Nico
--