Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement

From: Michael Ko <[email-masked]>
Date: Mon, 07 Nov 2011 01:12:24 +0800

I just came across this draft and there seem to be quite a bit of overlap in 
the problems to be solved between this draft and the draft I submitted last 
month titled "Problem Statement for Dynamic Secure Interconnect".  Here is a 
link to the draft: 
http://tools.ietf.org/html/draft-ko-dsi-problem-statement-00

Dynamic Secure Interconnect examines the problems and challenges associated 
with the process of setting up secure interconnections between authorized 
network nodes.  The network nodes can be located anywhere in a
private or public network, directly connected or behind one or more levels 
of NAT.  Setting up a secure interconnection in this environment entails the 
resolution of various issues such as authentication, peer discovery, virtual 
network address management, and connection parameters determination.

I would be interested in getting together to discuss the problem associated 
with creating large scale mesh VPNs.  Someone suggested Wednesday evening. 
That works for me.  But I am open to other time slots as well.

Mike
----- Original Message ----- 发件人: [email-masked] 
[mailto:[email-masked]] 代表 Yoav Nir
发送时间: 2011年10月14日 13:24
收件人: [email-masked]
主题: [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 often built in
hub-and-spoke configurations, not because policy demanded this, but
because it was more convenient to configure. Individual vendors have
incompatible solutions for this, but they only work with that vendor's
products, and within the same administrative domain.

In this draft, we are proposing that the IPsecME working group take on a
working item to first define the problem, and then offer solutions that
will make IPsec scale better and in an inter-operable way.

We plan to hold a side meeting in Taipei, and we welcome comments both
before and at that meeting.

Yoav

http://www.ietf.org/id/draft-nir-ipsecme-p2p-00.txt
http://tools.ietf.org/html/draft-nir-ipsecme-p2p-00

_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Tue, 8 Nov 2011 00:05:16 +0200

Hi Michael

I have only skimmed your draft, and it does seem to have overlap with ours.   However, I think your draft is more about generic hosts on the Internet that have no pre-existing trust between them. It's not clear whether this central repository that you mention in your draft is something specific to a small part of the Internet, say, a company or a government network, or if the repository is some service that everybody can use, similar to DNS or the public CAs.

Our use-cases are when there is enough pre-existing trust to establish tunnels, just not all tunnels. It's mostly about turning stars or trees into meshes by having center nodes introduce other nodes to each other, and it will also probably be about resolving differences in configuration and bypassing NAT.

That said, there is considerable overlap, and I hope you can be at our side meeting on Wednesday night.

Yoav

On 11/6/11 7:12 PM, "Michael Ko" <[email-masked]<mailto:[email-masked]>> wrote:

I just came across this draft and there seem to be quite a bit of overlap in the problems to be solved between this draft and the draft I submitted last month titled "Problem Statement for Dynamic Secure Interconnect".  Here is a link to the draft:  http://tools.ietf.org/html/draft-ko-dsi-problem-statement-00

Dynamic Secure Interconnect examines the problems and challenges associated with the process of setting up secure interconnections between authorized network nodes.  The network nodes can be located anywhere in a
private or public network, directly connected or behind one or more levels of NAT.  Setting up a secure interconnection in this environment entails the resolution of various issues such as authentication, peer discovery, virtual network address management, and connection parameters determination.

I would be interested in getting together to discuss the problem associated with creating large scale mesh VPNs.  Someone suggested Wednesday evening.  That works for me.  But I am open to other time slots as well.

Mike
----- Original Message ----- 发件人: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] 代表 Yoav Nir
发送时间: 2011年10月14日 13:24
收件人: [email-masked]<mailto:[email-masked]>
主题: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem
Statement

Hi all

Yoav

_______________________________________________
IPsec mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Michael Ko <[email-masked]>
Date: Tue, 08 Nov 2011 09:54:15 +0800

Yoav,

Thank you for taking the time to review the draft and providing your 
feedback.

In the scenario depicted in my draft, there is pre-existing trust between 
the central repository and the other nodes.  If I understand your draft 
correctly, it is akin to your center nodes which "introduce other nodes to 
each other, and it will also probably be about resolving differences in 
configuration and bypassing NAT".  As envisioned, the central repository is 
not intended to be "specific to a small part of the Internet, say, a company 
or a government network", and most likely "the repository is some service 
that everybody can use, similar to DNS or the public CAs".  But again, this 
is just a problem statement, not a solution proposal.  The role of the 
central repository can evolve as we explore other alternatives and use 
cases.

Mike

----- Original Message ----- 
From: Yoav Nir
To: Michael Ko ; [email-masked]
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 your draft is more about generic hosts on the Internet that 
have no pre-existing trust between them. It's not clear whether this central 
repository that you mention in your draft is something specific to a small 
part of the Internet, say, a company or a government network, or if the 
repository is some service that everybody can use, similar to DNS or the 
public CAs.

Our use-cases are when there is enough pre-existing trust to establish 
tunnels, just not all tunnels. It's mostly about turning stars or trees into 
meshes by having center nodes introduce other nodes to each other, and it 
will also probably be about resolving differences in configuration and 
bypassing NAT.

That said, there is considerable overlap, and I hope you can be at our side 
meeting on Wednesday night.

Yoav

On 11/6/11 7:12 PM, "Michael Ko" <[email-masked]> wrote:

  I just came across this draft and there seem to be quite a bit of overlap 
in the problems to be solved between this draft and the draft I submitted 
last month titled "Problem Statement for Dynamic Secure Interconnect".  Here 
is a link to the draft: 
http://tools.ietf.org/html/draft-ko-dsi-problem-statement-00

  Dynamic Secure Interconnect examines the problems and challenges 
associated with the process of setting up secure interconnections between 
authorized network nodes.  The network nodes can be located anywhere in a
  private or public network, directly connected or behind one or more levels 
of NAT.  Setting up a secure interconnection in this environment entails the 
resolution of various issues such as authentication, peer discovery, virtual 
network address management, and connection parameters determination.

  I would be interested in getting together to discuss the problem 
associated with creating large scale mesh VPNs.  Someone suggested Wednesday 
evening.  That works for me.  But I am open to other time slots as well.

  Mike

  Hi all

  Yoav

--------------------------------------------------------------------------------

---

From: Yoav Nir <[email-masked]>
Date: Tue, 8 Nov 2011 10:14:12 +0200

In that case, would RFC 4322 solve your problem? It is based on DNS.

________________________________
From: Michael Ko [mailto:[email-masked]]
Sent: 08 November 2011 03:54
To: Yoav Nir; [email-masked]
Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement

Yoav,

Thank you for taking the time to review the draft and providing your feedback.

In the scenario depicted in my draft, there is pre-existing trust between the central repository and the other nodes.  If I understand your draft correctly, it is akin to your center nodes which "introduce other nodes to each other, and it will also probably be about resolving differences in configuration and bypassing NAT".  As envisioned, the central repository is not intended to be "specific to a small part of the Internet, say, a company or a government network", and most likely "the repository is some service that everybody can use, similar to DNS or the public CAs".  But again, this is just a problem statement, not a solution proposal.  The role of the central repository can evolve as we explore other alternatives and use cases.

Mike

----- Original Message -----
From: Yoav Nir<mailto:[email-masked]>
To: Michael Ko<mailto:[email-masked]> ; [email-masked]<mailto:[email-masked]>
Sent: Tuesday, November 08, 2011 6:05 AM
Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement

Hi Michael

Yoav

Mike

Hi all

Yoav

________________________________

---

From: Michael Ko <[email-masked]>
Date: Wed, 09 Nov 2011 03:19:24 +0800

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 only is opportunistic encryption impossible, but it is also 
impossible for any communication to be initiated to the end system.  It may 
be possible for this end system to initiate such communication, but the 
initiator in this use case is the mobile user.  Note that the private IP 
address of a host in an end system behind a NAT may also change due to the 
fact that it is migrated for load balancing or other reasons.

Mike
----- Original Message ----- 
From: Yoav Nir
To: 'Michael Ko' ; [email-masked]
Sent: Tuesday, November 08, 2011 4:14 PM
Subject: RE: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem 
Statement

Yoav,

Mike

----- Original Message ----- 
From: Yoav Nir
To: Michael Ko ; [email-masked]
Sent: Tuesday, November 08, 2011 6:05 AM
Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem 
Statement

Hi Michael

Yoav

  Mike

  Hi all

  Yoav

---

From: Michael Richardson <[email-masked]>
Date: Tue, 08 Nov 2011 15:34:31 -0500

>>>>> "Michael" == Michael Ko <[email-masked]> 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 particular, given a service like
TURN, HIP, or IKEv2, and a hub to exchange the outside addresses, it is
entirely possible to arrange for things to work.

    Michael> Not only is opportunistic encryption impossible, but it is
    Michael> also impossible for any communication to be initiated to
    Michael> the end system.  It may be possible for this end system to

In fact, we've done it.
The problem is that is doesn't scale to the Internet, since the
overlapping RFC1918 address ranges mean that eventually, there is
another 192.168.1.0/24 network that you want to talk to, while you are
on one.

One can pick new addresses for inside the tunnel, but which ones?
We couldn't solve this problem in a way that scaled to the Internet: the
rise of ubiquitous NAT is the reason why RFC4332 died.

While these problems are still challenging in a walled garden, they are
much more tractable.  Or, given that it's all inside a tunnel, why not
just use IPv6 addresses on the inside of host to host tunnels?

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Michael Ko <[email-masked]>
Date: Wed, 09 Nov 2011 23:58:38 +0800

IPv6 definitely has advantages over IPv4, and everyone should switch to IPv6 
post haste.  But reality being the way it is, accommodating IPv4 is 
sometimes unavoidable.  (Please note that I have no intention of provoking a 
religious debate here.)

Mike
----- Original Message ----- 
From: Michael Richardson
To: [email-masked]
Sent: Wednesday, November 09, 2011 4:34 AM
Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs 
ProblemStatement

In fact, we've done it.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls 
[
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net 
architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device 
driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
               then sign the petition.
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Paul Wouters <[email-masked]>
Date: Sat, 12 Nov 2011 13:54:11 -0500 (EST)

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 very possible for two XMPP clients to convey where they are and poke a hole for each other.

Paul

---

From: Michael Ko <[email-masked]>
Date: Sun, 13 Nov 2011 05:27:58 +0800

Paul,

It seems that my statement has been taken out of context.  It is in response 
to the question from Yoav who asked "would RFC 4322 solve your problem".  My 
response was paraphrased from section 6.3 of RFC 4322 on End System Behind a 
NAT/NAPT where it began with "If the end system is behind a NAT (perhaps 
SG-B), then there is, in fact, no way for another end system to address a 
packet to this end system."

The problem as stated in my draft addressed the situation where not all the 
attributes regarding the resources that a client wants to access is known. 
This include address, security protocol, configuration, etc.  Having a 
center node to establish a line of trust between the client and the 
resources and to discover the attributes associated with the resources 
facilitate the process whereby a client can make a direct connection, most 
likely a secure 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 ; [email-masked]
Sent: Sunday, November 13, 2011 2:54 AM
Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem 
Statement

> system to address a packet to this end

Not neccessarilly true. If you look at traditional hosts, you are correct. 
But if you look at more human driven
systems, then it is very possible for two XMPP clients to convey where they 
are and poke a hole for each other.

Paul