Subject: [Mobike] When to do Return Routability Checks

From: Tschofenig Hannes <[email-masked]>
Date: Mon, 6 Dec 2004 13:02:57 +0100

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. 

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

---

From: "Dondeti, Lakshminath" <[email-masked]>
Date: Mon, 06 Dec 2004 13:16:43 -0500

> this conclusion seems to be fine with me. i will try to produce a new 
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

---

From: Jari Arkko <[email-masked]>
Date: Mon, 06 Dec 2004 22:48:46 +0200

> (WHEN to send return routability checks - if at all) needs to be separated. 

Yes. For the do it all, I think the answer depends on configured policy,
with default being yes. For the when part, I think it should be done
prior to moving the SA and the data stream towards that address.

> this conclusion seems to be fine with me. i will try to produce a new text

Ok.

--Jari

---

From: Francis Dupont <[email-masked]>
Date: Thu, 09 Dec 2004 13:50:29 +0100

In your previous mail you wrote:

=> this is my position but there is an exception: the update is to
an authorized* address but from an unknown address. A RR check should
be performed in this case, not because of a security issue, but because
the node can have just moved behind a NAT (the RR check for the authorized
address fails, the RR check for the unknown (in fact NATed) address succeeds).

*I use the term "authorized" in order to keep the policy decision to
the peer, i.e., the RR check can be a part of the authorization procedure.

Regards

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

---

From: Francis Dupont <[email-masked]>
Date: Thu, 09 Dec 2004 13:53:14 +0100

=> we need more flexibility about moving the SA: to wait the RR check
result is fine only when the previous peer address is still usable.

Regards

---

From: Jari Arkko <[email-masked]>
Date: Tue, 14 Dec 2004 16:55:55 +0200

> result is fine only when the previous peer address is still usable.

Yes. Or to be more precise, if you are still using the previous address
you can delay the check; but if you move the traffic stream to the
new address then you should do the check first. (All assuming the
check was configured ON in the first place.)

And as you wrote in another e-mail, a peer address that appears in
a cert or one that was just used one minute ago is already authorized.

--Jari