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

["Dan Wing" <[e-mail]>]

Sam, PCP working group,

> -----Original Message-----
> From: Sam Hartman [mailto:[e-mail]]
> Sent: Sunday, September 23, 2012 11:38 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: draft-ietf-pcp-base-27: objection to security considerations
> change; ietf last call requested
> 
> 
> 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.


Thanks for describing this attack.

Given the same scenario -- namely, a victim not using PCP and an attacker
using PCP -- how would PCP authentication prevent the attack?  The only
way I see is if the attacker lacks authorization to create mappings or lacks
authorization to delete mappings.  


I have enumerated the mitigations discussed so far and provided 
my analysis of each.  I hopes will foster further technical 
discussion:

  a. Require PCP authentication.

     Requires attacker to lack authorization to create a mapping or
     lack authorization to delete a mapping.

     Analysis:  May not be useful for preventing such an attack on
     CGN, because PCP authentication is likely rare for CGN
     deployments, according to REQ-9-D of
     draft-ietf-behave-lsn-requirements.


  b. Prohibit reducing lifetime of a mapping.

     That is, revert to draft-pcp-base-26.

     Analysis:  Prevents the described attack.  However, this can
     create a denial of service for a normal PCP that is making a
     bunch of PCP mappings -- the PCP client can consume all of its
     mappings with no way to remove them.  This harms successful
     use of PCP.  We can mitigate this harm by strongly suggesting
     large port quotas, allowing un-acknowledged TCP RST to 
     shortcut this prohibition, or separate suggesting separate 
     port quota space for PCP-created mappings and implicit
     mappings (so PCP cannot consume all of the port quota).

     Note: the specific text in the Security Considerations of
           pcp-base-26, which has been there for many versions, only
           prohibited shortening PEER mappings.  Based on the
           description of the attack above and the text in REQ-9 of
           draft-ietf-behave-lsn-requirements, draft-ietf-pcp-base
           needs to worry about both MAP and PEER mappings.


  c. Prevent same internal host from acquiring same external port.

     After a port is mapped using PCP, prevent the same internal IP
     address from remapping that same external port to a different
     internal port for a period of time.  Allow a different internal
     IP address to map that same external port.

     Analysis:  Prevents the described attack.  This solution is
     superior to (b), because it does not harm the user's port quota.
     After the PCP client issues a Delete, the port can be allocated
     to a different internal host.  An attacking host would need a
     more sophisticated attack, specifically it would need to
     coordinate with another attacking host behind the same PCP-
     speaking NAT (that is, the two attacking hosts would need to be
     in different NATted homes and both homes are behind the same
     PCP-speaking CGN).


  d. Do not immediately delete mappings created by MAP or PEER.

     Instead, only allow the lifetime to be reduced to a few minutes.
     For TCP, suggested value RFC5382's "transitory connection idle-
     timeout" of 4 minutes; for UDP, RFC4787's 2 minutes.

     Analysis:  Forces attacker to wait longer before the attacker can
     re-map the port to themselves.  Attack will fail if victim host
     sends traffic during the 4 (TCP) or 2 (UDP) minutes.

-d