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: Ulliott, Chris <Chris.Ulliott_at_nospam>
Date: Mon Oct 17 2011 - 11:39:32 GMT
To: 'Yoav Nir' <ynir@checkpoint.com>, Michael Richardson <mcr@sandelman.ca>, "ipsec@ietf.org" <ipsec@ietf.org>

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!


-----Original Message-----
From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yoav Nir
Sent: Sunday, October 16, 2011 8:03 PM
To: Michael Richardson; ipsec@ietf.org
Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement

I definitely think that the authors of this draft (I'm mostly just the
editor) need a good answer about why RFC 4322 doesn't cover the use cases.
Mostly, the starting point is different.

RFC 4322 begins with nodes that have no prior trust relationship, and
builds opportunistic bridges between them.

The problem here is that groups of nodes that have trust relationships
between them, but not between every pair of them. They want communications
that now go through some hub gateway to go directly from spoke to spoke.

On 10/14/11 3:48 PM, "Michael Richardson" <mcr@sandelman.ca> wrote:

>>>>>> "Yoav" == Yoav Nir <ynir@checkpoint.com> writes:
> Yoav> A little. Also like GET-VPN and AC-VPN and Provider-1
> Yoav> (apologies to all the vendors I've missed)
> Yoav> Those are some of the incompatible solutions by individual
> Yoav> vendors.
>And RFC4322.
>FreeSWAN has a number of local controls whereby one simply lists the
>CIDRs that one wishes to be "secure or fail" vs ones that are "nice to
>be secure". Many people have implemented MESHs by distributing the
>reverse DNS.
>What it is missing in IKEv1 is a way to turn the host<->host tunnels
>into subnet<->subnet tunnels, and that would be easy to do in IKEv2 with
>the TS.
> >> Sounds like TED:
> >>
> >>
> >>
> >> Dan.
> >>
> >> On Thu, October 13, 2011 10:23 pm, Yoav Nir wrote:
> >>> Hi all
> >>>
> >>> For years, one of the barriers to the adoption of IPsec was that
> >>> configuration didn't scale. With thousands of peers, the PAD and
> >>> SPD would become unwieldy, so even where IPsec was deployed it
> >>> was often built in hub-and-spoke configurations, not because
> >>> policy demanded this, but because it was more convenient to
> >>> configure. Individual vendors have incompatible solutions for
> >>> this, but they only work with that vendor's products, and within
> >>> the same administrative domain.
> >>>
> >>> In this draft, we are proposing that the IPsecME working group
> >>> take on a working item to first define the problem, and then
> >>> offer solutions that will make IPsec scale better and in an
> >>> inter-operable way.
> >>>
> >>> We plan to hold a side meeting in Taipei, and we welcome
> >>> comments both before and at that meeting.
> >>>
> >>> Yoav
> >>>
> >>> http://www.ietf.org/id/draft-nir-ipsecme-p2p-00.txt
> >>> http://tools.ietf.org/html/draft-nir-ipsecme-p2p-00
> >>>
> >>> _______________________________________________ IPsec mailing
> >>> list IPsec_at_ietf.org https://www.ietf.org/mailman/listinfo/ipsec
> >>>
> >>
> >>
> >>
> >> Scanned by Check Point Total Security Gateway.
> Yoav> _______________________________________________ IPsec mailing
> Yoav> list IPsec@ietf.org
> Yoav> https://www.ietf.org/mailman/listinfo/ipsec
>IPsec mailing list
>Scanned by Check Point Total Security Gateway.

IPsec mailing list

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


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