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

Please see inline:

Jari Arkko wrote:

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

Not necessarily, MOBIKE still would have more functionality than NAT-T.

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

After a quick scan, I got the impression that perhaps this or similar 
schemes can be implemented by the server.

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

I think this is best, i.e., RR should be an option, that can be turned 
on either on a GW level or on a per IPsec association (based on the type 
of authentication of the client, say in RA scenarios).

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

We were considering another option (in early May): That an empty 
informational exchange for RR verification might not work and that we 
should introduce a nonce for liveness of the test.  I still like that 
option.

regards,
Lakshminath

> _______________________________________________
> Mobike mailing list
> [email protected]
> https://www.machshav.com/mailman/listinfo.cgi/mobike
>