Subject: [pcp] PCP and simple firewalls

From: james woodyatt <[email-masked]>
Date: Tue, 26 Jul 2011 16:16:16 -0400

everyone--

I have a side concern with the base protocol specification of PCP.  The current -13 revision lists "IPv4 and IPv6 simple firewall control [RFC6092]" among the deployment scenarios in section 2.1, yet here is what it says about supported protocols in section 2.2:

>    The PCP OpCodes defined in this document are designed to support
>    transport-layer protocols that use a 16-bit port number (e.g., TCP,
>    UDP, SCTP, DCCP).  Protocols that do not use a port number (e.g.,
>    IPsec ESP) are beyond the scope of this document, as is using PCP to
>    request forwarding of all traffic to a single default host (often
>    nicknamed a "DMZ").

My concern is that simple IPv6 firewalls do not have network address translators, much less address-port sharing network address translators.  They just filter packets, and they don't necessarily need to care about upper layer transport protocols just to admit them into the interior network.

My principle concern is that hosts behind simple firewalls shouldn't be limited to requesting specific ports that are only in protocols that are expressly supported by PCP.

If my host is prepared to process ICMPv6 echo requests from the Internet, I don't see why PCP shouldn't be able to give me a mapping for the ICMPv6 echo request/reply protocol if policy allows, which in a residential network, it should.  If I want to run IPv6 mobility home agent, and policy permits this, then I should be able to request a mapping for the IPv6 Mobility Header upper layer transport.  Likewise for GRE and IP-in-IP tunnels.

If I want my host to have complete responsibility for securing itself, and I want the stupid simple cheap commodity firewall to get out of the way for me, and policy permits this, then the PCP server ought to be able to grant my request for opening a pinhole for the whole of IP upper layer protocol space to my host.

That the draft seems to figuratively wave its hands and declare those aspects of the problem space "out of scope" without further addressing them is a pretty big disappointment.

I also have a secondary concern that careless implementers may not be sufficiently aware of what is in RFC 6092 (which is Informational and therefore easily ignored) to exempt IPsec AH/ESP and Internet Key Exchange from the inbound default-deny policy, and, seeing that PCP is not concerned with protocols without any port numbers, they will then unnecessarily and *unintentionally* break this IPsec exemption in simple firewalls for unmanaged firewalls by requiring residential hosts explicitly to request a MAP6 pinhole for the IKE port, and to assume that if they can't get one or a PCP server is unavailable, then they can't use IPsec.

Worse, implementors may also require hosts to request explicitly a mapping for port 4500 to permit IPsec ESP over UDP, which would be a waste of resources adding UDP headers to every packet just to work around broken firewalls that deny straight ESP because PCP has no control plane for it.

I recognize that the PCP working group is chartered with the idea that PCP should be a good candidate to meet REC-48 in the "Passive Listeners" section of RFC 6092, and I commend the working group for taking up the challenge, but I don't think the current -13 draft meets the objective.

If it had been up to me, I would have set PCP as the protocol explicitly intended for controlling port maps for inbound flows in address-sharing network address translators.  I would have left the problem of handling simple firewalls and 1:1 translators in IPv6 to a different protocol, namely the one I proposed expressly for that purpose three years ago in I-D.woodyatt-ald, which makes it a first-class profile of the Internet Control Message Protocol (ICMPv6) as it should be.  Alas, that's not what happened.  I'd like to know what I can do to help the working group come to workable compromise that would make PCP a better fit for RFC 6092 simple firewalls.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking