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
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
