Re: [pcp] strengthening PCP with Mapping Nonce

["Zhangzongjian (Thomas)" <[e-mail]>]

Dear wing


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Dan
> Wing
> Sent: Saturday, August 18, 2012 8:51 AM
> To: [e-mail]
> Cc: 'Stuart Cheshire'
> Subject: [pcp] strengthening PCP with Mapping Nonce
> 
> We incorporated changes to draft-ietf-behave-pcp-base from IESG review.
> 
> After reading the PCP restrictions in REQ-9-A through E in
> draft-ietf-behave-lsn-requirements-09 (copied below for reference), we had a
> productive phone call this week between Stuart Cheshire, Simon Perreault,
> Sam Hartman, and myself.  During that discussion, we found a way to
> strengthen security of PCP against a specific attack and hopefully soften
> some of the restrictions in both draft-ietf-behave-lsn-requirements (REQ-9-A
> through E) and draft-ietf-pcp-base for the PCP Basic Threat Model, when PCP
> is not using authentication.
> 
> To achieve this, we need to improve how draft-ietf-pcp-base handles Mapping
> Nonce values.  Currently, draft-ietf-pcp-base is pretty silent on how and
> when the PCP client chooses its Mapping Nonce value, and says this about
> server processing, which sort of implies the PCP client is free to change
> the Mapping Nonce value whenever it likes,
> http://tools.ietf.org/html/draft-ietf-pcp-base-26#section-11.3,
> 
>    The PCP server only needs to remember one Mapping Nonce value for
>    each mapping (that is, the most recent Mapping Nonce value overwrites
>    the previous Mapping Nonce value).
> 
> We would replace the above text with something like:
> 
>    If the Internal port, Protocol, and Internal Address match an
>    existing explicit dynamic mapping, but the Mapping Nonce does not
>    match, the request MUST be rejected with a NOT_AUTHORIZED error with
>    the Lifetime of the error indicating duration of that existing
>    mapping.  The PCP server only needs to remember one Mapping Nonce
>    value for each explicit dynamic mapping.
> 
> with this change (and corresponding text for the PCP client's generation of
> a Mapping Nonce, and corresponding text for PEER), we avoid the attack
> described in detail below.
> 
> 
> Attack:  The attack is a traffic-stealing attack.  The diagram below may
> help with the textual description.  The attack scenario is where there is a
> CGN running PCP and a home NAT not running PCP, and two hosts on separate
> networks behind the same home NAT.  The hosts are on separate networks.
> One
> host is running a server (the victim) on the wired network, the other host
> is the attacker on the guest Wi-Fi network.  The host running the server has
> a mapping created in the NAT, which was created with UPnP IGD or created
> manually, and has a PCP-created mapping in the CGN.  The attacker uses
> UPnP
> IGD, NAT-PMP, STUN (RFC5389), or STUNT
> (http://nutss.gforge.cis.cornell.edu/stunt.php) to create a mapping in the
> home NAT and learn the home NAT's "WAN" address.  The attacker
> formulates a
> PCP MAP request with the NAT's WAN address in the PCP Client IP Address
> field, Lifetime=0, and sends that to the CGN, deleting the CGN's existing
> mapping that goes to the victim machine.  That attack packet is sent without
Thomas=>
Why does not the home NAT use the third party option? 
When home NAT receives a PCP MAP request with lifetime=0 from attacker, it should add a third party option with the attacker's IP address in this option. When CGN gets the PCP request, it will use the third party option address as the source address to search the MAP entries. Then the attacker can't delete the MAP entry created by victim.


> address spoofing.  120 seconds later (per REQ-8 of
> draft-ietf-behave-lsn-requirements-09), the attacker sends a new PCP MAP
> request to try to acquire the (old) mapping of the victim host.  In this
> way, the attacker steals incoming traffic intended to go to the victim host.
> 
> 
> Diagram:
> 
>                   +-------------+    +----------+
>   attacker -------+             |    |          |
>   (guest network) |             |    |          |
>                   |   home NAT  +----+    CGN   +----{Internet}
>   victim ---------+(without PCP)|    |(with PCP)|
>   (wired network) |             |    |          |
>                   +-------------+    +----------+
> 
> 
> Please provide us feedback.  I expect to publish -27 soon with these
> changes, but we are doing some text coordination before publishing -27.
> 
> -d
> 
> -----
> 
>    REQ-9:  A CGN MUST implement a protocol giving subscribers explicit
>            control over NAT mappings.  That protocol SHOULD be the Port
>            Control Protocol [I-D.ietf-pcp-base], in which case the PCP
>            server MUST obey the following constraints on its behavior:
> 
>            A.  It MUST NOT permit the lifetime of a mapping to be
>                reduced beyond its current life or be set to zero
>                (deleted).
> 
>            B.  It MUST NOT permit a NAT mapping to be created with a
>                lifetime less than the lifetime used for implicit
>                mappings.
> 
>            C.  It MUST NOT support the THIRD_PARTY option except for
>                requests received from "trusted" sources where it is
>                impractical for those sources to be spoofed.
> 
>            D.  The MAP opcode MAY be permitted if the recommendation
> of
>                endpoint independent filtering behavior described in
>                REQ-7 is adopted; the map opcode MUST NOT be permitted
> in
>                other circumstances.  These constraints MAY be relaxed if
>                a security mechanism consistent with PCP's Advanced
>                Threat Model (see Section 17.2 of [I-D.ietf-pcp-base]) is
>                used; this is expected to be rare for CGN deployments.
> 
>            E.  Mappings created by PCP MUST follow the same deallocation
>                behavior (REQ-8) as implicitly mapped traffic.
> 
> 
> _______________________________________________
> pcp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pcp

Best regards
Thomas