Port Control Protocol (PCP) Anycast Addresses
draft-ietf-pcp-anycast-08

[Ballot comment]
My DISCUSS was:
I'm surprised by the lack of RFC 2119 keywords in a spec like this.
For example:

  The PCP anycast addresses, as defined in Sections 4.1 and 4.2, are
  added after the default router list (for IPv4 and IPv6) to the list
  of PCP server(s)

              MUST?

    ...

  A PCP Server can be configured to listen on the anycast address for
  incoming PCP requests.

Is this a MAY or SHOULD?

I received this message:
  the authors have discussed with the doc shepherd and the AD that
  not a single statement in the document has to be reinforced by a MUST,
  in order to insure interoperability or avoid unneccessary harm to the
  Internet as a whole[1]. There are two sentences where a SHOULD would
  make some sense, but leaving it as is does not seem too bad either.  So
  we decided to move forward without introducing RFC 2119 language.

So some RFC 2119 keyword would make sense, but the responsible AD doesn't insist on doing what's right.
I'm surprised. This is a bad signal for future documents. However, I won't stand in the way but I want my
point of view to be archived in this COMMENT.

[Ballot comment]
My DISCUSS was:
I'm surprised by the lack of RFC 2119 keywords in a spec like this.
For example:

  The PCP anycast addresses, as defined in Sections 4.1 and 4.2, are
  added after the default router list (for IPv4 and IPv6) to the list
  of PCP server(s)

              MUST?

    ...

  A PCP Server can be configured to listen on the anycast address for
  incoming PCP requests.

Is this a MAY or SHOULD?

I received this message:
  the authors have discussed with the doc shepherd and the AD that
  not a single statement in the document has to be reinforced by a MUST,
  in order to insure interoperability or avoid unneccessary harm to the
  Internet as a whole[1]. There are two sentences where a SHOULD would
  make some sense, but leaving it as is does not seem too bad either.  So
  we decided to move forward without introducing RFC 2119 language.

So some RFC 2119 keyword would make sense, but the responsible AD doesn't insist on doing what's right.
I'm surprised. This is a bad signal for future documents. However, I won't stand in the way and will document my reaction in this COMMENT.

[Ballot comment]
My DISCUSS was:
I'm surprised by the lack of RFC 2119 keywords in a spec like this.
For example:

  The PCP anycast addresses, as defined in Sections 4.1 and 4.2, are
  added after the default router list (for IPv4 and IPv6) to the list
  of PCP server(s)

              MUST?

    ...

  A PCP Server can be configured to listen on the anycast address for
  incoming PCP requests.

Is this a MAY or SHOULD?

I received this message:
  the authors have discussed with the doc shepherd and the AD that not a
  single statement in the document has to be reinforced by a MUST, in order
  to insure interoperability or avoid unneccessary harm to the Internet as
  a whole[1]. There are two sentences where a SHOULD would make some sense,
  but leaving it as is does not seem too bad either.  So we decided to
  move forward without introducing RFC 2119 language.

So some RFC 2119 would make sense, but the responsible AD doesn't insist on doing what's right.
I'm surprised. This is a bad signal for future documents. However, I won't stand in the way and will document my reaction in this COMMENT.

[Ballot discuss]
Thanks for writing this useful document. Before recommending its approval
I would like to raise one small question.

I believe it might be appropriate to use clearer language to specify that
BCP 105 (RFC4085) recommendations are to be followed. Specifically,
while the "hard-coding" language has changed, I would have wanted to
seein the later statement about configuration or override, the use of
"SHOULD" instead of "should".

[Ballot comment]
Thanks for writing this useful document. Before recommending its approval
I would like to raise one small question.

I believe it might be appropriate to use clearer language to specify that
BCP 105 (RFC4085) recommendations are to be followed. Specifically,
while the "hard-coding" language has changed, I would have wanted to
seein the later statement about configuration or override, the use of
"SHOULD" instead of "should".

Points 2 and 3 from Robert Spark's Gen-ART review should be considered.

[Ballot discuss]
Thanks for writing this useful document. Before recommending its approval
I would like to raise one small question.

I believe it might be appropriate to use clearer language to specify that
BCP 105 (RFC4085) recommendations are to be followed. That is, that
there needs to be a configuration mechanism to override these addresses.

Specifically, I think you might want to change

  These well-known addresses may be hard-coded into PCP clients.

to

PCP clients may default to the use of these well-known addresses

and in the later statement about configuration or override, consider
the use of "SHOULD" instead of "should".

[Ballot comment]

Say if PCP authentication is supported and the PCP client can
authenticate with various different PCP servers, e.g. at home
and in the office. Imagine further that the secrets for the
home PCP authentication leak (or are guessed). Wouldn't we
want the PCP client in the office in such a case to not accept
a PCP server that uses the home secrets? Is that scenario
possible? If so, and if the PCP client has some way to know
that it is at home or in the office, (could it?), shouldn't
there be some security considerations text saying to not
accept authenticated responses that come from the "wrong" PCP
server? That would probably mean extending the last paragraph
of 5.2 to say "if the client knows what server it expects to
authenticate to it after the anycast request was sent, then
the client MUST check that the response is authenticated from
that server (and not some other)."

Separately, I hate one of the arguments used (twice!) in 5.2.
What you are saying is "I don't need to do stuff because worse
things can happen." If all protocol developers made that
argument then we would never improve security or privacy.
It's a bad argument. You need instead to argue that there's
really nothing practical than can be done and that would be
used and that would improve over doing nothing.

[Ballot discuss]
I'm surprised by the lack of RFC 2119 keywords in a spec like this.
For example:

  The PCP anycast addresses, as defined in Sections 4.1 and 4.2, are
  added after the default router list (for IPv4 and IPv6) to the list
  of PCP server(s)

              MUST?

    ...

  A PCP Server can be configured to listen on the anycast address for
  incoming PCP requests.

Is this a MAY or SHOULD?


What is the rationale for not using the RFC 2119 keywords?
Question to my fellow ADs. I'm so used to RFC 2119 keywords for such type of specifications that I now wonder:
what are the guidelines for may/should/must use the RFC 2119 for standard track spec?
At this point, it's preferable for the authors to wait for guidance from the responsible AD and IESG.

[Ballot comment]
I think items 2 and 3 from Robert Spark's Gen-ART review deserve more consideration:

https://mailarchive.ietf.org/arch/msg/ietf/I7D6wPEGZ5lxqHCzFSfi7qC55qo

Editorial Comments:

2.1, "The PCP anycast addresses ...  are added..."
Added by what?

2.2, 2nd paragraph:
Same as the anycast address? It seems odd to embed the “iana-assigned” bit in this sentence. That fact deserves it’s own sentence.

5.2, first paragraph:

s/"... require to impersonate..."/" ... require the attacker to impersonate..."/  ; or "require the impersonation"

[Ballot comment]
I think items 2 and 3 from Robert Spark's Gen-ART review deserve more consideration.

Editorial Comments:

2.1, "The PCP anycast addresses ...  are added..."
Added by what?

2.2, 2nd paragraph:
Same as the anycast address? It seems odd to embed the “iana-assigned” bit in this sentence. That fact deserves it’s own sentence.

5.2, first paragraph:

s/"... require to impersonate..."/" ... require the attacker to impersonate..."/  ; or "require the impersonation"

[Ballot comment]
Thanks for addressing the SecDir review questions.  Filtering and setting a TTL seem like the best options to prevent leakage, but I do agree with the reviewers that it may not happen on many networks.  I do appreciate the warning and advice though for the gateway.

[Ballot comment]
Given the issue described in 5.1, I'm curious about this text:

"PCP clients usually send PCP requests to these addresses if
  no other PCP server addresses are known or after communication
  attempts to such other addresses have failed."

Would it make more sense to make a normative recommendation about the order in which addresses should be tried, to help minimize the frequency of cases where PCP requests to the anycast address(es) leak out unnecessarily?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-pcp-anycast-06.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA understands that, upon approval of this document, there are two actions which IANA must complete.

First, in the IANA IPv4 Special Purpose Address registry located at:

http://www.iana.org/assignments/iana-ipv4-special-registry/

a new address block is to be registered as follows:

+----------------------+-------------------------------------------+
| Attribute | Value |
+----------------------+-------------------------------------------+
| Address Block | [ TBD-at-registration ] |
| Name | Port Control Protocol Anycast |
| RFC | [ RFC-to-be ] |
| Allocation Date | [ TBD-at-registration ] |
| Termination Date | N/A |
| Source | True |
| Destination | True |
| Forwardable | True |
| Global | True |
| Reserved-by-Protocol | False |
+----------------------+-------------------------------------------+

IANA will collaborate with the authors to select an appropriate address for this use.

Second, in the IANA IPv6 Special Purpose Address registry located at:

http://www.iana.org/assignments/iana-ipv6-special-registry/

a new address block is to be registered as follows:

+----------------------+-------------------------------------------+
| Attribute | Value |
+----------------------+-------------------------------------------+
| Address Block | [ TBD-at-registration ] |
| Name | Port Control Protocol Anycast |
| RFC | [ RFC-to-be ] |
| Allocation Date | [ TBD-at-registration ] |
| Termination Date | N/A |
| Source | True |
| Destination | True |
| Forwardable | True |
| Global | True |
| Reserved-by-Protocol | False |
+----------------------+-------------------------------------------+

IANA will collaborate with the authors to select an appropriate address for this use.

IANA understands that these two actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 

Please note that IANA cannot reserve specific values. However, early allocation is available for some types of registrations. For more information, please see RFC 7120.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Port Control Protocol (PCP) Anycast Addresses) to Proposed Standard


The IESG has received a request from the Port Control Protocol WG (pcp)
to consider the following document:
- 'Port Control Protocol (PCP) Anycast Addresses'
  as Proposed Standard

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 2015-06-11. 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


  The Port Control Protocol (PCP) Anycast Addresses enable PCP clients
  to transmit signaling messages to their closest PCP-aware on-path
  NAT, Firewall, or other middlebox, without having to learn the IP
  address of that middlebox via some external channel.  This document
  establishes one well-known IPv4 address and one well-known IPv6
  address to be used as PCP Anycast Addresses.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-pcp-anycast/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-pcp-anycast/ballot/


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

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard, and the title page indicates Standards Track.
This doc completes the chartered WG work on PCP server discovery,
and the companion documents (RFC 7291, 7488) are already Proposed Standard.


(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

    The Port Control Protocol (PCP) Anycast Addresses enable PCP clients
    to transmit signaling messages to their closest PCP-aware on-path
    NAT, Firewall, or other middlebox, without having to learn the IP
    address of that middlebox via some external channel.  This document
    establishes one well-known IPv4 address and one well-known IPv6
    address to be used as PCP Anycast Addresses.

Working Group Summary:

    The WG has consensus on this document, nothing particularly rough.

Document Quality:

    Implementation status is unknown, although its existence was motivated
    by experience from Apple's implementation.

Personnel:

Who is the Document Shepherd?

    Dave Thaler

Who is the Responsible Area Director?
   
    Brian Haberman

(3) Briefly describe the review of this document that was performed by the
Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the IESG.

    1) reviewed it for technical quality
    2) verified that review was done during WGLC by multiple individuals
      plus the authors
    3) reviewed it against WGLC feedback, which was tracked by issue tracker
      tickets, to verify all were addressed
    4) checked id-nits

(4) Does the document Shepherd have any concerns about the depth or breadth
of the reviews that have been performed?

    No concerns

(5) Do portions of the document need review from a particular or from broader
perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or
internationalization? If so, describe the review that took place.

    No special reviews were expected to be needed

(6) Describe any specific concerns or issues that the Document Shepherd has
with this document that the Responsible Area Director and/or the IESG should
be aware of?

    None

(7) Has each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79 have
already been filed.

    Yes

(8) Has an IPR disclosure been filed that references this document? If so,
summarize any WG discussion and conclusion regarding the IPR disclosures.

    No disclosures filed.

(9) How solid is the WG consensus behind this document? Does it represent the
strong concurrence of a few individuals, with others being silent, or does
the WG as a whole understand and agree with it?

    It was discussed at length over a long period of time, by many in the WG.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate email
messages to the Responsible Area Director. (It should be in a separate email
because this questionnaire is publicly available.)

    No

(11) Identify any ID nits the Document Shepherd has found in this document.
(See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).
Boilerplate checks are not enough; this check needs to be thorough.

    No errors.  One warning which is intentional.

(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, media type, and URI type reviews.

    None relevant.

(13) Have all references within this document been identified as either
normative or informative?

    Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state?

    No.

(15) Are there downward normative references references (see RFC 3967)?

    No

(16) Will publication of this document change the status of any existing RFCs?

    No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes are
associated with the appropriate reservations in IANA registries. Confirm
that any referenced IANA registries have been clearly identified. Confirm
that newly created IANA registries include a detailed specification of the
initial contents for the registry, that allocations procedures for future
registrations are defined, and a reasonable name for the new registry has
been suggested (see RFC 5226).

    Section 4 covers new entries to be added to existing IANA registries.
    It identifies the registries and provides all required fields.

(18) List any new IANA registries that require Expert Review for future
allocations.

    None.

(19) Describe reviews and automated checks performed by the Document Shepherd
to validate sections of the document written in a formal language, such as
XML code, BNF rules, MIB definitions, etc.

    None relevant.

I’m working on the proto writeup for this doc and I notice I didn’t see any response to Charles.
Appendix B is now gone so that comment is moot, but what about his comment on the Abstract?


From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com]
Sent: Monday, November 10, 2014 1:04 PM
To: Dave Thaler; pcp@ietf.org
Subject: Re: [pcp] WGLC: draft-ietf-pcp-anycast-02 comments due by NOV 10

I have a couple editorial comments and a question.

Abstract
s/to their closest on-path NAT, Firewall, or other middlebox, …/to their closest on-path PCP aware NAT, Firewall, or other middle box, …

Appendix B.2.
s/first-hop router is also the NAT gateway/first-hop router is also a PCP aware NAT gateway

Appendix B.2 reads, "Since we posit that other network infrastructure does not need (and should not have) any special knowledge of PCP (or its anycast address) this means that to other non-NAT routers, the PCP anycast address will look like any other unicast destination address on the public Internet, and consequently the packet will be forwarded as for any other packet destined to the public Internet, until it reaches a NAT or firewall device that is aware of the PCP anycast address. “

My understanding is that a NAT that is not PCP aware will route the PCP request normally as well. This complicates matters but is not insurmountable. Is that discussed somewhere, in which case a reference should be added?

Cheers,
Charles