Subject: Re: [pcp] PCP and simple firewalls

From: james woodyatt <[email-masked]>
Date: Tue, 04 Oct 2011 14:01:55 -0700

everyone--

I've recently been reminded of a message I sent back in July to this working group, and so far as I can tell, it received no response from the working group.

  <http://www.ietf.org/mail-archive/web/pcp/current/msg01436.html>

I still believe these concerns are serious and merit more attention than they have so far received from the working group, especially since V6OPS is now in the process of revising RFC 6204 and there is a move to make an explicit recommendation to use PCP in IPv6 residential gateway devices.

As the -13 revision of the draft remains the most recent published edition, my previous message to the list on the topic, cited above, should still be relevant.  Could the working group PLEASE engage on this?

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

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 4 Oct 2011 16:45:58 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> james woodyatt
> Sent: Tuesday, October 04, 2011 2:02 PM
> To: PCP
> Subject: Re: [pcp] PCP and simple firewalls
> 
> everyone--
> 
> I've recently been reminded of a message I sent back in July to this
> working group, and so far as I can tell, it received no response from
> the working group.
> 
> I still believe these concerns are serious and merit more attention
> than they have so far received from the working group, especially since
> V6OPS is now in the process of revising RFC 6204 and there is a move to
> make an explicit recommendation to use PCP in IPv6 residential gateway
> devices.
> 
> As the -13 revision of the draft remains the most recent published
> edition, my previous message to the list on the topic, cited above,
> should still be relevant.  Could the working group PLEASE engage on
> this?

Thanks for the reminder -- that one had slipped off my list.  I agree
it is important, and is something in PCP's scope.

Here is the new text in that same section you quoted above:

2.2.  Supported Protocols

   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.,
   RSVP, IPsec ESP, ICMP, ICMPv6) are supported for IPv4 firewall, IPv6 
   firewall, and NPTv6 functions, but are out of scope for any NAT 
   functions.  A future document may describe how PCP can create NAT 
   mappings for such protocols.  Also out of scope is using PCP to 
   request forwarding of all traffic to a single default host (often 
   nicknamed a "DMZ").

Let me know if that is acceptable.

In the 'generating MAP request' section, I added:

   If the Protocol does not use 16-bit port numbers (e.g., RSVP), the
   port number MUST be 0.

In the 'processing MAP request' section, I adjusted the relevant
paragraph to allow port=0 if the Protocol 

        If the requested lifetime is non-zero, it indicates a
        request to create a mapping or extend the lifetime of an
        existing mapping.  If the PCP server or PCP-controlled device
        does not support the Protocol or cannot create a mapping for
        the Protocol (e.g., because the request is for a NAT mapping
        instead of a firewall mapping and the PCP-controlled device is
        not a NAT or does not support NATting that specific Protocol),
        it MUST generate an UNSUPP_PROTOCOL error.  If the Protocol is
        supported and the Internal Port is zero but the protocol uses
        a 16 bit port number (e.g., TCP, SCTP), it generates a
        MALFORMED_REQUEST error.  If the Protocol is supported and
        does not use 16 bit port number (e.g., RSVP), the Internal
        Port and the Requested External Port are ignored, but are
        copied into the response.

I don't believe we need similar support for PEER.  Let me know if
I'm wrong.

-d

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

---

From: james woodyatt <[email-masked]>
Date: Tue, 04 Oct 2011 17:30:36 -0700

> Let me know if that is acceptable.

I still have two major objections.

p1. I still don't see anything that permits an IPv6 host to request a MAP for the entire upper layer protocol number space from a simple non-translating or 1:1 NPTv6 firewall.  I suggest permitting protocol zero, HOPOPT, to stand as a wildcard for all upper layer protocols when creating a mapping as well as when deleting mappings.

p2. I still don't see any informative references to RFC 6092 or text that offers guidance to implementors of RFC 6092-conformant residential gateways regarding its exceptions to the default denial policy for IKE and IPsec AH/ESP in simple firewalls.  I suggest adding some text to the "Mapping Types" entry in the Terminology section that cites RFC 6092 and describes an additional mapping type: the 'conventional' mapping, which are always applied as a matter of convention or even future standards action.  If the term 'conventional mapping' is used, then section 8 [and everywhere else that mentions static mappings] will need to be revised to discuss how conventional mappings are handled differently or the same as static mappings.

---

From: Dave Thaler <[email-masked]>
Date: Wed, 5 Oct 2011 00:34:02 +0000

Also, PCP doesn't have any requirement on what the default policy is prior to
receiving any PCP messages.   There might be static mappings, or whatever else.
So if a simple firewall chooses to permit the IKE port or the ESP/UDP port or 
whatever else, introducing PCP should have no effect on that.

-Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan Wing
Sent: Tuesday, October 04, 2011 4:46 PM
To: 'james woodyatt'; 'PCP'
Subject: Re: [pcp] PCP and simple firewalls

> than they have so far received from the working group, especially 
> since V6OPS is now in the process of revising RFC 6204 and there is a 
> move to make an explicit recommendation to use PCP in IPv6 residential 
> gateway devices.
> 

Thanks for the reminder -- that one had slipped off my list.  I agree it is important, and is something in PCP's scope.

2.2.  Supported Protocols

In the 'processing MAP request' section, I adjusted the relevant paragraph to allow port=0 if the Protocol 

I don't believe we need similar support for PEER.  Let me know if I'm wrong.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 4 Oct 2011 17:57:23 -0700

> From: Dave Thaler [mailto:[email-masked]]
> Sent: Tuesday, October 04, 2011 5:34 PM
> To: Dan Wing; 'james woodyatt'; 'PCP'
> Subject: RE: [pcp] PCP and simple firewalls
> 

That default falls to RFC6092 (or RFC6092bis that James was mentioning).

-d

> Dan Wing

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 4 Oct 2011 18:09:55 -0700

> From: james woodyatt [mailto:[email-masked]]
> Sent: Tuesday, October 04, 2011 5:31 PM
> To: Dan Wing
> Cc: 'PCP'
> p1. I still don't see anything that permits an IPv6 host to request a
> MAP for the entire upper layer protocol number space from a simple non-
> translating or 1:1 NPTv6 firewall.  I suggest permitting protocol zero,
> HOPOPT, to stand as a wildcard for all upper layer protocols when
> creating a mapping as well as when deleting mappings.

Is this text sufficient?  Highlighting the new sentence which I 
believe captures what you want:

        If the Protocol is supported and
        does not use 16 bit port number (e.g., RSVP), the Internal
        Port and the Requested External Port are ignored, all packets
..........................................................^^^^^^^^^^^
        with that Protocol number are mapped to the internal host, and
........^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        these ignored field values are copied into the response.</t>

> p2. I still don't see any informative references to RFC 6092 or text
> that offers guidance to implementors of RFC 6092-conformant residential
> gateways regarding its exceptions to the default denial policy for IKE
> and IPsec AH/ESP in simple firewalls.  I suggest adding some text to
> the "Mapping Types" entry in the Terminology section that cites RFC
> 6092 and describes an additional mapping type: the 'conventional'
> mapping, which are always applied as a matter of convention or even
> future standards action.  If the term 'conventional mapping' is used,
> then section 8 [and everywhere else that mentions static mappings] will
> need to be revised to discuss how conventional mappings are handled
> differently or the same as static mappings.

I added a new paragraph to Section 4.  For context, here is all of
Section 4, the new paragraph is marked with "+".  I believe this is a
good place to add the paragraph (rather than in a terminology section,
which are often skipped over).

4.  Relationship between PCP Server and its NAT/firewall

   The PCP server receives and responds to PCP requests.  The PCP server
   functionality is typically a capability of a NAT or firewall device,
   as shown in Figure 1.  It is also possible for the PCP functionality
   to be provided by some other device, which communicates with the
   actual NAT or firewall via some other proprietary mechanism, as long
   as from the PCP client's perspective such split operation is
   indistinguishable from the integrated case.

                                  +-----------------+
         +------------+           | NAT or firewall |
         | PCP client |-<network>-+      with       +---<Internet>
         +------------+           |    PCP server   |
                                  +-----------------+

                   Figure 1: PCP-Enabled NAT or Firewall

+  A NAT or firewall device, between the PCP client and the Internet,
+  might implement simple or advanced firewall functionality.  This may
+  be a side-effect of the technology implemented by the device (e.g., a
+  network address and port translator, by virtue of its port rewriting,
+  normally requires connections to be initiated from an inside host
+  towards the Internet), or this might be an explicit firewall policy
+  to deny unsolicited traffic from the Internet.  Some firewall devices
+  deny certain unsolicited traffic from the Internet (e.g., TCP, UDP
+  to most ports) but allow certain other unsolicited traffic from the
+  Internet (e.g., UDP port 500 and IPsec ESP) [RFC6092]).  Such default
+  filtering (or lack thereof) is out of scope of PCP itself.  If a
+  device supports PCP and wants to receive traffic, and does not
+  possess knowledge of such filtering, SHOULD use PCP to create the
+  necessary mappings to receive the desired traffic.

I believe this allows RFC6092 CPE which filter, RFC6092 CPE which don't
filter, and also covers RFC6092bis.  I believe this text also walks
the line between mandating RFC6092 filtering and ignoring RFC6092
filtering.

-d

---

From: james woodyatt <[email-masked]>
Date: Tue, 04 Oct 2011 20:19:40 -0700

So far as I know there is no effort underway to revise RFC 6092. It's RFC 6204bis that seems to be underway now.

Sent from my secret agent device.

---

From: Keith Moore <[email-masked]>
Date: Tue, 4 Oct 2011 17:05:35 -0400

I share your concern.   There is definitely a need for PCP to support firewall traversal for IP protocols that don't have ports.  There's no reason that this should be out of scope.  If PCP is going to be a firewall control protocol, it needs to address this case.

Keith

---

From: Tina TSOU <[email-masked]>
Date: Mon, 10 Oct 2011 18:43:56 +0000

I said it on the mic.
However, it seems that the WG priority now is to publish the base protocol ASAP. After that, we can add more functions.

Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Keith Moore
Sent: Tuesday, October 04, 2011 2:06 PM
To: james woodyatt
Cc: PCP
Subject: Re: [pcp] PCP and simple firewalls

Keith

---

From: james woodyatt <[email-masked]>
Date: Mon, 10 Oct 2011 12:13:45 -0700

I very much hope the working group will not make such a terrible mistake as to publish a base protocol specification with such a serious flaw in it, the current -13 revision does.

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 10 Oct 2011 15:21:36 -0400

Hi James,

> I very much hope the working group will not make such a terrible mistake as to publish a base protocol specification with such a serious flaw in it, the current -13 revision does.

Dan suggested several changes on-list to address the concerns you have raised, and I haven't seen you respond to them...  Do you think that the changes he has suggested will fix this "serious flaw", or is there something further that you think ought to be done?

I agree that you pointed out some valid omissions in version -13 of the spec, but it appears to me that Dan's proposed changes would address them.  Am I missing something?

Margaret

---

From: james woodyatt <[email-masked]>
Date: Mon, 10 Oct 2011 14:10:09 -0700

> I agree that you pointed out some valid omissions in version -13 of the spec, but it appears to me that Dan's proposed changes would address them.  Am I missing something?

I've looked at the new -14 revision, and yes, it is still seriously flawed.

In section 2.2, the last sentence reads:

               Also out of scope is using PCP to request forwarding of
   all traffic to a single default host (often nicknamed a "DMZ").

In section 9.1, under the entry for Protocol in the format of the MAP packet, I see this text:

                             The value 0 has a special meaning for 'all
      protocols', and is used only for delete requests.

I proposed allowing a firewall (both non-translating and NPTv6 variants) to process MAP requests for the HOPOPT protocol as a request for all upper-layer protocols to be mapped to the requesting private network address.  Are there any technical objections to this proposal?

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 10 Oct 2011 23:38:54 -0400

-14 should work with any protocol, including protocols that don't have
ports (e.g., IPSec ESP, RSVP).  That was my attempt when editing -14.

If there was an error where this _doesn't_ work, please point it out.

-d

> Sent: Monday, October 10, 2011 3:14 PM
> To: Tina TSOU
> Cc: PCP; Keith Moore
> I very much hope the working group will not make such a terrible
> mistake as to publish a base protocol specification with such a serious
> flaw in it, the current -13 revision does.
> 
> > However, it seems that the WG priority now is to publish the base
> protocol ASAP. After that, we can add more functions.
> >
> >
> > Best Regards,
> > Tina TSOU
> Keith Moore
> > I share your concern.   There is definitely a need for PCP to support
> firewall traversal for IP protocols that don't have ports.  There's no
> reason that this should be out of scope.  If PCP is going to be a
> firewall control protocol, it needs to address this case.
> >
> > Keith
> >

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 10 Oct 2011 23:42:18 -0400

> Sent: Monday, October 10, 2011 5:10 PM
> To: Margaret Wasserman
> Cc: PCP
> > I agree that you pointed out some valid omissions in version -13 of
> the spec, but it appears to me that Dan's proposed changes would
> address them.  Am I missing something?
> 

That is "all traffic for all protocols."

That is different from "a protocol that does not use ports," which
is what you indicated you wanted, and I believe we have consensus
to add, and which I believe -14 allows.

> I proposed allowing a firewall (both non-translating and NPTv6
> variants) to process MAP requests for the HOPOPT protocol as a request
> for all upper-layer protocols to be mapped to the requesting private
> network address.  Are there any technical objections to this proposal?

Yes.  If this is a NAPT, does the DMZ request supersede all other
mappings, supersede just PCP-created explicit mappings (PEER/MAP)?
And if a new outgoing packet is sent by another host, how does it
get mapped?

If this isn't a NAPT, and just a firewall, the answers are easier.  I
don't know if we could scope DMZ to non-NAPT, but perhaps we could
do that.  Thoughts?

-d

---

From: james woodyatt <[email-masked]>
Date: Mon, 10 Oct 2011 21:20:07 -0700

> If there was an error where this _doesn't_ work, please point it out.

How do I ask the PCP server to MAP *all* protocols?  Send a request for each protocol number in turn?  I mean there's only 254 of them, so I suppose that's doable.  It would be stupid if that's what I've got to do.

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 11 Oct 2011 00:42:10 -0400

> Sent: Tuesday, October 11, 2011 12:20 AM
> To: Dan Wing
> Cc: PCP
> How do I ask the PCP server to MAP *all* protocols?  Send a request for
> each protocol number in turn?  I mean there's only 254 of them, so I
> suppose that's doable.  It would be stupid if that's what I've got to
> do.

You are asking for something different today than you have asked 
for previously.  So please cut me some slack.

I believe we can do this for a firewall.  I believe we cannot do this
for a NAPT.

I will attempt to make the modifications to the document accordingly,
and get that published on Wednesday, along with the correction to
the ADDRESS_MISMATCH oversight.

-d

---

From: james woodyatt <[email-masked]>
Date: Mon, 10 Oct 2011 22:10:35 -0700

On Oct 10, 2011, at 21:42 , Dan Wing wrote:
> 
> You are asking for something different today than you have asked for previously.

The way I see it, I'm asking for something I started asking for-- and have not stopped asking for since-- back in July, when I wrote this:

On Jul 26, 2011, at 13:16 , james woodyatt wrote:

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

I'm sorry if I've come off sounding brusque earlier.  Hazard of writing IETF email on a device with only a touchscreen keyboard and an annoying autocomplete feature: I tend to write only what's necessary to convey the technical point I want to make, and it makes me come off sounding impatient or worse.  I'm merely trying to be constructively assertive, not cranky and angry.

I do wonder, however, if the mental model of NAPT and IPv4 address amplification is a bit overly dominant in the PCP working group.  I'm surprised that we've gotten all the way up to a -14 revision without anybody noticing this problem with 1:1 NAT and IPv6 firewall host mappings prior to my pointing it out.

> And if a new outgoing packet is sent by another host, how does it

One imagines that a NAPT might have a pool of public IP addresses that it reserves for granting 1:1 NAT mappings to hosts that request them.  I would agree that you could save until the successor document the opportunity to extend PCP to permit mapping requests for NAPT rules that apply in a more general case only when more specific mapping have not been inserted into the NAPT engine.  What's important is that the protocol have a way for A) a host to request a 1:1 pinhole mapping for the whole of IP protocol space, and B) a server to respond that it has either mapped the pinhole to the host or it is refusing to do so.

---

From: Keith Moore <[email-masked]>
Date: Tue, 11 Oct 2011 06:24:44 -0400

> I do wonder, however, if the mental model of NAPT and IPv4 address amplification is a bit overly dominant in the PCP working group.  I'm surprised that we've gotten all the way up to a -14 revision…

I've wondered the same thing.

>  What's important is that the protocol have a way for A) a host to request a 1:1 pinhole mapping for the whole of IP protocol space, and B) a server to respond that it has either mapped the pinhole to the host or it is refusing to do so.

Right.  The protocol needs to define a way that the host can ask for this, but the server should be able to respond "I can't do this".

Keith

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 13 Oct 2011 10:01:24 -0700

> Sent: Monday, October 10, 2011 10:11 PM
> To: Dan Wing
> Cc: 'PCP'
> The way I see it, I'm asking for something I started asking for-- and
> have not stopped asking for since-- back in July, when I wrote this:

-15 now allows a single message to request all firewalling be 
disabled, using a MAP request with protocol=0 and port=0.  This is
an optimization (reduction of PCP message round trips) compared
to -14.

You seemed to want/need the optimization.

-d