[Mip6-firewall] [Fwd: CN behind FW section]

[Niklas Steinleitner]

Forget to add the list!

-------- Original Message --------
Subject: 	CN behind FW section
Date: 	Sat, 30 Jun 2007 13:45:03 +0200
From: 	Niklas Steinleitner <steinleitner at cs.uni-goettingen.de>
To: 	Suresh Krishnan <suresh.krishnan at ericsson.com>



Hi Suresh,

please find the "CN behind a FW" section attached. Please review it 
before attaching it to the document, especially because of my limited 
english-skills!

Regards,
Niklas

-- 
Niklas Steinleitner          Tel: +49 551 3913583
Institute for Informatics    steinleitner at cs.uni-goettingen.de
University of Göttingen      http://www.tmg.informatik.uni-goettingen.de
Lotzestrasse 16-18
D-37083 Göttingen, Germany



-------------- next part --------------
<section anchor="CN-behind-Firewall" title="Correspondent Node behind a firewall">

<t> This section presents the recommendations for configuring a firewall if a 
node behind it should be able to act as Mobile IPv6 CN. For each type of traffic 
that needs to pass through this firewall, recommendations are presented on how 
to identify that traffic. The following types of traffic are considered

<list style="symbols">
	<t> RRT signaling between MN and CN through HA</t>
	<t> Route optimization signaling between MN and CN</t>
	<t> Binding Update from MN to CN</t>
	<t> Route Optimization data traffic from MN</t>
	<t> Bi-directional tunnelled data traffic from the MN to the CN through HA</t>
</list>
</t>


<section anchor="cbf-rrt-through-HA" title="RRT signaling between MN and CN through HA">

<t> Parts of the initial RRT signaling has to pass through the HA, namely the 
HoTI and the HoT messages. Without assistance, the HoTI message from the HA to 
the CN is not able to traverse the firewall. The following pattern will allow these 
messages to traverse.

<list style="hanging">
	<t>Destination Address: CN Address</t>
	<t>Mobility Header Type: 1</t>
</list>

This pinhole allows the HoTI message from the HA to the CN to traverse the 
firewall. The HoT message from the CN to the MN through the HA can traverse the 
firewall without any assistance. Hence no pinhole is required.
</t>   
</section>

<section anchor="cbf-rrt-MNCN" title="Route optimization signaling between MN and CN ">

<t> Route Optimization allows direct communication of data packets between the 
MN and a CN without tunnelling it back through the HA. To get route optimization 
work, the MN has to send a CoTI message directly to the CN, which response with a 
CoT message. However, a stateful firewall would prevent the CoTI message to pass 
through as there is no established state on the firewall. The following pinhole 
will allow the CoTI message to traverse.

<list style="hanging">
	<t>Destination Address: CN Address</t>
	<t>Mobility Header Type: 2</t>
</list>

The CoT message from the CN to the MN can traverse the firewall without any 
assistance. Hence no pinhole is required.
</t>
</section>

<section anchor="cbf-BU-MNCN" title="Binding Update from MN to CN">

<t> After successfully performing the RRT, the MN sends the BU to the CN and 
expects the BA. Since this BU does not match any previous installed pinhole 
rules, an additional pinhole with the following format is required. 

<list style="hanging">
	<t>Destination Address: CN Address</t>
	<t>IPv6 Destination Options Header</t>
</list>

This allows the BU to traverse the firewall and the BA can pass the firewall 
without any assistance. Therefore, the Binding Update sequence can be performed
successfully.
</t>
</section>

<section anchor="cbf-RO-MNCN" title="Route Optimization data traffic from MN">

<t> Also the Route Optimization data traffic from MN directly to the CN can not 
traverse the firewall without assistance. But as we have configured the firewall 
to allow the BU message from MN to the CN to traverse the firewall, the Route 
Optimization data traffic is able to pass through as it also matches the pinhole 
installed for the BU.
</t>
<t>Therefore, no additional pinhole rules are required.</t>
</section>


<section anchor="cbf-BI-MNCN-throughHA" title="Bi-directional tunnelled data traffic from the MN to the CN through HA">

<t>If a MN tries to initiate traffic to a CN through the HA using bi-directional 
tunnelling, a stateful firewall would prevent these connection requests to pass 
through as there is no established state on the firewall. This is usually a 
problem as CNs often provide services. A solution is to static configure the 
firewall to let this traffic pass through. However, this is only an acceptable 
option if it is not necessary to open an all-embracing pinhole, e.g. if the 
destination ports are well-known. In this case, the pinhole has to look like

<list style="hanging">
	<t>Destination Address: CN Address</t>
	<t>Destination Port: Application Ports</t>
</list>

If the ports are unknown, it is necessary to install a pinhole with only the 
Destination Address as pattern. Allowing this traffic might allow any kind of 
traffic, including malicious traffic, to traverse to the CN. This might cause a 
Denial of Service at the CN.
</t>
</section>   
   
</section>