Subject: [pcp] PCP security model

From: Francis Dupont <[email-masked]>
Date: Fri, 29 Oct 2010 18:02:32 +0200

This is an attempt to describe a PCP security model.
First I embrace and extend the base-01 terminology.

TERMINOLOGY

>From draft-wing-pcp-base-01.txt section 3:
 - Port Forwarding
 - PCP Client (note this is a restricted meaning of 'client')
 - PCP Server
 - Mapping (divided in the 3 types below)
 - dynamic Mapping
 - PCP configured mapping
 - static configured mapping
 - Interworking Function (abbrev IWF)
Port Forwarding is described as a function. I propose to map it into
not-dynamic Mapping, i.e., a Mapping is either a dynamic Mapping or
a Port Forwarding.
I extend IWF to PCP proxies, i.e., an IWF maps a pcp, including PCP
itself, to PCP.

New definitions:
 - Port Forwarding (abbrev PF): without a better proposal, the term is
  extended to cover firewall filter rules
 - 'a pcp' (lower case): a way (PCP, UPnP-IGD, NAT-PMP, CLI, web page, etc)
  to manage (this term will be defined below) PFs on a NAT/firewall.
  By convention in this text, when a PF is not explicitely managed
  by a pcp, it is managed by PCP, i.e., a PF is either managed by PCP
  or explicitely managed by another way.
 - requesting application (abbrev RA): an application running on a host
  which sends PCP requests (i.e., a PCP terminal client)
 - host: a terminal machine where RA(s) run(s).
 - home network (abbrev HN): a LAN or a collection of LANs where are
  the hosts. The home network is supposed to be one domain for
   trust/security.
 - home gateway (abbrev HG): the device between the HN and the external
  network. It can be a NAT/firewall, runs IWF, etc. It is a privileged
  point of control for PCP.
 - subscriber: the entity (usually a person) using the home network
  viewed from the Internet Service Provider providing the CGN service.
 - infrastructure: the network(s) between the HG and the CGN.
  The infrastructure is supposed to be fully on the control of the
  Internet Service Provider providing the CGN service.
 - carrier-grade NAT (abbrev CGN): a NAT/firewall of an Internet Service
  Provider providing a NAT/firewall service for subscribers.
 - to manage PFs: to create / delete / list PFs
 - administrator: a person which can perform operations (including
  but not limited to manage operations) on a NAT/firewall
 - to steal PFs: to create a PF with the same external address and port
  than used by another entity
 - to renumber: for an entity identified by an address to change this
  address. The term applies to hosts (identified by the internal address)
  and subscribers in some scenarios (identified by the HG
  infrastructure address).

The hierarchy is RA - host - subscriber.

SCENARIOS

Legacy scenario using IWF:

                      HN
 <--------------------------------------------->
     host                         HG
 +------------+             +------------------+
 | legacy RA  |--- a pcp ---| IWF - PCP server |--- Internet
 +------------+             +------------------+

Legacy scenario using PCP:

               HN
 <-------------------------------->
   host                    HG
 +-------+           +------------+
 |  RA   |--- PCP ---| PCP server |--- Internet
 +-------+           +------------+

The idea is to reason on the legacy scenario using PCP and to map
results when possible to the legacy scenario using IWF.
So from this point the HN is supposed to have been upgraded
to directly use PCP.

DS-Lite scenario:

               HN                     infrastructure
 <-------------------------><------------------------------->
   host                 HG                          CGN
 +-------+           +-----+                   +------------+
 |  RA   |--- PCP ---| IWF | -- IPv6 tunnel -- | PCP server | --- Internet
 +-------+           +-----+                   +------------+

with:
 - the HG is a Basic Bridging BroadBand (B4)
 - the CGN is an Address Family Transition Router (AFTR)
 - the infrastructure transports IPv4 packets encapsulated into IPv6
 - subscribers are identified by the HG/B4 IPv6 address

NAT444 scenario:

                  HN                     infrastructure
 <------------------------------------><----------------->
   host                     HG                   CGN
 +-------+           +----------------+     +------------+
 |  RA   |--- PCP ---| IWF/PCP server | --- | PCP server | --- Internet
 +-------+           +----------------+     +------------+

with:
 - the HG runs a NAT/firewall so it provides a PCP server for its
  control and at the same time an IWF for the CGN
 - the infrastructure addressing should be in a dedicated /8
 - subscriber are identified by the HG address on the infrastructure
We are interested only by the not-home part: the home part can be
considered as a special case of the legacy scenario.

I need descriptions for NATxy (64, 46, etc).
The enterprise NAT description is an issue: only a flat organization
can map to the legacy scenario.

SECURITY ANALYSIS

between RAs: I propose to not address security issue between
two RAs running on the same host inside PCP. BTW usually two
applications can't bind the same port so this doesn't introduce
operational problems.
To summary the proposal is to accept the vulnerability in PCP
and to rely on the host operating system to address it if/when
it can/should.
Note this implies an RA to authorize to manage its host PFs.

between hosts: a host is identified by the internal address so
either:
 - a host is authorized to manage PFs on the behalf of another host
  so to use an internal address which is not its address.
 - a host is not authorized to do this and the IWF or PCP
  server receiving PCP requests from a host must check the PCP
  request source address and the internal address are the same.
We can recommend this check to be implemented (BTW it is built-in
in NAT-PMP and optional in UPnP-IGD), but what to propose for
the default?
Note the check restricts the management of subscriber PFs to
the HG administrator, the same for host renumbering.

to steal in the home: if the HG as a NAT loses its state,
this opens a race where a host can steal another host PFs.
There are two possible answers:
 - this vulnerability is acceptable
 - this vulnerability is not acceptable and the HG is
  required to keep its state in stable storage.
IMHO the first is right for a real residential HN, i.e.,
with a consumer-grade NAT which has no reliable stable
storage. The second is better for an enterprise NAT.

I propose a simple way to decide: as legacy pcps (UPnP-IGD
for instance) don't provide a protection against this threat
if a legacy pcp is reasonably application then the
vulnerability is acceptable, if it is not then stable
storage is required.

between subscribers:
 - a subscriber is not authorized to manage PFs on the behalf
  of another subscriber. So the PCP server of a CGN is
  required to check the subscriber identity (typically the
  HG address on the infrastructure).
 - a subscribe is not authorized to steal another subscriber PFs.
  So the PCP server of a CGN is required to keep its state
  (PFs and subscriber identities) in stable storage.
These have some direct consequences:
 - scenarios with subscribers require a per subscriber authentication.
  (this is for scenarios with subscribers other than DS-Lite and NAT444)
 - if the subscriber identity is the HG address on the infrastructure,
  some measures must be taken to ensure a subscriber can't use
  the address of another subscriber, i.e., access control on the
  infrastructure including ingress filtering.
  (with other words the identification should be able to provide
   authentication)
 - the support of subscriber renumbering requires a subscriber
  authentication which is not based on addresses (proposal in PPS).

summary: (to be written if/when consensus will be reached)

Regards

[email-masked]

PS: it is a request for comment: I need help for terminology
(better names, clarifications for definions), there are some
missing scenarios and perhaps I missed some security threats.
My purpose is when this will be finalize to XMLize it and
to include it in Mohamed's requirement I-D.

PPS: the idea is to introduce in DS-Lite and NAT444 a database
associating HG addresses with subscriber IDs (something like
a NAI). This database is managed by the ISP back office, it
can be used to give a more human friendly identification of
subscribers in CLI/logs/etc, and must be checked for a
renumbering (i.e., on address mismatch but for the same
subscriber).

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 29 Oct 2010 11:45:01 -0700

Thanks for writing this up.  A few comments below.

...

> in NAT-PMP and optional in UPnP-IGD), but what to propose for

I don't know what should be recommended as the default for that.

>   (PFs and subscriber identities) in stable storage.

The actual requirement is to not give the mapping to another 
subscriber until the lifetime expires.  That can be implemented by 
using stable storage, true.  Two *examples* of ways to implement
that requirement, without stable storage of PCP-mappings:

  * algorithmically assigning certain ports to certain 
    subscribers -- like A+P (port range routing) does for 
    its dynamic connections.
  * using a completely different pool of IPv4 addresses upon 
    NAT server restart, as explained for dynamic connections
    with cold standby in Section 6 of 
    draft-xu-behave-stateful-nat-standby.

>   (with other words the identification should be able to provide

That's needed anyway, without PCP -- to prevent subscribers from 
clobbering each others sessions.

>   authentication which is not based on addresses (proposal in PPS).

I don't care about maintaining PCP mappings during a subscriber 
renumbering event.  Dynamic connections will break anyway and
we can't fix them.  I don't see the value in expending much effort
in PCP to deal with this infrequent action.  And if ISPs are
frequently renumbering subscribers, they're doing it for one 
reason:  to interfere with subscriber-operated servers.  And 
those ISPs will not be interested in a PCP feature which 
makes subscriber-operated servers easier.

-d

> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp