On Fri, 4 May 2018, Tero Kivinen wrote:
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.
I think this is true. Especially now it seems there is no narrowing to
be done from one security label to another one.
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 would say "dictated by both ends", but yes :)
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.
Exactly, except s/MARK/label because MARKing of packets is another
functionality of the (linux) kernel.
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.
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
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.
That would work for me.
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.
Right.
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
