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:
On 3/11/15, 11:38 PM, paul_kon...@dell.com 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
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
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
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 points.
Thanks,
Fred
(sent from mobile)
On 06 Feb 2014, at 00:31, Praveen Sathyanarayan
pravee
Hi Fred,
My comments inline.
Thanks,
Praveen
On 2/5/14, 5:42 AM, Frederic Detienne (fdetienn) fdeti...@cisco.com
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
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
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) fdeti...@cisco.com
wrote:
Hi,
I would like to re-iterate the importance of clarifying the
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
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
Thanks Fred for clarifications.
-- Praveen
On 10/16/13 10:00 AM, Frederic Detienne (fdetienn) fdeti...@cisco.com
wrote:
On 15 Oct 2013, at 20:05, Praveen Sathyanarayan pravee...@juniper.net
wrote:
Are there any other detail that are not part of this draft, that is
required
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,
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 there
/13 6:05 PM, internet-dra...@ietf.org 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-advpn
Revision: 02
Title
:45 AM
To: Praveen Sathyanarayan pravee...@juniper.netmailto:pravee...@juniper.net
Cc: Toby Mao yum...@gmail.commailto:yum...@gmail.com, Yoav Nir
y...@checkpoint.commailto:y...@checkpoint.com, IPsecme WG
ipsec@ietf.orgmailto:ipsec@ietf.org, ma...@h3c.commailto:ma...@h3c.com
ma...@h3c.commailto:ma
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 yum...@gmail.commailto:yum...@gmail.com
Date: Sunday, May 5, 2013 8:49 AM
To: Yoav Nir
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
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 credentials. But if pre
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 are
Few of my suggestions here
1.) Cut through VPN
2.) Auto mesh VPN
Thanks,
Praveen
On 3/12/12 5:22 PM, Stephen Hanna sha...@juniper.net 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
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
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
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
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
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 manning; Geoffrey Huang
Cc: ipsec@ietf.org
Subject: Re: [IPsec] New -00 draft: Creating Large
, in different Virtual router.
-- Praveen
On 11/8/11 9:25 AM, Praveen Sathyanarayan pravee...@juniper.net 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
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 *
+
27 matches
Mail list logo
