Re: Third proposal: MOBIKE

Hi Pasi,

And thanks for your proposal, I think it brings
up very important points. The actual protocol
that you suggest also seems very promising.

Some discussion below:

>       SMOBIKE works fine, except in some variations of simultaneous
>       address change (see below).  This case is typical in multihoming

I believe this is true of the other proposals as
well. I don't think handling it is a requirement
for MOBIKE; lets leave that to other mobility
protocols.

Note: this will still work in the multihoming case,
the failure will occur only if you actually had to
give both of the addresses the peers used for
communication.

>       other party is be mobile and/or multihomed, and sometimes behind a

s/is be/is/

>    Assuming that simultaneous mobility is not very important, this
>    analysis would seem to indicate that more complex solutions are
>    justified only if they not only handle cases #1-#3, but also improve
>    case #4. Not handling case #2 would in our opinion be a serious
>    deficiency.

This looks like a valid analysis. (Personally, I'd be willing to
compromise on some cases even in #2.)

At this point I'm not very convinced that we need to provide
a solution for #4. Have you looked at the other two proposals
to see if they actually can handle #4?

>    SMOBIKE does not support moving traffic to a new address before the
>    host is able to send packets using the new address as a source
>    address. Other than that, SMOBIKE works for both "break-before-make"
>    (snip)

Personally, I don't consider this to be a limitation.
Typically, return routability tests on mobility protocols
require the ability to send from an address anyway.
There have been some recent proposals in the MOBOPTS RG
about advanced schemes where you can actually send some
traffic before completing a test, by tracking the effort
the mobile node has spent before the move and comparing
it to the harm it would cause if the address turned out
to be fake. However, its very advanced stuff and certainly
beyond our charter to attempt something like that for
MOBIKE.

>    In the "transient pseudo-NAT attack" [3], an attacker intercepts
>    authenticated packets and changes their source IP address (and port).
>    As a consequence the recipient will start using the incorrect peer

I don't believe this is a significant issue, because
an attacker who is on the path can cause similar problems
in any case, whether or not there was any IPsec, IKE, or
NAT traversal present.

>    In "third party bombing" [2], a valid peer redirects its traffic to
>    some third party with the intent of flooding the victim with large

I personally believe this is something that we need
to deal with. But its fair to say that different people
have had different opinions about this, e.g., in the
context of Mobile IPv6. The primary worry that I have
is getting DoS amplification, e.g. 10 packets to
get things going and 1000 packets to the victim until
the sender realizes the other party is not responding.
Other people have said that they consider virus-infected
PCs or non-ingress filtered networks already bad enough
that such amplification does not matter.

But maybe this is very Mobile IPv6 specific, reading
on...

>    attack instead. A regular IKEv2 dead peer exchange will also detect
>    third party bombing.

Presumably with some delay, however. How large amplification
factors would we be talking about here?

>    Both attacks require that the adversary is along the data path. Note
>    that unlike, for instance, in standard Mobile IP, IPsec protects the
>    transmitted payloads from eavesdropping and modification, and thus
>    the consequences of traffic redirection are different.

If we concentrate on the bombing issue, eavesdropping is not
an issue per se. But we need to look at the requirements for
the attacks to occur:

- Have to be on path; otherwise you don't see the
   authenticated packets that you need to modify.

- Attack initiated either by the real peer or the
   on-path attacker.

- Need to establish a high-bandwidth stream either
   from the peer or through the peer.

- Stream hitting a third party has many more packets
   than what the attacker had to modify or send.

> Even if the MOBIKE extensions
> had more complex return routability checks, the attacker could claim
> not to support them, and use normal IKEv2 NAT Traversal for the
> attack instead.

That's right. And we are not chartered to fix the IKEv2 NAT
traversal feature. However, personally I would still like to
make the MOBIKE protocol as secure as it can/need be, irrespective
of the possible issues in the NAT traversal protocol. I might
have a policy of using MOBIKE, but disallowing NAT traversal.

>  It might be worth mentioning that a truly secure NAT traversal can be
>  accomplished only if the client can determine which NAT devices are
>  actually authorized to modify the addresses, and communicate with
>  them in secure fashion to determine the current mappings. This
>  requires a protocol for communicating with the NAT, such as NSIS. A
>  detailed discussion of these approaches is far beyond the scope of
>  this document.

Personally, I wouldn't put my hopes up for achieving something
like this. Lets try to do the best we can without assuming
it.

--Jari