[Mip6-firewall] initial draft

Wed Jun 27 12:28:04 EDT 2007

Hi

only a few quick comments.

QIU Ying wrote:
>
> 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.
>

I believe we should consider IPv4/IPv6 transition as this is a topic 
being develop currently in the MIP6 working group with the dual stack 
approach.

> 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.
>
Both end points might move. That's fine. Even if they move they might 
not continuously change their IP address because of link layer mobility 
or things like proxy Mobile IP.

> 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.
I need to look at the page to see what you have in mind.

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

In the typical case it will be quite fast since there aren't too many 
addresses available and you don't need to try all of them.
If you want to be really fast always (when it comes to the number of 
messages to get exchange) route traffic through the HA since this would 
at least ensure that you get you messages to the other end. That can be 
a local policy. In many cases, I do, however, expect that people want to 
directly exchange messages and there is no other way than just trying 
what works.

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

That's true. You need to get the MIP6 signaling through at least. I am 
working with Gabor to update his draft to show what has to be done to 
get that to work.
Regarding STUN messages: You can either use STUN todo the connectivity 
checks or related techniques. The STUN messages will look like data 
packets and there is ongoing work to get that to go though firewalls a

> 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.
Suresh wanted to write a document what you about "how to configure a 
firewall to get MIP messages to through".
Haven't seen et

Ciao
Hannes

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