Subject: [pcp] updated security model

From: Francis Dupont <[email-masked]>
Date: Thu, 10 Feb 2011 18:19:12 +0100

This is an updated version of the security model
for the NAT operations of PCP.
First I embrace and extend the base-04 terminology.

TERMINOLOGY

>From draft-wing-pcp-base-04.txt section 3:
 - Mappings (divided in the 3 types below)
   - implicit dynamic mapping
   - explicit dynamic mapping
   - static mapping
 - Port Forwarding (this is the function, the object being
  a mapping)
 - PCP Client
 - PCP Server
 - Interworking Function (abbrev IWF)
  I extend IWF to PCP proxies, i.e., an IWF maps a pcp, including PCP
  itself, to PCP.
 - subscriber
 - host (note as in base-04 a 'host' is in fact an Internal Host)

New definitions:
 - 'a pcp' (lower case): a way (PCP, UPnP-IGD, NAT-PMP, CLI, web page, etc)
  to manage explicit dynamic or static mappings on a NAT.
  By convention in this text, when an explicit dynamic mapping is not
  explicitely managed by a pcp, it is managed by PCP, i.e., an
  explicit dynamic mapping is either managed by PCP or explicitely
  managed by another way. Of course static mappings are managed
  by a pcp which is not PCP.

 - requesting application (abbrev RA): an application running on a host
  which sends PCP requests (i.e., a PCP terminal client)

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

 - 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 explicit dynamic or static mappings:
  to create / delete / list explicit dynamic or static mappings

 - administrator: a person which can perform operations (including
  but not limited to manage operations) on a NAT/firewall

 - to steal/theft of an explicit dynamic or static mapping: to create
  an explicit dynamic or static mapping 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).

After this point, the document will only address explicit dynamic
mappings but in fact the same considerations apply to static mappings,
but there is no concensus about whether PCP applies only to explicit
dynamic mapping or to both explicit dynamic and static mappings.

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

The theft of explicit dynamic mappings is considered to be the
key threat: the idea is if users are protected against this
threat then other threats as not authorized creations or
deletions of explicit dynamic mappings are impossible too
(the logic is if any is possible then theft is possible).

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 is authorized to manage its host
explicit dynamic mappings.

between hosts: a host is identified by the internal address so
either:
 - a host is authorized to manage explicit dynamic mappings 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 on
  the HG 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 explicit dynamic
mappings to the HG administrator, the same role/entity than for host
renumbering.

theft in the home: if the HG as a NAT loses its state and may
re-assign a previously assigned external address and port, this opens
a race where a host can steal another host explicit dynamic mappings.
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.
Note: it is possible to remove the vulnerability by
using a new external address and/or port pool but this raises
operational concerns.

I propose a simple way to decide: as legacy pcp's (UPnP IGD 1.0
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, i.e., the pcp's supported by the IWF
show what should be the default.

between subscribers:
 - a subscriber is not authorized to manage explicit dynamic mappings
  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 explicit
  dynamic mappings.  So the PCP server of a CGN is required to keep
  its state (explicit dynamic mappings and subscriber identities) in
  stable storage when it re-assigns external addresses and/or ports
  from the same pool.

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.

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

Regards

[email-masked]

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 10 Feb 2011 14:19:17 -0500

I do not think we can throw security concerns that have requirements built
into them without a reasonable discussion of how ISPs can or should meet
them. 

If you want just to flag some security issues that is fine but saying '...is
required' needs more discussion. A PCP Server by itself does not know how to
map a subscriber to IP address(es). If you are requiring this then there is
an implicit mandate for a PCP Server to hook into the ISP's subscriber
database. 

Let's take the case of DS-Lite where a B4(CPE) sends requests to a PCP
Server:

If the CPE gets a delegated /56 there is nothing that says which IPv6
address should be used to establish the tunnel. There is nothing that says
that the CPE can (or not) after some time switch to another IPv6 and swap
tunnels. And there is nothing precluding a CPE from having more than one
tunnel.

An ISP might (or not) have a policy in place but that is an enforcement
issue.

Therefore, we can mandate that PCP messages use the same source IPv6 address
of the tunnel but this address can change dynamically and even if after
reboot the CPE gets the same exact delegated /56.

Thanks,

Reinaldo

>...

---

From: Francis Dupont <[email-masked]>
Date: Fri, 11 Feb 2011 00:53:50 +0100

In your previous mail you wrote:

=> I have a concern about the word 'throw' but I can't believe you
mean 'throw away': clearly it is the opposite.
BTW requirements are not gratuitous: they follow the usual security logic:
there is a threat, the threat is not acceptable, a counter-measure to
the threat is to do xxx, in the context the threat applies xxx is required.

   If you want just to flag some security issues that is fine but saying '...is
   required' needs more discussion.

=> I agree but this means to find a way to break the logic chain
I've just explained.

   A PCP Server by itself does not know how to map a subscriber to IP
   address(es).

=> the subscriber-ID doesn't need to be an address but in scenarios
where there are subscribers a reliable subscriber-ID is required
(and not only for pure security, as I explained it is first required
for billing). Now in the two scenarios I detailed because I know them
well the subscriber-ID is an address.

   If you are requiring this then there is an implicit mandate for a
   PCP Server to hook into the ISP's subscriber database.
   
=> this is the next step: pure security doesn't mandate this because
it is enough to identify subscribers between them, i.e., to implement
the "same subscriber" function. But I agree a hook to the subscriber
DB helps advanded features, different per subscriber services for instance,
or subscriber renumbering when the subscriber-ID is an address.

   
=> in this case (which implicitly use the plain mode) you have two choices:
 - you don't matter if the PCP client is really the B4 and the subscriber-ID
  is the /56
 - you don't want to be flexible and you require one address (and one tunnel)
In fact it is bound to the way the B4 gets its IPv6 address: if one address
is assigned to it then it makes sense to require the B4 to use it.

   
=> the recommended (but not enforced) way for the B4 is to use DHCPv6 to
get its IPv6 addresses and a prefix for the home network. In this case
you get a stable IPv6 address you can enforce.
   
   >   (this is for scenarios with subscribers other than DS-Lite and NAT444)

=> I considered the issue as solved for DS-Lite and NAT444, and as opened
for scenarios I don't know well or I don't know yet.

Now what is your concern: the requirement itself, the definition of
the term subscriber, or the ways to meet the requirement?

Regards

PS: note there likely are some scenarios where in fact strong mutual
authentication between the subscriber CPE and the PCP server is required.
At least the insecure infrastructure case is an example.

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 10 Feb 2011 19:43:09 -0500

> mean 'throw away': clearly it is the opposite.

Yes, of course.

> there is a threat, the threat is not acceptable,

I guess it depends who you ask. The trade-off between the operational of the
whole solution and acceptable security risks need to be analyzed.

> a counter-measure to

But we can not solve this here (maybe Broadband Forum) so how can we enforce
what you propose?

> you get a stable IPv6 address you can enforce.

Much like you argued that many NATs do not implement EIM, lots of deployment
will not use DHCPv6 and therefore I'm still not sure how we can enforce what
you propose.

> for scenarios I don't know well or I don't know yet.

I can only agree if we spell out all the constraints for both types of
deployments (which are considerable - and therefore might make the security
requirement questionable).

> the term subscriber, or the ways to meet the requirement?

All, but instead of this back and forth it is better if ISPs chime in, given
the many different network deployments if this security assessment makes
sense, the trade-offs vs. deploying the solution and how/if it can be
solved.