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

 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.

   The issue also has to do with the relationship of the
   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
   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.)
   
=> 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 :-).

   As Tero pointed out in another e-mail (and Francis has
   reported earlier), NAT-T has no protection against such
   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 (:-)!
   
   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:
   
=> IMHO this is a pure policy option, i.e., we have a lot of time
to solve it.

   - No tests at all. (Then you might ask whether NAT-T is
      sufficient.)
   
=> IMHO it should be the default policy (rationale: when you don't trust
the other party please don't run IKE with it).

   - Mandatory tests all the time, done before the traffic is moved.
      Implies one RTT delay.
   
=> when you'd like to be paranoid, please be paranoid...

   - 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.
   
=> half-backed solution (I don't like it at all).

   - 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.)
   
=> I don't like this too and our charter says MOBIKE is an *IETF* WG.

   - Tests done prior to moving the traffic stream, but allow
      the tests to be configured off.
   
=> make no sense as the issue is about policy: list possible policies,
select some of them, elect one as the default policy.

   Also, we need to decide what level of protection the tests
   should provide. It seems that we have the following options:
   
   - None, no tests.
   
=> this is about mechanism so the first item has no meaning.

   - A party willing to answer is on the path to the claimed
      address. This is the basic form of return routability
      test.
   
=> IKEv2 provides more (the origin of the answer is always
authenticated).

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

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

Regards

[email protected]