Hi Linda,
We published the following draft for AutoDiscovery VPN. It is already
implemented by Juniper and other major vendors.
https://tools.ietf.org/html/draft-sathyanarayan-ipsecme-advpn-03
Thanks,
Praveen
From: IPsec on behalf of Linda Dunbar
Sent: Monday
On 3/11/15, 11:38 PM, "paul_kon...@dell.com" wrote:
>As for buggy implementations, I think that it isn’t needed for that. If
>someone has a bug that breaks interoperability, we would in general take
>the view of “if they fix it, it will work” — in other words, vendors
>normally don’t tak
I agree, it is a corner case. Example, out of 5000 tunnels, may be we will
see 10 to 15 tunnels end up in this scenario. So memory/resource is not a
concern. But question is, how do we handle once we are in that state. For
example, which phase1/phase2 SA we should continue to hold (Rekey) and
which
Why not trigger Re-authentication from base station, when upgraded/REDIRECT
enabled in config?
RFC 5996:
Reauthentication is done by creating a new IKE SA from scratch (using
IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA Notify
payloads), creating new Child SAs within the new IK
On 3/21/14, 4:25 PM, "Yoav Nir" wrote:
> So without #3, I am not sure the effort is worthwhile.
+1 for this.
We started this effort to solve #3. To me, #1 and #2 are important
requirements as well. But #3 is a must.
‹ Praveen
___
IPsec mailing l
egotiation methods.
>
>In practice, it means only a couple vendors will be able to implement it
>decently and will likely clash quite hard. All this at the expense of
>users who are lured by failed promises.
>
>More inline on this topic then I will slowly move on to the next po
Hi Fred,
I see draft-detienne¹s view of discovery of tunnel-peer is a routing
issue. So DMVPN solution predominantly a routing solution. So,
draft-detienne may work good for routing vendors.
But it is not a solution for non-routing vendors. As an example, mobile
devices increasingly can do more f
Hi Fred,
My comments inline.
Thanks,
Praveen
On 2/5/14, 5:42 AM, "Frederic Detienne (fdetienn)"
wrote:
Hi Praveen,
Sorry about the delay. I am just back from our EMEA company event and have
been a lot busier than I planned.
> [PRAVEEN] For one-liner question, we could only imagine the scenar
Hi Fred,
Comments inline.
Thanks,
Praveen
On 1/23/14 7:32 AM, "Frederic Detienne (fdetienn)"
wrote:
>>
>> 1.2 What happens when a prefix administratively changes from behind
>>one
>> branch to another ? How do servers get notified about that ?
>>
>> [PRAVEEN] That¹s an interesting point F
Hi Fred,
Many thanks for the good comments. We're happy to clarify the fine details and
nuances in our proposal further. As you could imagine, there are two ways that
one can deploy ADVPN, as described in our draft. First, you can use the IPSec
rules as defined on a per system/zone/virtual-sy
Hi Fred,
All of our co-authors are currently busy, as we need to catch up with many
post holidays pending works. We will get back to you soon.
-- Praveen
On 1/17/14 1:56 AM, "Frederic Detienne (fdetienn)"
wrote:
>Hi,
>
>I would like to re-iterate the importance of clarifying the points below
Hi Paul,
Extracts from 4301: Section 4.1
Distribution of traffic among these
parallel SAs to support QoS is locally determined by the sender and
is not negotiated by IKE. The receiver MUST process the packets from
the different SAs without prejudice. These requirements apply to
bot
Hi Mike,
I am not sure when you refer to other proposal, you meant ours as well :-).
Appreciate your review and feedback.
You mentioned 4 points that DMVPN is capable of doing that other proposal falls
short. I can speak for our proposal
* Routing protocol: Our proposal does not prevent ru
Thanks Fred for clarifications.
-- Praveen
On 10/16/13 10:00 AM, "Frederic Detienne (fdetienn)"
wrote:
On 15 Oct 2013, at 20:05, Praveen Sathyanarayan
wrote:
>>
>> Are there any other detail that are not part of this draft, that is
>> required for interoperating
>
> Are there any other detail that are not part of this draft, that is
> required for interoperating with existing DMVPN solution?
I think the draft is exhaustive.
[PRAVEEN] Thanks. Good to know. I can think of, handling of NAT in DMVPN
(looks like there is some special mechanism). And are the
Are there any other detail that are not part of this draft, that is
required for interoperating with existing DMVPN solution? And, is there
any other feature that DMVPN supports today (and not required for
interoperability) that is not part of this draft?
Thanks,
Praveen
On 10/9/13 8:23 AM, "Fr
/13 6:05 PM, "internet-dra...@ietf.org"
wrote:
>
>A new version of I-D, draft-sathyanarayan-ipsecme-advpn-02.txt
>has been successfully submitted by Praveen Sathyanarayan and posted to the
>IETF repository.
>
>Filename: draft-sathyanarayan-ipsecme-advp
ain
QoS policies per spoke (or spoke type) on the Hub, as well as to be able to
push some QoS policies to the spokes from the Hub.
Do I make sense?
Thanks,
Vishwas
On Mon, May 6, 2013 at 9:30 AM, Praveen Sathyanarayan
mailto:pravee...@juniper.net>> wrote:
Hi Toby,
When you say QoS pol
Hi Toby,
When you say QoS policy, could you elaborate what it really means? I mean what
kind of information does it need to have or exchanged?
-- Praveen
From: Toby Mao mailto:yum...@gmail.com>>
Date: Sunday, May 5, 2013 8:49 AM
To: Yoav Nir mailto:y...@checkpoint.com>>
Cc: IPsecme WG mailto:ip
If I understood accurately, author meant to establish mesh BGP sessions,
which would allow discovery of each other information. But IMO, this may
cause scale issue. AD-VPN is mainly to address a large VPN deployments. As
an example, say 2000 end-points are deployed. With this MESH approach,
there a
2012 3:04 AM
To: Praveen Sathyanarayan
Cc: Yaron Sheffer; Geoffrey Huang; ipsec@ietf.org; Stephen Hanna
Subject: Re: [IPsec] [ipsecme] #217: Temporary credentials
Praveen Sathyanarayan writes:
> Yes. If certificate based authentication was used in the network, there is
> no need of new cre
Yes. If certificate based authentication was used in the network, there is
no need of new credentials. But if pre-shared key based was used, then we
need this "temporary credentials". Also, it is required to define the
lifetime of this "temporary credentials". For example, if tunnel between
spokes
Few of my suggestions here
1.) Cut through VPN
2.) Auto mesh VPN
Thanks,
Praveen
On 3/12/12 5:22 PM, "Stephen Hanna" wrote:
Of course, you're right. The acronym DMVPN makes this
a very bad choice. Thanks for pointing that out.
I'll throw out a few ideas here:
Dynamic Direct VPN (DDVPN)
Sh
I would like to re-iterate again.
1.) Juniper solution is not based on GRE. Juniper solution is based on
"pure" IPSec in tunnel mode. It works very well.
2.) Juniper implementation has many proprietary messages to solve all
scenarios. NHRP is required, but it is not complete.
3.) Authentication me
Hi Tero,
Looks like there were few discussion happened on this topic while writing
RFC 5996. Why it was not noted in RFC? Even if it was not decided to
address it in RFC, I think there is a good value to note it.
I have few more comments inline.
-- Praveen
On 12/19/11 6:14 AM, "Tero Kivinen" w
I am representing Juniper. Juniper will plan to publish a draft.
Thanks,
Praveen
On 12/8/11 12:46 PM, "Yaron Sheffer" wrote:
I'm fine with the new text. Again, provided that people come forward
with a commitment to work on the vendor documents.
Thanks,
Yaron
On 12/08/2011 10:06 PM, Yoav Nir
We agree with Paul. It does look like overkill to us.
We could have NHRP-like messaging. When a spoke establishes preconfigured
spoke-to-hub (s2h), spoke will also does registration with HUB (policy,
protected networks, PAD). Registration information would involve networks
this particular spoke p
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
xample, Org A is
>willing to communicate with all spokes 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
ke, in different Virtual router.
-- Praveen
On 11/8/11 9:25 AM, "Praveen Sathyanarayan" wrote:
Will spoke having part of different hub will solve?
Sure there could be overlapping addresses, which could be solved by having
routing instance (Virtual router/VR). Since HUB as all the info
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
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
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
33 matches
Mail list logo