-00 draft: Creating Large Scale Mesh VPNs Problem
Statement
On Wed, 9 Nov 2011, Michael Ko wrote:
> If the end system is behind a NAT, then there is no way for another end
> system to address a packet to this end
> system.
Not neccessarilly true. If you look at traditional hosts, you
On Wed, 9 Nov 2011, Michael Ko wrote:
If the end system is behind a NAT, then there is no way for another end system
to address a packet to this end
system.
Not neccessarilly true. If you look at traditional hosts, you are correct. But
if you look at more human driven
systems, then it is ver
> "Michael" == Michael Ko writes:
Michael> If the end system is behind a NAT, then there is no way for
Michael> another end system to address a packet to this end system.
Of course, the machine behind the NAT has to initiate, but there are
numerous ways that this can happen. In part
To: 'Michael Ko' ; ipsec@ietf.org
Sent: Tuesday, November 08, 2011 4:14 PM
Subject: RE: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem
Statement
In that case, would RFC 4322 solve your problem? It is ba
l Message -
From: Yoav Nir<mailto:y...@checkpoint.com>
To: Michael Ko<mailto:mich...@huaweisymantec.com> ;
ipsec@ietf.org<mailto:ipsec@ietf.org>
Sent: Tuesday, November 08, 2011 6:05 AM
Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem
Statement
Hi Mich
ssage -
From: Yoav Nir
To: Michael Ko ; ipsec@ietf.org
Sent: Tuesday, November 08, 2011 6:05 AM
Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem
Statement
Hi Michael
I have only skimmed your draft, and it does seem to have overlap with ours.
However, I think yo
e - 发件人:
ipsec-boun...@ietf.org<mailto:ipsec-boun...@ietf.org>
[mailto:ipsec-boun...@ietf.org] 代表 Yoav Nir
发送时间: 2011年10月14日 13:24
收件人: ipsec@ietf.org<mailto:ipsec@ietf.org>
主题: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem
Statement
Hi all
For years, one o
收件人: ipsec@ietf.org
主题: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem
Statement
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
Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs
Problem Statement
On Oct 28, 2011, at 9:01 AM, Ulliott, Chris wrote:
> So the assumption I've always had is that a spoke knows two things:
>
> 1) a method to identify the next cryptographic hop
> 2) a method t
On Oct 28, 2011, at 9:01 AM, Ulliott, Chris wrote:
> So the assumption I've always had is that a spoke knows two things:
>
> 1) a method to identify the next cryptographic hop
> 2) a method to determine if it's allowed to talk to a specific cryptographic
> hop once identified.
>
> The second p
Nir
Sent: Wednesday, October 26, 2011 6:04 PM
To: 'Galina Pildush'; Paul Hoffman; IPsecme WG
Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem
Statement
This goes back to my previous question.
What is this information that is "known to hub and all spokes&qu
On 10/26/11 9:39 PM, "Yaron Sheffer" wrote:
>There is a common use case where we don't worry about malicious spokes,
>i.e. where they are all trusted.
>
>We do worry about misconfigured spokes, but that would most likely
>result in loss of connectivity, which I expect to be fixed in due time.
>
On Oct 26, 2011, at 12:39 PM, Yaron Sheffer wrote:
> There is a common use case where we don't worry about malicious spokes, i.e.
> where they are all trusted.
Exactly right. The fact that the hub trusts a spoke is all that a different
spoke needs to know for many (most?) common cases.
Having
providers wanting this ability to
scale painlessly and seamlessly.
Galina Pildush
-Original Message-
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@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
blem of a malicious spoke claiming Facebook's subnets?
Yoav
-Original Message-
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@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 Scal
ginal Message-
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@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:
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 s
OTOH if I
> didn't like inventing new mechanisms, I wouldn't be participating in
> the IETF.
>
>
> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
> Of Michael Richardson
> Sent: 24 October 2011 16:01
> To: ipsec@ietf.
-
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of
Michael Richardson
Sent: 24 October 2011 16:01
To: ipsec@ietf.org
Cc: Ulliott, Chris
Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem
Statement
I was not intending to be, (I have no ticket as ye
>> I hope that helps!
>>
>> Chris
>>
>> -Original Message-
Yoav> From: Yoav Nir [mailto:y...@checkpoint.com]
>> Sent: Sunday, October 23, 2011 10:37 PM
>> To: Ulliott, Chris; Michael Richardson; ipsec@ietf.org
ryptographic routes, then make decisions based on the results
>combined with a policy.
>
>I hope that helps!
>
>Chris
>
>-Original Message-
>From: Yoav Nir [mailto:y...@checkpoint.com]
>Sent: Sunday, October 23, 2011 10:37 PM
>To: Ulliott, Chris; Michael Richardson;
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&
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
Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem
Statement
>>>>> "Yoav" == Yoav Nir writes:
Yoav> I definitely think that the authors of this draft (I'm mostly
Yoav> just the editor) need a good answer about why RFC 4322 doesn't
> "Yoav" == Yoav Nir writes:
Yoav> I definitely think that the authors of this draft (I'm mostly
Yoav> just the editor) need a good answer about why RFC 4322 doesn't
Yoav> cover the use cases. Mostly, the starting point is different.
Yoav> RFC 4322 begins with nodes that hav
aphic devices
are run by the same team.
I hope that helps!
Chris
-Original Message-
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@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: Creati
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
> "Yoav" == Yoav Nir 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 whe
A little. Also like GET-VPN and AC-VPN and Provider-1 (apologies to all
the vendors I've missed)
Those are some of the incompatible solutions by individual vendors.
Yoav
On 10/14/11 8:18 AM, "Dan Harkins" wrote:
>
> Sounds like TED:
>
>http://www.cisco.com/en/US/docs/ios/12_0t/12_0t5/feature/
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 S
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
31 matches
Mail list logo
