Subject: [pcp] PCP security question

From: Alain Durand <[email-masked]>
Date: Thu, 11 Nov 2010 03:59:22 -0800

During the wg meeting, there was a discussion on how to deal with security with PCP. The two options were either to deal with it within the PCP protocol or rely on channel security.
There was a rough consensus in the room to rely on channel security. The chairs would like to verify this on the mailing list.  Deadline to comment is Nov. 18th 2010.

  Alain & Dave.

---

From: <[email-masked]>
Date: Thu, 11 Nov 2010 15:46:04 +0100

Hi,

I favor the channel security approach.

Cheers,

Christian. 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Alain Durand
Envoyé : jeudi 11 novembre 2010 12:59
À : [email-masked]
Objet : [pcp] PCP security question

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

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

---

From: Francis Dupont <[email-masked]>
Date: Fri, 12 Nov 2010 06:32:18 +0100

In your previous mail you wrote:

   During the wg meeting, there was a discussion on how to deal with
   security with PCP. The two options were either to deal with it
   within the PCP protocol or rely on channel security.

   There was a rough consensus in the room to rely on channel security.

=> I agree (the idea is to build from scratch the security is bad).

Regards

[email-masked]

---

From: "Lee, Yiu" <[email-masked]>
Date: Fri, 12 Nov 2010 13:11:27 +0000

I got couple questions for multi-layer NAT scenario. If I read the spec
correctly, PCP is a hop-by-hop protocol. It means the first NAT will proxy
the request if there is another layer north of the NAT. If this is true.
How does the lower layer NAT discover the upper layer NAT and proxy the
request? Also, how does the security mechanism apply to this model? Will
the trust relationship only between two hops rather than end-to-end?

In fact, this is very different from ICE which is e2e.

On 11/11/10 6:59 AM, "Alain Durand" <[email-masked]> wrote:

>security with PCP. The two options were either to deal with it within the
>PCP protocol or rely on channel security.
>There was a rough consensus in the room to rely on channel security. The
>chairs would like to verify this on the mailing list.  Deadline to
>comment is Nov. 18th 2010.
>
>  Alain & Dave.

---

From: Francis Dupont <[email-masked]>
Date: Fri, 12 Nov 2010 22:27:56 +0100

I got couple questions for multi-layer NAT scenario. If I read the spec
   correctly, PCP is a hop-by-hop protocol. It means the first NAT will proxy
   the request if there is another layer north of the NAT.

=> I think about this case:
 - all NATs in the chain must support a pcp: if one doesn't it is not
  possible to offer the service. Assume all pcps are PCP.
 - IMHO the simplest is to open a port forwarding entry for PCP itself
  in intermediate NATs. As a side effect it will make the mapping static
  so NAT detection should work.
 - proxying can become too complex: the best is to recursively open
  pinholes in the NAT chain

   If this is true.
   request?

=> discovery is still an open problem but we have a working detection so
when the discovery problem will be solved it will be safe.

   Also, how does the security mechanism apply to this model?

=> it is the avantage of the not-proxying approach: the security
model will apply without changes. BTW today only the NAT444 and
the spurious NAT inside the home network cases are handled.

=> ICE uses a lot of middleboxes so it is not end-to-end in the
common sense (but I understand what you mean).
   
Regards

PS: BTW this should be in a new thread.

---

From: "Lee, Yiu" <[email-masked]>
Date: Fri, 12 Nov 2010 23:02:47 +0000

Hi Francis,

ICE itself doesn't "require" middle box. If you refer to TURN, ICE doesn't
need it. ICE is a discovery protocol. TURN is needed if ICE can't find an
available interface w/o using a Relay. However, ICE requires the peer
application to support ICE as well, PCP doesn't have the same requirement.

My basic question is what is the scope of PCP? Does PCP cover only the
case to reserve ports inside an ISP? Or, does PCP cover the case of
inter-PCP communication between providers? I argue that we should make
some assumptions (or use cases) to limit the scope. If the scope is too
large, we may reinvent a wheel to solve a problem ICE has already solved.

For the trusted relationship, IMHO we should only focus o hop-to-hop
rather than end-to-end. This will make our lives much easier :-)

Cheers,
Yiu

---

From: Francis Dupont <[email-masked]>
Date: Mon, 15 Nov 2010 21:55:34 +0100

=> IMHO	we understand ourselves...
BTW I found a good paper about real world NAT behavior:
http://pds.twi.tudelft.nl/reports/2010/PDS-2010-007.pdf
(it confirms my	own finding: EIM/EIF is	not common on home gateways)

   My basic question is what is the scope of PCP? Does PCP cover only the
   case to reserve ports inside an ISP?

=> yes,	it is in the same class	than NAT-PMP and UPnP IGD
(cf an IETF document about NAT control protocols, I can't remember
the reference at this time).

   Or, does PCP cover the case of
   inter-PCP communication between providers? I argue that we should make
   some assumptions (or use cases) to limit the scope.

=> no, the idea is to make a service visible from the Internet.

   If the scope is too
   
=> IMHO the problem is very different but I agree the scope is not so
clear, for instance do we want to address the static port forwarding
(today done by a web interface)? Note this point was clarified between
UPnP IGD 1.0 and 2.0.

=> I already answered about this: making the tool too clever (or
expecting it will be so clever) is a bad idea.

Thanks

PS: if PCP should handle static objects then a web IWF should be
added in the charter.

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 23 Nov 2010 16:32:59 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Lee, Yiu
> Sent: Friday, November 12, 2010 5:11 AM
> To: Alain Durand; [email-masked]
> Subject: Re: [pcp] PCP security question
> 

I have not written text describing how multiple layers of NAT could
work, but it *can* work without every NAT supporting PCP.  As one
example, consider this network topology, which would commonly occur
in the popularly-named "NAT444" case, and would commonly occur with
DS-Lite if the subscriber bought and installed their own WiFi device
which incorporates a NAT function:

      host, supporting PCP and UPnP IGD
        |
        |
     in-home NAT, supporting only UPnP IGD
        |
        |
     Large-Scale NAT, supporting only PCP
        |
        |
     Internet

In the case above, the host can communicate to the in-home NAT using
UPnP IGD to do port forwarding to that NAT's public address and port 
"X", and then communicate to the PCP server to obtain port forwarding 
from the Internet-facing address and port "Y" to the UPnP IGD-
acquired address and port "X".

Same thing could occur if the in-home NAT supporting NAT-PMP (rather
than UPnP IGD).

-d

> The

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 23 Nov 2010 16:38:46 -0800

> Francis Dupont
> Sent: Monday, November 15, 2010 12:56 PM
> To: Lee, Yiu
> Cc: [email-masked]

Maybe you were remembering draft-ietf-dime-nat-control, which was presented
in BEHAVE
at IETF 74 (Prague).  See slide 5 at
http://www.ietf.org/proceedings/74/slides/behave-3.pdf which lists MIDCOM
and SIMCO, ETSI Ia, ETSI Gq, ITU Rs, ITU Rw, UPnP IGD, NAT-PMP, NAT-PMP
Relay, NSLP, and Diameter NAT Control Application.

-d

---

From: Francis Dupont <[email-masked]>
Date: Wed, 24 Nov 2010 23:10:28 +0100

=> I agree: I introduced the term pcp (lower case) to catch this idea
(PCP, NAT-PMP. UPnP iGD, even Web interface, etc).

Thanks

---

From: Francis Dupont <[email-masked]>
Date: Wed, 24 Nov 2010 23:35:51 +0100

> the reference at this time).
   
   Maybe you were remembering draft-ietf-dime-nat-control,

=> no, this I-D is only about DNCA (Diameter Network address and port
translation Control Application).

   which was presented in BEHAVE at IETF 74 (Prague).  See slide 5 at
   http://www.ietf.org/proceedings/74/slides/behave-3.pdf which lists MIDCOM
   and SIMCO, ETSI Ia, ETSI Gq, ITU Rs, ITU Rw, UPnP IGD, NAT-PMP, NAT-PMP
   Relay, NSLP, and Diameter NAT Control Application.
   
=> this slide is fine but I can't find the I-D with the corresponding text
(perhaps it is expired... argh)?

Thanks