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

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

Hi Dan -

Yes, we should go with options c) and d)

Few comments

a)If a flow is created which matched the PCP request (MAP/PEER request)
If H2 tries to delete MAP, should it be permitted because a flow still exists ?
Would the security attack be prevented if only H2 is permitted to delete MAP only after all the sessions associated with the MAP/PEER request are closed ?
For TCP flows N1 could have a TCP state machine to detect when the flow is closed/terminated. 

2) For UDP in addition to d) and client H1 will anyhow will have to send keep lives to keep the NAT bindings alive (since it is not PCP-aware and will have to use technique like RFC 6263) 

3) Since anyway N2 does not support PCP, it can block PCP using simple port-based ACL. Legitimate hosts may not even have an application that would work in this case (let's say use UPnP with N2 and PCP with N1) ? 

--Tiru.

> -----Original Message-----
> From: Dan Wing (dwing)
> Sent: Friday, September 28, 2012 10:27 AM
> To: 'Sam Hartman'; [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: Re: [pcp] draft-ietf-pcp-base-27: objection to security
> considerations change; ietf last call requested
> 
> 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
> 
>