Subject: FW: [Mip4] AD review of draft-ietf-mip6-dsmip-problem-02.txt

From: "Tsirtsis, George" <[email-masked]>
Date: Wed, 17 Jan 2007 03:29:52 -0800

Jari,

See below the text requested for some of your requests.

George

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]] 
Sent: Wednesday, January 17, 2007 6:20 AM
To: Tsirtsis, George
Cc: Soliman, Hesham; Mobile IPv6 Mailing List; Mobile IPv4 Mailing List
Subject: Re: [Mip4] AD review of draft-ietf-mip6-dsmip-problem-02.txt

George,
>> Is this true under all circumstances? For instance,
>> is it true if one uses RFC 4285 or EAP for Mobile IPv6
>> authentication?
>>
>> Depending on the answer, please reword
>> and add the necessary explanations.
>>     
>
>
> GT> I believe that, assuming nothing is changed, what the draft says
is
> accurate since typically applications/protocols can not share keys
> unless security is implemented at a lower layer than that of the
> application/protocol. Still, I will add something to indicate that for
> some of the mechanisms listed and with further work, it might be
> possible to optimize operations.
>   
Do you have text? We are not talking about typical applications,
we are talking about a very specific case. And there are many
applications that can share the same credentials through, say,
AAA.

GT> Here is what I have. 
" In addition, deploying both protocols will require duplication of
   security credentials on mobile nodes and home agents.  This includes,
   IPsec security associations, keying material, and new authentication
   protocols for Mobile IPv6, in addition to the security credentials
   and associations required by Mobile IPv4.  Depending on the security
   mechanisms used and with some further work it might be possible to
   optimize some of these processes.  Assuming nothing else changes,
   however, such duplication is again significant with no gain to the
   operator or the mobile node."

>>>    - Local network optimizations for handovers will also need to be
>>>      duplicated.
>>>       
>> Only insofar as  they are bound to the mobility
>> protocol. There are a large number of optimizations
>> (L2 pre-auth etc) that deal with other aspects of the
>> handover problem and do not impact what happens
>> at IP or IP mobility layers.
>>
>> Please reword.
>>     
>
> GT> I will clarify that we are talking about IP layer optimizations
>   
Ok.
>>> 3.1. Implementation burdens
>>>
>>>    As mentioned above, a node that is IPv4 and IPv6 capable mustalso
be
>>>       
>>>    MIPv4 and MIPv6 capable to roam within the Internet. Clearly this
>>>    will add implementation efforts, which, we argue, are not
necessary.
>>>       
>>>    In addition to the implementation efforts, some vendors may not
>>>    support both protocols in either mobile nodes or home agents.
>>>    Although this is more of a commercial issue, it does affect the
>>>    large-scale deployment of mobile devices on the Internet.
>>>
>>>       
>> I'm not sure this section reflects the complete
>> picture. In a situation where host vendors
>> are independent of those who deploy the
>> mobility infrastructure, for instance, its
>> not clear that there is any reduction in
>> implementation effort.
>>
>> Please reword for better balance.
>>
>>     
>
> GT> OK, I will clarify 
>   
Good. Again, I would like to see the text...

GT> Here it is:
" As mentioned above, a node that is IPv4 and IPv6 capable must also be
   MIPv4 and MIPv6 capable to roam within the Internet.  Clearly this
   increases the complexity of implementations for vendors that decide
   to support both protocols.
   Some vendors, however, may not support both protocols in either
   mobile nodes or home agents.  Although this is more of a commercial
   issue, it does affect the large-scale deployment of mobile devices on
   the Internet."

>>>    Further work in this area, possibly independent of Mobile IP, may
>>>    also be of interest to some parties in which case it should be
dealt
>>>       
>>>    with separately from the incremental Mobile IP based changes.
>>>       
>> This statement seems out of place. Or at least I could
>> not think of what specific further work you were thinking
>> of.
>>     
>
> GT> Ok, I think we can remove this.
>   
Good.
>>> 3.0 Problem description
>>>       
>> I am missing an explanation of why various existing,
>> non-mobility related transition mechanisms are insufficient
>> for solving the issues listed in this document. I believe
>> they are insufficient, but the document needs to explain
>> why.
>>
>> Please add the explanation.
>>     
>
> GT> It is a bit difficult to write general negative statements like
> this. I will add a section on this and add something generic about the
> fact that current transition mechanisms do not seem to deal with
> mobility. 
>   
Ok. Text needed.

GT> Here it is: 
"4.5.  IPv4 to IPv6 Transition Mechanisms

   The IETF has standardized a number of transition mechanisms to allow
   networks and end nodes to gain IPv6 connectivity while the Internet
   is migrating from IPv4 to IPv6.  A cursory examination of such
   transition mechanisms indicates that none of them is designed to deal
   with mobile nodes.  While some transition mechanisms can be combined
   with Mobile IPv4 or Mobile IPv6, non of the known mechanisms have
   been shown to assist with the issues described in this document."

Jari

-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/