Hi Tero,
It seems to me we are adding architectural assumptions, just to gain a
relatively minor simplification of the protocol. Not a very good trade-off.
Thanks,
Yaron
On 09/13/2010 03:43 PM, Tero Kivinen wrote:
Yaron Sheffer writes:
you are assuming you can always map an IP address (of the incoming ESP)
into the peer's identity. This is often possible, but not always. For
example, if you're using round-robin DNS to look up the B peer, or if
IKE Redirect was used.
Yes, that is the case if you have information in the configuration.
Round-robin DNS is not a problem, as all the IP-addresses are there in
the DNS, thus you do know all of them. IKE Redirect could be problem,
but I do not think that is commonly used with site to site VPNs, it is
mostly used in the road warrior cases where you have lots of clients
connecting to the same server, and as in this case the configuration
was so that either end could initiate connection all of the possible
redirected addresses are most likely already in the configuration to
make sure we know which policy to use when other end connects (in IKE
you must be able to select the initial IKE SA responder policy based
on the IP-address alone, thus in most site-to-site VPNs where the
policy is enforced, configuration already is such that every possible
IP-address of the other end is configured in to the system).
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
