Subject: Re: [pcp] WGLC: draft-ietf-pcp-anycast-02 comments due by NOV 10

From: 🔓Dan Wing <[email-masked]>
Date: Tue, 4 Nov 2014 00:54:59 -0800

On Oct 30, 2014, at 1:33 AM, Markus Stenberg <[email-masked]> wrote:

> On 27.10.2014, at 22.23, Dave Thaler <[email-masked]> wrote:
>> This email initiates a Working Group Last Call on : draft-ietf-pcp-anycast-02 to conclude on
>> Monday, November 10th at the PCP WG meeting in Honolulu.  Please send comments to the list.
>> 
>> As a reminder, when responding to a WGLC, what we chairs are looking for is a statement about
>> document quality (not really about whether the mechanism should move forward).  That is,
>> state whether you think the document is ready as is, or if not, what issues you see.
> 
> I think the document (and the mechanism) is mostly fine and needed.
> 
> What I am wondering about is security considerations section; given implementations not aware of this draft, a host on the inner side can also advertise the anycast address, and potentially get traffic meant for first-hop PCP server. Given the scheme defined in section 2.1 (SHOULD use first-hop first), it is possible, although not probable. But still, I would say the same problem is both on local network(s) _and_ on the other side of the firewall.

I agree such an attack would work if the PCP client (or the router) listen to a routing protocol and the attacker advertises the PCP anycast address's network using that routing protocol.  But on the local network the PCP client won't ARP for an address beyond its own subnet, so the attack seems limited to where a routing protocol is being used?

> (It could also state that finding (platform independently) next-hop gateway programmatically can be hard for pure ‘applications’ sometimes, but I wonder if this is too much detail.

Earlier in PCP's development I recall some sample code was rolling around for how to find first-hop gateway on several OSs.

> But if app just chose anycast address, the above SHOULD would not be followed and the security considerations problems would be more severe.)
> 
> Also.. Is there actually defined mechanism to redirect or provide list of PCP servers that is mentioned in the introduction?

There isn't; that sentence should be removed.

-d

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 10 Nov 2014 21:03:59 +0000

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

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Monday, October 27, 2014 at 12:23 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [pcp] WGLC: draft-ietf-pcp-anycast-02 comments due by NOV 10

Thanks,

-Dave