Auto-Discovery VPN Problem Statement and Requirements
RFC 7018

Note: This ballot was opened for revision 07 and is now closed.

(Spencer Dawkins) Yes

Comment (2013-06-25 for -07)
No email
send info
Not my area of clue, but very clear. 

I did have one comment for your consideration - the reference to host-to-host transport mode being deployed less often read oddly. I was waiting for the document to say "so transport mode is out of scope, but it included transport mode use cases.

Could you think about what that sentence was supposed to imply? One possibility is that you were headed towards "transport mode hasn't been deployed nearly as often, but we're including transport mode because we expect that to change with WebRTC", but you might have been thinking of something else entirely.

(Stephen Farrell) Yes

Comment (2013-06-25 for -07)
No email
send info
Good to see this being done. I've mostly nitty comments,
I'm entirely ok if you take 'em or leave 'em.

- 1: "is not superflous" is an odd phrase, better to have
a positive statement e.g. "is important but also complex"
or something.

- 1.1: the definition of spoke is unclear to me, esp. the
mention of cleartext. I think you just mean spoke :==
endpoint or gateway but only if gateway != hub, but I'm
not sure that quite works in a full mesh really since
every gateway is then a hub and a spoke. Its probably ok
though, but could be a source of confusion later I guess.

- 2.1: does endpoint-endpoint direct imply transport
mode? its not clear to me 

- 4.1, req#4: "MUST be disallowed" seems wrong, I think
you mean there's no requirement to enable that via the
ADVPN, but since they're two hosts on the Internet you
can't in general prevent them communicating directly.

- 4.1, re1#5: 1st sentence is odd, maybe its not needed
as the 2nd & 3rd sentences capture the requirement
better. (A public key could be interpreted as a long term
credential unless there's a definition of credential that
only means things with a private/secret component.)

- 4.1, req#6: saying f/ws and NAT "will not be
considered" seems wrong - I think you mean that handoff
solutions are not required to cater for f/w & NAT
oddities but if so, better to say it that way perhaps.

- 4.1, req#11: Is "The" administrator correct? Maybe
administrator*s* would be better.

- 5: SPD should probably have been expanded on 1st use

(Sean Turner) Yes

(Jari Arkko) (was Discuss) No Objection

(Richard Barnes) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Adrian Farrel) No Objection

Comment (2013-06-26 for -07)
No email
send info
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)

   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:

   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 

   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.


   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"?

(Joel Jaeggli) No Objection

Barry Leiba No Objection

Comment (2013-06-25 for -07)
No email
send info
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

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

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:
   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.
   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.

-- 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.

(Ted Lemon) No Objection

(Pete Resnick) No Objection

(Martin Stiemerling) No Objection