5.2 Framework
5.3.7 Improved NSIS Based Mobile IPv6 Firewall Traversal
As explained in Section 5.3.6, the assumption that all involved Mobile IPv6 nodes,
namely, MN, HA and CN, must support NSIS, the NAT/FW NSLP and a modified Mobile IPv6 implementation is quite unrealistic, at least in the initial NSIS migration. This is especially the case for the assumption that the CN must support NSIS, the NAT/FW NSLP and a modified Mobile IPv6 implementation. Such a situation will occur quite frequently, and hence a scenario where the CN does not support NSIS
and the NAT/FW NSLP should be supported. Therefore, Section 5.3.6 has proposed
an improved NAT/FW NSLP proxy mode, which allows the NSIS based Mobile IPv6
firewall traversal approach, as specified in Section 5.3.5, to support such a scenario
where the CN is not NSIS and NAT/FW NSLP aware.
When utilising the improved NAT/FW NSLP proxy mode as introduced in Sec- tion 5.3.6, all NSIS firewall signaling which is intended to the CN, will be intercepted and processed by the firewall at the edge of the CN’s ASP. Obviously, this firewall has to support NSIS and the NAT/FW NSLP. As the firewall now acts as NSIS Re- sponder for the received request, it replies to the received CREATE message with a RESPONSE message and installs the requested firewall pinhole rule.
As mentioned before, this is the case for all NSIS firewall signaling addressed to the CN. Thus, all NSIS based Mobile IPv6 firewall traversal message flows to the CN would be intercepted and processed by the edge firewall. The correspondent node can stay focused on Mobile IPv6 and does not require to support NSIS, the NAT/FW NSLP and a modified Mobile IPv6 implementation. Hence, the requirement to support NSIS, the NAT/FW NSLP and a modified Mobile IPv6 implementation is not longer valid.
Figure 5.36 exemplifies how the NSIS firewall signaling flow would look with the
improved NAT/FW NSLP proxy mode for the CoTI message as it was specified for
the normal NSIS based Mobile IPv6 firewall traversal in Section5.3.5.2.2, depicted in
Figure5.26.
The MN initiates a NSIS NAT/FW NSLP session by sending a CREATE message to the CN to install firewall pinhole rule for the CoTI message. The NSIS firewall
signaling to allow the CoTI message is shown in Figure 5.36. In contrast to the flow
described in Section5.3.5.2.2, the CREATE message from the MN is now intercepted
and processed by the firewall at the edge of the CN’s ASP. The firewall processes the message and, in case the request is permitted, installs the firewall pinhole and replies with the RESPONSE message to the MN. As can be seen from the figure, the CN is not longer involved in the NSIS based Mobile IPv6 firewall traversal procedure.
CN MN FW CoTI CoTI CREATE RESPONSE CoT CoT
Figure 5.36: NSIS Firewall Signaling with Improved NAT/FW NSLP Proxy Mode
5.3.8 Summary
This section has described how the NSIS NAT/FW NSLP can address the issues caused by stateful packet filter firewalls encountered in Mobile IPv6 environments. It has utilised an IETF NSIS NAT/FW NSLP based firewall traversal solution and introduced some essential extensions which allow it to handle all the problems and impacts of having firewalls in Mobile IPv6 environments in all the different scenarios,
as described in Chapter 3. It has to be noted that a real scenario could include a
combination of some set of these cases. This approach has been submitted to the
IETF in [SFL07] and has also been proposed at [SFH+07].
In contrast to other middlebox configuration solutions, the NSIS based solution can offer a solution for all deployment scenarios, assuming that the MN, the CN, the HA and the firewalls are NSIS and NAT/FW NSLP aware. However, in contrast to other explicit middlebox configuration approaches, NAT/FW NSLP requires more signaling overhead but does not require knowledge about the topology and avoids possible performance problems caused by the deep packet inspection of other approaches.
Whereas Section 5.3.5 has only described how Mobile IPv6 firewall traversal can be
accomplished with the current NSIS and NAT/FW NSLP specification and the es-
sential extensions presented in Section5.3.3, Section5.3.6 has introduced some major
5.3 NSIS Based Mobile IPv6 Firewall Traversal
traversal based on NSIS to significantly reduce the requirements and to perform faster by utilising the improved NSIS and NAT/FW NSLP.
An important aspect for firewall traversal or firewall signaling is how to ensure that only authorised hosts are allowed to perform actions. This authentication and au-
thorisation considerations and aspects are discussed in detail in Section 6.1. Later,
Section 7.1 presents an overview on the NSIS based Mobile IPv6 firewall traversal
5.4 Mobile IPv6 Application Layer Gateway
Several problems and impacts could prevent Mobile IPv6 from operating success-
fully in the presence of firewalls as introduced in Chapter 3. To overcome these
problems, this section introduces one possible solution, based on Application Layer Gateways (ALGs) [SH99]. This solution was developed and standardised within the IETF MEXT working group [MEXT]. The Mobile IPv6 Application Layer Gateway solution has been adopted as working group draft. It represents one key contribution of this thesis.
Section4.3already introduces the Application Layer Gateway [SH99] technique. ALGs
are application specific agents that are aware of the protocol details of a specific pro- tocol, e.g., Session Initiation Protocol (SIP) [RSC+02] for VoIP, and is able to under-
stand the protocol messages and their dependencies within the communication. Thus, it is able to allow applications in different networks and domains behind middleboxes to connect each other transparently. An ALG processes the application traffic while transit and assists the middlebox in implementing its function. Therefore, the ALG performs a deep packet-inspection of packets and understands the application proto- cols which are supported. The work of the ALG is transparent to end-hosts, and does not terminate or influence sessions between the end-hosts. The ALG interacts with a middlebox to set up middlebox states, firewall pinholes or access control filters or uses the middlebox state information.
As described in Chapter 3, the standard Mobile IPv6 does not work in presence of
firewalls. One possible approach to tackle this issue is to utilise the Application Layer Gateway technique for Mobile IPv6 firewall traversal. The following sections describe how Application Layer Gateways could be utilised to overcome the Mobile IPv6 fire- wall traversal problems. This approach has been adopted by the IETF in [KSYB08] and [KSSB08].
Firstly, Section 5.3.1 presents the requirements and assumptions for the Application
Layer Gateway based Mobile IPv6 firewall traversal approach. The approach itself
is divided into two parts, more precisely two guidelines. Section 5.4.2 present the
guidelines for firewall administrators regarding Mobile IPv6 traffic, i.e., which type of traffic has to be allowed by pre-configuration, whereas Section 5.4.3present guidelines for firewall vendors to help them implement their firewalls in a way that allows Mobile IPv6 signaling and data messages to traverse. Only a combination of these two parts can achieve Mobile IPv6 Application Layer Gateway firewall traversal, i.e., both need
to be deployed together. Section 5.4.4summarises the Mobile IPv6 Application Layer
5.4 Mobile IPv6 Application Layer Gateway
5.4.1 Requirements and Assumptions
When utilising Application Layer Gateway for Mobile IPv6 firewall traversal, several requirements and assumptions have to be considered:
• All networks and nodes MUST support IPv6; IPv4/IPv6 interworking as well as dual-stack solutions are out of scope and not supported.
• All involved Mobile IPv6 nodes, i.e., MN, HA and CN (as depict in Figure5.1),
MUST support a Mobile IPv6 implementation.
• All firewalls at the edge of the different networks or domains, as well as all potentially intermediate middleboxes MUST support a Mobile IPv6 Application Layer Gateway implementation and MUST perform middlebox functionality, e.g., by implementing the netfilter/ip6tables [netfilter]. In addition, the firewall must be able to analyse the IPv6 Mobility Header, the IPv6 Routing Header and the IPv6 Destination Options Header.
• The firewalls MUST be configured as described in Section 5.4.2. This has to be
done by manual pre-configuration.
• The firewalls MUST implement the recommendations for firewall vendors, as described in Section5.4.3.
• The Mobile IPv6 Application Layer Gateway firewall traversal approach does not require any firewall MUST to be deployed. However, any firewall – independent of its position – CAN be deployed.