|
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."
• 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.
• 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"?
• 2.2: what are "different administrative domains" in this
context, and why discuss this case before we discuss meshed VPN
within a single domain?
• 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.
• The scenario of two remote users communicating with one another
is mentioned clearly in the introduction but surely deserves a use
case.
• 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.
|
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
