Telechat Review of draft-ietf-pcp-anycast-07

Request Review of draft-ietf-pcp-anycast
Requested rev. no specific revision (document currently at 08)
Type Telechat Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2015-09-15
Requested 2015-08-27
Authors Sebastian Kiesel, Reinaldo Penno
Draft last updated 2015-12-14
Completed reviews Genart Last Call review of -06 by Robert Sparks (diff)
Genart Telechat review of -07 by Robert Sparks (diff)
Secdir Last Call review of -06 by Yoav Nir (diff)
Secdir Telechat review of -07 by Yoav Nir (diff)
Assignment Reviewer Robert Sparks
State Completed
Review review-ietf-pcp-anycast-07-genart-telechat-sparks-2015-12-14
Reviewed rev. 07 (document currently at 08)
Review result Ready
Review completed: 2015-12-14


I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at


Document: draft-ietf-pcp-anycast-07
Reviewer: Robert Sparks
Review Date: 14 Sep 2015
IETF LC End Date: past
IESG Telechat date: 17 Sep 2015

Summary: On the right track, but has issues that should be discussed

I can't find any response to the LC review provided below. Apologies if 

I'm just failing to find or remember a thread...

Reviewing the diff between -06 and -07, I see some text in the 

introduction that

touches point 1. I think, however, it would be good to have something 

more strongly


There's also new text in 5.2 that looks like it's targeting point 4, and 

I think it's sufficient.

The other points do not appear to be addressed.


On 6/4/15 2:20 PM, Robert Sparks wrote:

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at


Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-pcp-anycast-06
Reviewer: Robert Sparks
Review Date: 04Jun15
IETF LC End Date: 11Jun15
IESG Telechat date: Not yet scheduled

Summary: On the right track, but has issues that should be discussed

This draft reads easily, but there are a few things that might need 

more attention.

It could be that these have been beaten to death already, but if so, 

it would be better if the document gave pointers to places where 

others with the questions wouldn't be left wondering.


1) The document recommends hard-coding these addresses into 

applications. In the spirit (at least) of BCP 105 (RFC4085), shouldn't 

the recommendation be more "have their configuration set by default to 

this well known value"?

2) Section 3 punts on some really hard things that deserve more 

discussion in this document, or this document should point to a good 

discussion elsewhere. It's fine that the document doesn't solve the 

synchronization or coordination problems it hints at, but it should 

make it more clear that these problems will exist, and are important 

to consider when deploying a new node that joins this anycast address. 

In particular, without careful synchronization and coordination, 

applications like VoIP using PCP controlled resources will be 

disrupted. The current text really does not convey that message.

3) Aren't there some new security issues with just having the 

well-known address? At a minimum, it's an attractive target, and the 

guidance in 18.3.1 of RFC6887 may be particularly relevant. More 

subtly, would it make it easier to construct packets that look enough 

like PCP to be disruptive to send from compromised nodes participating 

in a DDos Attack from inside an administrative domain? Would it make 

it easier for an attacker that has partially compromised a host 

influence the firewall between him and that host, making finishing the 

compromise even easier? (Especially compared to a PCP server that was 

configured at the client that wasn't just the default router).

4) It would help to expand on the 3rd paragraph of section 5.2. In 

very simple scenarios (like having a home router start responding to 

this address), it's easy to see the tradeoffs between automatic 

configuration and securing the pcp commands. But it would help if the 

document talked through the consequences of not using 

pcp-authentication in more complex environments (using something like 

a departmentalized university, or several distinct administrative 

domains behind a common CGN as an example perhaps?)