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

From: Tschofenig Hannes <[email-masked]>
Date: Thu, 9 Dec 2004 14:16:19 +0100

hi francis, 

thanks for the response. please see my comments below: 

>  In your previous mail you wrote:
> 
>    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. 
> 
> => 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. 

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

we know that the header is not protected. that is the place where the nat
handling comes into the picture. 
we are aware of the limitation (and the same is true for the base ikev2
specification). 

> 
>    - 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. 
>    
> => you already know my opinion (:-).   

yes, i do. 

>    
>    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 can't parse your idea: it is needed or not?

this issue was related to the issue described on the webpage. 

forget about it. 

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

i know. (see rfc 3554)

ciao
hannes

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

---

From: Francis Dupont <[email-masked]>
Date: Fri, 10 Dec 2004 11:13:28 +0100

=> 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.
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
BTW the first point is Pasi's idea, and it has the extra advantage
to be outside of the NAT traversal IPR.

Thanks

---

From: Jari Arkko <[email-masked]>
Date: Tue, 14 Dec 2004 13:52:11 +0200

>  - inject the peer addresses from the header into a protected space

Right. This is very good.

> to be outside of the NAT traversal IPR.

(Lets not assume too much about the IPR coverage. That's a
tricky field. You never know how broad the IPR claims are,
particularly if you consider that not all IPR may be public
yet.)

--Jari