Traffic selector narrowing can also have uses in end-to-end IPsec. For example, on Solaris apps can use the IP_SEC_OPT socket option to request IPsec protection, and they can even request narrow SAs such that there's an SA pair for just the connected socket's packet flow, and this can be requested on both, the client and server side of a TCP socket.
I don't think narrowing traffic selectors implies that the responder is unwilling to handle traffic covered by the initiator's proposal but not by the responder's narrowed selectors. If the initiator tries again for a different triggering outbound packet it may find that it can tunnel that packet too, and it may find itself having many narrow SAs instead of one big one. So what? Or have I misunderstood narrowing? A tunnel is "up" when bits move. IKE connectivity (specifically being able to establish an IKE_SA) will be a pre-requisite, if you're using IKE anyways. Beyond that bits will move IFF a) local policy allows them to, b) nothing is wrong with the network, the responder, and ultimate end-point. "Bits are not moving" in some cases can only be determined heuristically (by timeouts). So what does "tunnel is up" mean? To me it means local configuration is setup to require tunneling, not that the bits are guaranteed to move. Nico -- _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
