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