D115 Return Routability

From: Pasi Eronen
Subject: [Mobike] Design draft, return routability
Date: Fri, 23 Dec 2005 14:25:04 +0200

- "Finally it would be possible not to execute return routability
  checks at all.  In case of indirect change notifications we only
  move to the new preferred address after successful dead-peer
  detection (i.e., a response to a DPD test) on the new address, 
  which is already a return routability check."

  Confusing text; we don't execute return routability checks at
  all, but we do it already. And what exactly are the indirect
  change notifications we're talking about here?

- "but potential attacks are possible if a return
  routability check does not include some kind of a nonce." 

  A return routability check verifies that the peer can receive 
  messages sent to this address. If the message doesn't do this, 
  then IMHO it's not a return routability check at all. So I'd 
  rewrite this section to say something like "A successful IKEv2 
  informational exchange itself does not perform a return 
  routability check because ... and thus a nonce is needed ...".

- The text about different levels of return routability checks is
  very confusing. A return routability check should verify the IKEv2
  peer can receive packets sent to the given address; a check that
  just verifies that "someone can receive packets at the given
  address" is something quite different! I'd suggest removing most
  of this text.

- Section 5.5.1: Again, confusing text: if some other protocol wants
  to know "can remote entity A receive packets sent to X?", MOBIKE
  might be able to provide information that "remote entity B can
  receive packets sent to X" -- but this is not very useful unless we
  can also know that A and B are the same entity (with some reasonable
  definition of "sameness").  I'd suggest shortening this text and 
  stating that this was deemed complex, not absolutely needed, and 
  thus beyond the scope.

From: Tero Kivinen
Subject: [Mobike]  D115 Design draft, return routability
Date: Tue, 3 Jan 2006 20:31:51 +0200

Pasi.Eronen@nokia.com writes:
| - "Finally it would be possible not to execute return routability
|   checks at all.  In case of indirect change notifications we only
|   move to the new preferred address after successful dead-peer
|   detection (i.e., a response to a DPD test) on the new address, 
|   which is already a return routability check."
|
|   Confusing text; we don't execute return routability checks at
|   all, but we do it already. And what exactly are the indirect
|   change notifications we're talking about here?

ICMP messages, or path failing, i.e. anything we do not get directly
from the other end.

I.e. if we notice that path has failed, and we do DPD to verify it and
then change to new address, that changing to new address can actually
already act as return routability check in certain cases.

Added text "(i.e. something we notice from the network, not from the
peer directly)" and "(i.e. notification from the other end directly)"
after indirect notifications and direct notifications.

We used to have much more text describing those, but that was removed
few versions back. 

| - "but potential attacks are possible if a return
|   routability check does not include some kind of a nonce." 
| 
|   A return routability check verifies that the peer can receive 
|   messages sent to this address. If the message doesn't do this, 
|   then IMHO it's not a return routability check at all. So I'd 
|   rewrite this section to say something like "A successful IKEv2 
|   informational exchange itself does not perform a return 
|   routability check because ... and thus a nonce is needed ...".

There are multiple different levels of return routability check. For
example if you do not care about authenticated attacker faking
packets (I do not), then normal IKEv2 informational exchange is return
routability check.

Your definition of he return routability check is not only one, and
this section tries to explain different return routability checks.

| - The text about different levels of return routability checks is
|   very confusing. A return routability check should verify the IKEv2
|   peer can receive packets sent to the given address; a check that
|   just verifies that "someone can receive packets at the given
|   address" is something quite different! I'd suggest removing most
|   of this text.

I disagree. It might be clear for you what you mean by return
routability check, but I have noticed that people do have very
different views what it is. Thus we need to explain what do we mean it
with in this context.

I would say that outside the security area most common format of
return routability check would be "someone can receive packets at the
given address".

| - Section 5.5.1: Again, confusing text: if some other protocol wants
|   to know "can remote entity A receive packets sent to X?", MOBIKE
|   might be able to provide information that "remote entity B can
|   receive packets sent to X" -- but this is not very useful unless we
|   can also know that A and B are the same entity (with some reasonable
|   definition of "sameness").  I'd suggest shortening this text and 
|   stating that this was deemed complex, not absolutely needed, and 
|   thus beyond the scope.

I again think we do need this, just to explain people that this is
complex issue and we do point out few most common cases there. Saying
"this is complex, we do not tell you anything about it" does not
really help.