Hi Chris As I've asked you off-list, I'm still trying to understand the initial condition.
It's one thing if Za believes that "host 2" is behind *some* gateway, and it's only a matter of finding out which gateway that is. It's a different thing if "host 2" might also be not behind any gateway at all. In that case policy should either say that the packet should be dropped, or it should say that the packet should be forwarded unencrypted (BYPASS in RFC 4301 language). There is a subset of the Internet where Za can encrypt traffic. Is Za pre-configured with that subset? Yoav On 10/17/11 1:39 PM, "Ulliott, Chris" <[email protected]> wrote: >The challenge for us is around discovery of the next cryptographic hop >combined with the increase use of VoIP and other protocols that need peer >to peer connectivity / low latency etc. > >If I'm sat behind a gateway and send a packet to a.b.c.d - my gateway >needs to perform a lookup to find out who it needs to establish an SA >with before it can encrypt the packet and send it on its way. To my >knowledge, there is not standard way of discovering this (although I'll >happily be corrected!) > >For example... (and I hope the ASCII art works!) > >Host 1 --> R --> Za --> R --> R --> Zb --> R --> Host 2 > >(Where R is a router and Zx is a crypto) > >Host 1 send a packet to Host 2, it's routed to the gateway Za as normal, >but at this point Za needs to work out which remote endpoint to establish >an SA with. In this case it's Zb - but the traditional way to achieve >this is through static configuration which doesn't scale if you want to >run fully meshed networks (we have thousands of nodes). When Zb received >the packet it decrypts and forwards to Host 2. > >When you add resilience, this gets even more complicate, for example: > >Host 1 --> R --> Za --> R --> R --> Zb --> R --> Host 2 > | --------> Zc --> R ------^ > >Packets for Host two can be sent via Zb or Zc, how does Za make that >decision? In this example Zc is less hops away so would make more sense >unless it wasn't available. > >Our interest also throws in the problem of multiple administrative >domains. We have numerous sites, but IT is provisioned by differing >integrators. Any standard should (in our opinion) enable this to still >work. At the moment, commercial solutions for meshed VPN's assume that >all the cryptographic devices are run by the same team. > >I hope that helps! > >Chris _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
