Re: When to do Return Routability Checks

Tschofenig Hannes wrote:

> hi all,
>
> i would like to close the 'When to do Return Routability Checks' issue
> (which can be found at:
> http://www.vpnc.org/ietf-mobike/issue6.txt)
>
> please take a look at previous text in the design document on this issue:
>
> "
> 3.2 When to do Return Routability Checks
>
>    One of the decisions that needs to be done, when to do return
>    routability checks. The simple approach is to do it always.
>                                                       ^^^^^^^^
> [hannes] 'always' is not very precise.
>
>  Another
>    option is to do it every time new IP-address is taken in to use.
>
> [hannes] jari introduces useful terminology relevant for this sentence in
> <draft-arkko-multi6dt-failure-detection-00.txt>. we might want to use 
> some
> of it in mobike.
>
>  The
>    basic format of the return routability check could be similar than
>    dead-peer-detection, but the problem is that if that fails then the
>    IKEv2 specification requires the IKE SA to be deleted. Because of
>    this we might need to do some kind of other exchange.
>
>    If the other end is SGW with limited set of fixed IP-addresses, then
>    the SGW can get certificate having all the IP-addresses in the
>    certificate. If the certificate includes all the IP-addresses, it is
>    no point to do weaker return routability check, the data in the
>    certificate is already properly authenticated after the IKE SA is
>    created, so the peer might simply use that and ignore return
>    routability checks.
>
>    Another option is to use draft-dupont-mipv6-3bombing
>    [I.D.dupont-mipv6-3bombing] approach: do it only if you had to send
>    the update from some other address than indicated preferred address.
>
>    Final option would simply not to do return routability checks at all.
>    If we use indirect change notifications then we only move to the new
>    IP address after successfull dead-peer-detection on the new address,
>    which is already return routability check. In the direct change
>    notifications the authenticated peer have given out authenticated
>    IP-address, thus we could simply trust the other end. There is no way
>    external attacker can cause any attacks, but we are not protected by
>    the internal attacker, i.e. the authenticatede peer forwarding its
>    traffic to the new address. On the other hand we do know the identity
>    of the peer in that case.
> "
>
> [hannes] the relationship between authorization and the aspect of timing
> (WHEN to send return routability checks - if at all) needs to be 
> separated.
>
> discussions during the ietf meeting (see issue tracker web page) 
> concluded
> that it is a policy issue when to perform the return routability checks.
> this conclusion seems to be fine with me. i will try to produce a new 
> text
> proposal.
>
Thanks.  There was a discussion on this earlier this year and some of us 
came to the same conclusion, i.e., it is a local matter (but there was a 
fair amount of disagreement on this :-)).  I summarized some guidelines 
in this message from the archive:
http://www.machshav.com/pipermail/mobike/2004-May/000176.html

best regards,
Lakshminath

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