Re: When to do Return Routability Checks

 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.
So another tentative:
 - the peer address set is known, each peer address has been authorized
 - there are many ways to authorize an address, RR check can be one of
   these ways
 - 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)
 - 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.

Can you reply if you have understood and propose a better explaination?

Thanks

[email protected]