Subject: Re: [IPsec] Comments on the new meshed VPN draft

From: Yoav Nir <[email-masked]>
Date: Fri, 4 Nov 2011 23:37:40 +0200

Hi Yaron

Sorry for taking so long to respond. My comments inline.

On Oct 14, 2011, at 11:37 AM, Yaron Sheffer wrote:

> I am going on vacation, but I did want to post these before. Sorry if I cannot take part in the ensuing discussion.
> Overall, this is a good start for an important set of problems. But I would have liked the document to be clearer/deeper before we can discuss it seriously. I find some of the use cases too vague to discuss the issues, let alone engineer a solution.
> Thanks,
>     Yaron
> • The following sentence simply doesn't apply to standard remote access situations, and should be refined: "IKE implementations need to know the identity and credentials of all possible peer systems, as well as the addresses of hosts and/or networks behind them."

Remote access clients still need to know the identity and credentials of all possible peer systems. As for protected domain, there are really three options:
	• The can be pre-configured with the peer's protected domain. My company's clients do that.
	• They can learn the peer's protected domain using some routing protocol over IPsec. Microsoft's L2TP and IKEv2 clients do that.
	• They can assume that the peer is able to hide all of the Internet. Android's L2TP client does that.
Maybe the "behind" work should be clarified, but if a peer is willing to re-route any packet, then the entire Internet is effectively behind it.

> • The introduction should mention the related problem that RA clients are not discoverable and in some scenarios lack any usable identity (when using IP addresses for example). Whether we choose to deal with this problem now is a different matter.

Remote access is part of the use cases. See sections 2.2.1 and 2.3. I don't think RA clients ever use IP addresses as identities, or at least that they shouldn't. They don't have a useable identity before they connect to the center gateway, but then they are authenticated. At that point it's possible for the center gateway to tell Bob: "Alice is at IP address so-and-so. You can connect there and she will show you a certificate with public key xxxx, or use shared secret 76b5638236b0a6d51e15b7b8331296ea. So yes, I think we should deal with it soon.

> • 2.1: it is unclear whether the discussion is of the service provider as an enterprise, in which case the fact that it is a service provider is immaterial. What is "service provider enterprise"?

I think "service provider" is the usual meaning. An ISP that also provides some additional services, like configuring VPN for and between its customers. But I'll defer to John and Geoffrey to discuss this, as it's their use case.

> • 2.2: what are "different administrative domains" in this context, and why discuss this case before we discuss meshed VPN within a single domain?

Yet another term we will need to define in the next iteration of the draft. By having two IKE implementations within the same administrative domain means that the administrator configuring policy on one is either the same person as the administrator configuring policy on the other, or else they are co-workers. We'll have to refine this definition to exclude contractors working for multiple organizations.

> • 2.3.1: this scenario sounds very much like a requirement for per-user profiles, and I don't see how it relates to the problem at hand.

I think it's different, but I will defer to Jorge on this.

> • The scenario of two remote users communicating with one another is mentioned clearly in the introduction but surely deserves a use case.

It is described in section 2.2.1.

> • The security considerations again make some assumptions about the desired solution. My personal opinion is that the static RFC 4301 "databases" must remain static and provisioned by humans, but their semantics may need to be extended so they can express more dynamic policies.

I did say "may", but that's a cop-out. In my defense, this section was hastily put together because I thought this draft should not go out with a blank security considerations section. Most of what's in there is relevant regardless of where the dynamic policies are recorded. 

Can you elaborate on how the databases semantics can be extended?

Yoav