Re: [pcp] PCP security model

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

Thanks for writing this up.  A few comments below.

...

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

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

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

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.

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

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

>  - the support of subscriber renumbering requires a subscriber
>   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


> summary: (to be written if/when consensus will be reached)
> 
> Regards
> 
> [e-mail]
> 
> 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).
> 
> _______________________________________________
> pcp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pcp