RE: issue 1: direct or indirect indicators

i guess we can close issue#1. 

the listed sub-issues have to be added somewhere else.  

> -----Original Message-----
> From: Jari Arkko [mailto:[email protected]] 
> Sent: Montag, 06. Dezember 2004 20:49
> To: Tschofenig Hannes
> Cc: MOBIKE Mailing List
> Subject: Re: [Mobike] issue 1: direct or indirect indicators
> 
> Tschofenig Hannes wrote:
> 
> > 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).
> 
> Right. Given that there are a lot of local mechanisms such as 
> DNA, ND, and L2 that can detect problems, I would support 
> allowing either party to detect a problem. (But it could be 
> that e2e path failure detection is only the initiator's 
> responsibility. In any case the reaction at the MOBIKE layer 
> is similar, letting the peer know that a new address needs to 
> be used.)
> 
> > as a summary: i am not quite about the possible conclusion of this 
> > issue since the issue description is too fuzzy.
> 
> When the issue was first discussed, we did not understand 
> quite everything we do now...
> 
> But I think as far as the original issue goes, I think we can 
> say that both forms of indication need to be supported.
> For instance, we discussed in IETF-61 about the use of local 
> ND/L2/DNA information, we have earlier agreed on the list 
> that we need to support path failure detection, and we 
> certainly need to be able to act if the peer tells us via 
> MOBIKE that his address has changed.
> 
> Perhaps the above could be conclusion of this issue and then 
> we can open new ones for the other questions that you had below:
> 
> > 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. 
> 
> That's a good question and observation about NAT. For 
> simplicity, I would actually prefer we just use one address/message...
> 
> > - 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)
> 
> This is also a good question. I agree that both are needed.
> In this case we can't simplify because we really do want to 
> work with NAT-T, and we also really want to be more secure 
> than NAT-T is when we don't have to use NAT. Or that's at 
> least what I think.
> 
> > - 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.
> 
> My personal preference would be always sending the full list.
> 
> 
> > 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.
> 
> Right. And I think that in IETF-61 we had general agreement 
> that information from these other protocols needs to be 
> supported by MOBIKE. It would be funny if L2 informed us that 
> the link is down but we still kept trying to get an answer from DPD.
> 
> --Jari
> 
>