Subject: Re: [pcp] PCP security question

From: Paul Selkirk <[email-masked]>
Date: Thu, 16 Dec 2010 19:07:34 +0000 (UTC)

Here I'll try to summarize my preso from Beijing.  I'm not an
operator, and have never been an operator, so take my analysis with a
grain of salt, but I think I'm speaking from common sense.

PCP was motivated by the CGN case (whether NAT64, nested NAT44, or
DS-Lite), and the need for end-node applications to control its
mappings on the non-local NAT.

A CGN placed in a carrier network will inherit the operational
characteristics of the network.  In particular, I believe any rational
ISP would implement address-level ingress filtering at the customer
network attachment point.  There are all sorts of solid business
reasons beyond PCP for the ISP to want to prevent customers from
spoofing each other or outside addresses.  So the customer-facing side
of the network should already be secure.

Also (and I'm speculating more wildly here), I would expect an ISP to
have ingress filtering on its internet-facing side, at least to the
extent of preventing internet-originating packets from spoofing
customer addresses.  In other words, it shouldn't be possible for
legitimate customer-originating traffic to get routed out of the
carrier network, and then back into it.  Again, there are good
business and operational reasons why the ISP would already have this
protection in place.

So if the ISP network already has proper ingress filtering on the
customer-facing side and on the internet-facing side, then the PCP
server should already be protected against source address spoofing.
And if the ISP doesn't have proper ingress filtering, then it has
bigger problems than just PCP.

Furthermore, the ISP controls the path between the customer and the
CGN, and can set routing policies to prevent internet-originating
traffic from even reaching the customer-facing interface of the CGN.
(This assumes the PCP server will be co-located with the CGN, which
will normally be the case.)

Therefore, I believe that the PCP security question can be solved by
operational rather than protocol means, and that these operational
means are (or should be) already in place in any sanely-run ISP
network.  Therefore, I don't see a need to add security to PCP in this
situation.  Or rather, I don't see why PCP needs a higer level of
security than any other traffic following the same path from the
customer to the CGN.

In the local-NAT case, where PCP is directly replacing UPnP-IGD or
NAT-PMP in the default router, address spoofing is possible and not
preventable.  This presents a problem, but it's the same problem that
UPnP-IGD and NAT-PMP have today.  A design goal should be to suck less
if possible, but at any rate not suck more.  Since PCP allows one
device to control port mappings on behalf of another device, this is
an area where we might suck more than existing protocols, if we're not
careful.  We probably want to add language restricting on-behalf-of
mappings to the CGN scenario.  The whole local-NAT case needs more
study.

				paul

---

From: Francis Dupont <[email-masked]>
Date: Fri, 17 Dec 2010 00:36:06 +0100

The ISP CGN is an easy case for the security (roles are well
understood and as you explain the ISP has already operational and
security measure or it will kill its business).

I can see at least two difficult cases:
 - general enterprise NAT (it is hard to know a priori the roles
  and it can't be reduced to home NAT (one trust domain) or to
  the Internet access service by an ISP)
 - hotspots or any kind of insecure infrastructure (here the issue
  is not the lack of a model but the lack of any serious security.
  Note a quick solution should be to just give up on the security
  but I don't know if it is an acceptable answer for us).

Regards

[email-masked]