[Mip6-firewall] initial draft

[QIU Ying]

Hi, Hannes and Gabor

Thanks for your hard job. Below is my 2 cents:

1. NAT vs. IPv6: The proposal uses STUN mechanism that is based on NAT. As 
we know, NAT and IPv6 are irreconcilable. In NAT, many network interface 
share one public address. Contrarily, in IPv6, a network interface can own 
many global addresses. Do we must come back old time? Hence, my opinion is 
that we should not consider the NAT situation, but focus on firewall.

2. Figure 1 may not describe exactly the scenario we should solve. Our 
scenario is that the agent L is moving continuously and getting a new 
address frequently. So the problem is how to let agent L's new addresses can 
go through the firewalls between MN and HA as well as firewalls between MN 
and CN.

3. In the first paragraph on page 5, it is not appreciated to display an 
IPv4 private address here since we are talking in mobile IPv6 environment. 
In fact, a typical IPv6 address consists of local network prefix + interface 
ID. Because the interface ID is unique, it is impossible to find out a pair 
of working addresses by the method described this section.

4. Even if the proposed approach is accepted, it is not suitable for quickly 
moving mobile network. According to the last description of MEXT, 3 
application cases should be in mind: aviation (~1000km/h, across 
continents), automotive (~100-300km km/h, across networks) and personal 
mobile routers. Refer to Figure 5 in page 13, in order to set up a 
connection, the proposal needs up to 10 round messages. Moreover in order to 
discover which pairs of addresses will work, the M-ICE will try all possible 
addresses. It is really time consideration and not meets the speed 
requirements in aviation and automobile cases.

5. Figure 5 show how to employ the protocol. Due to STUN, the HoTI/HoT and 
CoTI/CoT messages can go though the firewall freely. It implies that the 
firewall open to the STUN signaling. According to RFC3776, only 4/6 
signaling, HoTI, HoT, CoTI and CoT as well as BU and BA, have the mobile 
protocol 135. In this case, we could simply ask the firewall also open to 
all of the MIP6 signaling with protocol 135. The security risk is not higher 
than STUN.

Correct me if I am wrong.

Regards
Qiu Ying




----- Original Message ----- 
From: "Hannes Tschofenig" <Hannes.Tschofenig at gmx.net>
To: "QIU Ying" <qiuying at i2r.a-star.edu.sg>
Cc: <Gabor.Bajko at nokia.com>; <mip6-firewall at zeke.ecotroph.net>; "Thomas 
Schreck" <thomas.schreck at gmail.com>
Sent: Wednesday, June 27, 2007 4:36 PM
Subject: Re: [Mip6-firewall] initial draft


> Hi
>
> here is the document. We called it "Mobile IP Interactive Connectivity 
> Establishment (M-ICE)" since it aims to leverage the ongoing work in the 
> VoIP community to provide more robust end-to-end connectivity:
> http://www.tschofenig.com/svn/draft-tschofenig-mip6-ice/draft-tschofenig-mip6-ice-00.txt
>
> This is a first version and a number of issues are still subject for 
> further investigation (we tried to highlight them in the draft). This 
> document aims to leverage existing work as much as possible. There are, 
> however, adaptations possible.
>
> Ciao
> Hannes
>
> PS: Thomas Schreck is providing us help with the implementation work.
>
> QIU Ying wrote:
>> where is it :-)
>>
>> ----- Original Message ----- 
>> From: <Gabor.Bajko at nokia.com>
>> To: <mip6-firewall at zeke.ecotroph.net>
>> Sent: Wednesday, June 27, 2007 7:03 AM
>> Subject: [Mip6-firewall] initial draft
>>
>>
>>
>>> Folks,
>>>
>>> Hannes and myself worked in the last three days to produce an initial
>>> draft for NAT/FW traversal. We plan to submit it tomorrow morning CET.
>>> Once submitted, Hannes will send a link to the draft.
>>>
>>> It would be good if you could take a look at the draft before the phone
>>> conference, maybe we could briefly discuss about it.
>>>
>>> - gabor
>>> _______________________________________________
>>> Mip6-firewall mailing list
>>> Mip6-firewall at zeke.ecotroph.net
>>> https://zeke.ecotroph.net/mailman/listinfo/mip6-firewall
>>>
>>
>> ------------ Institute For Infocomm Research - Disclaimer -------------
>> This email is confidential and may be privileged.  If you are not the 
>> intended recipient, please delete it and notify us immediately. Please do 
>> not copy or use it for any purpose, or disclose its contents to any other 
>> person. Thank you.
>> --------------------------------------------------------
>> _______________________________________________
>> Mip6-firewall mailing list
>> Mip6-firewall at zeke.ecotroph.net
>> https://zeke.ecotroph.net/mailman/listinfo/mip6-firewall
>>
> 


------------ Institute For Infocomm Research - Disclaimer -------------
This email is confidential and may be privileged.  If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you.
--------------------------------------------------------