On Feb 13, 2012, at 12:16 PM, Paul Wouters wrote: > On 02/13/2012 02:28 PM, Yoav Nir wrote: >> There is no reason why the initiator cannot allow any narrowing. This is >> supposed to be an improvement over IKEv1 where any mismatch in configuration >> between the peers resulted in failure to set up a tunnel. I realize that >> this invalidates the concept of a defined tunnel being either "up" or "down". > > Right. This is the exact problem I'm trying to handle, and I don't see a good > way out. I'm also really afraid people will start demanding I configure 0/0 > to them so they can be lazy and I end up with massive overlapping policies to > deal with and I won't be able to have more then one vpn up at a time.
If the problem is "the application knows the exact tunnel it needs", then the solution is that if the responder narrows the tunnel, the IPsec stack tells the application "you never got a tunnel". IKEv2 was designed around the idea of gateways being the ones that control the tunnel properties, thus avoiding the API issues to applications. --Paul Hoffman _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
