On Tue, 15 Nov 2011, Praveen Sathyanarayan wrote:
Couple of clarification here. Juniper implementation of AC-VPN does not do
GRE over IPSec. It is IPSec alone for implementation (Route based VPN).
Yes, AC-VPN uses NHRP to do resolution just like DM-VPN. But in AC-VPN
there are proprietary messag
On 16 Nov 2011, at 01:57, Praveen Sathyanarayan wrote:
> Couple of clarification here. Juniper implementation of AC-VPN does not do
> GRE over IPSec. It is IPSec alone for implementation (Route based VPN).
> Yes, AC-VPN uses NHRP to do resolution just like DM-VPN. But in AC-VPN
> there are propri
Couple of clarification here. Juniper implementation of AC-VPN does not do
GRE over IPSec. It is IPSec alone for implementation (Route based VPN).
Yes, AC-VPN uses NHRP to do resolution just like DM-VPN. But in AC-VPN
there are proprietary messages. It uses standard messages, but has many
proprieta
On Nov 15, 2011, at 10:52 PM, Michael Richardson wrote:
>
>> "Mark" == Mark Boltz writes:
>Mark> With all due respect to Cisco, the larger problem we're trying
>Mark> to address, is in part the fact that DMVPN and ACVPN are
>Mark> vendor specific implementations. And the goal of
> "Mark" == Mark Boltz writes:
Mark> With all due respect to Cisco, the larger problem we're trying
Mark> to address, is in part the fact that DMVPN and ACVPN are
Mark> vendor specific implementations. And the goal of the
Mark> implementation we're seeking is *large scale* P2P
policy will be
>>> needed to determine which spokes they are permitted to communicate with
>>> (_not_ specified by IP address though - but something more logical, such as
>>> organisation or function.... for example, Org A is willing to communicate
>>> with
s run by org B)
>>
>> Chris
>>
>>
>> -Original Message-
>> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of
>> Praveen Sathyanarayan
>> Sent: Monday, November 07, 2011 5:10 PM
>> To: bill manning; Geoffrey Huang
07, 2011 5:10 PM
> To: bill manning; Geoffrey Huang
> Cc: ipsec@ietf.org
> Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem
>
> There was offline discussion about P2P offered by Juniper Networks (we
> believe Cisco has similar approach, called DMVPN) S
ure tunnel, with the resource. For more information, please see
my draft at http://tools.ietf.org/html/draft-ko-dsi-problem-statement-00
Mike
- Original Message -
From: Paul Wouters
To: Michael Ko
Cc: Yoav Nir ; ipsec@ietf.org
Sent: Sunday, November 13, 2011 2:54 AM
Subject: Re: [IPsec] New
av Nir
Cc: ipsec@ietf.org; Geoffrey Huang; bill manning; Praveen Sathyanarayan
Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs
Problem
"Yoav" == Yoav Nir writes:
Yoav> I don't see how DNS figures into this. We have three
Yoav> gateways: - hub-gw, which kn
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
ael Richardson; ipsec@ietf.org
> Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem
> NHRP is a generic protocol that converts overlay addresses in any address
> family into transport addresses in any address family. The protocol works over
> NBMA meaning that it
11:59 AM
To: Galina Pildush
Cc: Michael Richardson; ipsec@ietf.org
Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem
NHRP is a generic protocol that converts overlay addresses in any address
family into transport addresses in any address family. The protocol works over
> Galina
>
> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of
> Michael Richardson
> Sent: Tuesday, November 08, 2011 3:29 PM
> To: Frederic Detienne
> Cc: ipsec@ietf.org
> Subject: Re: [IPsec] New -00 draft: Creatin
On Behalf
>>Of Praveen Sathyanarayan
>> Sent: Monday, November 07, 2011 5:10 PM
>> To: bill manning; Geoffrey Huang
>> Cc: ipsec@ietf.org
>> Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs
>>Problem
>>
>> There was offline discussion
On 11/08/2011 04:18 PM, Galina Pildush wrote:
NHRP is a protocol that is used to discover the shortest path
> through an NBMA cloud.It does not, however, "speak" IPSec ...
I don't believe that Michael was suggesting that there's a
complete solution here, just that there's prior work on
routing,
11 3:29 PM
To: Frederic Detienne
Cc: ipsec@ietf.org
Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem
RFC2332: NBMA Next Hop Resolution Protocol (NHRP)
I think that it is a much better thing to use something like this, than
invent something new.
--
] He who is tire
> "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
RFC2332: NBMA Next Hop Resolution Protocol (NHRP)
I think that it is a much better thing to use something like this, than
invent something new.
--
] He who is tired of Weird Al is tired of life! | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON|net
On 11/08/2011 11:02 AM, Michael Richardson wrote:
"Geoffrey" == Geoffrey Huang writes:
Geoffrey> Is there a mechanism in DNS to communicate this kind of
Geoffrey> policy? As I understand the example below, the
Geoffrey> communication from hub-gw to spoke32 would be something
manning; Geoffrey Huang
> Cc: ipsec@ietf.org
> Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs
>Problem
>
> There was offline discussion about P2P offered by Juniper Networks (we
> believe Cisco has similar approach, called DMVPN) SSG product line. I am
> forward
> "Geoffrey" == Geoffrey Huang writes:
Geoffrey> Is there a mechanism in DNS to communicate this kind of
Geoffrey> policy? As I understand the example below, the
Geoffrey> communication from hub-gw to spoke32 would be something
Geoffrey> like: "to get to 192.168.79.0/24, go t
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
ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of
> Praveen Sathyanarayan
> Sent: Monday, November 07, 2011 5:10 PM
> To: bill manning; Geoffrey Huang
> Cc: ipsec@ietf.org
> Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem
>
> There was offline di
manning; Geoffrey Huang
Cc: ipsec@ietf.org
Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem
There was offline discussion about P2P offered by Juniper Networks (we
believe Cisco has similar approach, called DMVPN) SSG product line. I am
forwarding this email to group.
In nuts
n by org B)
Chris
-Original Message-
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of
Praveen Sathyanarayan
Sent: Monday, November 07, 2011 5:10 PM
To: bill manning; Geoffrey Huang
Cc: ipsec@ietf.org
Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VP
@ietf.org; bill manning; Praveen Sathyanarayan
Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem
There isn't now, but adding stuff to the DNS is all the rage now that DNSSEC,
ummm, exists. Just take a look at DANE.
On 11/8/11 5:18 PM, "Geoffrey Huang" wr
;Cc: ipsec@ietf.org; Geoffrey Huang; bill manning; Praveen Sathyanarayan
>Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem
>
>
>>>>>> "Yoav" == Yoav Nir writes:
>Yoav> I don't see how DNS figures into this. We have three
>
ndelman.ca]
Sent: Monday, November 07, 2011 10:46 PM
To: Yoav Nir
Cc: ipsec@ietf.org; Geoffrey Huang; bill manning; Praveen Sathyanarayan
Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem
>>>>> "Yoav" == Yoav Nir writes:
Yoav> I don
Praveen Sathyanarayan
Sent: Monday, November 07, 2011 5:10 PM
To: bill manning; Geoffrey Huang
Cc: ipsec@ietf.org
Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem
There was offline discussion about P2P offered by Juniper Networks (we
believe Cisco has similar approach, called
In that case, would RFC 4322 solve your problem? It is based on DNS.
From: Michael Ko [mailto:mich...@huaweisymantec.com]
Sent: 08 November 2011 03:54
To: Yoav Nir; ipsec@ietf.org
Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem
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
On 11/07/2011 12:46 PM, Michael Richardson wrote:
So, okay, so you want to do new work to replace work that's already been
well defined, that uses DNS as the transport.
Could always use SIP, and relegate DNS to discovery:
http://www.cs.cornell.edu/people/francis/sigcomm07-nutss-final.pdf
[I
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
On 11/7/11 11:46 PM, "Michael Richardson" wrote:
>
>> "Yoav" == Yoav Nir writes:
>Yoav> I don't see how DNS figures into this. We have three
>Yoav> gateways: - hub-gw, which knows the protected domains of
>Yoav> everyone - spoke32, which protects 192.168.32.0/24, knows
>Yoav
Yes. Communicated over IKE.
-- Praveen
On 11/7/11 12:32 PM, "Yoav Nir" wrote:
On 11/7/11 10:19 PM, "Michael Richardson" wrote:
>
>> "Yoav" == Yoav Nir writes:
>Yoav> I don't see how DNS figures into this. We have three
>Yoav> gateways: - hub-gw, which knows the protected domai
> "Yoav" == Yoav Nir writes:
Yoav> I don't see how DNS figures into this. We have three
Yoav> gateways: - hub-gw, which knows the protected domains of
Yoav> everyone - spoke32, which protects 192.168.32.0/24, knows
Yoav> about hub-gw, and sends all 192.168.0.0/16 to hub-gw.
On 11/7/11 10:19 PM, "Michael Richardson" wrote:
>
>> "Yoav" == Yoav Nir writes:
>Yoav> I don't see how DNS figures into this. We have three
>Yoav> gateways: - hub-gw, which knows the protected domains of
>Yoav> everyone - spoke32, which protects 192.168.32.0/24, knows
>Yo
> "Yoav" == Yoav Nir writes:
Yoav> I don't see how DNS figures into this. We have three
Yoav> gateways: - hub-gw, which knows the protected domains of
Yoav> everyone - spoke32, which protects 192.168.32.0/24, knows
Yoav> about hub-gw, and sends all 192.168.0.0/16 to hub-gw.
On 11/7/11 9:44 PM, "Michael Richardson" wrote:
>
>> "Praveen" == Praveen Sathyanarayan writes:
>Praveen> In this solution, HUB is the trust entity that all spoke
>Praveen> establish static IPSec tunnel (either using Site to site
>Praveen> tunnel or spoke establish dynamic remo
> "Praveen" == Praveen Sathyanarayan writes:
Praveen> In this solution, HUB is the trust entity that all spoke
Praveen> establish static IPSec tunnel (either using Site to site
Praveen> tunnel or spoke establish dynamic remote access tunnel with
Praveen> hub). When tunnel is e
Mike
- Original Message -
From: Praveen Sathyanarayan
To: bill manning ; Geoffrey Huang
Cc: ipsec@ietf.org
Sent: Tuesday, November 08, 2011 1:09 AM
Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem
There was offline discussion about P2P offered by Juniper Networ
There was offline discussion about P2P offered by Juniper Networks (we
believe Cisco has similar approach, called DMVPN) SSG product line. I am
forwarding this email to group.
In nutshell:
Site to site tunnel -
P2P cut thru tunnel *
+ SP
i don;t think that DNSSEC (writ large) is inapplicable - but thats a
deployment quibble.
I like the idea of ad-hoc, peer based secure channels - but that sort
of requires a trusted introducer. Unfortunately for me, I have to
leave on tuesday. Please keep me posted
on the nature and future of the
收件人: 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
Hello,
On Tue, November 1, 2011 1:56 pm, Paul Wouters wrote:
> On Tue, 1 Nov 2011, Yoav Nir wrote:
>> Raw RSA keys work. If there is an introducer that tells both sides about
>> each other, a shared secret also works. Shared secrets are very secure
>> if you generate them randomly.
>
> PSK's ha
> "Paul" == Paul Hoffman writes:
Paul> On Oct 31, 2011, at 8:09 PM, Michael Richardson wrote:
>> If the entities are in fact a group who has an internal trust
>> anchor:
Paul> They have an entity they trust to make introductions. That's
Paul> different.
Please explain, a
On 11/1/11 7:51 PM, "Keith Welter" wrote:
>>Having been working for the same vendor for 10 years, I've gotten used to
>> our marketing jargon. Anyway, I'd like to have some short term for the
>> set of addresses that are behind a certain gateway", or "the set of
>> addresses that you can reach th
On Tue, 1 Nov 2011, Yoav Nir wrote:
You could use "local subnet" and "remote subnet"?
It's not necessarily a single subnet. It could be an entire corporate LAN
with multiple subnets.
Adding an "s" was left as an exercise for the reader?
Raw RSA keys work. If there is an introducer that tel
On 11/1/11 7:49 PM, "Paul Wouters" wrote:
>On Tue, 1 Nov 2011, Yoav Nir wrote:
>
>>
>> On 11/1/11 4:53 PM, "Mark Boltz" wrote:
>>
>>> I agree with Paul H. that the term "encryption domain" is not really
>>> fully correct for this problem set and its scenarios. I also apologize
>>> for lurking
> >I agree with Paul H. that the term "encryption domain" is not really
> >fully correct for this problem set and its scenarios. I also apologize
> >for lurking for quite some time before chiming in. I'd also rather
avoid
> >marketing-related jargon of any given vendor.
>
> Having been working fo
On Tue, 1 Nov 2011, Yoav Nir wrote:
On 11/1/11 4:53 PM, "Mark Boltz" wrote:
I agree with Paul H. that the term "encryption domain" is not really
fully correct for this problem set and its scenarios. I also apologize
for lurking for quite some time before chiming in. I'd also rather avoid
mar
On 11/1/11 4:53 PM, "Mark Boltz" wrote:
>I agree with Paul H. that the term "encryption domain" is not really
>fully correct for this problem set and its scenarios. I also apologize
>for lurking for quite some time before chiming in. I'd also rather avoid
>marketing-related jargon of any given
On Oct 31, 2011, at 8:09 PM, Michael Richardson wrote:
> If the entities are in fact a group who has an internal trust anchor:
They have an entity they trust to make introductions. That's different.
> a) if they want to use DNSSEC, it only matters they have DNSSEC
> deployed for the part o
I agree with Paul H. that the term "encryption domain" is not really fully
correct for this problem set and its scenarios. I also apologize for lurking
for quite some time before chiming in. I'd also rather avoid marketing-related
jargon of any given vendor.
Before I make further comment, let m
> "Yoav" == Yoav Nir writes:
Jorge> I agree DNSSEC cannot be assumed, its deployments have been
Jorge> marginal.
>> DNSSEC is *one* *public* trusted third party. It's not the only
>> way to use DNS securely, it's just the easiest one to arrange
>> between total strangers
Put differently, it better be Wednesday night, since I can't be in Taipei any
earlier ;-).
-geoff
From: Stephen Hanna
Sent: Friday, October 28, 2011 3:09 PM
To: Yoav Nir; Geoffrey Huang
Cc: ipsec@ietf.org
Subject: RE: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem
I
On 10/31/11 3:30 PM, "Michael Richardson" wrote:
>
>> "Jorge" == Jorge Coronel writes:
>Jorge> +1
>
>Jorge> I agree DNSSEC cannot be assumed, its deployments have been
>Jorge> marginal.
>
>DNSSEC is *one* *public* trusted third party. It's not the only way to
>use DNS securely
> "Jorge" == Jorge Coronel writes:
Jorge> +1
Jorge> I agree DNSSEC cannot be assumed, its deployments have been
Jorge> marginal.
DNSSEC is *one* *public* trusted third party. It's not the only way to
use DNS securely, it's just the easiest one to arrange between total
strangers
On Oct 29, 2011, at 1:34 PM, Yoav Nir wrote:
> So the administrator of this administrative domain may not need to
> configure a lot of tunnels, but he or she still needs to configure all of
> the encryption domain of all the spokes on the introduces, but at least
> that's only one place.
>
> What
OK. So DNSSEC is off the table. At least for now.
At least with Chris's scenario, we can assume that there's an
"administrative domain" that includes a "hub" and some "spokes". This
"hub" has information about the addresses protected by each of the
"spokes", so it makes sense that it will do the
inate with someone representing my company to
attend the BOF meeting.
Thanks
Jorge Coronel
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of
Geoffrey Huang
Sent: Wednesday, October 26, 2011 1:19 PM
To: ipsec@ietf.org
Subject: Re: [IPsec] New -00 draft: Creating Large
Cc: ipsec@ietf.org
Sent: Fri Oct 28 23:09:27 2011
Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem
I agree. Wednesday night would be best.
Who else is interested in getting together to discuss this? Clearly, there are
plenty of interesting issues to discuss.
Steve
From:
-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] *On
Behalf Of *Yoav Nir
*Sent:* Friday, October 28, 2011 10:00 AM
*To:* Geoffrey Huang; Stephen Hanna
*Cc:* ipsec@ietf.org
*Subject:* Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs
Problem
Well, there is a free room between 1300-1500
: Geoffrey Huang; Stephen Hanna
Cc: ipsec@ietf.org
Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem
Well, there is a free room between 1300-1500 on Wednesday, but then we're
opposite WebSec, and I can't attend.
Our best bet is to do it after the Plenary. The pl
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
Well, there is a free room between 1300-1500 on Wednesday, but then we're
opposite WebSec, and I can't attend.
Our best bet is to do it after the Plenary. The plenary ends at 19:30, and
people might want to grab something to eat, so it would probably be best to do
it at 20:00.
Hope you don't h
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.
>
I have to agree with the recent comments about the inapplicability of RFC 4322.
I don't think that a DNNSEC infrastructure can be assumed, particularly not in
the deployments I have seen.
I agree with Steve Hanna's comments about the need for ad-hoc peer-to-peer
VPNs, bypassing a centralized h
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
se standards.
Thanks,
Steve Hanna
> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
> Of Yoav Nir
> Sent: Tuesday, October 25, 2011 4:40 AM
> To: 'Michael Richardson'; ipsec@ietf.org
> Cc: Ulliott, Chris
> Subject: R
-
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
90 matches
Mail list logo
