Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2013-09-04
09 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2013-08-26
09 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2013-08-15
09 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2013-08-12
09 Suresh Krishnan Request for Last Call review by GENART Completed: Almost Ready. Reviewer: Suresh Krishnan.
2013-07-22
09 Amy Vezza State changed to RFC Ed Queue from Approved-announcement sent
2013-07-19
09 (System) RFC Editor state changed to EDIT
2013-07-19
09 (System) Announcement was received by RFC Editor
2013-07-19
09 (System) IANA Action state changed to No IC from In Progress
2013-07-19
09 (System) IANA Action state changed to In Progress
2013-07-19
09 Amy Vezza State changed to Approved-announcement sent from Approved-announcement to be sent
2013-07-19
09 Amy Vezza IESG has approved the document
2013-07-19
09 Amy Vezza Closed "Approve" ballot
2013-07-19
09 Amy Vezza Ballot approval text was generated
2013-07-19
09 Amy Vezza Ballot writeup was changed
2013-07-19
09 Amy Vezza State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2013-07-15
09 Vishwas Manral New version available: draft-ietf-ipsecme-ad-vpn-problem-09.txt
2013-07-14
08 Jari Arkko [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss
2013-07-13
08 (System) Sub state has been changed to AD Followup from Revised ID Needed
2013-07-13
08 Vishwas Manral IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2013-07-13
08 Vishwas Manral New version available: draft-ietf-ipsecme-ad-vpn-problem-08.txt
2013-06-27
07 Tero Kivinen Request for Telechat review by SECDIR Completed: Has Nits. Reviewer: Carl Wallace.
2013-06-27
07 Cindy Morgan State changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2013-06-27
07 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2013-06-27
07 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo
2013-06-27
07 Jari Arkko
[Ballot discuss]
Thank you for writing a document on this important problem. I'm planning to ballot a Yes vote on the document. But before that …
[Ballot discuss]
Thank you for writing a document on this important problem. I'm planning to ballot a Yes vote on the document. But before that I would like to discuss two items. First, it would be good to ensure that the authors have seen Suresh Krishnan's Gen-ART review. Secondly, Suresh raised a question on Section 2.3:

> The following sentence is a bit confusing. How does a mobile user
> connect to a new gateway without reinitiating a connection? Can you
> please clarify or reword.

> "The mobile user ought to be able to discover and then connect to the
> current most efficient gateway without having to reinitiate the connection."

I would also like to see a clarification or rewording, as the way that the current text is written, this seems like an almost impossible requirement.
2013-06-27
07 Jari Arkko [Ballot Position Update] New position, Discuss, has been recorded for Jari Arkko
2013-06-26
07 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick
2013-06-26
07 Ted Lemon [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon
2013-06-26
07 Richard Barnes [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes
2013-06-26
07 Adrian Farrel
[Ballot comment]
I have no objection to the publication of this document.

Martin Vigoureux posted his Routing Directorate review to the authors
and to the …
[Ballot comment]
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"?
2013-06-26
07 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel
2013-06-26
07 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2013-06-25
07 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant
2013-06-25
07 Barry Leiba
[Ballot comment]
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 …
[Ballot comment]
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.
2013-06-25
07 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2013-06-25
07 Barry Leiba Changed document writeup
2013-06-25
07 Barry Leiba Changed document writeup
2013-06-25
07 Sean Turner State changed to IESG Evaluation from Waiting for AD Go-Ahead
2013-06-25
07 Spencer Dawkins
[Ballot comment]
Not my area of clue, but very clear.

I did have one comment for your consideration - the reference to host-to-host transport mode …
[Ballot comment]
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.
2013-06-25
07 Spencer Dawkins [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins
2013-06-25
07 Stephen Farrell
[Ballot comment]

Good to see this being done. I've mostly nitty comments,
I'm entirely ok if you take 'em or leave 'em.

- 1: "is …
[Ballot comment]

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
2013-06-25
07 Stephen Farrell [Ballot Position Update] New position, Yes, has been recorded for Stephen Farrell
2013-06-21
07 Cindy Morgan Note field has been cleared
2013-06-21
07 (System) State changed to Waiting for AD Go-Ahead from In Last Call
2013-06-20
07 Sean Turner Ballot has been issued
2013-06-20
07 Sean Turner [Ballot Position Update] New position, Yes, has been recorded for Sean Turner
2013-06-20
07 Sean Turner Created "Approve" ballot
2013-06-20
07 Sean Turner Ballot writeup was changed
2013-06-19
07 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2013-06-19
07 Pearl Liang
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-ipsecme-ad-vpn-problem-07, which is
currently in Last Call, and has the following comments:

We understand that, upon approval of this …
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-ipsecme-ad-vpn-problem-07, which is
currently in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no
IANA Actions that need completion.

If this assessment is not accurate, please respond as soon as possible.
2013-06-14
07 Jean Mahoney Request for Last Call review by GENART is assigned to Suresh Krishnan
2013-06-14
07 Jean Mahoney Request for Last Call review by GENART is assigned to Suresh Krishnan
2013-06-14
07 Jean Mahoney Closed request for Last Call review by GENART with state 'Withdrawn'
2013-06-13
07 Jean Mahoney Request for Last Call review by GENART is assigned to Kathleen Moriarty
2013-06-13
07 Jean Mahoney Request for Last Call review by GENART is assigned to Kathleen Moriarty
2013-06-07
07 Tero Kivinen Request for Telechat review by SECDIR is assigned to Carl Wallace
2013-06-07
07 Tero Kivinen Request for Telechat review by SECDIR is assigned to Carl Wallace
2013-06-07
07 Amy Vezza IANA Review state changed to IANA - Review Needed
2013-06-07
07 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Auto Discovery VPN Problem Statement …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Auto Discovery VPN Problem Statement and Requirements) to Informational RFC


The IESG has received a request from the IP Security Maintenance and
Extensions WG (ipsecme) to consider the following document:
- 'Auto Discovery VPN Problem Statement and Requirements'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-06-21. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document describes the problem of enabling a large number of
  systems to communicate directly using IPsec to protect the traffic
  between them.  It then expands on the requirements, for such a
  solution.

  Manual configuration of all possible tunnels is too cumbersome in
  many such cases.  In other cases the IP address of endpoints change
  or the endpoints may be behind NAT gateways, making static
  configuration impossible.  The Auto Discovery VPN solution will
  address these requirements.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ad-vpn-problem/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ad-vpn-problem/ballot/


No IPR declarations have been submitted directly on this I-D.


2013-06-07
07 Amy Vezza State changed to In Last Call from Last Call Requested
2013-06-07
07 Amy Vezza Last call announcement was generated
2013-06-06
07 Sean Turner Placed on agenda for telechat - 2013-06-27
2013-06-06
07 Sean Turner Last call was requested
2013-06-06
07 Sean Turner State changed to Last Call Requested from Last Call Requested
2013-06-06
07 Sean Turner Last call was requested
2013-06-06
07 Sean Turner Ballot approval text was generated
2013-06-06
07 Sean Turner State changed to Last Call Requested from AD Evaluation::AD Followup
2013-06-06
07 Sean Turner Ballot writeup was changed
2013-06-06
07 Sean Turner Ballot writeup was generated
2013-06-06
07 Sean Turner Last call announcement was generated
2013-06-06
07 (System) Sub state has been changed to AD Followup from Revised ID Needed
2013-06-06
07 Vishwas Manral New version available: draft-ietf-ipsecme-ad-vpn-problem-07.txt
2013-04-30
06 Sean Turner Here's a link to my first AD review comments:
https://www.ietf.org/mail-archive/web/ipsec/current/msg08190.html

Here's a link to the second AD review comments:
https://www.ietf.org/mail-archive/web/ipsec/current/msg08372.html
2013-04-30
06 Sean Turner Note changed to 'Paul Hoffman (paul.hoffman@vpnc.org) is the document shepherd.'
2013-04-30
06 Sean Turner State changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup
2013-04-30
06 Sean Turner Document shepherd changed to Paul Hoffman
2013-04-30
06 Sean Turner Document shepherd changed to Paul Hoffman
2013-04-24
06 Sean Turner Changed document writeup
2013-04-22
06 Steve Hanna New version available: draft-ietf-ipsecme-ad-vpn-problem-06.txt
2013-04-19
05 Cindy Morgan

1. Summary

This is a document writeup for draft-ietf-ipsecme-ad-vpn-problem-05, prepared by Paul Hoffman for Sean Turner.

The document lists the requirements and likely use …

1. Summary

This is a document writeup for draft-ietf-ipsecme-ad-vpn-problem-05, prepared by Paul Hoffman for Sean Turner.

The document lists the requirements and likely use cases for auto-discovery IPsec VPNs. These VPNs automate configuration when a very large number of hosts and networks must communicate over IPsec in environments where static configuration is not appropriate. There are already a number of proprietary solutions to this problem, and this document is meant as a precursor to the IETF possibly working on a standardized interoperable solution.

This document is appropriate for Informational because it lists requirements and scenarios, not a protocol.

2. Review and Consensus

The document was reviewed by many people in the WG over many months and there is strong consensus to publish. There is one possible open issue from one WG participant, but that can be dealt with during IETF review.

3. Intellectual Property

Both authors have stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79. There was no WG discussion about any IPR disclosures regarding this document.
2013-04-08
05 (System) Sub state has been changed to AD Followup from Revised ID Needed
2013-04-08
05 Steve Hanna New version available: draft-ietf-ipsecme-ad-vpn-problem-05.txt
2013-03-15
04 Sean Turner State changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup
2013-02-21
04 (System) Sub state has been changed to AD Followup from Revised ID Needed
2013-02-21
04 Vishwas Manral New version available: draft-ietf-ipsecme-ad-vpn-problem-04.txt
2013-01-09
03 Sean Turner State changed to AD Evaluation::Revised ID Needed from AD Evaluation
2013-01-02
03 Sean Turner State changed to AD Evaluation from Publication Requested
2013-01-02
03 Sean Turner Note added 'Yaron Sheffer (yaronf.ietf@gmail.com) is the document shepherd.'
2013-01-02
03 Sean Turner Intended Status changed to Informational
2013-01-02
03 Sean Turner IESG process started in state Publication Requested
2013-01-02
03 (System) Earlier history may be found in the Comment Log for draft-ietf-ipsecme-p2p-vpn-problem
2013-01-01
03 Sean Turner Shepherding AD changed to Sean Turner
2012-12-30
03 Yaron Sheffer IETF state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2012-12-30
03 Yaron Sheffer Annotation tag Doc Shepherd Follow-up Underway cleared.
2012-12-30
03 Yaron Sheffer Changed protocol writeup
2012-12-17
03 Yaron Sheffer Changed shepherd to Yaron Sheffer
2012-12-17
03 Vishwas Manral New version available: draft-ietf-ipsecme-ad-vpn-problem-03.txt
2012-12-15
02 Yaron Sheffer Annotation tag Doc Shepherd Follow-up Underway set.
2012-12-15
02 Yaron Sheffer IETF state changed to WG Consensus: Waiting for Write-Up from WG Document
2012-12-14
02 Yaron Sheffer Review/revise security considerations.
2012-12-14
02 Stephanie McCammon New version available: draft-ietf-ipsecme-ad-vpn-problem-02.txt
2012-11-26
01 Vishwas Manral New version available: draft-ietf-ipsecme-ad-vpn-problem-01.txt
2012-08-23
00 Steve Hanna New version available: draft-ietf-ipsecme-ad-vpn-problem-00.txt