Subject: [SAFE] Addressing nested NAT issues for STUN control

From: Magnus Westerlund <[email-masked]>
Date: Thu, 25 Oct 2007 15:41:42 +0200

Hi,

Isn't there a related issue to what is brought up in section 8.1 in that
the STUN client will be able to send packets to that NAT.

If a NAT on the path has the same address as another NAT then you can
only send to the closest one.

STUN Client 192.168.1.2

NAT-A 192.168.1.1/10.0.0.45

NAT-B 10.0.0.1/192.168.1.2

NAT-C 192.168.1.1/192.0.2.53

In this case the STUN client can't send to NAT-B as there is no external
address which routes from STUN client to NAT-B.

Have you thought of this problem? I think this one is more serious as
private address spaces used on the internal side are limited to a few
common ones. And here it is likely that even if the client in the above
example wasn't using 192.168.1.2 then another host in his private
network would.

cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

_______________________________________________
SAFE mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/safe

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 25 Oct 2007 12:51:31 -0700

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]] 
> Sent: Thursday, October 25, 2007 6:42 AM
> To: [email-masked]
> Subject: [SAFE] Addressing nested NAT issues for STUN control
> 
> Hi,
> 
> Have you thought of this problem? 

Yes.

> I think this one is more serious as

I know a way to detect such an address overlap has occurred, and abandon
STUN Control in that situation.  The only way to allow STUN Control to
work is to have each NAT participate as a STUN Control client itself
(and control the next-hop NAT).  This could work, but I haven't put much
thought into that and it seems to get complex quickly.

Detecting address overlap
-------------------------

If we want to merely detect address overlap (so that STUN Control can
be abandoned), we would need to add a way for each NAT to identify itself 
uniquely, and allow the outer NAT to learn that unique identifier from its
next-innermost NAT.  Using your example above:

  STUN Client 192.168.1.2

 

  STUN server 161.44.1.1 (on the Internet)

The STUN client would contact the STUN server on the Internet and learn the
public IP address (192.0.2.53) of the outer-most NAT (NAT-C).  The STUN client
would then send a STUN Control message to that public IP address on the STUN
port 192.0.2.53, UDP port 3478.  NAT-C would receive that message.  What we
would add to the existing STUN Control procedure is to have NAT-C then send
its own STUN Control message to the STUN port of the next-innermost NAT's IP
address (this is the IP address NAT-C normally sends in XOR-INTERNAL-ADDRESS),
and collect a NAT-IDENTIFIER value in the response.  NAT-C would include that
NAT-IDENTIFIER value  to the STUN client.  Then, when the STUN client tries to
contact 192.168.1.1, and sees a different NAT-IDENTIFIER value, it knows it is
talking to a different NAT.  The STUN client could then abandon the STUN
Control optimization.

Message flow:

  STUN Client   NAT-A   NAT-B  NAT-C  STUN Server
      |           |       |      |        |
1.    |---------------------------------->|
      |           |       |      |        |
2.    |<----------------------------------|
      |           |       |      |        |
3.    |------------------------->|        |
      |           |       |      |        |
4.    |           |       |<-----|        |
      |           |       |      |        |
5.    |           |       |----->|        |
      |           |       |      |        |
6.    |<-------------------------|        |    
      |           |       |      |        |
7.    |---------->|       |      |        |
      |           |       |      |        |
8.    |<----------|       |      |        |

1-2 are classic RFC3489 STUN.  Message 3 is the existing STUN Control request
message.  Messages 4-5 are new; In message 4, NAT-C sends a STUN request to
NAT-B.  Message 5 contains NAT-B's NAT-IDENTIFIER value.  In message 6,
NAT-B's NAT-IDENTIFIER value is returned (in a new NAT-IDENTIFIER-INTERNAL
attribute), and NAT-C's identifier is returned (in a new NAT-IDENTIFIER
attribute).  In message 7, the STUN client is sending a packet to NAT-B's
public IP address; however, this is also NAT-A's public IP address, so the
message is routed to NAT-A.  In message 8, the STUN client learns NAT-A's
NAT-IDENTIFIER value, and sees it differs from the value returned in message
6.  This causes the STUN client to abandon STUN Control.

Today, STUN Control encourages the NAT to not listen on the STUN port on its
public (WAN) interface.  For this idea to work, that would need to be softened
so the NAT listens on its public interface has an RFC1918 address.

-d

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 26 Oct 2007 09:33:57 +0200

See below

> Detecting address overlap

Are you not misstating yourself here? Section 5.1 in the draft states
the following:

  "After learning the public IP address of its outer-most NAT, the
   endpoint sends a STUN packet to the STUN port (UDP/3478) of its
   outer-most NAT's public IP address. "

And for the whole walk from out to in you only know the external IP
address of the NAT.

I thought the issue with my example is that when stun client tries to
send to 192.168.1.2/3478 it will only reach itself. Rather then being
issues to send to the gateway address.

My initial reaction is that this is a big limitation. Nested NATs seems
to be the most common case when STUN control would provide any serious
benefit.

Cheers

Magnus Westerlund

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 26 Oct 2007 00:56:23 -0700

...
> issues to send to the gateway address.

Either way, the STUN client has reached an incorrect conclusion:  the
STUN client is unaware of a NAT.  My proposal to use NAT-IDENTIFIER
prevents that incorrect conclusion.

> My initial reaction is that this is a big limitation. Nested 
> NATs seems to be the most common case when STUN control would provide 
> any serious benefit.

Let's separate (a) nested NATs with non-overlapping IP addresses from 
(b) nested NATs with overlapping IP addresses.  I believe STUN Control
works fine with (a), and you are pointing out that it doesn't work
well with (b).  (Let me know if I'm correct on that point.)

To resolve overlapping IP addresses, first we need to see how to
detect that, and then avoid doing STUN Control.  It might also be
possible, by doing more creative things, to have the outer-most
NAT contact the NATs on the inside by itself (and repeat that
procedure on each inner NAT).  I'm worried that could cause some
horrid security implications (packet expansion) and have not 
investigated it.  That is why I proposed in my previous email
a mechanism to use NAT-IDENTIFIER to detect NATs with overlapping
IP addresses.

-d

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 26 Oct 2007 10:07:41 +0200

> prevents that incorrect conclusion.

Sure, it is important to be aware of the situation.

> well with (b).  (Let me know if I'm correct on that point.)

Yes, that seems correct to me.

> a mechanism to use NAT-IDENTIFIER to detect NATs with overlapping

I am worried that NATs that hand out overlapping addresses will be
fairly common. Most home NATs or modems seem to use 192.168.1.1/26 as
default range to hand out and those will easily be nested.

But we maybe should avoid getting to far into this issue. I think the
main issue is that there need to be a discussion on how common is this
issue and do it needs to be solved. After answering these questions we
can start talking about a solution.

Cheers

Magnus Westerlund

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 26 Oct 2007 10:11:14 -0700

> > send to 192.168.1.2/3478 it will only reach itself. Rather 
> > then being issues to send to the gateway address.

I looked at your original email in more detail, and now understand
the case you were depicting.  In that case, the STUN client will
know the next-closer NAT has a certain NAT-IDENTIFIER value, and it
knows it isn't itself listening on UDP/3478, so it knows that
NAT-IDENTIFIER value came from an upstream NAT.

-d

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 29 Oct 2007 12:30:58 +0200

From a higher-level stand point:

> only send to the closest one.

This is a subset of the more general problem of overlapping net ranges. In 
that case, not only can't you reach the outer NAT, but you can't reach any 
node on the overlapping outer net.

As such, collecting "candidates" (in ICE sense) for that net is pretty 
useless, since you will not be able to communicate with any 
remote "candidate" from that same network.

As regard the binding refresh negociation, I would suppose the Tagging method 
could be made to work relatively easily, while indeed the Outside-In approach 
fails.

> example wasn't using 192.168.1.2 then another host in his private

Agreed. I would say this is unlikely to occur with 2 NATs, likely to occur 
with 3 of them, very likely with 4 or more.

In principle, off-the-shelves NATs should probably bridge rather than NAT when 
the outer network is using private space though. But I am not gullible enough 
to think they will.

As far as I can tell, the only way to properly solve this, would involve some 
kind of TURNish thing on the NAT. Basically, we'd end up doing source 
routing - which might bring some unwelcome security issues, and surely bad 
publicity.
For the ICE nested "candidate" scenario, this also adds significant complexity 
to the client side, as it involves adding "foundations" to each "components" 
(recycling ICE terminology).

-- 
Rémi Denis-Courmont

---

From: Philip Matthews <[email-masked]>
Date: Wed, 31 Oct 2007 08:36:47 -0400

> default range to hand out and those will easily be nested.

I think this is a hard question to answer without solid experimental  
evidence.

(As antidotal evidence, my home Internet access is through four levels
of NAT -- two in my house and two from my ISP, and I (at least) did  
nothing
to avoid IP address overlap.)

- Philip