Subject: [IPsec] Mesh VPN I-D (temporary name) - new author

From: Yaron Sheffer <[email-masked]>
Date: Tue, 08 May 2012 22:46:24 +0300

Hi everybody,

Vishwas Manral has agreed to join Steve Hanna as co-author of this 
draft, now at -00 ( 
http://tools.ietf.org/html/draft-ietf-ipsecme-p2p-vpn-problem-00). I'd 
like to thank them both.

While Vishwas and Steve are busy working on the next version, feel free 
to read and comment on the current version.

Regards,

     Yaron

---

From: Izaac <[email-masked]>
Date: Tue, 8 May 2012 22:17:03 -0400

On Tue, May 08, 2012 at 10:46:24PM +0300, Yaron Sheffer wrote:
> While Vishwas and Steve are busy working on the next version, feel
> free to read and comment on the current version.

In what way is this "problem" not addressed by transport mode, despite
it's being "far less commonly deployed?"

But more generally speaking, what exactly is this document attempting to
accomplish in is present form?

-- 
. ___ ___  .   .  ___
.  \    /  |\  |\ \
.  _\_ /__ |-\ |-\ \__

---

From: John Leser <[email-masked]>
Date: Tue, 08 May 2012 23:22:07 -0400

> accomplish in is present form?

I agree with Izaac.

Furthermore, a lot of the language in the draft is confusing (at least 
to me).  You talk about point-to-point tunnel creation, but many of your 
use cases involve VPNs.  Your use cases mostly describe configurations 
that are already solved today using existing transport mode IPsec (2.1) 
and VPN configurations (2.2 and 2.3).  The idea of connecting to the VPN 
(section 2.3) gateway closest to a particular destination seems 
unworkable.  It would be more reasonable, and probably more useful, for 
a client to automatically locate the nearest VPN server to itself (that 
alone would be an interesting and potentially useful problem).

I think you need to narrow down the scope of the problem statement, and 
provide more careful analysis of why current methods are inadequate, 
before this draft is going to get you much useful feedback.

As a side note, in general, the challenge in constructing large IPsec 
configurations across multiple administrative domains is getting the 
"trust relationship" in place to begin with, not the configuration of 
IPsec and key management policy.

-John

---

From: Izaac <[email-masked]>
Date: Wed, 9 May 2012 12:46:37 -0400

On Tue, May 08, 2012 at 11:22:07PM -0400, John Leser wrote:
> particular destination seems unworkable.  It would be more
> reasonable, and probably more useful, for a client to automatically
> locate the nearest VPN server to itself (that alone would be an
> interesting and potentially useful problem).

Even this is better served by just letting IP routing handle it through
the use of transport mode.

-- 
. ___ ___  .   .  ___
.  \    /  |\  |\ \
.  _\_ /__ |-\ |-\ \__

---

From: Vishwas Manral <[email-masked]>
Date: Wed, 9 May 2012 11:54:47 -0700

Hi Izaac/ John,

Thanks for the great inputs you provide. I agree we may not see changes in
the way packets would traverse the network in either the transport/ tunnel
mode.

Like you mention Routing in such topologies is an issue for sure
(especially in the Hub and Spoke topology) and there are extensions being
worked on to resolve those issues. However the above does not solve the
problem of exhaustive IPsec database configurations. It also does not solve
the issues of how to handle changing identifiers in the SPD either (as
addresses of spokes change).

Like the draft mentioned an exhaustive configuration could solve some of
the issues, but that would lead to issues with the weakest link the the
topology.

Thanks,
Vishwas