Subject: [pcp] [Sam Hartman] draft-ietf-pcp-base-27: objection to security considerations change; ietf last call requested

From: Sam Hartman <[email-masked]>
Date: Mon, 24 Sep 2012 20:10:09 -0400

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

Subject: draft-ietf-pcp-base-27: objection to security considerations change; ietf last call requested
From: Sam Hartman <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Date: Sun, 23 Sep 2012 14:37:56 -0400

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.

---

From: Simon Perreault <[email-masked]>
Date: Tue, 25 Sep 2012 09:06:07 -0400

Here's an easy fix idea: an unauthenticated delete (with matching nonce) 
would do the equivalent of a TCP RST (with matching sequence number). 
That is, it would reduce the mapping's lifetime to what a TCP RST would 
reduce it to (which depends on the implementation but usually is not zero).

In fact, the TCP RST lifetime would become sort of a floor lifetime 
below which mappings cannot be reduced. Once a mapping has attained this 
lifetime, all that can be done is either increase the lifetime or wait 
for the mapping to expire.

That way, unauthenticated delete would still be useful while also 
preserving current NAT behaviour and thus eliminating this class of attacks.

Simon

-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Simon Perreault <[email-masked]>
Date: Tue, 25 Sep 2012 09:26:33 -0400

Le 2012-09-25 09:16, Sam Hartman a écrit :
>      Simon> Here's an easy fix idea: an unauthenticated delete (with
>      Simon> matching nonce) would do the equivalent of a TCP RST (with
>      Simon> matching sequence number). That is, it would reduce the
>      Simon> mapping's lifetime to what a TCP RST would reduce it to
>      Simon> (which depends on the implementation but usually is not
>      Simon> zero).
>
> First, this clearly only works for TCP.

The same behaviour can be specified no matter what the transport 
protocol is.

> However, in my situation, could H2 actually send a TCP RST?  The mapping
> at N2 is to H1 not to H2.  While H2 can appear to be from the same
> address as H1 from the vantage of N1, it cannot use the same ports.

That is besides the point. My point is that RST spoofing is a well-known 
attack that current NATs know how to deal with, and I'm proposing that 
the same mitigation technique could be applied to the PCP attack you 
described.

Simon

---

From: Sam Hartman <[email-masked]>
Date: Tue, 25 Sep 2012 09:16:20 -0400

>>>>> "Simon" == Simon Perreault <[email-masked]> writes:

So, I still believe that PCP creates new attacks.

---

From: Simon Perreault <[email-masked]>
Date: Tue, 25 Sep 2012 09:33:36 -0400

> This is the kind of attack that looks hard until someone has it working,

Another thought: once H2 deletes the mapping, the external port will be 
unusable for 120 seconds. See the last paragraph of section 15:

    To reduce unwanted traffic and data corruption, External UDP and TCP
    ports created by the MAP Opcode or PEER Opcode SHOULD NOT be re-used
    for the same interval enforced by NAT for implicitly creating
    mappings, which is typically the maximum segment lifetime interval of
    120 seconds [RFC0793].

IMHO this needs to be mentioned as it can make the attack much harder to 
accomplish.

Simon

---

From: Sam Hartman <[email-masked]>
Date: Tue, 25 Sep 2012 09:36:38 -0400

>> However, in my situation, could H2 actually send a TCP RST?  The
    >> mapping at N2 is to H1 not to H2.  While H2 can appear to be from
    >> the same address as H1 from the vantage of N1, it cannot use the
    >> same ports.

    Simon> That is besides the point. My point is that RST spoofing is a
    Simon> well-known attack that current NATs know how to deal with,
    Simon> and I'm proposing that the same mitigation technique could be
    Simon> applied to the PCP attack you described.

I agree the mittigation technique  you describe makes things bettter.
However we're still in a situation  where deploying PCP decreases
security.

I'm happy with that situation  if we have a mandatory-to-implement
security mechanism but not otherwise.

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 25 Sep 2012 07:19:24 -0700

Simon Perreault wrote:
> mapping

That mitigation is already in pcp-base-27 (and was in earlier versions,
but not nearly as clear).  pcp-base-27 says:

   15.2. Lifetime Processing for the PEER Opcode

   The assigned lifetime MUST NOT be shorter than the lifetime the PCP-
   controlled device uses for an implicitly-created mapping with active
   bi-directional traffic (e.g., a NAT device might use 2-5 minutes for
   UDP [RFC4787], and might use 2 hours 4 minutes [RFC5382] for
   established TCP sessions).  If the Requested Lifetime is outside that
   range, the mapping lifetime is assigned to the value within the
   range.

-d

---

From: Simon Perreault <[email-masked]>
Date: Tue, 25 Sep 2012 10:30:53 -0400

>     range, the mapping lifetime is assigned to the value within the

Right, but that's for PEER only. Sam said the attacker could use either 
MAP or PEER.

Simon

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 25 Sep 2012 07:55:05 -0700

> -----Original Message-----
> From: Simon Perreault [mailto:[email-masked]]
> Sent: Tuesday, September 25, 2012 7:31 AM
> To: Dan Wing
> Cc: 'Sam Hartman'; [email-masked]
> Subject: Re: [pcp] [Sam Hartman] draft-ietf-pcp-base-27: objection to
> security considerations change; ietf last call requested
> 
> Right, but that's for PEER only.

Correct.

> Sam said the attacker could use either MAP or PEER.

I have not understood Sam's new attack with MAP.

-d