Subject: [Mobike] Comments on draft-mohanp-mobike-nat-00.txt

From: Jari Arkko <[email-masked]>
Date: Sat, 31 Jul 2004 10:09:37 +0300

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
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Sat, 31 Jul 2004 16:09:07 -0700

Jari,

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

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

> my home box can do NAT and send this same option to the hosts
Yes. That should be possible. I was too biased about the setup i have
at home :-)

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

> 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.
 
> but not accept any new public addresses later unless you move.
Yes, that should add some robustness.

Thanks
mohan