--------------------

Tuomas Aura (2005-10-07):
https://www.machshav.com/pipermail/mobike/2005-October/001102.html

The security considerations section covers well the important
issues. However, I have the following comments and questions.

Comment 1:  

As explained in the security considerations section 6.1, an attacker
can spoof the source address of UPDATE_SA_ADDRESSES and, thus, cause
the responder to record the wrong address for the
initiator. Essentially, the attacker behaves as a NAT for selected
messages. I'd like to add the following observations:

- Mobike hosts are more vulnerable to this attack than non-Mobike
hosts that are behind a NAT and use IKE NAT-T negotiation (e.g., VPN
clients at a home LAN). This is because a mobile host is more likely
to visits untrusted access networks and to be exposed to attackers at
its local link.

- The sender-authentication of the address updates in Mobike is weaker
than it is in other mobility protocols like Mobile IPv6 or HIP where
the mobile's new address is included in the authenticated part of the
location update. This may be surprising because Mobike uses the strong
authentication provided by IKE.

- As a possible defense mechanism, the initiator local policy can be
configured to send NO_NATS_ALLOWED if and only if the initiator
address at the local link is private or link-local. This does not
require any changes to the specification.

- As another defense mechanism, the responder could reject address
updates where the initiator moves between two addresses on the same
local link. This would prevent attacks by the most likely type of
attacker that is on the same local link as the initiator and uses its
own address as the spoofed source address. In IPv6, it is obvious
which addresses are on the same local link. It should probably be the
initiator that makes the decision about such a policy, in the same way
as the initiator can decide whether to use NO_NAT_ALLOWED. In IPv4,
the address mask would need to be communicated to the responder. I
haven't considered the details.

Comment 2:  

If the initiator does not support NAT traversal, is it required to
send the NO_NATS_ALLOWED payload? Looks like this would make sense but
I cannot find it anywhere in the spec. Or does it make sense for an
initiator to behave otherwise.

Comment 3: 

Does the SA recover from the attack of comment 1 if NAT traversal is
not in use?

Consider an initiator and responder at least one of which does not
support NAT traversal, or an initiator that sends NO_NATS_ALLOWED. The
attacker is located on the route between the initiator and the
responder, for example, at the initiator's local link. The attacker
intercepts the UPDATE_IP_ADDRESS notification, modifies its source
address to be the attacker's address, and forwards the packet to the
responder. The attacker receives the response and forwards it to the
initiator. That is, the attacker behaves like a NAT for this one
address pair. The result is that the responder has records the wrong
address for the initiator. Moreover, the result of the NAT traversal
negotiation is that NAT traversal will not be used between these two
end hosts. The attacker now stops interfering with packets and leaves
the network. Can the SA recover?

The security considerations section 6.1 refers to "IKEv2 and Mobile
mechanisms designed to detect NAT mapping changes" as the recovery
mechanism. But these mechanisms will not kick in after the above
attack because NAT traversal is not in use. It looks like the SA won't
recover from this attack. Or is there some other recovery mechanism
that I have missed?

--------------------

Tero Kivinen (2005-10-10):
https://www.machshav.com/pipermail/mobike/2005-October/001110.html

>- The sender-authentication of the address updates in Mobike is
>weaker than it is in other mobility protocols like Mobile IPv6 or
>HIP where the mobile's new address is included in the authenticated
>part of the location update. This may be surprising because Mobike
>uses the strong authentication provided by IKE.

Yes, this is because of support for NAT-T. If you do not want to
support NAT-T you will use NO_NATS_ALLOWED and that will provide
stronger authentication.

>- As a possible defense mechanism, the initiator local policy can
>be configured to send NO_NATS_ALLOWED if and only if the initiator
>address at the local link is private or link-local. This does not
>require any changes to the specification.

I assume you meant to say, that allow NAT-T only for private or
link-local addresses, and use NO_NATS_ALLOWED if initiator have global
routable ip-addresses?

>- As another defense mechanism, the responder could reject address
>updates where the initiator moves between two addresses on the same
>local link. This would prevent attacks by the most likely type of
>attacker that is on the same local link as the initiator and uses
>its own address as the spoofed source address. In IPv6, it is
>obvious which addresses are on the same local link. It should
>probably be the initiator that makes the decision about such a
>policy, in the same way as the initiator can decide whether to use
>NO_NAT_ALLOWED. In IPv4, the address mask would need to be
>communicated to the responder. I haven't considered the details.

The problem there is to know which one to reject. If you select wrong
one, you block all updates from the real client, not the attacker.
There is not really way to detect which one is correct client. If the
client is not behind NAT, then using NO_NAT_ALLOWED will fix the
situation, and tell the other end which updates to reject.

>Comment 2:  
>
>If the initiator does not support NAT traversal, is it required to
>send the NO_NATS_ALLOWED payload? Looks like this would make sense
>but I cannot find it anywhere in the spec. Or does it make sense
>for an initiator to behave otherwise.

-04 says that all if NAT-T is not enabled, then messages which can
update address MUST include NO_NATS_ALLOWED.

>Comment 3: 
>
>Does the SA recover from the attack of comment 1 if NAT traversal
>is not in use?

If NAT traverseal is not in use (i.e. disabled), then that situation
cannot happen, as NO_NAT_ALLOWED will be used, and they will block all
updates by the attacker.

>Consider an initiator and responder at least one of which does not
>support NAT traversal, or an initiator that sends NO_NATS_ALLOWED.
>The attacker is located on the route between the initiator and the
>responder, for example, at the initiator's local link. The attacker
>intercepts the UPDATE_IP_ADDRESS notification, modifies its source
>address to be the attacker's address, and forwards the packet to
>the responder.

Responder will reject that packet because the NO_NATS_ALLOWED contents
do not match, and it will return error UNEXPTECTED_NAT_DETECTED. No
update happens. 

> The attacker receives the response and forwards it
>to the initiator. That is, the attacker behaves like a NAT for this
>one address pair. The result is that the responder has records the
>wrong address for the initiator. Moreover, the result of the NAT
>traversal negotiation is that NAT traversal will not be used
>between these two end hosts. The attacker now stops interfering
>with packets and leaves the network. Can the SA recover?

As no changes to SA happened, there is nothing to recover from. 

>The security considerations section 6.1 refers to "IKEv2 and Mobile
>mechanisms designed to detect NAT mapping changes" as the recovery
>mechanism. But these mechanisms will not kick in after the above
>attack because NAT traversal is not in use. It looks like the SA
>won't recover from this attack. Or is there some other recovery
>mechanism that I have missed?

You either have NO_NATS_ALLOWED or NAT_DETECTION_*_IP payaloads in the
updates, so either it enables NAT-T on that attack, or disallows NAT,
thus that should take care of that attack. 

--------------------

Jari Arkko (2005-10-24):
https://www.machshav.com/pipermail/mobike/2005-October/001177.html

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.

--------------------

Pasi Eronen (2005-10-24):
https://www.machshav.com/pipermail/mobike/2005-October/001195.html

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

--------------------

Jari Arkko (2005-10-24):
https://www.machshav.com/pipermail/mobike/2005-October/001197.html

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?

--------------------