Subject: [IPsec] Please Comment on New P2P VPN Problem Statement

From: Stephen Hanna <[email-masked]>
Date: Tue, 6 Mar 2012 16:54:31 -0500

In case you didn't notice, I have posted the -00 version
of the P2P VPN problem statement. The URL is below.
Please review and comment.

I'm especially interested in getting feedback on the
use cases in this document. As previously agreed, they
are based on the use cases in section 2.2 of the
previous problem statement draft. I have tried to
clarify those use cases, especially by providing
definitions of terms and using those terms consistently
throughout the document. 

After we reach consensus on the use cases, we can move
on to defining requirements derived from those use cases.
But I see no point in talking about requirements before
we've agreed on a clear description of the problems
that we are trying to solve.

So please review this short document and send comments.

Thanks,

Steve

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, March 06, 2012 11:01 AM
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-ipsecme-p2p-vpn-problem-00.txt

A new Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF.

    Title         : Point to Point VPNs Problem Statement
    Author(s)     : S. Hanna
    Filename      : draft-ietf-ipsecme-p2p-vpn-problem
    Pages         : 13 
    Date          : March 6, 2012 
    
   This document describes the problem of enabling a large number of
   systems to communicate directly using IPsec to protect the traffic
   between them.  Manual configuration of all possible tunnels is too
   cumbersome in such cases, so an automated method is needed.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-p2p-vpn-problem

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Vishwas Manral <[email-masked]>
Date: Tue, 6 Mar 2012 14:22:36 -0800

Hi Steve,

I agree to the need of standardization for a large scale point-to-point
solution.

1. I guess the problem statement is not just about lessening the number of
configuration commands but also the fact that static configuration may not
work in some cases. The spokes may get new addresses every time they come
up (using DHCP/ PPPoE) and hence the communication end point identifiers
change.

2. I am not sure but the use cases do not come out very clearly to me. The
most important part of the communication is of end-sites communicating to
the gateway hub router. In a typical enterprise deployment that would mean
a branches connected to the campus/ data center. This tunnel is permanent.
Mainly to access resources at the back end. There could be redundancy here
to provide HA.

3. We then optionally require communication between end sites and such
communication may be temporary or permanent. For such cases we want to be
able to unburden the gateway so as to not cause overload.

4. We could have multiple gateways work in a cluster mode to serve a set of
end-sites and to provide HA.

5. The clusters may in turn communicate with each other.

We as HP would love to participate in this draft as well as any solution
document that is produced.

Thanks,
Vishwas

On Tue, Mar 6, 2012 at 1:54 PM, Stephen Hanna <[email-masked]> wrote:

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

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 6 Mar 2012 14:39:49 -0800

Yes, please do comment on the draft. Before commenting, read the whole draft. For extra points: start different threads of the comments with different subject lines.

We will discuss this draft at the upcoming IETF meeting in Paris. By "discuss", I do *not* mean "have the draft introduced to us": I do mean "talk about issues with the draft and things that should be added". Given that there are weeks between now and the meeting, Yaron and I will be somewhat ruthless in preventing Steve from doing much intro in his presentation, and instead insist that he focus on open issues. This will give the folks in the room the maximum amount of time to discuss issues.

This WG has one active draft in front of it; it is not too much of us to expect you to read it before coming to the meeting.

--Paul Hoffman

---

From: Yoav Nir <[email-masked]>
Date: Wed, 7 Mar 2012 00:54:37 +0200

Hi Steve

> So please review this short document and send comments.

While the draft does a good job of describing use cases, and certain inadequate solutions, I think it's missing a description of why this is hard.

Even if we accept the solution of a star topology, where a satellite needs only have one single tunnel, there are really two choices:
 1. that each satellite know about all the protected networks of all the gateways in the configuration, or
 2. that satellites send all traffic to the "core" or "hub" gateways. This includes clear traffic (as in HTTP to facebook.com). This increased the load even more.

If you don't want #2, then the satellite still needs to know about every IP address whether it is protected by some gateway (and therefore needs to go in the tunnel), or not (and so packets with that destination should go out in the clear). Since the protected networks change, this requires that information to propagate throughout the network, and dynamic updates to SPD

If we don't want a star topology, the gateways or endpoints still need to know what is or is not encrypted. They also need to either know about all peers, or be able to find the peer and (securely) learn how it should authenticate. Either way, without a star topology, you need dynamic updates to PAD.

I think the draft should mention this.

Yoav

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 07 Mar 2012 23:25:58 +0200

Hi Yoav, Steve,

I'm not sure that this star-vs-mesh discussion is so important, because 
even if you choose the simplest star topology, data propagation is still 
required.  Configuration of the satellites is simple: *everything* goes 
to the hub. But the hub needs to know which satellite to send each 
packet to, and as the satellites' configuration changes, the hub 
constantly needs to be reconfigured. So it's really the same problem in 
a more limited form.

Thanks,
	Yaron

---

From: Stephen Hanna <[email-masked]>
Date: Wed, 7 Mar 2012 17:46:59 -0500

Vishwas,

Thanks for your comments. I'll respond inline below.

1. I guess the problem statement is not just about lessening the number of configuration commands but also the fact that static configuration may not work in some cases. The spokes may get new addresses every time they come up (using DHCP/ PPPoE) and hence the communication end point identifiers change.

SH> Yes, the dynamic nature of configuration data is as much a problem as the size of that data.

2. I am not sure but the use cases do not come out very clearly to me. The most important part of the communication is of end-sites communicating to the gateway hub router. In a typical enterprise deployment that would mean a branches connected to the campus/ data center. This tunnel is permanent. Mainly to access resources at the back end. There could be redundancy here to provide HA.

3. We then optionally require communication between end sites and such communication may be temporary or permanent. For such cases we want to be able to unburden the gateway so as to not cause overload.

4. We could have multiple gateways work in a cluster mode to serve a set of end-sites and to provide HA.

SH> I'm sorry that the use cases are not clear. However, I'm sure we can and will improve them.

SH> Your description of "The most important part of the communication" seems to be focused only on use case 2.2 in the draft. In your example, several "end-sites" need to establish a direct connection to each other instead of going through a "gateway hub router". To use the terminology defined in the draft, that's a gateway-to-gateway use case. I understand that you consider that to be the most important use case but others have previously spoken out about the importance of use cases 2.1 and 2.3.

SH> So I do agree with your description of use case 2.2. Maybe we should add another example under use case 2.2, based on your example. Could you provide more details about why a direct connection between two "end-sites" might be needed? I can add that as an example in the next version of the draft.

SH> And thanks for volunteering to participate in formulating the problem statement and the solutions. That's great!

Take care,

Steve

From: Vishwas Manral [mailto:[email-masked]]
Sent: Tuesday, March 06, 2012 5:23 PM
To: Stephen Hanna
Cc: IPsecme WG
Subject: Re: [IPsec] Please Comment on New P2P VPN Problem Statement

Hi Steve,

I agree to the need of standardization for a large scale point-to-point solution.

1. I guess the problem statement is not just about lessening the number of configuration commands but also the fact that static configuration may not work in some cases. The spokes may get new addresses every time they come up (using DHCP/ PPPoE) and hence the communication end point identifiers change.

2. I am not sure but the use cases do not come out very clearly to me. The most important part of the communication is of end-sites communicating to the gateway hub router. In a typical enterprise deployment that would mean a branches connected to the campus/ data center. This tunnel is permanent. Mainly to access resources at the back end. There could be redundancy here to provide HA.

3. We then optionally require communication between end sites and such communication may be temporary or permanent. For such cases we want to be able to unburden the gateway so as to not cause overload.

4. We could have multiple gateways work in a cluster mode to serve a set of end-sites and to provide HA.

We as HP would love to participate in this draft as well as any solution document that is produced.

Thanks,
Vishwas
On Tue, Mar 6, 2012 at 1:54 PM, Stephen Hanna <[email-masked]<mailto:[email-masked]>> wrote:
In case you didn't notice, I have posted the -00 version
of the P2P VPN problem statement. The URL is below.
Please review and comment.

Thanks,

Steve

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Tuesday, March 06, 2012 11:01 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: I-D ACTION:draft-ietf-ipsecme-p2p-vpn-problem-00.txt

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

---

From: Yoav Nir <[email-masked]>
Date: Thu, 8 Mar 2012 07:46:10 +0200

There's actually two types of stars. 

One is where the satellite forwards *everything* to the hub, even some user behind the satellite checking their Facebook account. That kind of satellite really needs very little configuration.
The other is where the satellite forwards only traffic going to an address that is behind *some* satellite or hub gateway. This requires that it partition the Internet into a "protected" and a "non-protected" parts.

Stars vs Mesh is IMO important, because with stars you only need to propagate SPDs while with mesh you also need to propagate PADs. The mechanisms for propagating each kind of information may be different when the time comes to discuss solutions.

Yoav

On Mar 7, 2012, at 11:25 PM, Yaron Sheffer wrote:

> Scanned by Check Point Total Security Gateway.

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 12 Mar 2012 16:11:54 -0700

Hi Steve,

** **
> ****
Great. This is a critical factor for even smaller deployments and not just
about the amount of configuration but the fact the configuration cannot be
done.

****
> ** **
> to provide HA.****
> ****
> SH> I’m sorry that the use cases are not clear. However, I’m sure we can
> and will improve them.****
>
> ** **
>
> SH> Your description of “The most important part of the communication”
> seems to be focused only on use case 2.2 in the draft. In your example,
> several “end-sites” need to establish a direct connection to each other
> instead of going through a “gateway hub router”. To use the terminology
> defined in the draft, that’s a gateway-to-gateway use case. I understand
> that you consider that to be the most important use case but others have
> previously spoken out about the importance of use cases 2.1 and 2.3.
>
I meant 2.2 is most important from our perspective as HP.

I agree 2.1 and 2.3 are important too and could be realized the same way,
where an IPsec tunnel could terminate on a gateway/ load balancer.

> ****
>
> ** **
>
> SH> So I do agree with your description of use case 2.2. Maybe we should
> add another example under use case 2.2, based on your example. Could you
> provide more details about why a direct connection between two “end-sites”
> might be needed? I can add that as an example in the next version of the
> draft.****
>
> **
>
In a simple use case we want hub and spoke topology for say the DC and the
branches. This would also be true of ATM's connecting to their DC.

However for scalability reasons we would not want all traffic to go through
the hub. In the ATM example we could want VoIP session to bypass the DC and
have a direct connectivity between themselves. There are multiple other
uses cases for the same. These new sessions however are temporary, when
compared to permanent branch to hub connections.

> **
>
> SH> And thanks for volunteering to participate in formulating the problem
> statement and the solutions. That’s great!
>
Absolutely. Let me know if you need the exact text for the same and I can
help provide it.

Thanks,
Vishwas

> ****
>
> Take care,****
>
> ** **
>
> Steve****
>
> ** **
>
> *From:* Vishwas Manral [mailto:[email-masked]]
> *Sent:* Tuesday, March 06, 2012 5:23 PM
> *To:* Stephen Hanna
> *Cc:* IPsecme WG
> *Subject:* Re: [IPsec] Please Comment on New P2P VPN Problem Statement****
>
> ** **
>
> Hi Steve,
>
> Vishwas****
> On Tue, Mar 6, 2012 at 1:54 PM, Stephen Hanna <[email-masked]> wrote:*
> ***
>
> https://www.ietf.org/mailman/listinfo/ipsec****
>
> ** **
>