Re: [BEHAVE] Scalability of endpoint independent mapping

["Dan Wing" <[e-mail]>]

 

> -----Original Message-----
> From: Iljitsch van Beijnum [mailto:[e-mail]] 
> Sent: Wednesday, May 14, 2008 10:23 AM
> To: Dan Wing
> Cc: 'Philip Matthews'; [e-mail]
> Subject: Re: [BEHAVE] Scalability of endpoint independent mapping
> 
> On 14 mei 2008, at 18:33, Dan Wing wrote:
> 
> >> If an application wants to make use of endpoint independent mapping
> >> behavior by the NAT, wouldn't its first packets be towards 
> a STUN(T)
> >> server? If we can detect this, providing endpoint independent
> >> behavior where it's needed and using endpoint dependent mappings  
> >> everywhere
> >> else is easy.
> 
> > Someone else (Rémi Després, I believe) had proposed doing that using
> > port numbers.  Doing it with port numbers would also be the 
> first time
> > that TCP behavior is different for different port numbers (the port
> > 1024 restriction does not change the behavior of TCP itself).  But
> > I see (below) that you are considering DPI rather than TCP port
> > numbers.
> 
> I was.
> 
> If STUN always uses port 3478 then that's obviously a good way to  
> detect sessions towards a STUN server.
> 
> So if a host first contacts some random destination using 
> source port  
> 8000 and destination 3478, we know it's talking to a STUN 
> server so we  
> need to make the mapping for source port 8000 address 
> independent. But  
> if a session goes towards port 80 or what have you and the 
> source port  
> isn't used in recent history by that host, we know the host doesn't  
> require endpoint independent mapping.
> 
> > Another idea floating in my head is to use STUN-over-TCP to the
> > NAT64's public IP address itself, which is trivial for the NAT64
> > to notice.
> 
> Yes, but how do hosts know to only use the NAT64's address as their  
> STUN server?
> Don't STUN-aware applications use STUN servers that are 
> preconfigured by the application?

Yes, so you could configure that application so its STUN server is
the public IP address of the NAT64 box.  Or the application could
talk to any STUN server on the Internet and learn the IP address of
its NAT64 box (which is the mechanism described in 
draft-wing-behave-nat-control-stun-usage).

> >> For TCP, another option would be a TCP option in the SYN from
> >> the host to the STUNT server, or in the SYN/ACK from the STUNT
> >> server back to the host, this is probably easier to do than deep
> >> packet inspection to determine whether a random TCP session is
> >> used for STUNT.
> 
> > If the NAT64-aware box at the customer premise could make 
> > the decision
> > (somehow; I'm not sure how it could do that yet), the 
> > NAT64-aware box
> > could communicate the decision to the ISP's big NAT64-box-in-the-sky
> > using a simple-to-see trigger like that.
> 
> Right. Maybe add a router alert for good measure.  :-)

heh.

> > Unfortunately the application and host OS (Windows, OSX) 
> > couldn't set
> > that TCP bit without changes to the TCP API and the TCP stack itself
> > - which means an OS upgrade or, at minimum (if the vendors are
> > motivated) an OS patch.
> 
> Right, that's why I was thinking the option could also flow in the  
> direction from the STUN server to the NAT. Presumably, a STUN server  
> can more easily be set up to include such an option.
> 
> But if we can simply look for port 3478 that's a lot easier.

I am worried that could tie NAT64 too much to STUN.

-d

_______________________________________________
Behave mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/behave