Re: 52 - security of address updates

<[email protected]> Mon, 24 Oct 2005 14:18:13 +0300
Newsgroups gmane.ietf.mobike
Message-ID <[email protected]>
Jari Arkko wrote:
> There seems to be six issues:
> 
> 1) Noting that mobike hosts are more vulnerable to various
>     attacks than static hosts, due to the variety of links they visit
> 
>     We can do this. Add this to Section 6, first paragraph, between
>     the first and second paragraphs: "Mobile nodes are also more
>     likely to encounter malicious environments, given the many
>     networks that they travel in."

This text is confusing "mobile node" and "node implementing MOBIKE".
E.g. my laptop is already a "mobile node", and visits malicious 
environments. Adding MOBIKE would make it less cumbersome for me 
(no need to find my SecurID token etc.), but it does not change
the environment...

<snip>
    can be used is another matter).
> 
> 3) Defense 1: use NO_NATS_ALLOWED if on a public address
> 
>     This would be good to have as an option. Here's some
>     suggested text:
> 
>     Insert to 4.8, at the end of the 2nd paragraph:
>    
>     An initiator may also have a policy that if it
>     has an address that is know to be a public address,
>     it employs NO_NATS_ALLOWED. This prevents the
>     vulnerability to address changing attacks when
>     the node has an obviously public address. (However,
>     some firewalls may require UDP encapsulation
>     to be used even in such cases.)

IMHO the leap from "public address" to "no NAT" is not correct.
IKEv2 NAT-T does the right thing, and does not try to hard-code
lists of addresses which are NATted: it's much better to just
detect that. 

BR,
Pasi