Re: 52 - security of address updates

The first text appears to be correct (its the mobility,
not MOBIKE support that makes you more likely
to hit bad environments).

But maybe that's a moot point if your opinion is
that the heuristic for deciding about possible
existence of NATs is too weak and likely to cause
errors. It certainly can fail in the case of certain
firewalls where it would be better to run NAT-T.

I have some sympathy for this argument. This
would mean not adding anything about this
defensive policy to the document. What
do others think?

--Jari

[email protected] wrote:

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