Subject: Re: [pcp] #52: More security considerations

From: Margaret Wasserman <[email-masked]>
Date: Tue, 26 Jul 2011 02:56:13 -0400

Hi All,

As I promised in my previous message to the list, I have proposed
new text for the Security Considerations section in the PCP Base 
Spec below.  This is my suggested text to address open issue #52.  

Comments and feedback will be appreciated!

Margaret

---

13 Security Considerations

The goal of the PCP protocol is to improve the ability of end nodes to
control their associated NAT state, and to improve the efficiency and
error handling of NAT mappings when compared to existing implicit
mapping mechanisms in NAT boxes and stateful firewalls.  It is the
security goal of the PCP protocol to limit any new denial of service
opportunities, and to avoid introducing new attacks that can result in
unauthorized changes to mapping state.  One of the most serious
consequences of unauthorized changes in mapping state is traffic
theft.  All mappings that could be created by a specific host using
implicit mapping mechanisms are inherently considered to be
authorized.  Confidentiality of mappings is not a requirement, even in
cases where the PCP messages may transit paths that would not be
travelled by the mapped traffic.

13.2 Simple Threat Model

Current protocol is secure against off-path attackers who cannot spoof
a packet that the PCP Server will view as a packet received from the
internal network.

Defending against attackers who can modify or drop packets between the
internal network and the PCP server, or who can inject spoofed packets
that appear to come from the internal network is out-of-scope.

A PCP Server is secure under this threat model if the PCP Server is
constrained so that it does not configure any explicit mapping that it
would not configure implicitly.  In most cases, this means that PCP
Servers running on NAT boxes or stateful firewalls that support the
PEER4 and PEER6 OpCodes can be secure under this threat model if all
of their hosts are within a single administrative domain (or if the
internal hosts can be securely partitioned into separate
administrative domains, as in the DS-Lite B4 case), explicit mappings
are created with the same lifetime as implicit mappings, the PCP
server does not support deleting or reducing the lifetime of existing
mappings, and the PCP server does not support the third party option.
PCP Servers can also securely support the MAP4 and MAP6 OpCodes under
this threat model if the security policy on the device running the PCP
Server would permit endpoint independent filtering of implicit
mappings.

PCP Servers that comply with the Simple Threat Model and do not
implement the PCP Security mechanism described in section 13.2 MUST
enforce the constraints described in the paragraph above.

[Side Note: If on-path attackers being able to delete existing
mappings is an acceptable risk, delete operations could be securely
supported if the PEER4/PEER6 and MAP4/MAP6 responses included a cookie
value that was stored on the client and server, and the cookie value
was provided in subsequent delete requests.]

13.1.1 Attacks Considered

- If you allow multiple administrative domains to send PCP requests to
  a single PCP server that does not enforce a boundary between the
  domains, it is possible for a node in one domain to perform a denial
  of service attack on other domains, or to capture traffic that is
  intended for a node in another domain.

- If explicit mappings have longer lifetimes than implicit mappings,
  it makes it easier to perpetrate a denial of service attack than it
  would be if the PCP Server was not present.

- If the PCP Server supports deleting or reducing the lifetime of
  existing mappings, this allows an attacking node to steal an
  existing mapping and receive traffic that was intended for another
  node.

- If the THIRD_PARTY option is supported, this also allows an attacker
  to open a window for an external node to attack an internal node,
  allows an attacker to steal traffic that was intended for another
  node, or may facilitate a denial of service attack.  One example of
  how the THIRD_PARTY option could grant an attacker more capability
  than a spoofed implicit mapping is that the PCP server (especially
  if it is running in a service provider's network) may not be aware
  of internal filtering that would prevent spoofing an equivalent
  implicit mapping, such as filtering between a guest and corporate
  network.

- If the MAP OpCodes are supported by the PCP server in cases where
  the security policy would not support endpoint independent filtering
  of implicit mappings, then the MAP OpCodes change the security
  properties of the device running the PCP Server by allowing explicit
  mappings that violate the security policy.

13.1.2 Deployment Examples Supporting the Simple Threat Model

This section offers two examples of how the Simple Threat Model can be
supported in real-world deployment scenarios.

13.1.2.1 Residential Gateway Deployment

Parity with many currently-deployed residential gateways can be
achieved using a PCP Server that is constrained as described in the
section 13.1 above.

13.1.2.2 DS-Lite Deployment

A DS-Lite deployment could be secure under the Simple Threat Model,
even if the B4 device makes PCP mapping requests on behalf of internal
clients using the THIRD_PARTY option.  In this case the DS-Lite PCP
server MUST be configured to only allow the B4 device to make
THIRD_PARTY requests, and only on behalf of other Internal Hosts
sharing the same DS-Lite IPv6 tunnel.  The B4 device MUST guard
against spoofed packets being injected into the IPv6 tunnel using the
B4 device's IPv4 source address, so the DS-Lite PCP Server can trust
that packets received over the DS-Lite IPv6 tunnel with the B4
device's source IPv4 address do in fact originate from the B4 device.
The B4 device is in a position to enforce this requirement, because it
is the DS-Lite IPv6 tunnel endpoint.

Allowing the B4 device to use the THIRD_PARTY option to create
mappings for hosts reached via the IPv6 tunnel terminated by the B4
device is acceptable, because the B4 device is capable of creating
these mappings implicitly and can prevent others from spoofing these
mappings.

DS-Lite's security policies may also permit use of the MAP4 and MAP6
opcodes.

13.2 Advanced Threat Model

The PCP protocol must be ensure that attackers (on- or off-path)
cannot create unauthorized mappings or make unauthorized changes to
existing mappings.  The protocol must also limit the opportunity for
on- or off-path attackers to perpetrate denial of service attacks.

This security model will be needed in the following cases:

- Security infrastructure equipment, such as corporate firewalls, that
  does not create implicit mappings.

- Equipment (such as CGNs or service provider firewalls) that serve
  multiple administrative domains and do not have a mechanism to
  securely partition traffic from those domains.

- Any implementation that wants to be more permissive in authorizing
  explicit mappings than it is in authorizing implicit mappings.

- Implementations that support the THIRD_PARTY option (unless they can
  meet the constraints outlined in section 13.1.2.2).

- Implementations that wish to support any deployment scenario that
  does not meet the constraints described in the section 13.1.

To protect against attacks under this threat model, PCP Servers must
implement the PCP Security mechanism [Normative Reference TBD].  This
mechanism needs to provide an authenticated, integrity-protected
channel that PCP clients and servers MAY use to exchange messages.
PCP Servers MUST allow configuration of which actions authenticated
clients are authorized to perform.

PCP Servers that implement the PCP Security mechanism MAY accept
unauthenticated requests.  PCP Servers implementing the PCP Security
mechanism MUST enforce the constraints described in the Simple Threat
Model section above, in their default configuration, when processing
unauthenticated requests.

13.3 Residual Threats

This section describes some threats that are not addressed in either
of the above threat models, and recommends appropriate mitigation
strategies.

13.3.1 Denial of Service

Because of the state created in a NAT or firewall, a per-host and/or
per-subscriber quota will likely exist for both implicit dynamic
mappings and explicit dynamic mappings.  A host might make an
excessive number of implicit or explicit dynamic mappings, consuming
an inordinate number of ports, causing a denial of service to other
hosts.  Thus, Section 12.2 recommends that hosts be limited to a
reasonable number of explicit dynamic mappings.

An attacker, on the path between the PCP client and PCP server, can
drop PCP requests, drop PCP responses, or spoof a PCP error, all of
which will effective deny service.  Through such actions, the PCP
client would not be aware the PCP server might have actually processed
the PCP request.

13.3.2 Ingress Filtering

It is important to prevent a host from fraudulently creating,
deleting, or refreshing a mapping (or filtering) for another host,
because this can expose the other host to unwanted traffic and
consumes the other host's mapping quota.  Both implicit and explicit
dynamic mappings are created based on the source IP address in the
packet, and hence depend on ingress filtering to guard against spoof
source IP addresses.

13.3.3 Mapping Theft

In the time between when a PCP server loses state and the PCP client
notices the lower than expected Epoch value, it is possible that the
PCP client's mapping will be acquired by another host (via an explicit
dynamic mapping or implicit dynamic mapping).  This means incoming
traffic will be sent to a different host ("theft").  A mechanism to
immediately inform the PCP client of state loss would reduce this
interval, but would not eliminate this threat.  The PCP client can
reduce this interval by using a relatively short lifetime; however,
this increases the amount of PCP chatter.  This threat is reduced by
using persistent storage of explicit dynamic mappings in the PCP
server (so it does not lose explicit dynamic mapping state), or by
ensuring the previous external IP address and port cannot be used by
another host (e.g., by using a different IP address pool).

13.3.4 Attacks Against Server Discovery

TBD.  We need analyze and discuss the impact of attacks which result
in a PCP Client choosing the wrong server and/or attacks that make a
PCP Server appear to be non-functional.