Subject: [Mobike] issue 1: direct or indirect indicators

From: Tschofenig Hannes <[email-masked]>
Date: Mon, 6 Dec 2004 17:42:06 +0100

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
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Jari Arkko <[email-masked]>
Date: Mon, 06 Dec 2004 21:48:51 +0200

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

> 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

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

>   answer: both is desired (depending on whether nat traversal is desired or

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.

> example, seems to offer an approach which defines add/delete operations. 

My personal preference would be always sending the full list.

> 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

---

From: Francis Dupont <[email-masked]>
Date: Thu, 09 Dec 2004 14:05:57 +0100

In your previous mail you wrote:

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

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

=> you already know my opinion (:-).   

=> I can't parse your idea: it is needed or not?

=> this is another issue and depends on the environmen (i.e., not
interesting for mobility but very useful for multi-homing and SCTP).

=> the address update is about peer addresses, *not* traffic selectors.

Regards

[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike