ipsec October 2011 archive
Main Archive Page > Month Archives  > ipsec archives
ipsec: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs

Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement

From: Michael Richardson <mcr_at_nospam>
Date: Mon Oct 24 2011 - 14:00:34 GMT
To: "ipsec@ietf.org" <ipsec@ietf.org>

I was not intending to be, (I have no ticket as yet), but plans might change.
It seems like Chris has all of the requirements of OE, and there is all
of the challenges. IPv6 and homenet might well provide FDQNs for hosts,
and a trusted path to update the reverse.

If DNS does not work for you, then you need another trusted introducer,
and there have been many proposals out there for doing this kind of
thing. None of taken off and hit the elbow of exponential growth.

>>>>> "Yoav" == Yoav Nir <ynir@checkpoint.com> writes:
    Yoav> It does.

    Yoav> But then, both I and MCR agree that RFC 4322 in its present form is not
    Yoav> the answer, but a second edition (as in "rfc4322bis") might be.

    Yoav> Do you think a discovery process based on DNS could be acceptable? I have
    Yoav> never registered a domain, but I know how one could publish records for an
    Yoav> FQDN. I have no idea how I (or an administrator) could get to add records
    Yoav> to the reverse registry. RFC 4322 acknowledges this, and suggests an
    Yoav> alternative - add the records to the FQDN of the host. But in general
    Yoav> networking, we don't have FQDNs for hosts.

    Yoav> Anyway, we seem to be doing the engineer thing of jumping right to the
    Yoav> solution. We're currently at the problem statement phase.

    Yoav> MCR: are you going to be in Taipei?

    Yoav> Yoav

    Yoav> On 10/24/11 1:52 PM, "Ulliott, Chris" <Chris.Ulliott@cesg.gsi.gov.uk>
    Yoav> 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-----
    Yoav> From: Yoav Nir [mailto:ynir@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.Ulliott@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 postmaster@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
>> infoleg@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.
>>
>> Scanned by Check Point Total Security Gateway.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec