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

From: Tschofenig Hannes <[email-masked]>
Date: Wed, 8 Dec 2004 11:33:36 +0100

i guess we can close issue#1. 

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

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

---

From: Tschofenig Hannes <[email-masked]>
Date: Mon, 20 Dec 2004 09:25:05 +0100

hi francis,

please see my comment below:

>  In your previous mail you wrote:
> 
>    >  In your previous mail you wrote:
>    > 
>    >    - should a peer send an address list in one message or 
>    > individual messages
>    >    (which only contain one address/message)?
>    > => 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.
>    
>    having an address list in the ike message makes nat 
> handling impossible. 

i need to correct myself here: i shouldn't say impossible. i should say
'impossible without using an additional protocol which allows to learn the
public ip address+ possible port'

>    
> => now I see: you speak about the first message when I speak 
> about NAT prevention in the first message and address list in 
> the next exchange.
does this make a difference. 

> I've already explained this but I used NAT prevention for two 
> purposes:
>  - make the choice between either NAT traversal and MOBIKE clear
>  - inject the peer addresses from the header into a protected 
> space

that's fine. it is certainly good to have an indication in the first message
exchange to tell the other peer whether to enable/disable nat handling
support. 

the second issue is fine with me. 

 BTW the first point is Pasi's idea, and it has the 
> extra advantage to be outside of the NAT traversal IPR.
very good. 

to come back to the original issue: 
if you have don't send a nat prevention payload (notification or vendor id)
in the first few messages and
if you have a nat somewhere along the path (at least between some src/dst
address pairs) then
you cannot send an address list (expect if you use another protocol which
allows you to learn your public ip address + port).

> Thanks

ciao
hannes

> 
> [email-masked]
>