Subject: [pcp] feedback on security considerations

From: "Dan Wing" <[email-masked]>
Date: Thu, 17 Feb 2011 10:10:59 -0800

Please provide feedback on the re-written security considerations section, 
below, which is planned for inclusion in the upcoming pcp-base-05.

Two notes, related to changes in the upcoming -05 that are reflected in 
the Security Considerations text you will review below:
  * In -05, the THIRD_PARTY option will be removed and internal-ip-address
    (Target IP address) will be in the MAP message itself.  This restores
    the location of the internal address as with previous versions of
    pcp-base.
  * While editing -05, I found the text was simplified by using "Target 
    IP Address" to refer to the internal host that will receive incoming 
    packets that are mapped.  You will notice Target Address and Target 
    IP Address used below.  

-d

-----

12.  Security Considerations

   The PCP client's source port SHOULD be randomly generated [RFC6056].
   The PCP server MUST only listen for requests from its internal
   interfaces, and MUST NOT listen for requests on its Internet-facing
   interfaces.

   This document defines Port Control Protocol and two types of OpCodes,
   PEER and MAP.  The PEER OpCode allows querying and extending (if
   permitted) the lifetime of an existing implicit dynamic mapping, so a
   host can reduce its keepalive messages.  The MAP OpCode allows
   creating a mapping so a host can receive incoming unsolicited
   connections from the Internet in order to run a server.

   The PEER OpCode does not introduce any new security considerations.

   On today's Internet, ISPs do not typically filter incoming traffic
   for their subscribers.  However, when an ISP introduces stateful
   address sharing with a NAPT device, such filtering will occur as a
   side effect.  Filtering will also occur with IPv6 CPE
   [I-D.ietf-v6ops-cpe-simple-security].  The MAP OpCode allows a PCP
   client to create a mapping so that a host can receive inbound traffic
   and operate a server.  Security considerations for the MAP OpCode are
   described in the following sections.

12.1.  Denial of Service

   Because the state created in a NAPT or firewall, a per-subscriber
   quota will likely exist for both implicit dynamic mappings (e.g.,
   outgoing TCP connections) and explicit dynamic mappings (PCP).  A
   subscriber might make an excessive number of implicit or explicit
   dynamic mappings, consuming an inordinate number of ports, causing a
   denial of service to other subscribers.  Thus, it is RECOMMENDED that
   subscribers be limited to a reasonable number of explicit dynamic
   mappings.

      Note: this is similar to guidance for implicit dynamic mappings
      [I-D.ietf-behave-lsn-requirements]).

12.2.  Ingress Filtering

   It is important to prevent a subscriber from creating a mapping for
   another subscriber, because this allows incoming packets from the
   Internet and consumes the other user's mapping quota.  Both implicit
   dynamic mappings (e.g., outgoing TCP connections) and explicit
   dynamic mappings (PCP) need ingress filtering [RFC2827].

   Ingress filtering MUST be performed by the edge router or aggregation
   router to drop packets which have a source address not belonging to
   the subscriber.  Ingress filtering prevents the source IP address of
   a PCP message from being spoofed.

12.3.  Validating Target Address

   The MAP OpCode contains a Target Address field, which allows a PCP
   client to create an explicit dynamic mapping for another host.  This
   is called a "third party mapping" and is used in specific cases.

   A PCP server implemented in a customer premise router MUST generate
   an UNAUTH_TARGET_ADDRESS response if it receives a PCP MCP request
   with a Target Address that does not match the source IP address of
   that request.  This is because third party mappings using PCP within
   a subscriber's home network are prohibited.  If such a mapping is
   desired, the user needs to interact out-of-band with their customer
   premise router to create a third party mapping (e.g., using its
   administrative interface).

   In contrast, a PCP server implemented outside of a customer premise
   router, such as by a service provider, does allow third party
   mappings.  However, a third party mapping can only be performed by
   the subscriber's customer premise router and only to devices
   belonging to the same subscriber.  The end result is that hosts
   within the customer premise can only create mappings for themselves,
   and administrative access to the customer premise router is required
   to create mappings for other hosts within the home.

   To enforce these restrictions, the PCP server needs certain knowledge
   about the network's subscribers.  It needs to determine the IP
   address of the subscriber's customer premise router and to determine
   the IP subnet assigned to the subscriber.  This knowledge might be
   dynamic (e.g., database query into the service provider's user
   database for every incoming PCP request), might be a table (e.g.,
   subscribers with a certain IPv4 network prefix all have an IPv4 /24,
   other IPv4 prefixes have an IPv4 /32, certain IPv6 prefixes have an
   have an IPv6 /32, and so on), or might be very static (e.g., all
   subscribers have one IPv4 address).  If there are multiple addresses
   assigned to a subscriber, the PCP server allows the highest-numbered
   address to perform third party mappings.  On a network supporting PCP
   with multiple addresses assigned to a subscriber, the highest-
   numbered host SHOULD be the subscriber's customer premise router.

   Upon receiving a MAP request where the Target Address does not match
   the source IP address of the request, the PCP server determines if
   the source IP address of the request is the subscriber's highest
   numbered address, following the procedure in the previous paragraph.
   If not, the PCP server MUST generate an UNAUTH_SOURCE_ADDRESS error.
   Then the PCP server determines if the Target Address belongs to the
   same subscriber as the source IP address of the PCP packet, using the
   procedure described in the previous paragraph.  If not, the PCP
   server MUST generate an UNAUTH_TARGET_ADDRESS error.