Re: [pcp] strengthening PCP with Mapping Nonce

[Sam Hartman <[e-mail]>]

Hi.
Margaret Wasserman and I got together for about 1.5 hours to look at the
security implications of this proposal.
I've been pondering it since that meeting.

I believe that this proposal does improve the PCP protocol.
In  particular once we have a widely implemented security mechanism, a
proposal like this could help give deployers a better set of options
under the advanced threat model.
That is, people who do need a security mechanism could turn it
on. More people would find PCP met their security needs with  the nonce
mapping change than without it even if those people did not turn on a
security mechanism.

However, Margaret and I found that this change did not remove several of
the attacks that most concern us  when a security mechanism is not used.
So, I'm strongly against the idea of relaxing the restrictions in
section 17.1 of the  base specification even if this proposal is
adopted.

>From a process standpoint, I think several people in the security
community (myself included) supported the draft because of the
compromise we reached in the simple threat model. I think we'd need to
open up the document to fairly wide review if we changed those
restrictions to seek a new security balance. I think that would add
significant delay. I'd rather see us publish the base spec with as few
changes as possible and move on with the authentication work.  In that
document or a future document we can update security restrictions if we
gain consensus to do so.

Beyond the process issues, I continue to support the technical direction
of the simple thread model.

The most serious attacks are present when there are multiple layers of
NAT involved and the outer-most NAT has a PCP server.  PCP or some other
NAT control protocol really assists the attacker in that situation.  At
least with PCP we've thought through the security implications and we've
given recommendations.  Other NAT control protocols are worse than PCP
in their security impact on the Internet.
(I don't consider this justification for weakening the simple threat
model: when we standardize things in the IETF, we often find we're
considering security implications that pre-standardization efforts
didn't consider. That's part of our value add)

Even creating a very long-lived mapping in the PCP NAT can assist an
attacker. If there is  a longer-lived outer mapping, it can assist an
attacker behind the inner NAT in capturing traffic when the inner
mapping (but not outer mapping) expires.
These attacks are somewhat complex to analyze because you have to assume
things about application behavior.
That's one of the reasons we want a very conservative stance prior to
having a mandatory to implement security mechanism.

Being able to create a mapping can also be valuable in capturing
traffic.

A and B are behind the same two nats, N1 and N2. N1, the inner NAT does
not  support PCP; N2, the outer NAT does.

A is about to contact C.  Note that from the prospective of N2, B and A
have the same source address. So, B can create mappings on A's behalf if
it can guess the port A will use.  There are a number of cases where
this is probable, especially if you consider that B can create multiple
mappings.


So, B creates a mapping that A will happen to use. B is an attacker; it
can easily deal with PCP through an inner NAT. A, even if it does
support PCP probably will not choose to use it through N1.

Later as A's session is in progress, B deletes its mapping and attempts
to create a new mapping that will reuse the same external port on N2.

Obviously several factors affect this: N2's port allocation strategy,
the application characteristics, etc etc.  It's easy to decide that the
attack is too difficult in practice.  Unfortunately, people tend to find
ways to exploit resource allocation strategies, mount timing attacks,
etc in order to mount such attacks.  Once the attack has been scripted
in a convenient tool and argument that the attack is difficult to mount
holds little weight.

Yes, there are doubtless environments where being concerned with these
attacks is not necessary.  I strongly support moving as fast as we can
to a point where we have a security mechanism and we can give customers
the choice to either use the security mechanism or turn off restrictions
required by the simple threat model.  I do not support relaxing the
simple threat model to get there.  I do not support delaying the PCP
base spec significantly at this point in the process.