[pcp] strengthening PCP with Mapping Nonce

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

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
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.