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: Yoav Nir <ynir_at_nospam>
Date: Wed Oct 26 2011 - 17:03:47 GMT
To: "'Galina Pildush'" <galina@juniper.net>, Paul Hoffman <paul.hoffman@vpnc.org>, IPsecme WG <ipsec@ietf.org>

This goes back to my previous question.

What is this information that is "known to hub and all spokes" ?

If the spoke knows what addresses are behind each other spoke, then we lose the scalability - that's a lot of configuration up front.

If the spoke only knows the union of all addresses behind other spokes, it sounds more feasible, but I still would like to know how it's configured.

If it's only the hub that knows the union, then again, how was that configured?

If each spoke knows only its own addresses and informs the hub, how do we prevent the problem of a malicious spoke claiming Facebook's subnets?

Yoav

-----Original Message-----
From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Galina Pildush
Sent: 26 October 2011 16:52
To: Paul Hoffman; IPsecme WG
Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement

+ Definitely agree with Steve and Paul - the proposed draft proposes spoke-to-spoke direct tunnel establishment based on the information known to hub and all spokes. We've seen many service providers wanting this ability to scale painlessly and seamlessly.

Galina Pildush

-----Original Message-----
From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Paul Hoffman
Sent: Wednesday, October 26, 2011 10:41 AM
To: IPsecme WG
Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement

On Oct 26, 2011, at 7:00 AM, Stephen Hanna wrote:

> I'm concerned about using DNS as the introducer here. Doing this
> securely requires DNS records to be updated, signed, and distributed
> whenever a new "satellite" gateway or host arrives or departs.
> That's cumbersome, expensive, and complex since it requires
> interfacing the IPsec and DNSSEC infrastructure and lots of resigning.
>
> The core IPsec gateway already knows all the information necessary to
> establish a secure direct connection between satellites and there's
> already a secure connection between the core and the satellites. Why
> not use that connection to distribute the information directly from
> the core to the satellites?

+1. Putting in a dependency not only on DNS, but DNSSEC, seems odd here. If there is already a trusted introducer here, use it. The use case for RFC 4322, opportunistic encryption (and thus no trusted introducer), is quite different than the one being proposed here.

--Paul Hoffman

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Scanned by Check Point Total Security Gateway.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec