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

> -----Original Message-----
> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] 
> Sent: Thursday, October 25, 2007 6:42 AM
> To: safe@ietf.org
> Subject: [SAFE] Addressing nested NAT issues for STUN control
> 
> 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? 

Yes.

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

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

  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

  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

_______________________________________________
SAFE mailing list
SAFE@ietf.org
https://www1.ietf.org/mailman/listinfo/safe