[Mobike] When to do Return Routability Checks

[Francis Dupont]

 In your previous mail you wrote:

   > 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.
   
=> by default the context I use is the address management draft one.

   >  - there are many ways to authorize an address, RR check can be one of
   >    these ways
   i 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. 
   
=> I use also this term but here this is not the right one because the
update can be limited to some IPsec SAs (i.e., you suppose the IKE SA
is always updated).

   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. 
   
=> I proposed the delete operation in my draft.

   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). 
   
=> I use/propose:
 - primary address for the IKE SA address (you propose preferred)
 - alternate addresses for other members of the sets
 - candidate addresses for not yet authenticated addresses the peer'd like
   to add to its peer address set.

   >  - an unknown peer address is an address which is not (was 
   > never) in the
   >    peer address test

=> "never seen" is likely a better description

   >  - 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.

=> right

   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). 
   
=> right

   now, it depends whether we would like to use the address 'abc' as the new
   preferred address. if so, then we should authorize it. 

=> here not only the peer'd like to add in the peer address set but
update all SAs too.

   which address should we test?
   -  'abc' (as indicated in the mobike message) or
   - source ip address

=> abc must be tested but if this doesn't work and a NAT is suspected
a test on the source ip address can show the connectivity is not
simply broken.

   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. 

=> we are in mobike so nat traversal is not supported.

   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).

=> to authorize the source ip address is not useful for mobike because
this is not the address to update to.

   the answer which address we would like to test 
   
=> in fact IMHO is the case should be made impossible in the protocol
(with a SHOULD NOT) so false NAT detections would come only from
incorrect configuration or operation... Has someone a better idea.
   
Thanks

Francis.Dupont at enst-bretagne.fr

PS: so the requirement for the initiator of an update is "SHOULD NOT" use
an address which is not member or candidate member of its peer address set
as the source address of an update message.
And the requirement for the responder of an "whole" update from a never
seen before (including the update message itself) address is to suspect
a NAT in the path: a return-routability checks on the new primary address
SHOULD be performed, if it fails another one on the source address SHOULD
be performed too. If it succeeds then a NAT is likely on the path (the
action depends on the NAT traversal discussion :-).