[pcp] Genart LC review: draft-ietf-pcp-anycast-06

[Robert Sparks <[e-mail]>]

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

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

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.

Issues:

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