[Mip6-firewall] initial draft

Wed Jun 27 19:36:24 EDT 2007

The scope of the draft is wider than fw traversal in an ipv6
environment. We split the problem into two:
- exchange the addresses the two nodes have. For this we need a
signalling between the two nodes and for mipv6 case we could use a
modified rrt, where the coti&cot would be routed through the ha, thus
ensuring that the messages reach their destination
- use a generic protocol to test/achieve connectivity. Here we propose
to use id.stun(bis), with the procedures described in id.ice

The above assumes that stun, hoti/hot, esp packets are allowed to pass
through the fw in the in-->out direction, and the fw installs state to
let the return packets through also. For this we may need a bcp.
Alternatively, we may make use of
http://www.ietf.org/internet-drafts/draft-wing-behave-nat-control-stun-u
sage-02.txt, which will have more support for discovery/control for mh
and esp in the next revision.

 - gabor

-----Original Message-----
From: ext QIU Ying [mailto:qiuying at i2r.a-star.edu.sg] 
Sent: Wednesday, June 27, 2007 8:48 AM
To: Hannes Tschofenig
Cc: Bajko Gabor (Nokia-SIR/MtView); mip6-firewall at zeke.ecotroph.net;
Thomas Schreck
Subject: Re: [Mip6-firewall] initial draft

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