On Tue, 1 May 2018, Nico Williams wrote:
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)
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.
- 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
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
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
