It does. But then, both I and MCR agree that RFC 4322 in its present form is not the answer, but a second edition (as in "rfc4322bis") might be.
Do you think a discovery process based on DNS could be acceptable? I have never registered a domain, but I know how one could publish records for an FQDN. I have no idea how I (or an administrator) could get to add records to the reverse registry. RFC 4322 acknowledges this, and suggests an alternative - add the records to the FQDN of the host. But in general networking, we don't have FQDNs for hosts. Anyway, we seem to be doing the engineer thing of jumping right to the solution. We're currently at the problem statement phase. MCR: are you going to be in Taipei? Yoav On 10/24/11 1:52 PM, "Ulliott, Chris" <[email protected]> wrote: >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:[email protected]] >Sent: Sunday, October 23, 2011 10:37 PM >To: Ulliott, Chris; Michael Richardson; [email protected] >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" <[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 > > >************************************************************************** >** >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 [email protected]. > >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 >[email protected] > >************************************************************************** >** > > >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. > >Scanned by Check Point Total Security Gateway. _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
