On Wed, May 02, 2018 at 12:00:26AM -0400, Paul Wouters wrote: > 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.
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. > >- 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. 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. > >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. 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 :) > 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. 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 -- _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
