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
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
