Subject: [Mobike] Issue: When to do return-routability tests (#6)

From: Jari Arkko <[email-masked]>
Date: Wed, 23 Jun 2004 14:53:11 +0300

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.
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: "Dondeti, Lakshminath" <[email-masked]>
Date: Wed, 23 Jun 2004 11:12:48 -0400

Please see inline:

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

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

>   avoid amplification. See 
> draft-vogt-mip6-credit-based-authorization-00.txt.

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

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

>   answer was authenticated (including the address) to be

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

---

From: Jari Arkko <[email-masked]>
Date: Thu, 24 Jun 2004 10:10:55 +0300

> should introduce a nonce for liveness of the test.  I still like that 

Yes.

This is a related issue, but partly different too. I agree that
empty informational exchanges are not sufficient for an RR
test, and a nonce is needed. Basically, an empty informational
exchange just proves that the answer came from the peer, but
not that it came from the address we wanted to test. I guess
you could amend my list above as follows;

  - None, no tests.

  - There was an authenticated answer from the peer, but
    it is not guaranteed to be from the tested address
    or path to it (because the peer can construct a
    response without seeing the request).

The last option corresponds to making an empty informational
exchange. I think the first and the last options are not
practical options; its either the second or the third
option that we should adopt.

--Jari

---

From: Francis Dupont <[email-masked]>
Date: Thu, 24 Jun 2004 19:57:39 +0200

In your previous mail you wrote:
   
   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.
   
=> there is a little difference with the DNS reflection example:
for the victim the traffic is full IPsec garbage, it cannot
get an idea of the reflecting application/service for instance.

   two peers using IKEv2.

=> I agree: usually this relationship includes some kind of trust.

   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.

=> this is the argument used in MIPv6 to avoid an extra return
routability check between a mobile node and its home agent.
Of course it should be applied to the nomadic client and its
security gateway case too.

   OTOH, this can only
   
=> BTW in HIP at most one party can use an anonymous identity
so at least one party uses an authenticated identity, so there
should be a beginning of relationship (unfortunately usually
not for the moving party :-).

   issues.

=> the summary is with a NAT you have no control over the NAT
and no trust in it, and the NAT is the box which changes your
address.

   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,

=> this weaker support comes from the NAT behavior, i.e., don't
expect that something which is known to not work with a NAT in the
path works when you use NAT-T without a NAT in the path.
Perhaps we should add AH in this list?

   you could actually use just NAT-T instead of MOBIKE.

=> as I wrote this is not a stupid option, and obviously
it is compatible with NAT-T in all cases (:-)!

   
   
=> IMHO this is a pure policy option, i.e., we have a lot of time
to solve it.

=> IMHO it should be the default policy (rationale: when you don't trust
the other party please don't run IKE with it).

=> when you'd like to be paranoid, please be paranoid...

=> half-backed solution (I don't like it at all).

=> I don't like this too and our charter says MOBIKE is an *IETF* WG.

=> make no sense as the issue is about policy: list possible policies,
select some of them, elect one as the default policy.

   - None, no tests.
   
=> this is about mechanism so the first item has no meaning.

=> IKEv2 provides more (the origin of the answer is always
authenticated).

=> I don't understand what is "including the address" but this
is in some other messages...

Regards

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

---

From: Francis Dupont <[email-masked]>
Date: Thu, 24 Jun 2004 20:10:03 +0200

> should introduce a nonce for liveness of the test.  I still like that 
   
=> if I understand the issue: the attacking peer doesn't get the
RR probe but infers its (empty) content and answers...
   
   not that it came from the address we wanted to test.

=> I disagree with your wording, the issue is not it came
from the address we wanted to test, it is the peer really got
the probe.

   I guess you could amend my list above as follows;

=> I really prefer this wording.

=> so it will be the third (informational exchanges with nonces,
BTW IKEv2 doesn't really constraint the contents of informational
messages, so this is compatible/available).

Regards