Subject: [pcp] discuss: firewall

From: "Dan Wing" <[email-masked]>
Date: Tue, 7 Dec 2010 11:18:50 -0800

This is one of the PCP discussion points.

Firewall is in PCP's charter:

  The PCP working group is chartered to standardize a client/server Port
  Control Protocol (PCP) to enable an explicit dialog with a middlebox
  such as a NAT or a firewall to open up and/or forward TCP or UDP port,
  regardless of the location of that middlebox.

and Section 3.4 of draft-ietf-v6ops-cpe-simple-security,
http://tools.ietf.org/html/draft-ietf-v6ops-cpe-simple-security-16#section-3
.4,
says that IPv6 CPE should filter incoming packets. 

This means some sort of protocol will be necessary for IPv6 to allow
incoming connections.  PCP could be that protocol.

There has been concern about securing PCP so that it can open a firewall
pinhole.  

My thought is that we limit the scope of what sort of "firewall" that
PCP could control.  For example:

  PCP's ability to open a pinhole in a firewall is intended for
  low security needs, such as a firewall that would permit an
  internal host to initiate a session towards the Internet.  If
  a firewall would not permit an internal host to open a connection
  to the Internet, PCP's security model is insufficient - because
  PCP allows an internal host to open such pinholes for incoming
  connections.

Thoughts?

-d

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 7 Dec 2010 14:26:51 -0500

Just to make sure I understand the scope of 'low security needs' and 'would
permit an internal host to initiate a session towards the Internet'

Are we leaving out things like an Application Proxy w/ authentication or in
general a firewall that needs further authentication than a mere packet
going out?

On 12/7/10 11:18 AM, "Dan Wing" <[email-masked]> wrote:

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

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 7 Dec 2010 11:41:51 -0800

> -----Original Message-----
> From: Reinaldo Penno [mailto:[email-masked]]
> Sent: Tuesday, December 07, 2010 11:27 AM
> To: Dan Wing; [email-masked]
> Subject: Re: [pcp] discuss: firewall
> 

Yes -- it just needs to see a packet go out, and that is sufficient.

I don't know yet how to craft the wording around this, but that's the
idea to Keep It Simple.

-d

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 7 Dec 2010 14:45:00 -0500

The limitations looks reasonable.

---

From: <[email-masked]>
Date: Wed, 8 Dec 2010 11:02:19 +0100

Dear Dan, all,

For the firewall part of PCP, IMHO PCP should be used to let an internal host establish communications with remote hosts (both inbound and outbound communications should be covered). Advanced policies such as preventing a remote host (IP address or IP prefix) to reach one or all internal hosts can be supported with the same PCP OpCode; additional bits would be required. 

Some restrictions should be indicated in the spec to prevent security risks related to running an automatic means to control the firewall such as the following:

* The PCP Client must not issue PCP requests to open a pinhole from/to ANY remote destination to/from ANY internal host. 
* The PCP Server must not honor a request to open a pinhole from/to ANY remote destination to/from ANY internal host.
* The PCP Client should not send a request to open a pinhole for ANY protocol from/to ANY remote destination to/from a given internal host.
* The PCP Server must open a pinhole only of the PROTOCOL specified in the request.

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Dan Wing
Envoyé : mardi 7 décembre 2010 20:19
À : [email-masked]
Objet : [pcp] discuss: firewall

Thoughts?

-d

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************