Subject: [Mobike] D115 Design draft, return routability

From: Tero Kivinen <[email-masked]>
Date: Tue, 3 Jan 2006 20:31:51 +0200

[issue list: http://www.kivinen.iki.fi/ietf/mobike-design-issues.html
 working copy of document:
 http://www.kivinen.iki.fi/ietf/draft-ietf-mobike-design-06.txt]

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