Re: 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