Re: issue 1: direct or indirect indicators

 In your previous mail you wrote:

   a separate question but also of interest: 
   - should a peer send an address list in one message or individual messages
   (which only contain one address/message)?
     (the address list does not work in a nat environment.)
     answer: both seems to be desired. 

=> as I don't like the idea to mix MOBIKE and NAT-T I am in favor
of one message which can be submitted to the authorization procedure
once and gives less exchanges. Of course this doesn't make the
one address/message impossible.

   - should the individual address be part of the protected payload or taken
   from info of the header?
     answer: both is desired (depending on whether nat traversal is desired or
   not)

=> from info: the header is not protected... In fact the header is only
interesting for indirect indication, for instance using an unknown address
in the header...

   - should the address list be idempotent or not?
     answer: this is still an open issue. always resending the full list
   (idempotent operation) requires more bandwidth but avoid synchonization
   issue which needs to be addressed. <draft-dupont-ikev2-addrmgmt-06.txt>, for
   example, seems to offer an approach which defines add/delete operations. 
   
=> you already know my opinion (:-).   
   
   there is little doubt that a mobike protocol needs some mechanisms that
   allows one peer to inform the other peer about address changes. (direct
   indications)
   
=> I can't parse your idea: it is needed or not?

   address lists are a separate issue and a performance aspect. with some
   respect address lists (as traffic selectors are already supported in ikev2)
   which allow multiple ipsec sas to be established with one child-sa exchange.
   
=> this is another issue and depends on the environmen (i.e., not
interesting for mobility but very useful for multi-homing and SCTP).
   
   if ipsec sas should be modified without using a new child sa exchange then
   they might use address lists again or one message exchange per traffic
   selector. 
   
=> the address update is about peer addresses, *not* traffic selectors.

Regards

[email protected]