issue 1: direct or indirect indicators

hi all, 

i would like to discuss issue #1: 
http://www.vpnc.org/ietf-mobike/issue1.txt

the current text on this issue says: 
--------------------

[Comment from secretary: TEMP-draft-kivinen-mobike-protocol-00.txt has
both direct indications (peer explicitly requests change) and indirect
based on address lists (when current address seems to have stopped
working, try others). draft-dupont-ikev2-addrmgmt-04.txt also has
both.]

--------------------

here are some basic observations:

you need to have more than one address anyway to switch to another one. 

it depends which entity detects the problem first. 

if the initiator detects that there is a problem (e.g., on the local link)
then it can switch to a new address. sending an ikev2 notification message
from the new address to the responder is fine and might cause an address
update of the ipsec sa with or without return routability check
(authorization decision). 

if the responder detects that there was a problem (e.g., on its local link)
then it might want to send the initiator a notification that it should use a
different address. if the initiator uses a dead peer detection mechanism he
will also discover the problem (after some time). 

as a summary: i am not quite about the possible conclusion of this issue
since the issue description is too fuzzy. 

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

ciao
hannes



i do not necessarily see the relationship between an address list and the
term 'direct/indirect' indications. 

in any case a peer might want to be able to send a message to the other peer
if it detects that an address does not work anymore (based on some triggers
provided by other protocols. see
<draft-arkko-multi6dt-failure-detection-00.txt>) 

i don't see the big difference.  



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 think think that the term indirect indication has anything todo with
address lists. 
for me an indirect indication is a hint provided by other protocols or
mechanisms to switch from one address to another. draft  talks about various
hints provided by other protocols which may lead to the conclusion to switch
from one address to another. 

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.


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. 

ciao
hannes