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

Mohan,

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.

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.

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

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.

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

--Jari