RE: issue 1: direct or indirect indicators

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 protected]
>