Auto-Discovery VPN Problem Statement and Requirements
draft-ietf-ipsecme-ad-vpn-problem-09

I have no objection to the publication of this document.

Martin Vigoureux posted his Routing Directorate review to the authors
and to the ipsec mailing list on the last day of IETF last call.  I
didn't see a response.

The review raises the following non-blocking comments for consideration
by the authors before publication as an RFC.

> Minor Issues:
>
> The draft defines and uses the term "endpoint" and "gateway" while 
> RFC 4301 apparently employs the terms "host" and "gateway" (although
> there are few occurrences of "endpoint"). While I doubt that this 
> difference will be misleading, it might be wise to seek for
> consistency in terminology between the documents, or alternatively
> state the differences and similarities between the functions these
> terms refer to.
>
> Nowhere is there a requirement for (backward) compatibility with 
> regards to existing specifications. Is this intentional?
>
> Requirement 1 is unclear with regards to the type of configuration 
> changes that must be minimized. It should be clarified if these
> changes are manual configuration changes or simply configuration
> changes. If not, out of this requirement both the solutions of having
> no/few change or having as many changes as today but all/most of them
> done without human intervention, are possible.
> I can not state if any of these makes sense or is feasible but they 
> are surely substantially different from a design and engineering 
> perspective.
> As an illustration, Requirement 2 has the same ambiguity but resolves
> it by means of the second sentence where the configurations are 
> explicitly qualified as "manual".
>
> Isn't requirement 8 too strong? The keyword "MUST" is used, while 
> "SHOULD" would seem more appropriate. Indeed, follows the requirement
> a description of situations in which it might not be possible to meet
> the requirement, or where it might be but by means of external
> factors.
>
> While requirement 12 is not an unusual one, its presence in a document 
> that focuses on point-to-point can be discussed.
>
> As a general comment it is difficult to estimate how much some of
> these requirements scope/guide the design of a solution.
>
>
> Nits:
>
>Section 2.2:
> "It is for this purpose spoke-to-spoke tunnels are dynamically created
> and torn-down." This sentence seems difficult to read.

---

Please consider consistency of hyphenation. For example: "site-to-site"
and "host to host".

---

Section 1

I stumbled over

   The difficulty is that all the configuration mentioned in RFC 4301 is
   not superfluous.

Is this equivalent to

   The difficulty is that none of the configuration mentioned in RFC 
   4301 is superfluous.

---

Section 1.1 (Hub)

   The
   hubs usually forward traffic coming from encrypted links to other
   encrypted links, i.e.  there are no devices connected to it in clear.

Seems to be a contradiction between "usually" and "no devices".  Should
it read:

   The
   hubs usually forward traffic coming from encrypted links to other
   encrypted links, i.e.  there are usually no devices connected to it
   in clear.

---

I found requirement 4 to be self-defining (or possibly not saying 
anything).

   4.  In the full mesh and dynamic full mesh topology, Spokes MUST
   allow for direct communication with other spoke gateways and
   endpoints.  In the star topology mode, direct communication between
   spokes MUST be disallowed.

The definiton of mesh topologies and star topology *are* these 
abilities. But I would also say that it is not the business of the
mechanism that is invented to specifically allow or disallow the
communications. That is a deployment model.

Maybe you are looking for...

   4. It must be possible to make a system-wide configuration of
   whether a mesh topology or star topology is being used, and to
   enable/limit the provision of keys so as to support or disallow the
   specific topology.

   More generally, it must be possible to configure which spokes are 
   allowed to communicate directly.

Similarly

   11.  The administrator of the ADVPN SHOULD allow for the
   configuration of a Star, Full mesh or a partial full mesh topology,
   based on which tunnels are allowed to be setup.

This seems to be self-defining.

---

Should you add a reference for "L3VPN"?

Here are a number of non-blocking, editorial comments.  There are lots more, which I'll leave to the RFC Editor; I've only included some that I think most affect the ability to understand the document.

-- Section 1 --

   The difficulty is that all the configuration mentioned in RFC 4301 is
   not superfluous.  IKE implementations need to know the identity and

The "all X is not Y" construction is pretty much always bad.  It usually means "not all X is Y", and should be said that way, but in this case I think "some X is Z" would be a much better way.  "...that some of the configuration mentioned in RFC 4301 is important to get right," or some such.

-- Section 2.1 --

   The need for secure endpoint to endpoint communications is often
   driven by a need to employ high-bandwidth, low latency local
   connectivity

At first I thought "secure" modified the first instance of "endpoint".  You want "endpoint-to-endpoint", with hyphens, yes?  (Also, as "high-bandwidth" is hyphenated, so should "low-latency" be.)

   Such a use case also enables connectivity when both behind NAT
   gateways.

Is "users are" missing after "both"?  Also, having two sentences in a row that begin with "Such a use case" is a bit awkward.

Misplaced comma and wrong word:
OLD
   In a star topology when two endpoints communicate, they need a
   mechanism for authentication, such that they do not expose themselves
   to impersonation by the other spoke endpoint.
NEW
   In a star topology, when two endpoints communicate they need a
   mechanism for authentication, so that they do not expose themselves
   to impersonation by the other spoke endpoint.
END

-- Section 2.2 --

   However for voice and other rich media traffic that requires a lot of
   bandwidth or is performance sensitive, the traffic tromboning to the
   hub can create traffic bottlenecks on the hub

"tromboning"?  Is everyone going to understand that term?  (I didn't, and I won't tell you what I found when I googled it.)

-- Section 2.3 --

Maybe making the first sentence, "A mobile endpoint [...]" would help?

I wouldn't mind if the first sentence of the second paragraph read more like actual prose, and less like someone took notes.

-- Section 3.2 --

   The challenge is to build a large scale, IPsec protected networks
   that can dynamically change with minimum administrative overhead.

I think you need to remove "a", hyphenate "IPsec-protected", and make it "minimal".

-- Section 4.1 --
In item (1), the first SHOULD actually makes things muddier, and I suggest removing it.  As it is, I read it this way: "you SHOULD do the following set of things: (MUST NOT x, SHOULD NOT y, MUST NOT z)."  Do you see how that SHOULD weakens the MUST NOTs if you read it that way?

I suggest replacing the first sentence like this: "For any network topology (...), when a new gateway or endpoint is added, removed, or changed, configuration changes are minimized as follows:"

In item (6):
   External factors like firewall, NAT boxes will not be
   considered part of this solution.

I don't understand that sentence in the context it's in.  Please say it another way, so it fits better into the requirement.