I noticed that  my original message never seems to have hit the list.
Let's see if this goes better.

--- Begin Message ---

Hi.
draft-ietf-pcp-base-27 relaxes restrictions in the simple threat model
(section 18.1).
In particular, it permits the lifetime of a mapping to be reduced or a
mapping to be deleted.

I understand that reducing the lifetime of mappings is useful, and think
that  many deployments that implement a security mechanism (and thus
fall under the advanced threat model) will choose to have a relaxed
authorization policy about deleting mappings.
I think the mapping nonce changes introduced in pcp-base-27 will help
make that possible.

However, for the simple threat model our goal is not to decrease the
security of the Internet by deploying a PCP server.
We fail to accomplish that.

Here's an example of an attack where enabling PCP decreases the security
of a network.

N1 is a NAT with PCP capability.

N2 is a NAT without PCP capability.

H1 and H2 are hosts behind N2.; N2 is behind N1.
That is, the path from H1 or H2 to the Internet looks like
{H1,H2}->N2->N1.

> From the standpoint of N1, H1 and H2 have the same internal address.
That permits H1 and H2 to create mappings on each others' behalf.
However, H1 and H2 cannot spoof each others' IP addresses from the
standpoint of N2. For example, H1 and H2 might be on different internal
subnets or address spoofing prevention may be in use.

H1 is a host  that either does not support PCP or follows the spec
recommendation  not to use PCP through a NAT that does not support PCP.

H2 would like to capture H1's traffic.
H2 guesses that  some traffic will be sent from  H1 towards x. H2
guesses that port P will be used as the external port on N2 (the
internal port from N1's standpoint).
So, N1 will see traffic from <N2, P> towards x.
Before H1 sends this traffic, H2 requests a PCP mapping for <N2,P>; it
could use either the map or peer opcode.
This traffic is mapped to appear to come from <N1, Q>.

Later, H2 wants to capture the reply traffic; because H2 created the
mapping, H2 knows the mapping nonce and can delete the mapping.

Now, H2 needs to convince N1 to allocate Q  such that traffic to <N1,Q>
will eventually make its way to H2.
That depends on attacking N1's port allocation algorithm. This is
probably not an attack H2 can mount with 100% chance of success.
However by using multiple mappings to amplify the attack, trying to
exploit any races in N1, etc.
This is the kind of attack that looks hard until someone has it working,
then becomes very easy.

If N1 disables PCP, the attack is impossible if H1 sends traffic often
enough to keep the mapping alive.
This is just one attack I found while not looking very hard.
I don't have time to perform detailed security analysis on this change,
but I have fairly high confidence that it does introduce harm. I suspect
that if we look we'll find other attacks.

If I end up in the rough within the working group and we send this
change to the IESG, I believe a new IETF last call is
required. Typically a protocol like PCP would be required to have a
mandatory-to-implement security mechanism according to BCP 61. We have
tried to strike a compromise to permit PCP to move forward more quickly
than the security mechanism work. Many people have reviewed PCP; this
has been discussed widely in the security community and elsewhere.  If
the working group is going to change this compromise after IESG review,
the IETF needs to be given a change to re-review and to suggest
balancing changes and debate questions like whether PCP should be
required to have a BCP 61 security mechanism.

--- End Message ---