Issue: When to do return-routability tests (#6)

This issue is about when to do return routability checks.
Note: There are some further protocol details (#12, #15).
We can discuss them later, but before that we need to
discuss when the checks are needed.

Basically, the purpose of the return routability tests
in this context is to avoid 3rd party bombing attacks. The
scenario is that the attacker claims that he has moved to
the victim's location, and the victim then gets the traffic
that was destined to the attacker. This can be troublesome
particularly if we talk about TCP or other streams. (Note
that the attacker can in some cases send faked TCP ACKs or
similar to keep the stream going for a while, since they
learned the TCP sequence numbers from the initial part of
the stream.)

There is nothing new in such attacks per se -- attackers can
already send a packet to the victim directly or through some
reflecting service; there have been known cases where DNS
infrastructure, for instance, was used as the reflecting
service. However, when we talk our scenario, attackers may
gain some amplification for their attack, making it easier
to launch a bigger attack with the same fixed amount of
resources.

The issue also has to do with the relationship of the
two peers using IKEv2. When they are part of the same
organization, getting a stream of packets from their
SGW would lead you to complain to their administration,
and the rogue peer would be shut down. OTOH, this can only
be done after the fact, and assumes that the two peers
really have a relationship. (Such relationships might not
exist in the case of opportunistic IPsec, for instance,
or if you used Verisign as your trust root. Both Mobile
IPv6 and HIP have the assumption of no relationship
between the parties.)

As Tero pointed out in another e-mail (and Francis has
reported earlier), NAT-T has no protection against such
issues. Basically, an authentic packet with a new
address causes the traffic to be moved to that address
without verification. If you are satisfied with this,
the UDP encapsulation overhead, and possibly weaker support
for failover, you could actually use just NAT-T instead of
MOBIKE.

Here's some reading material related to the issue:

     - draft-ietf-mip6-ro-sec-00.txt (Section 3.2)
     - draft-dupont-mipv6-3bombing-00.txt (all of it)
     - draft-dupont-transient-pseudonat-03.txt (all of it)
     - draft-vogt-mipv6-credit-based-authorization-00.txt (Section 3)

So, here's some of the options we have:

- No tests at all. (Then you might ask whether NAT-T is
   sufficient.)

- Mandatory tests all the time, done before the traffic is moved.
   Implies one RTT delay.

- Mandatory tests all the time, done in parallel with the traffic
   movement. No delay, but some small amount of amplification may
   still be possible. This approach is similar to draft-vogt-mip6-
   early-binding-updates-00.txt, which was later abandoned for
   another scheme.

- Some research-class solution to have no delay and still
   avoid amplification. See draft-vogt-mip6-credit-based-authorization-00.txt.
   (But these are complicated schemes and very new technology.
   Might be against our charter.)

- Tests done prior to moving the traffic stream, but allow
   the tests to be configured off.

Also, we need to decide what level of protection the tests
should provide. It seems that we have the following options:

- None, no tests.

- A party willing to answer is on the path to the claimed
   address. This is the basic form of return routability
   test.

- There is an answer from the tested address, and that
   answer was authenticated (including the address) to be
   from our peer.