52 - security of address updates

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

2) The lack of address authentication

    This is due to NATs, and there's little we can do about
    it. NO_NATS_ALLOWED, however, fixes this (where it
    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.)

4) Defense 2: disallow movements on the same link

    I would rather not do this.  This would make RFC 3041 harder,
    and I'm not sure we can reliably detect when two addresses
    "are on the same link".

5) Is NO_NATS_ALLOWED mandatory if NAT-T is not supported

    It is. See 4.8 in -04.

6) Can the protocol recover from an attack when NO_NATS_ALLOWED
     is in use.

     I think it can. As part of some other issues we've inserted
     text that talks about retrying rather than giving immediately
     upon when an address appears to have changed.

--Jari