Subject: [pcp] Ensuring Address Reuse In the Pinhole Control Protocol (PCP)

From: Tina TSOU <[email-masked]>
Date: Fri, 15 Oct 2010 23:26:11 -0700

Hi PCPers,
An I-D "Ensuring Address Reuse In the Pinhole Control Protocol (PCP)"  
was posted just now.

http://www.ietf.org/id/draft-tsou-pcp-address-modify-00.txt

Abstract

    This document proposes that a field be added to the PIN-REQUEST
    message in the Pinhole Control Protocol to ask that the new mapping
    being requested reuse the same external address already assigned to
    the requesting device.  The actual form of this new field is
    discussed within the document.

Good night.

B. R.
Tina
http://tinatsou.weebly.com

---

From: Francis Dupont <[email-masked]>
Date: Mon, 18 Oct 2010 16:01:00 +0200

In your previous mail you wrote:

=> I share your concern about wild external address change but
I prefer to get this including with the 'mandatory bit' stuff
(I put quotes because it is possible to get something slightly
different as 'mandatory per default').
I.e., a mean to say the not null requested external address must
be used or an error returned.
BTW your draft uses an obsolete packet format.

Thanks

[email-masked]

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 18 Oct 2010 17:14:40 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Tina TSOU
> Sent: Friday, October 15, 2010 11:26 PM
> To: [email-masked]
> Subject: [pcp] Ensuring Address Reuse In the Pinhole Control Protocol
> (PCP)
> 
> Hi PCPers,

The problem described is not solely with PCP.  The same problem would
also occur when different TCP SYNs are mapped to a different public
IPv4 address.  I believe that REQ-1 of
http://tools.ietf.org/html/draft-ietf-behave-lsn-requirements-00#section-3
establishes a requirement that solves this for both PCP and non-PCP
mappings.  Do you agree?

-d

---

From: Francis Dupont <[email-masked]>
Date: Tue, 19 Oct 2010 18:58:17 +0200

=> the REQ-1 doesn't solve all concerns because it says nothing about
stability during time.

Thanks

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 19 Oct 2010 11:14:01 -0700

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, October 19, 2010 9:58 AM
> To: Dan Wing
> Cc: 'Tina TSOU'; [email-masked]
> Subject: Re: [pcp] Ensuring Address Reuse In the Pinhole Control
> Protocol (PCP)
> 
> 

Are you worried that a NAT will change the public IPv4 address of a 
connection while the connection is still active, and that we need
a requirement saying Don't Do That.

-d

---

From: Francis Dupont <[email-masked]>
Date: Wed, 20 Oct 2010 00:17:58 +0200

=> no, I am worry a NAT will change the public address or port of
a port forwarding announced on the Internet: an announced port
forwarding entry can get an undefined lifetime, i.e., in practice
an unlimited one until it is deleted or updated.

REQ-1 is about dynamic mapping (e.g., created by a TCP SYN) which
has lower security constraints than port forwarding. Or with other
words this quoted from base-00:

[Ed.  Note: discuss three types of mapping: dynamic (TCP SYN), PCP,
and static configured (e.g., CLI or web page) -- all three are the
same and create a mapping entry.]

is *wrong* (dynamic mapping is for a specified peer address and port,
the two others are for any peer).

Regards

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 20 Oct 2010 07:18:25 -0700

> Sent: Tuesday, October 19, 2010 3:18 PM
> To: Dan Wing

PCP has a lifetime.  How does a port forwarding entry get an undefined
lifetime?

> the two others are for any peer).

Are you referring to the filtering behavior, imposed by some NATs,
("endpoint-dependent filtering")?  Such filtering is discouraged in
both the UDP and TCP behavior documents, but that's besides the point.
I disagree such filtering makes the Ed. Note "wrong"; rather, such
filtering (if implemented by the NAT) is an additional datastructure
associated with a mapping entry. 

-d

---

From: Francis Dupont <[email-masked]>
Date: Thu, 21 Oct 2010 14:17:58 +0200

=> by renewing, i.e., sending a request before the end of the lifetime
in order to extend it. It is explained in the UPnP-IGD IWF stuff
(needed as most UPnP-IGD users ask for an unlimited lifetime).

   Are you referring to the filtering behavior, imposed by some NATs,
   ("endpoint-dependent filtering")?

=> no, I refer again to the fact PCP or static configured port
forwarding entries have wildcard peer address and port at the opposite
of dynamic created (e.g., by TCP SYN) mappings.

Regards

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 21 Oct 2010 09:20:49 -0700

> Sent: Thursday, October 21, 2010 5:18 AM
> To: Dan Wing

I don't understand.

If there is no filtering, I don't understand the distinction being
raised.

-d

---

From: Francis Dupont <[email-masked]>
Date: Thu, 21 Oct 2010 19:54:39 +0200

I don't understand.

=> again: a NAT entry is a 7-tuple with for a packet from a client to
the Internet (it is described this way for a practical reason: a dynamic
entry is created by a packet in this way):
 - protocol
 - original source address
 - original source port
 - mapped source address
 - mapped source port
 - destination address
 - destination port
all these fields have a defined value (i.e., no wildcard) and in a
symmetrical NAT an exact match is required in both ways (from client
to Internet and from Internet to client) before the translation is
applied.

In a port forwarding entry (created by PCP or configured) the destination
address and port are wildcards. With other words only the client address
and port are used and translated.

Regards

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 21 Oct 2010 12:09:13 -0700

> Sent: Thursday, October 21, 2010 10:55 AM
> To: Dan Wing

Yep, I completely agree that certain NATs do that.

Do you agree/disagree that certain NATs do not do that?

-d

---

From: Francis Dupont <[email-masked]>
Date: Thu, 21 Oct 2010 22:48:13 +0200

=> this is the behavior of all NAT codes I wrote or read (:-),
i.e., they are symmetrical or port restricted cone NATs.

=> this doesn't matter: the real question is whether we agree
about the consequences on security.

Regards

PS: and yes I know the cone NATs...

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 22 Oct 2010 10:43:52 -0700

> Sent: Thursday, October 21, 2010 1:48 PM
> To: Dan Wing

Cisco has two NAT products that don't filter incoming packets after 
a mapping is created.

My point is that a NAT does not *have* to filter the incoming
packets, so the datastructure isn't necessarily something that
the NAT maintains.  There is no requirement in the RFCs for such
filtering, and the RFCs discourage such filtering.

> about the consequences on security.

I agree lack of filtering has a negative consequence to security 
(the host can receive packets from any host on the Internet).  
However, ISPs do not filter incoming packets for subscribers today.  
If there are ISPs that do such filtering, they can continue doing 
that filtering tomorrow (even with a CGN), in the same way they 
do today -- in the BRAS, inside the CGN (as you are suggesting),
or in front of the CGN.

Filtering has a negative consequence on UNSAF (RFC3424) NAT 
traversal techniques (Skype, ICE, HIP, et al.), which the host 
(and user) cannot resolve.

-d

---

From: Francis Dupont <[email-masked]>
Date: Sat, 23 Oct 2010 01:52:44 +0200

=> I have no reason to object (I didn't read the source of code run
by Cisco products). And it is known there are cone NATs
(even this characterization is not very good).

=> I had a sponsor who explicitely required the stricter version
of a symmetrical NAT (i.e., no sharing at all), even it was not
for a technical reason.

=> so we agree. BTW it seems cone NAT dynamic mappings (what you
call no filtering) are equivalent to PFs.

=> I believed this but obviously skype works well with any kind
of NATs. Same for Yahoo! Messenger according to my experiments
through a chain of 3 NATs (:-).
   
Regards

---

From: "Dan Wing" <[email-masked]>
Date: Sat, 23 Oct 2010 11:15:34 -0700

> Sent: Friday, October 22, 2010 4:53 PM
> To: Dan Wing

Filtering breaks direct peer-to-peer connectivity, requiring
the packets be routed through a media relay device of some sort.
That adds latency, fragility (media relay could die or get
busy doing other work), and additional cost.

My point, though, is that a NAT does not *have to* have a 7-tuple,
and that many do not.

-d

---

From: Reinaldo Penno <[email-masked]>
Date: Sat, 23 Oct 2010 14:31:55 -0400

>> call no filtering) are equivalent to PFs.

Yes, they are similar and one of the questions I asked you in a very early
thread. If the security model of PF mappings should be any different from
EIM+EIF (Endpoint Independent Mappings + EI Filtering).

> My point, though, is that a NAT does not *have to* have a 7-tuple,

I agree. Juniper CGN solutions have configurable mappings (EIM/EIF/APD) on a
per session basis.

---

From: Francis Dupont <[email-masked]>
Date: Sun, 24 Oct 2010 00:28:34 +0200

=> I remembered I asked the abbrevs in their extended form...
Now I have them so it seems you refer to RFC 4787 which BTW
provides a far better characterization than the cone stuff.
The answer is PF and EIM+EIF are equivalent.

Now linux/netfilter does (cf netfiler ML):

According to the terminology of RFC 4787 and RFC 5382, netfilter
implements
- endpoint-independent mapping, if the --random flag is not
specified to the SNAT/MASQUERADE/... targets, otherwise it's an
address and port-dependent mapping.
- address and port-dependent filtering.

Note it seems EIM severely conflicts with any port randomization
requiments so even EIM is claimed to have no security impact
I am afraid it is not true...

   > My point, though, is that a NAT does not *have to* have a 7-tuple,
   
=> hum, all have a 7-tuple but they differ how they use it for filtering
so in fact we agree and if we use compatible terminology (RFC 4787
proposed by Reinaldo seems right) it should be easier to convince
ourselves.

   I agree. Juniper CGN solutions have configurable mappings (EIM/EIF/APD) on
   a per session basis.
   
=> what is APD here (I can see two different interpretations, i.e.,
what is the next letter)? And BTW do you support port randomization?

Thanks

PS: as a NAT implementor EIM is the natural way because it is what
maximizes sharing and it is simple. But there are some not technical
reasons, including port randomization, which quickly leads to APDM.
For not explicit reasons I always saw APDF... and obviously not
only it doesn't harm current applications using NAT traversal
and worse customers don't matter or even know.