Subject: [pcp] Comments on draft-cui-pcp-subscriber-identification-00

From: Dave Thaler <[email-masked]>
Date: Sun, 7 Nov 2010 23:58:02 +0000

General comment:
I think this document provides an interesting security analysis of PCP.
That is the primary value of the document right now, it's not just
about subscriber identification per se.

Section 1:
> It's very easy to
> create a fake IP address in many cases, so PCP server could not
> differentiate between legitimate requests and fake requests.  

I'd expect that most of the time an organization deploying a PCP
server would want to do source ingress filtering from customers.
Suggest saying this and referencing BCP38.

Section 2.1:
>   Section 11.4 of PCP recommends IPv6 source address validation to
>   protect against creating unwanted mappings.  However, an adversary
>   can flood the PCP requests with bogus source address, which satisfies
>   the validation rules, to cause DoS attacks exhausting mapping
>   resources.  PCP server will allocate mappings for these illegal
>   requests.  The limited mapping resources will soon be exhausted,
>   causing legitimate subscribers not having available resources.

You don't need a "bogus" source address to do the attack, it could be
done with valid ones.  Secondly, see draft-ietf-behave-lsn-requirements
and in particular REQ-2 (c) regarding whether the PCP server will allocate
an arbitrarily large number of mappings.

Section 2.3:
> An adversary may try to eavesdrop  and collect PCP requests.

This requires the attacker to be on-path.  What scenario are we worried
about here?

Section 3.2:
Currently entitled "Random number" but should really be called
"Return Routability Test".

Section 3.3:
This section uses the term "safe tunnel" and uses TLS as an example.
TLS isn't a tunnel.  Suggest changing "safe tunnel" to "secure channel".

Section 3.4:
> The digit signature method suggests that PCP request and response
> messages should have an extended IE including digitally signed  random
> number.

s/digit/digital/  (also in section heading)

However, when it says "signed", I don't understand what this is talking
about.  Signed by what key?  How would such a key get configured or 
exchanged?  I couldn't follow this section.

-Dave