Subject: [pcp] XOR IP address in payloads

From: "Dan Wing" <[email-masked]>
Date: Thu, 6 Jan 2011 10:04:59 -0800

Both Teredo (*) and STUN (**) XOR IP addresses returned in payloads, in
order to avoid interference by overzealous UDP ALG code in some NATs.  Do we
need the same in PCP?  (I think we should, even though it slightly increases
implementation complexity.)

(*)  http://tools.ietf.org/html/rfc4380#section-4
(**) http://tools.ietf.org/html/rfc5389#section-15.2

-d

---

From: Simon Perreault <[email-masked]>
Date: Thu, 06 Jan 2011 13:17:36 -0500

> implementation complexity.)

I'd say "sure why not" if I had ever seen such an ALG...

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Dave Thaler <[email-masked]>
Date: Thu, 6 Jan 2011 19:58:49 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan
> Wing
> Sent: Thursday, January 06, 2011 10:05 AM
> To: [email-masked]
> Subject: [pcp] XOR IP address in payloads
> 
> Both Teredo (*) and STUN (**) XOR IP addresses returned in payloads, in order
> to avoid interference by overzealous UDP ALG code in some NATs.  Do we need
> the same in PCP?  (I think we should, even though it slightly increases

I think this is tightly related to the "nested NAT" discussion.

If we only ever use protocols hop-by-hop, then a PCP message would never
flow though a NAT and the answer would be No.

If we allow PCP to be used to talk to a remote PCP server through a NAT,
then the answer would be Yes.

-Dave

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

---

From: Francis Dupont <[email-masked]>
Date: Thu, 06 Jan 2011 21:02:25 +0100

In your previous mail you wrote:

=> NAT traversal should be a rare event. Teredo and STUN are designed
to work through a NAT so it makes sense but this should remain an exception
(and broken NATs too :-).
So I think we should *not*.

Regards

[email-masked]

---

From: Simon Perreault <[email-masked]>
Date: Thu, 06 Jan 2011 15:19:58 -0500

On 2011-01-06 15:02, Francis Dupont wrote:
> => NAT traversal should be a rare event.

I'm not too sure about that.

Use case: Imagine a home gateway that supports UPnP or NAT-PMP and does
not know anything about PCP (i.e. the kind we have now everywhere).
Imagine an application that has been updated to include a PCP client. It
uses UPnP or NAT-PMP for opening a pinhole in the home gateway, and PCP
for opening a pinhole in the CGN. Unless I'm wrong, PCP is supposed to
handle this use case.

In this use case the PCP request will be NATed by the home gateway.

Simon

---

From: Francis Dupont <[email-masked]>
Date: Thu, 06 Jan 2011 21:49:03 +0100

=> it is a rare case and not only the intermediate NAT is required
to support port forwarding, if possible controled by PCP, and
to make the NAT detection to work PCP itself should use port forwarding.
So IMHO this constraint should be far too high for a NAT which is
so broken it messes randomly byte patterns which look like an IP address.

So IMHO XOR IP address in PCP is more than overkilling.

Regards

PS: BTW I never saw a proposal to XOR IP addresses in the DNS
(this doesn't say a NAT can't mess the DNS :-).

---

From: Royer Software and Services <[email-masked]>
Date: Thu, 06 Jan 2011 14:03:58 -0700

> I'm not too sure about that.

I double NAT. Not because I want to, because my home ISP provides me 
with this very dumb
vendor router/firewall/NAT that I can't  do anything with (They do not 
give out the password). Inside of that
have my NAT that directs inbound traffic. Their firewall is one of the 
dumbest products on the Internet.
Their idiotic NAT only allows all inbound traffic to one internal IP. 
Outbound works fine.

To punch a hole in, I have to configure my PnP vendor NAT/firewall to 
let the port in. And I have to configure
my NAT to route the port.

Doug
*Royer Software and Services*
Project-Contracting.com <http://Project-Contracting.com>
+1-714-989-6135 <tel:+1-714-989-6135>

---

From: Simon Perreault <[email-masked]>
Date: Thu, 06 Jan 2011 16:07:42 -0500

On 2011-01-06 15:49, Francis Dupont wrote:
> to support port forwarding

Any recent home gateway supports static port forwarding, UPnP, and/or
NAT-PMP.

> and

What NAT detection? Please explain.

Simon

---

From: Francis Dupont <[email-masked]>
Date: Fri, 07 Jan 2011 00:15:56 +0100

=> and doesn't provide a wild ALG on unknown traffic too.

   
=> to detect a NAT (in fact at least a NAT, this doesn't give the number
of NATs or its/their positions) in a path you have to compare addresses
and ports at each side. It works too if there are known NATs in the path
(works == it detects unknown NATs) if you can control the address and
port translation. A common way to do that is to use port forwarding.

An example:

Host (PCP client in our case)
source address A0 and port P0

|
V

known NAT translating A0 P0 to A1 P1
(i.e., a port forwarding for external=(A1,P1) internal=(A0,P0) was created

|
perhaps a NAT here
|
V
NAT detection peer (PCP server in our case)
getting the packet from A2 P2

If A2 = A1 and P2 = P1 then there is no NAT,
If A2 != A1 and/or P2 != P1 then there is at least one NAT.

BTW there are two ways to handle this: either the peer gets
A1 and P1 is the message payload so it can conclude the path was broken
by a NAT (this is the way NAt detection works in IKEv2 for instance),
or the peer reflects to the Host the address and port it got and
the Host checks if it is what it expects (NAT detection in an old draft
uses this way).
IMHO the first way is better because its delay is half shorter.

Regards

PS: jamais deux sans trois...
PPS: I have in my VM platform two levels of NAT and three in my hardware
platform so I know how to get port forwarding to work through many NATs.

---

From: Simon Perreault <[email-masked]>
Date: Thu, 06 Jan 2011 18:36:37 -0500

Le 11-01-06 18:15, Francis Dupont a écrit :
> and ports at each side.

Yes of course, but why do you think NAT detection is needed? The host 
sends a UPnP/NAT-PMP request. If it gets a response, it knows there is a 
NAT, and it knows the external address of the pinhole in that NAT. Then 
it sends a PCP request with that external address as the PCP request's 
internal address. This creates the pinhole in the second layer of NAT. 
No NAT detection needed.

Simon

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 6 Jan 2011 18:49:53 -0800

> From: Dave Thaler [mailto:[email-masked]]
> Sent: Thursday, January 06, 2011 11:59 AM
> To: Dan Wing; [email-masked]
> Subject: RE: [pcp] XOR IP address in payloads
> 
> If we only ever use protocols hop-by-hop, then a PCP message would
> never flow though a NAT and the answer would be No.
> 
> If we allow PCP to be used to talk to a remote PCP server through a
> NAT, then the answer would be Yes.

I don't know how to prevent a packet from traversing a NAT.

The original STUN (RFC3489) didn't do XOR'ing but after someone
noticed the problem in the wild, its revision RFC5389 added XOR'ing.

I was looking to see if PCP might suffer a similar experience.  And
if so, to avoid it.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 6 Jan 2011 18:51:24 -0800

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, January 06, 2011 12:49 PM
> To: Dave Thaler
> Cc: Dan Wing; [email-masked]
> Subject: Re: [pcp] XOR IP address in payloads
> 
> 

The problem encountered, in the wild, was NATs were rewriting
UDP payloads when the NAT's WAN address was in the UDP payload
on a 32-bit boundary.  

That is less likely to happen with DNS payloads because the NAT's 
WAN address is very unlikely to appear in a DNS payload and 
if it appears it has a low probability of being 32 bit aligned.

-d

---

From: <[email-masked]>
Date: Fri, 7 Jan 2011 14:23:39 +0800

|On 2011-01-06 15:02, Francis Dupont wrote:
|> => NAT traversal should be a rare event.
|
|I'm not too sure about that.
|
|Use case: Imagine a home gateway that supports UPnP or NAT-PMP 
|and does not know anything about PCP (i.e. the kind we have 
|now everywhere).
|Imagine an application that has been updated to include a PCP 
|client. It uses UPnP or NAT-PMP for opening a pinhole in the 
|home gateway, and PCP for opening a pinhole in the CGN. Unless 
|I'm wrong, PCP is supposed to handle this use case.
|
|In this use case the PCP request will be NATed by the home gateway.

This is an interesting case. It depends on deployment scenarios, in Dual
Stack-Lite context, PCP request will not be NATed by the home gateway.
But in NAT444 context we may face this problem, so I suppose it is
necessary to XOR IP address in payloads in this case.

Yet, speaking of apps, consider two types of apps, a) UPnP/NAT-PMP
enabled(without PCP), e.g. today's apps; b) PCP enabled, e.g. future
apps; For type a) apps, we need to deploy UPnP IWF on home gateway to
deal with it. For type b) apps, It may traverse NAT depends on
deployment scenarios. In case it encounters NAT that does not support
PCP on its path, PCP port forwarding on the home gateway can be opened
statically via web interface or via UPnP/NAT-PMP control, but it is not
necessary to implement both PCP and UPnP/NAT-PMP on apps. 

|Simon
|--
|DTN made easy, lean, and smart --> http://postellation.viagenie.ca
|NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
|STUN/TURN server               --> http://numb.viagenie.ca
|

BR,
Xiaohong

---

From: <[email-masked]>
Date: Fri, 7 Jan 2011 07:39:05 +0100

Hi Dan, all,

What would these ALGs change in the packets: (1) the internal IP address of outgoing PCP packets, (2) any occurrence of IP addresses in PCP responses?

If (1), then this is even good because the internal IP address that should be maintained by the PCP server is the one used in the external interface of the NAT and not the original IP address set by the PCP Client. But still the problem is the port number. In this case, with or without that ALG, a failure will be experienced. I don't see the added value of xoring the IP address for this case. 

If (2), I don't really understand why these  ALGs do this.

Unless I missed something, I'm not sure there is a justification for xoring the IP address in PCP.

Cheers
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Dan Wing
Envoyé : jeudi 6 janvier 2011 19:05
À : [email-masked]
Objet : [pcp] XOR IP address in payloads

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

---

From: Francis Dupont <[email-masked]>
Date: Fri, 07 Jan 2011 09:00:58 +0100

> of NATs or its/their positions) in a path you have to compare addresses
   
   Yes of course, but why do you think NAT detection is needed?

=> because there could be a NAT where you expect there is none
(some use the term 'NAT protection').

   The host sends a UPnP/NAT-PMP request.

=> you believe in the universal deployment of UPnP? Why do we work on
PCP BTW?
For NAT-PMP it works only for the first router (aka default gateway).

   If it gets a response, it knows there is a NAT

=> the problem is if it doesn't get a response it can't conclude
there is no NAT...
   
Regards

---

From: Francis Dupont <[email-masked]>
Date: Fri, 07 Jan 2011 09:07:44 +0100

=> but we can detect unexpected NAT traversal.

=> 'wild' is the right word: my argument is if a NAT in the path
is too wild (in fact it is enough it is out of control) then
PCP will fail to open pinholes through.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Fri, 07 Jan 2011 09:16:06 +0100

=> it seems it should be better to pad the fixed header
to never be on a 32 bit boundary, isn't it?
BTW we have an unused octet in the fixed header, so we can remove
it or double it (in case we believe we'll get an use for it):
this shift the whole thing by one. Or do a similar thing with
the 3 octets of padding after the protocol field.

IMHO it is better to unalign packets than to obfuscate them.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Fri, 07 Jan 2011 09:28:42 +0100

=> I don't like the word 'necessary' at all: NATs requiring this
are broken: they need to be nuked. If we really believe it could
be an issue, we should design a way to detect them.

Regards

---

From: <[email-masked]>
Date: Fri, 7 Jan 2011 19:04:52 +0800

After re-thinking, I changed my mind. Like others, I don't see a use
case of XOR IP address in payloads.

Consider a typical NAT444 scenario, where the PCP encounters NAT in its
path. Assume all the 5-tuple IP headers in this example are in this
order: (source IP, source port, destination IP, destination port,
protocol).

NAT 2 with PCP server listening on A2:P2 (e.g. CGN)
 |
 V
NAT 1 (e.g. home gate way): translating A0 P0 to A1 P1
 |
 V
Host with PCP client: issue a PCP request with 5-tuple IP header: (A0,
P0, A2, P2, UDP)

PCP request issued by host:
5-tuple IP header: (A0, P0, A2, P2, UDP) payload: (internal ip: A0,
internal port: Px) 

PCP request translated by NAT 1
5-tuple IP header: (A1, P1, A2, P2, UDP) payload: (internal ip: A0,
internal port Px) 

PCP response from the PCP server:
5-tuple IP header: (A2, P2, A1, P1, UDP) payload: (external ip: A2 (or
any other IP addresses in NAT 2's address pool), internal port Py)

First, I don't think this PCP response has problems with traverse NAT 1
as the pinhole has been dynamically created by the previous PCP request.

But, when the NAT 1 handles the PCP response, even if NAT 1 attempts at
providing a generic ALG function and rewrites the 32-bit binary payloads
containing its public IP address, I don't see any reasons for NAT 1 to
change PCP response A because in PCP payload external ip== A2 (or any
other IP addresses in NAT 2's address pool), which is not likely to
match the WAN interface IP of NAT 1. 

Dan, Please tell me if I miss something.

| In your previous mail you wrote:
|
|   But in NAT444 context we may face this problem, so I suppose it is
|   necessary to XOR IP address in payloads in this case.
|   
|=> I don't like the word 'necessary' at all: NATs requiring 

I withdraw this word. :-)

BR,
Xiahong

---

From: GangChen <[email-masked]>
Date: Sat, 8 Jan 2011 00:03:11 +0800

> 5-tuple IP header: (A1, P1, A2, P2, UDP) payload: (internal ip: A0,
I guess the concern people have is PCP request translated by NAT 1
5-tuple IP header: (A1, P1, A2, P2, UDP) payload: (internal ip: A1,
external port: Py)

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 7 Jan 2011 08:31:06 -0800

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Thursday, January 06, 2011 10:39 PM
> What would these ALGs change in the packets: (1) the internal IP
> address of outgoing PCP packets, (2) any occurrence of IP addresses in
> PCP responses?

These overzealous ALGs modify UDP packets where the NAT's WAN address 
is in the UDP payload on a 32 bit boundary.  Very hard to guess how
many of these exist in the wild.  

> If (1), then this is even good because the internal IP address that
> should be maintained by the PCP server is the one used in the external
> interface of the NAT and not the original IP address set by the PCP
> Client. But still the problem is the port number. In this case, with or
> without that ALG, a failure will be experienced. I don't see the added
> value of xoring the IP address for this case.
> 

Like all ALGs, it was done in an attempt to get an application to
work.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 7 Jan 2011 08:35:38 -0800

> IMHO it is better to unalign packets than to obfuscate them.

Not on a lot of our platforms.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 7 Jan 2011 09:42:19 -0800

> From: [email-masked] [mailto:xiaohong.deng@orange-
> ftgroup.com]
> Sent: Friday, January 07, 2011 3:05 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; lan.wang@orange-
> ftgroup.com

That PCP response contains the NAT-1's public IP address, in the
existing internal-ip-address field of the PIN* response packet 
format.  

Teredo and STUN experience says that some NATs will modify the
PCP UDP payload.

-d

---

From: Francis Dupont <[email-masked]>
Date: Fri, 07 Jan 2011 22:59:27 +0100

=> as you seem to know what is exactly this crazy behavior,
can you design a way to detect such NATs? IMHO it should be
more useful for users than to mess the PCP message layout.

(the idea is such NATs will break randomly any protocol
(at the exception of Teredo and STUN) so if one can detect them
(s)he can jump on his/her favorite weapon to solve the issue).

Regards

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 7 Jan 2011 14:27:21 -0800

> Sent: Friday, January 07, 2011 1:59 PM
> To: Dan Wing
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]

http://tools.ietf.org/html/rfc5780#section-3.6

but it isn't always reliable, per
http://tools.ietf.org/html/rfc5780#section-1

-d

---

From: <[email-masked]>
Date: Mon, 10 Jan 2011 09:06:59 +0100

Re-,

I still don't get the point about what you mentioned: "where the NAT's WAN address 
is in the UDP payload on a 32 bit boundary" if this applies for incoming or outgoing packets.

Are you referring to what is defined for example in RFC5780, which I understand:

"
3.6. Detecting a Generic Application Level Gateway (ALG)

   A number of NAT boxes are now being deployed into the market that try
   to provide "generic" ALG functionality.  These generic ALGs hunt for
   IP addresses, either in text or binary form within a packet, and
   rewrite them if they match a binding.  This behavior can be detected
   because the STUN server returns both the MAPPED-ADDRESS and XOR-
   MAPPED-ADDRESS in the same response.  If the result in the two does
   not match, there is a NAT with a generic ALG in the path.  This test
   apples to UDP and TCP, but not TLS over TCP connections."

?

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : vendredi 7 janvier 2011 17:31
À : BOUCADAIR Mohamed NCPI/NAD/TIP; [email-masked]
Objet : RE: [pcp] XOR IP address in payloads

-d

---

From: <[email-masked]>
Date: Mon, 10 Jan 2011 16:53:17 +0800

|2011/1/7, [email-masked] 
|<[email-masked]>:
|> PCP request issued by host:
|> 5-tuple IP header: (A0, P0, A2, P2, UDP) payload: (internal ip: A0, 
|> internal port: Px)
|>
|> PCP request translated by NAT 1
|> 5-tuple IP header: (A1, P1, A2, P2, UDP) payload: (internal ip: A0, 
|> internal port Px)
|>
|I guess the concern people have is PCP request translated by 
|NAT 1 5-tuple IP header: (A1, P1, A2, P2, UDP) payload: 
|(internal ip: A1, external port: Py)

Would you explain why? I don't see why NAT-1 translates UDP payload/PCP
request from (internal ip: A0, external port: Px) to (internal ip: A1,
external port: Py),  
because  NAT-1s' WAN address A1 does *not* present in the PCP request
sent by host, even if "These overzealous ALGs modify UDP packets *where*
the
NAT's WAN address is in the UDP payload on a 32 bit boundary. "-- Quoted
from Dan's reply

BR,
xiaohong

---

From: <[email-masked]>
Date: Mon, 10 Jan 2011 16:54:16 +0800

|That PCP response contains the NAT-1's public IP address, in 
|the existing internal-ip-address field of the PIN* response 
|packet format.  

I wonder how PCP response could contain the NAT-1's public IP address in
the existing internal-ip-address.

Do you mean NAT-1's ALG has already modified the PCP request when it
passed through NAT-1? But even if these 
overzealous ALGs modify UDP packets where the NAT's WAN address is in
the UDP payload on a 32 bit boundary, 
I can't see a reason for NAT-1's ALG to modify PCP request's
internal-ip-address, as NAT-1's WAN addresses
does *not* present in the original payload of PCP request, which was
sent by host.

I missed something?

|Teredo and STUN experience says that some NATs will modify the 
|PCP UDP payload.
|

BR,
Xiaohong

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 10 Jan 2011 08:25:17 -0800

> Sent: Monday, January 10, 2011 12:07 AM

Yes, that is probably the best written description of the behavior of
such ALGs.

-d

> > If you are not the intended addressee of this message, please cancel
> it
> > immediately and inform the sender.

---

From: <[email-masked]>
Date: Tue, 11 Jan 2011 18:16:29 +0800

Sorry I was talking about an interim NAT which does not support PCP. 

You're referring to the nested NAT case, where the intermediate NAT acts
like both PCP Client and PCP server. However, IMHO, it's unlike STUN
case; because the destination of the STUN response is the internal
host's transport address therefore the intermediate NAT should forward
it and applies NAT/ALG on it. But in case of PCP response, the PCP
response from the upstream PCP server is sent to the PCP port of the
intermediate NAT so that the intermediate NAT will *not* perform NAT/ALG
on it. Instead, to my understanding, the intermediate NAT works like a
PCP proxy and there will be no NAT/ALG issues. Please anybody tell me if
I understood wrong.

BR,
Xiaohong

|
||That PCP response contains the NAT-1's public IP address, in the 
||existing internal-ip-address field of the PIN* response packet format.
|
|I wonder how PCP response could contain the NAT-1's public IP 
|address in the existing internal-ip-address.
|
|Do you mean NAT-1's ALG has already modified the PCP request 
|when it passed through NAT-1? But even if these overzealous 
|ALGs modify UDP packets where the NAT's WAN address is in the 
|UDP payload on a 32 bit boundary, I can't see a reason for 
|NAT-1's ALG to modify PCP request's internal-ip-address, as 
|NAT-1's WAN addresses does *not* present in the original 
|payload of PCP request, which was sent by host.
|
|I missed something?
|
||Teredo and STUN experience says that some NATs will modify 
|the PCP UDP 
||payload.
||
|
|BR,
|Xiaohong

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 11 Jan 2011 09:32:16 -0800

> Sent: Tuesday, January 11, 2011 2:16 AM
> To: [email-masked]; [email-masked]
> Subject: Does nested NAT apply NAT/ALG on PCP packet?
> 

For the nested NAT case, I am _not_ talking about a NAT that supports
PCP at all.

ftp://ftp-eng.cisco.com/dwing/pcp/pcp-nested-nat.pdf and my earlier
email " PCP and nested NAPT"
http://www.ietf.org/mail-archive/web/pcp/current/msg00654.html 
stated two goals:

  1. Work over one existing NAPT in people's homes
  2. Detect multiple existing NAPTs

Regarding (1), existing NAPT devices, as we all know, do not 
implement PCP.  Existing NAPT devices are devices that users 
have purchased at the local computer store and will continue 
to purchase at the local computer store for years and years 
in the future.  Maybe, at some point, PCP proxying will become a 
ubiquitous feature.  But I was not attempting to initiate a 
thread on NATs that do PCP proxying.  I believe we all know
how PCP proxying would work.

If there is a disagreement about the two goals, let's talk about 
the disagreement with those goals.  We cannot talk about bits and 
bytes on the wire without first agreeing on the goal.

-d

---

From: GangChen <[email-masked]>
Date: Thu, 13 Jan 2011 14:20:38 +0800

> NAT's WAN address is in the UDP payload on a 32 bit boundary. "-- Quoted

Let's see. NAT1 has the binding A0:Px<=>A1:Py. When PCP client send
PCP request(payload: (internal ip: A0, internal port Px). The ALG hunt
for IP address and rewrite,since they match a binding. PCP request
payload is translated by NAT 1 to (internal ip: A1,external port: Py).
The NAT2 responses PCP request (internal ip: A1,external port: Py),and
replies with payload: (external ip: A2 (orany other IP addresses in
NAT 2's address pool), internal IP address A1:Py).

That is my understanding. Please correct me.

BRs

Gang

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 12 Jan 2011 23:19:02 -0800

Don't over-think it.  The NATs with this behavior are only
seeing packets going in and packets going out.  Simplified,
they do:

  host----[NAT with (broken) UDP ALG]---------[network]

The problem is when the "NAT with the (broken) UDP ALG" device sees
a UDP packet arrive from the right network (its "WAN" interface)
and that UDP packet contains a payload on a 32 bit boundary that
matches the NAT's WAN address, the NAT will change those 32 bits.
It changes the 32 bits to become the internal host's IP address.

When PCP is added to the mix, the question is:  when a PCP
message accidentally (1) or purposefully (2) traverses such a NAT,
do we want PCP to protect its payload from such a NAT?

On (1), accidental may happen if a subscriber installs one of
these NATs in their home network.  The one that has been
sitting in their garage, for example.  Or a new one they
bought at a computer store.  We don't know, and can't 
control, what sort of crazy ALGs are running in NATs.  We
_know_ that some NATs have done what is described in the
top of this message.

On (2), we might want to traverse a NAT, on purpose, to
support nested NATs.  Again, we don't know and can't
tell if a NAT does this sort of UDP payload modification.
We can protect against it, though.

-d

> From: GangChen [mailto:[email-masked]]
> Sent: Wednesday, January 12, 2011 10:21 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]

---

From: <[email-masked]>
Date: Thu, 13 Jan 2011 15:46:17 +0800

|
|Let's see. NAT1 has the binding A0:Px<=>A1:Py. When PCP client 
|send PCP request(payload: (internal ip: A0, internal port Px). 

==>First, NAT1 will not have this binding until it receives any PCP
requests from this client;  second, the internal port of binding is NOT
the same as internal port in the PCP payload;
 so, assuming the binding A0:P0<=>A1:P1, and the PCP request should be
(payload: (internal ip: A0, internal port Px). 

|The ALG hunt for IP address and rewrite,since they match a 
|binding. PCP request payload is translated by NAT 1 to 
|(internal ip: A1,external port: Py).

==> The ALG will NOT rewrite this packet since fisrt its Niether come
from its "WAN" interface Nor its paylaod contains a payload on a 32 bit
boundary that matches the NAT-1's WAN address A1. Besides, the payload
will NOT match any NAT bindings either.

|The NAT2 responses PCP request (internal ip: A1,external port: 
|Py),and replies with payload: (external ip: A2 (orany other IP 
|addresses in NAT 2's address pool), internal IP address A1:Py).
|
|That is my understanding. Please correct me.

==> Prove me wrong if you have other opinions.
|
|BRs
|
|Gang

BR
Xiaohong

---

From: GangChen <[email-masked]>
Date: Thu, 13 Jan 2011 16:00:31 +0800

> (payload: (internal ip: A0, internal port Px).

It depends specific use cases. "Using PCP to Eliminate Application
Keepalive Messages" could be the case.
> will NOT match any NAT bindings either.

I think that is related to first question.

BRs

Gang

---

From: <[email-masked]>
Date: Thu, 13 Jan 2011 16:19:40 +0800

|> ==>First, NAT1 will not have this binding until it receives any PCP 
|> requests from this client;  second, the internal port of binding is 
|> NOT the same as internal port in the PCP payload;  so, assuming the 
|> binding A0:P0<=>A1:P1, and the PCP request should be
|> (payload: (internal ip: A0, internal port Px).
|
|It depends specific use cases. "Using PCP to Eliminate 
|Application Keepalive Messages" could be the case.

==> I agree with you, it may happen that the payload port eqauls to
binding port. 

|>
|> ==> The ALG will NOT rewrite this packet since fisrt its 
|Niether come 
|> from its "WAN" interface Nor its paylaod contains a payload on a 32 
|> bit boundary that matches the NAT-1's WAN address A1. Besides, the 
|> payload will NOT match any NAT bindings either.

==> Still, this PCP request does not satisfy the criteria to be applied
this kind of ALG.

|I think that is related to first question.

==> what makes you think it's different?

|
|BRs
|
|Gang
|

BR,
Xiaohong

---

From: <[email-masked]>
Date: Thu, 13 Jan 2011 16:19:47 +0800

|Don't over-think it.  The NATs with this behavior are only 
|seeing packets going in and packets going out.  Simplified, they do:
|
|  host----[NAT with (broken) UDP ALG]---------[network]
|
|The problem is when the "NAT with the (broken) UDP ALG" device 
|sees a UDP packet arrive from the right network (its "WAN" 
|interface) and that UDP packet contains a payload on a 32 bit 
|boundary that matches the NAT's WAN address, the NAT will 
|change those 32 bits.
|It changes the 32 bits to become the internal host's IP address.

==> My point is I don't  see that PCP request/response will satisfy the
criteria that been rewirtted by this kind of crazy NAT. Because there is
no NAT's WAN address in the PCP response. The internal-ip-address filed
of the PCP response should be the internal ip address of the PCP client
instead of the NAT's WAN address.  That's my understanding. Please
correct me.

|When PCP is added to the mix, the question is:  when a PCP 
|message accidentally (1) or purposefully (2) traverses such a 
|NAT, do we want PCP to protect its payload from such a NAT?
|
|On (1), accidental may happen if a subscriber installs one of 
|these NATs in their home network.  The one that has been 
|sitting in their garage, for example.  Or a new one they 
|bought at a computer store.  We don't know, and can't control, 
|what sort of crazy ALGs are running in NATs.  We _know_ that 
|some NATs have done what is described in the top of this message.

|On (2), we might want to traverse a NAT, on purpose, to 
|support nested NATs.  Again, we don't know and can't tell if a 
|NAT does this sort of UDP payload modification.
|We can protect against it, though.

==> Anyway, I agree with you that the point is it to make it work. When
it comes to the goals of addressing it, I wonder which one is of higher
priority. 

BR,
Xiaohong

|
|-d
|
|> -----Original Message-----
|> From: GangChen [mailto:[email-masked]]
|> Sent: Wednesday, January 12, 2011 10:21 PM
|> To: [email-masked]
|> Cc: [email-masked]; [email-masked]; [email-masked]; 
|> [email-masked]
|> Subject: Re: [pcp] XOR IP address in payloads
|> 
|> >
|> > Would you explain why? I don't see why NAT-1 translates UDP
|> payload/PCP
|> > request from (internal ip: A0, external port: Px) to (internal ip:
|> A1,
|> > external port: Py),
|> > because  NAT-1s' WAN address A1 does *not* present in the PCP 
|> > request sent by host, even if "These overzealous ALGs modify UDP 
|> > packets
|> *where*
|> > the
|> > NAT's WAN address is in the UDP payload on a 32 bit boundary. "--
|> Quoted
|> > from Dan's reply
|> 
|> 
|> Let's see. NAT1 has the binding A0:Px<=>A1:Py. When PCP client send 
|> PCP request(payload: (internal ip: A0, internal port Px). 
|The ALG hunt 
|> for IP address and rewrite,since they match a binding. PCP request 
|> payload is translated by NAT 1 to (internal ip: A1,external 
|port: Py).
|> The NAT2 responses PCP request (internal ip: A1,external 
|port: Py),and 
|> replies with payload: (external ip: A2 (orany other IP addresses in 
|> NAT 2's address pool), internal IP address A1:Py).
|> 
|> That is my understanding. Please correct me.
|> 
|> BRs
|> 
|> Gang
|
|

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 13 Jan 2011 00:29:52 -0800

> Sent: Thursday, January 13, 2011 12:20 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; lan.wang@orange-
> ftgroup.com
> Subject: RE:[pcp] XOR IP address in payloads
> 
> 

The internal-ip-address could be the NAT's WAN address:

  * after doing STUN (RFC5389) and then using PCP (and putting the
    learned IP address into PCP's internal-ip-address field)
or
  * after doing STUNT (http://nutss.gforge.cis.cornell.edu/stunt.php)
    and then doing PCP (and putting the learned IP address into
    PCP's internal-ip-address field)
or
  * doing the Nested NAT procedure described on slides 7-9 of 
    ftp://ftp-eng.cisco.com/dwing/pcp/pcp-nested-nat.pdf

Do we want PCP to forever fail (in obscure ways) with NATs that rewrite
UDP payloads such as I have described, or do we want PCP to work 
with such NATs.

Teredo and STUN decided the additional complexity of an XOR 
operation was worthwhile and necessary for their protocols.

I don't know all of the ways PCP might be deployed, and we (the
industry) do not know how often these horrible UDP ALGs
occur in the wild.  To my eyes, the safest thing is to prevent
the problem from occurring, such as XORing the address.

>   2. Detect multiple existing NAPTs

I stated my goals for nested NAT in another email.  I'm happy to
discuss those goals or re-prioritize them.  At this point, I don't
see much interest in the problem and I do not expect to include
anything about nested NAT in draft-ietf-pcp-base, other than "it
won't work without extensions to PCP and without documented
procedures".

-d

---

From: <[email-masked]>
Date: Thu, 13 Jan 2011 17:17:00 +0800

|> |Don't over-think it.  The NATs with this behavior are only seeing 
|> |packets going in and packets going out.  Simplified, they do:
|> |
|> |  host----[NAT with (broken) UDP ALG]---------[network]
|> |
|> |The problem is when the "NAT with the (broken) UDP ALG" 
|device sees a 
|> |UDP packet arrive from the right network (its "WAN"
|> |interface) and that UDP packet contains a payload on a 32 bit 
|> |boundary that matches the NAT's WAN address, the NAT will change 
|> |those 32 bits.
|> |It changes the 32 bits to become the internal host's IP address.
|> 
|> ==> My point is I don't  see that PCP request/response will satisfy 
|> the criteria that been rewirtted by this kind of crazy NAT. Because 
|> there is no NAT's WAN address in the PCP response. The 
|> internal-ip-address filed of the PCP response should be the internal 
|> ip address of the PCP client instead of the NAT's WAN 
|address.  That's 
|> my understanding. Please correct me.
|
|The internal-ip-address could be the NAT's WAN address:
|
|  * after doing STUN (RFC5389) and then using PCP (and putting the
|    learned IP address into PCP's internal-ip-address field) or
|  * after doing STUNT (http://nutss.gforge.cis.cornell.edu/stunt.php)
|    and then doing PCP (and putting the learned IP address into
|    PCP's internal-ip-address field)
|or

==>Thanks for  your clearfication. I don't see as far as you.

|  * doing the Nested NAT procedure described on slides 7-9 of 
|    ftp://ftp-eng.cisco.com/dwing/pcp/pcp-nested-nat.pdf

==>When I saw the proposal for working over one existing NAPT in
people's homes  in the slides, I was thinking that if CPE support UPnP
IWG and the present apps that speaks UPnP to CPE will work well in CGN
scenarios, what will be the urgent need for app developers to implement
PCP client in their apps?

|
|Do we want PCP to forever fail (in obscure ways) with NATs 
|that rewrite UDP payloads such as I have described, or do we 
|want PCP to work with such NATs.
|
|Teredo and STUN decided the additional complexity of an XOR 
|operation was worthwhile and necessary for their protocols.
|
|I don't know all of the ways PCP might be deployed, and we (the
|industry) do not know how often these horrible UDP ALGs occur 
|in the wild.  To my eyes, the safest thing is to prevent the 
|problem from occurring, such as XORing the address.
|
|> |When PCP is added to the mix, the question is:  when a PCP message 
|> |accidentally (1) or purposefully (2) traverses such a NAT, 
|do we want 
|> |PCP to protect its payload from such a NAT?
|> |
|> |On (1), accidental may happen if a subscriber installs one of these 
|> |NATs in their home network.  The one that has been sitting in their 
|> |garage, for example.  Or a new one they bought at a 
|computer store.  
|> |We don't know, and can't control, what sort of crazy ALGs 
|are running 
|> |in NATs.  We _know_ that some NATs have done what is 
|described in the 
|> |top of this message.
|> 
|> |On (2), we might want to traverse a NAT, on purpose, to support 
|> |nested NATs.  Again, we don't know and can't tell if a NAT 
|does this 
|> |sort of UDP payload modification.
|> |We can protect against it, though.
|> 
|> ==> Anyway, I agree with you that the point is it to make it work. 
|> When it comes to the goals of addressing it, I wonder which 
|one is of 
|> higher priority.
|> 
|>   1. Work over one existing NAPT in people's homes
|>   2. Detect multiple existing NAPTs
|
|I stated my goals for nested NAT in another email.  I'm happy 
|to discuss those goals or re-prioritize them.  At this point, 
|I don't see much interest in the problem and I do not expect 
|to include anything about nested NAT in draft-ietf-pcp-base, 
|other than "it won't work without extensions to PCP and 
|without documented procedures".
|
|-d
|
|> BR,
|> Xiaohong
|> 
|> |
|> |-d
|> |
|> |> -----Original Message-----
|> |> From: GangChen [mailto:[email-masked]]
|> |> Sent: Wednesday, January 12, 2011 10:21 PM
|> |> To: [email-masked]
|> |> Cc: [email-masked]; [email-masked]; [email-masked]; 
|> |> [email-masked]
|> |> Subject: Re: [pcp] XOR IP address in payloads
|> |>
|> |> >
|> |> > Would you explain why? I don't see why NAT-1 translates UDP
|> |> payload/PCP
|> |> > request from (internal ip: A0, external port: Px) to 
|(internal ip:
|> |> A1,
|> |> > external port: Py),
|> |> > because  NAT-1s' WAN address A1 does *not* present in the PCP 
|> |> > request sent by host, even if "These overzealous ALGs 
|modify UDP 
|> |> > packets
|> |> *where*
|> |> > the
|> |> > NAT's WAN address is in the UDP payload on a 32 bit 
|boundary. "--
|> |> Quoted
|> |> > from Dan's reply
|> |>
|> |>
|> |> Let's see. NAT1 has the binding A0:Px<=>A1:Py. When PCP 
|client send 
|> |> PCP request(payload: (internal ip: A0, internal port Px).
|> |The ALG hunt
|> |> for IP address and rewrite,since they match a binding. 
|PCP request 
|> |> payload is translated by NAT 1 to (internal ip: A1,external
|> |port: Py).
|> |> The NAT2 responses PCP request (internal ip: A1,external
|> |port: Py),and
|> |> replies with payload: (external ip: A2 (orany other IP 
|addresses in 
|> |> NAT 2's address pool), internal IP address A1:Py).
|> |>
|> |> That is my understanding. Please correct me.
|> |>
|> |> BRs
|> |>
|> |> Gang
|> |
|> |
|
|

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 13 Jan 2011 01:56:05 -0800

...
> PCP client in their apps?

There are two ways an application can get a pinholes created so the
application can operate a server:

  * Add PCP to their applications (or calling OS-provided frameworks),
    to speak directly to the ISP's large-scale NAT.  And, if there is
    also another NAT in the home, speak to it using UPnP IGD.  This
    may require telling the user to enable UPnP IGD on their existing
    NAT (as many are shipped with it disabled at the factory or by
    the ISP's preference [for CPE partially managed or shipped by 
    the ISP]).
OR
  * Tell the user (trying to use the application) to buy a new NAT,
    specifically a new NAT that includes a UPnP IGD->PCP interworking 
    function.  This is an additional $40-80 cost to the user, and this
    new NAT may not include the features of their old NAT (some NATs
    include Z-Wave or ZigBee radios (for home automation), others include 
    NAS disks, 802.11n with fancy-sounding acceleration technology, 
    and so on).
OR
  * Tell the user to throw away the existing NAT in their home.  This
    causes a loss of functionality to the user, such as losing WiFi
    in a part of their house, reconfiguring their network, etc.  The
    user must have purchased and installed the NAT for some legitimate
    reason, afterall.

Maybe there are more options.

I expect the first option will be most successful.

-d

---

From: Francis Dupont <[email-masked]>
Date: Fri, 14 Jan 2011 17:44:12 +0100

=> note if it doesn't support a pcp (lower case, i.e., no NAT-PMP,
UPnP IGD, PCP, Web interface, etc) then it is not possible to
create any port forwarding through it.

   You're referring to the nested NAT case, where the intermediate NAT acts
   like both PCP Client and PCP server.

=> this is not so clear: even it is technically possible IMHO one
should not send a request to the first NAT believing this NAT will
handle the whole chain. At the opposite the NAT chain should be
handled by the host, i.e., the host creates a port forwarding
by sending requests to each NAT.
To make things more complex an intermediate NAT can run a proxy
in order to enforce security, change transport (cf. DS-Lite), etc.
But IMHO in this case it should not change the content of requests.

Regards