Yoav... the answer is either! Za needs to pass a packet to Host 2, it may be between a gateway, may be running IPSec itself, or may be unable to receive encrypted packets at all. As with RFC 4322, you would need a policy to determine behaviour when an encrypted channel can't be achieved, but the solution needs to enable Za to discover if there are available cryptographic routes, then make decisions based on the results combined with a policy.
I hope that helps! Chris -----Original Message----- From: Yoav Nir [mailto:y...@checkpoint.com] Sent: Sunday, October 23, 2011 10:37 PM To: Ulliott, Chris; Michael Richardson; ipsec@ietf.org Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement 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" <chris.ulli...@cesg.gsi.gov.uk> 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 **************************************************************************** Communications with GCHQ may be monitored and/or recorded for system efficiency and other lawful purposes. Any views or opinions expressed in this e-mail do not necessarily reflect GCHQ policy. This email, and any attachments, is intended for the attention of the addressee(s) only. Its unauthorised use, disclosure, storage or copying is not permitted. If you are not the intended recipient, please notify postmas...@gchq.gsi.gov.uk. This information is exempt from disclosure under the Freedom of Information Act 2000 and may be subject to exemption under other UK information legislation. Refer disclosure requests to GCHQ on 01242 221491 ext 30306 (non-secure) or email info...@gchq.gsi.gov.uk **************************************************************************** The original of this email was scanned for viruses by the Government Secure Intranet virus scanning service supplied by Cable&Wireless Worldwide in partnership with MessageLabs. (CCTM Certificate Number 2009/09/0052.) On leaving the GSi this email was certified virus free. Communications via the GSi may be automatically logged, monitored and/or recorded for legal purposes. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
