Re: issue 34 proposal

 

> In your previous mail you wrote:
> 
>    > PS: please don't forget that NAT traversal is
>    > explicitely outside
>    > the WG charter.
>    
>    I don't know what this means.
> 
> => simply: In particular, the WG shall NOT develop mechanisms for the
> following functions:
> 
> o IP address changes done by third parties (NATs, firewalls etc). In
>   particular, MOBIKE shall not replace or modify IKEv2 NAT traversal
>   function. MOBIKE handles IP address changes initiated by one of the
>   endpoints of the security associations. NAT traversal handles other
>   address changes. MOBIKE should not be tightly coupled with the NAT
>   traversal function, but it is necessary to specify in which cases
>   (if any) they can be used together, and how they interact.
> 
> So this discussion itself is in the charter (last statement) but
> some proposed solutions can be outside.
> 
>    Do you mean to say MOBIKE should not care about NATs ?
> 
> => I mean it should care only inside the limits described in the charter.
> 
To me the charter is too restrictive and the above paragraph is very ambiguous.
It would be a waste of time discussing it now. 

>    The "issue 34" is
>    about a specific case of dynamic updates which also
>    has an impact on PATH_TEST messages. So, just arguing
>    about dynamic updates alone does not get us anywhere.
>    
> => one can consider than #34 is about the interaction between MOBIKE
> and NAT-T in cases they are used together.
>    
No, it is more than that. If you use implicit updates (as in IKEv2 NAT-T), then
you also need a mechanism to prevent implicit updates so that you can
find working path between the peers. We have discussed enough on this
topic now :-)

-mohan

> Regards
> 
> [email protected]
> 
> PS: http://www.ietf.org/html.charters/mobike-charter.html
> _______________________________________________
> Mobike mailing list
> [email protected]
> https://www.machshav.com/mailman/listinfo.cgi/mobike