Re: Comments on draft-mohanp-mobike-nat-00.txt

Jari,

Thanks for your comments. My comments in-line...

> 
> Thank you for this draft! It does show one simple way
> of authenticating NAT-based addresses.
> 
> A couple of comments and/or questions:
> 
> >    The solution described in this document may not work with all NAT  
> >    devices. It assumes that Network address Port Translation (NAPT) is  
> >    used by the NAT device. It also does not work with multiple NAPT  
> >    devices in the path. The solution is mainly targeted for SOHO type  
> >    environments where there is a NAPT with public address on one side  
> >    and a DHCP server to allocate private addresses on the other side.  
> 
> We have to discuss how big this limitation is. A NAT at the
> ISP and another NAT at the home WLAN/router/firewall box
> is a common configuration.
> 
Agreed. But there may be other mechanisms to learn the NAT bindings.
For example, there might be other applications on the node that uses
STUN to learn the NAT bindings. One could potentially learn the
NAT binding and use it across all applications including IKE. STUN
does provide some security, but we need to understand it a bit more. 
If someone can forge the address during this process, then we can't
prevent the 3rd party bombing attack. Also, this might introduce additional
latency. Perhaps, still better than re-negotiating a new SA.

> OTOH, it seems that your solution *could* work even across
> multiple NAPT devices, as long as the host can learn the
> true public IP address. For instance, if my ISP sends a
> DHCP option to my home box about the public IP address, then
> my home box can do NAT and send this same option to the hosts
> in my home network.
> 
Yes. That should be possible. I was too biased about the setup i have
at home :-)

> > 4.0 DHCP option  
> >   
> >    This option is used to indicate the presence of NAT in the network by  
> >    including the public address of the NAT. The option SHOULD be  
> >    included by the DHCP server in the DHCPACK packet if there is a NAT  
> >    present in the network and the public address of the NAT is known.  
> >    The format of the option is as follows.  
> 
> I wonder if there's a chicken and egg problem here. Remember that
> we started from wanting to authenticate addresses, including those
> inserted by NATs. Now, the only simple way I see the DHCP server
> can know the address is that it is in the same box as the NAT is.
> 
Agreed. We should still try to explore other ways as i described above.

> This means that you'll be trusting the information from the NAT
> box, through DHCP. But the NAT could still lie.
> 
> Of course, this does help in the sense that now only your home
> NAT box can lie about your address, not anyone else on the path.
> 
Yes, the whole thing hinges on how securely you can learn
the address to begin with.
 
> >      5) The peer on receiving the MOBIKE address update packet verifies  
> >         that the public address in the payload matches the address on  
> >         the IP header. If not, it drops the packet as it implies that  
> 
> Besides DHCP, you could use also other local information to
> ensure that rogue "NATs" do not change your addresses. For instance,
> you could dynamically discover the IP address after a movement,
> but not accept any new public addresses later unless you move.
> 
Yes, that should add some robustness.

Thanks
mohan

> --Jari
> _______________________________________________
> Mobike mailing list
> [email protected]
> https://www.machshav.com/mailman/listinfo.cgi/mobike