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

[Magnus Westerlund <[e-mail]>]

See below

Dan Wing skrev:
>> -----Original Message-----
>> From: Magnus Westerlund [mailto:[e-mail]] 
>> Sent: Thursday, October 25, 2007 6:42 AM
>> To: [e-mail]
>> 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.
> 

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

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------


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