On Mon, May 07, 2018 at 12:40:08AM -0400, Paul Wouters wrote: > On Thu, 3 May 2018, Nico Williams wrote: > I agree. But see Tero's post on why he prefers NOTIFY.
I mean, as long as it works, that's fine. > >>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. > > > >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. > > That's true. 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. > >>But also, the initiator should not yet have Child SA's ? (but that might > >>be implementation specific) > > > >In that case the parent IKE SA may have a broader label range/set than > >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. 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). > >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. > > 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 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. > 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 Yes, absolutely. I don't want to preclude that! I hope that's clear. > 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. > > >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. > > Again, agreed. The question though, is whether it is worth doing it as a > 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 -- _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
