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
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Yoav
Nir
Sent: Sunday, October 16, 2011 8:03 PM
To: Michael Richardson; [email protected]
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" <[email protected]> wrote:
>
>>>>>> "Yoav" == Yoav Nir <[email protected]> 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:
> >>
> >>
>http://www.cisco.com/en/US/docs/ios/12_0t/12_0t5/feature/guide/ted.html
> >>
> >> 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 [email protected] https://www.ietf.org/mailman/listinfo/ipsec
> >>>
> >>
> >>
> >>
> >> Scanned by Check Point Total Security Gateway.
>
> Yoav> _______________________________________________ IPsec mailing
> Yoav> list [email protected]
> Yoav> https://www.ietf.org/mailman/listinfo/ipsec
>_______________________________________________
>IPsec mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/ipsec
>
>Scanned by Check Point Total Security Gateway.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
****************************************************************************
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.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
