RE: When to do Return Routability Checks

hi francis, 

please see my comments below:

>  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 have read this paragraph several times but i am not 
> quite sure that i
>    understood it. 
> 
> => I apologize. I tried many times to write a good text but 
> without success.

thanks for your patience with me. i try hard to understand the arguments of
everyone else. 


> So another tentative:
>  - the peer address set is known, each peer address has been 
> authorized

i would phrase it a bit different. 

let us assume that the addresses available to a peer is called peer address
set. 

i guess we also assume that these addresses are exchanged somehow i.e., each
peer (initiator and responder of the mobike exchange) communicates its peer
address set to the other peer. 

the peer address set might change over time and might therfore involve
further communication between the peers.

>  - there are many ways to authorize an address, RR check can be one of
>    these ways
ii can agree with this statement.

>  - an update can be done only to an authorized peer address 
> (if the peer
>    address is not yet authorized, it must be authorized before the
>    application of the update)

i am not sure that this statement is correct. to explain what i have in mind
i need to introduce another term: the preferred address
the preferred address is used by mobike to send messages to the other peer. 

each peer needs to select a preferred address for communication. 

before an address is used as a preferred address it needs to be authorized. 
a peer might only have one address: the preferred address 
however, if it has more than one address (which is, for example, the case if
it is multi-homed) then the other addresses might not be authorized (for
example because they are in the queue to be experience the
return-routability check). 

if i want to delete one of these addresses (for whatever reason) then why
shouldn't i am allowed todo it? it is not used anyway. 


tbd: we need proper names for these individual addresses. jari provided some
input on these addresses. i suggest to reuse whatever he suggested (i might
have misused some terms already). 

>  - an unknown peer address is an address which is not (was 
> never) in the
>    peer address test
>  - usually the peer registers (i.e., add in its announced 
> peer address set)
>    the address it uses for IKE messages but we can extend the previous
>    statement with "or was never used as the source of an IKE message"
> So you get an update for an authorized/to-be-authorized peer 
> address in a message from an unknown source address: I argue 
> that both addresses (the one in the header and the one in the 
> message) must be RR checked because the initiator can have 
> just moved behind a NAT.
let me rephrase this paragraph: a mobike peer receives a message which says:
'add ip abc to the peer address set.'
additionally the mobike message was sent with a source address that the
other peer has never seen before. this might, for example, the case in a
break-before-make scenario. the ip address (abc in our example) might be the
same as in the ip header (in some cases). 

now, it depends whether we would like to use the address 'abc' as the new
preferred address. if so, then we should authorize it. 
which address should we test?
-  'abc' (as indicated in the mobike message) or
- source ip address
the answer is: it depends whether we support nat traversal or not. 
if we use a nat prevention mechanism then the address 'abc' needs to be
authorized. 
if we use nat-t then we should authorize the source ip address (in this case
the address in the payload and 'abc' does not match).
the answer which address we would like to test 


> 
> Can you reply if you have understood and propose a better 
> explaination?
sure. see above. 

>

ciao
hannes
 
> Thanks
> 
> [email protected]
>