Internet DRAFT - draft-chen-mobileip-packet-fitlering-xc
draft-chen-mobileip-packet-fitlering-xc
IETF Mobile IP Working Group Xiaobao Chen
INTERNET-DRAFT Orange PCS Ltd.
Expires: 17 December 2003
Martin Harris
Orange PCS Ltd.
Nick Sampson
Orange PCS Ltd.
17 June 2003
MIPv6 Inter-working with Packet Filtering
draft-chen-mobileip-packet-fitlering-xc-01.txt
Status of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or made obsolete by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document provides considerations for some requirements on
the IPv6 nodes using MIPv6 to communicate with their peers across
a network boundary where some specific packet filtering is
deployed for operator and service provider controlled access to
the services and network resources. Depending on the operational
policies, the packet filtering can be applied on either the
incoming packets or the outgoing packets or in both directions.
A mobile node using MIPv6 sends packets with Home IP address in
the extension headers, while the packet filtering is often based
on either the source address or the destination address or both
in the basic IPv6 header.Packet filtering that complies with the
policies from the mobility unaware applications will fail to
perform properly due to the change of the source and destination
addresses in the basic IPv6 header when MIPv6 is used. This
document provides an analysis on the operation requirements on
packet filtering and then proposes a simple solution that does
not impose any change on IPv6 but requires an addition to IPv6
nodes using MIPv6.
Xiaobao Chen et al Expires 17 December 2003 [Page i]
INTERNET-DRAFT MIPv6 Interworking with Packet Filtering
1 Introduction
Mobile IPv6 (MIPv6)[1] allows a mobile node to maintain its IP
connectivity regardless of its network attachment point.
Packets sent to the mobile node may still use its home address, or
the care-of address of the mobile node as the destination address.
The mobile node may continue to communicate with its existing
communication peers (stationary or mobile) by using its
topologically correct IP addresses. An important and highly
desirable feature of mobile IP based mobility is that the control
is transparent to transport and higher-layer protocols and
applications, i.e. the higher layer protocols and applications
function as if the mobile node is "stationary".
Packet filtering is used by operators and service providers for
protecting the network and the host(s). It is achieved by
distinguishing incoming and outgoing packets and then control
the access to network resources and services based on operator or
service provider defined policies.
An IPv6 node using MIPv6 sends packets with home address carried
in the extension headers of the IPv6 packets, while the packet
filtering can be based on either the source address or the
destination address or both in the basic IPv6 header. This is
usually because the packet filtering complies with policy control
information that comes from an application server or the upper
layers which operate independently from mobile IP . A packet that
fails to match either the source address or the destination IP
address in its basic IP header will be discarded by the gateway
node that performs packet filtering based on the
source or destination addresses in the basic IPv6 header.
In this document some common operational practices of packet
filtering are described. Then operational issues and requirements
are discussed when an IPv6 node uses MIPv6 to communicate with
its peers through a network boundary that performs a network
address based packet filtering. It then proposes a simple
solution of an addition to IPv6 nodes using MIPv6 without any
restrictions on standard IPv6 operations.
2 Terminology
The key words "MUST", "MUST NOT", "REQUIRED","SHALL","SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119.
3 Some Common Packet Filtering Practices
The following sections list some packet filtering operations
deployed by ISP's or 3G operators. It is not intended to
exhaust all the possible application scenarios for packet
filtering.
3.1 Network Ingress Filtering by ISP's
Some typical example are given in RFC2827[2] about ingress
filtering used to protect network and hosts against Denial of
Service Attacks using IP Source Address Spoofing. An attacker
using a forged but "valid" IP source address (e.g. those
that appear in the global routing tables) can launch an attack on
Xiaobao Chen et al Expires 17 December 2003 [Page 1]
INTERNET-DRAFT MIPv6 Interworking with Packet Filtering
a network or a host and cause serious disruptions or even a crash
of the network and service operations. The proposed operational
practice for an ISP is to restrict transit traffic which
originates from a downstream network to known, and intentionally
advertised, prefix(es). This "ingress filtering" would check if an
incoming packet uses a legitimate source address, i.e. the address
assigned by the ISP from which the packet is originated. For
example, the only valid source address for packets originating
from a PC is the one assigned by the ISP after successful log-in
process which usually involves the use of authentication and
authorisation procedures. This packet filtering based on valid
source address is also recommended on edge routers [3] to
validate the source IP address of the sender.
3.2 Network Packet Filtering by 3G Operators
Some strong driving factors for deploying IPv6 and mobility
support in IPv6 on a wide-scale have been seen in the 3GPP
community. The UMTS IP Multimedia Subsystem (IMS)[6] is based on
IPv6. Mobile IP has been identified by 3GPP as a solution for
providing mobility control between wireless LAN and GPRS/UMTS
networks to support 3G services including IMS services. Supporting
IPv6/MIPv6 in GPRS/UMTS networks has become an imminent and
important issue to 3G community, especially 3G operators. Two
important packet filtering operations that take place at the
GPRS Gateway Support Node (GGSN) in GPRS/UMTS networks are
described in the following sections.
3.2.1 Ingress Filtering at the GPRS/UMTS Gateway Node
To support IP multimedia services with differentiated QoS,
GPRS/UMTS networks support multiple simultaneous GPRS/UMTS
sessions as typically represented by multiple secondary PDP
(Packet Data Protocol) Contexts[4]. Each GPRS/UMTS session may be
assigned specific QoS with the necessary network resources
(including radio resources). An incoming packet from the external
IP network will be checked by the gateway node, GGSN, to decide if
there is an existing GPRS/UMTS session to deliver the packet
through the network to the mobile terminal. The packet is checked
against a Traffic Flow Template [5] (TFT) that contains the packet
filtering information such as the IPv4/IPv6 Source Addresses,
Protocol Identifier, Source/Destination Ports, etc. The packet
filtering operation will use at least one of those
packet filter parameters, primarily the Source Address, to choose
the appropriate GPRS/UMTS session.
On receiving an packet, the GGSN will search for a GPRS/UMTS
session with the TFT that contains the parameter values matching
those carried in the packet. For example, the Source IP Address
field of each existing TFT will be compared with the source address
carried by the packet.If no matching TFT is found, the packet may
be discarded.
3.2.2 Egress Filtering for IMS Services at the GPRS/UMTS Gateway Node
The IP Multimedia Subsystem (IMS) [6] is defined by 3GPP to
provide SIP-based IP multimedia services. In IMS, Service-based
Local Policy control(SBLP) [7, 8] is enforced by the gateway node,
GGSN, to authorise and control the access to the IMS services and
Xiaobao Chen et al Expires 17 December 2003 [Page 2]
INTERNET-DRAFT MIPv6 Interworking with Packet Filtering
the GPRS/UMTS network resources based on operator defined
local policies. For example, an IMS service request, a
GPRS/UMTS session set-up request and the subsequent data packets
originated by the mobile terminal will be checked at the gateway
node, GGSN, against a set of policy control information
parameters such as Destination Address, Destination Port Number,
Transport Protocol ID, etc. The policy control information is
issued as an authorisation from the upper layer (the IMS/Policy
Control Function -PCF). A service request or a packet will be
blocked the GGSN if it fails the packet filtering based on the
policy control information.
4. Problem statements
When a mobile node (MN) leaves its home network link and connects
to a foreign network that deploys the packet filtering described
in section 3.2, the MN will encounter some difficulties
communicating with its peers using MIPv6 and its upper layers
sessions will be disrupted.
4.1 Source Address based Ingress Filtering
For packets sent from the Correspondent Node) (CN) to the MN,
the packets may either be tunneled by the MN's Home Agent(HA) to
the MN or sent from the CN directly to the MN.
4.1.1 The Case of HA Tunneling
When the packets travel through the tunnel from the HA to the
MN, the source address in the outer header of the tunnelled packet
is the address of the HA. The gateway node in the foreign network
is likely to perform ingress filtering based on the original source
address, i.e., the address of the CN, despite the fact that the HA
will still tunnel packets to the MN. This is the case especially
when the ingress packet filtering function is not mobility aware,
i.e. it makes no distinction between a stationary node or mobile
node using mobile IPv6.
A typical example is the Ingress Filtering at GGSN in GPRS/UMTS
networks as described in section 3.2.1 where the UMTS sessions are
set up and operated independent of the mobile IP control. The GPRS
/UMTS sessions makes no distinction between packets with or without
MIPv6 extensions. An incoming packet with a source address (i.e.
the address of the HA) different from the address used for packet
filtering (i.e. the IP address of the CN) will fail to find a
matching UMTS session and may be discarded. This has some serious
implications. For example, a live IMS session between two IPv6
nodes will be broken when any one of them leaves its home network,
moves into GPRS/UMTS and start using MIPv6.
A mechanism that reads inner header of the tunnelling packet may
not work. For example, the gateway node fails to read the payload
of the tunnelling packet due to the possible encryption, e.g.
IPSec ESP.
4.1.2 The Case of Route Optimisation when the CN is mobile
When Route Optimisation is used, the packets are sent directly
from the CN to the MN with the source address being the address of
Xiaobao Chen et al Expires 17 December 2003 [Page 3]
INTERNET-DRAFT MIPv6 Interworking with Packet Filtering
the CN. When the CN is a mobile node itself and attached to a
foreign network, the source address of the packets sent from CN
will be its Care-of Address (CoA). When packet filtering is
based on the original source address of the CN, i.e. its home
address, packets sent from the CN will be discarded by the gateway
node.
A typical example is the case when the GSSN uses ingress
filtering for selecting the UMTS sessions.Although the packet sent
from the mobile CN to the MN has the "Home Address Destination
Option" containing its Home address[1], a gateway node as
an intermediate node operating standard IPv6 does not read it.
This will have some serious implications such as the disruption of
existing live sessions.
4.2 Destination Address based Egress Filtering
For packets sent directly from the CN to the MN that is attached
to a foreign network, the destination address will be the CoA of
the MN. The gateway node such as the GGSN in the GPRS/UMTS
networks that is not mobile IP aware will still use the original
destination IP address, i.e. the home address of the MN to perform
the Egress Filtering.
Section 3.2.2 describes the egress filtering using the Service-
based Local Policy Decision provided by the Policy Control Function
that operates independently from mobile ip based mobility control.
When an IPv6 node in the GPRS/UMTS network is to initiate or having a
IMS session with a MN that is away from its home network, the
packets sent from CN directly to the MN using MIPv6 compliant
header will fail to pass through the SBLP based packet filtering.
Although the packet sent from the CN to the MN has the Routing
Header Type 2 in its option headers field[1], a standard IPv6
operating gateway node as an intermediate node does not read
this header.
5. Requirements on Inter-working Mobile IPv6 with Packet Filtering
The following requirements are recommended for a gateway node that
performs source address and/or destination address based packet
filtering:
* A gateway node running standard IPv6 should not be required to
change to support packet filtering function.
* The policy control functions for packet filtering such as the PCF
should not be aware of the mobility control based on mobile IP.
6. A Recommended Practice
A simple solution to the above inter-working problem with MIPv6
and packet filtering is to enable the gateway node to access the
required information to perform the packet filtering while in the
meantime the operations on packets in the gateway node should comply
with standard IPv6 specifications. According to standard
IPv6,the Hop-by-Hop Options Header, is accessible to intermediate
Xiaobao Chen et al Expires 17 December 2003 [Page 4]
INTERNET-DRAFT MIPv6 Interworking with Packet Filtering
IPv6 nodes between the source and the destination.The Hop-by-Hop
Options Header carries information that intermediate nodes between
a source and destination needs to know. Every node along a
packet's path examines the Hop-by-Hop options header for the
required information.
6.1 MIPv6 Interworking with Source IP Address based Ingress Filtering
The following recommended practice will enable the gateway node,
such as the GGSN in GPRS/UMTS networks, to perform source address
based Ingress Filtering because a standard IPv6 gateway node, as
an intermediate node, is able to access the information contained
in the Hop-by-Hop Options Field.
6.1.1 The Recommended Practice in case of HA Tunnelling
For a CN communicating to its MN using HA tunnelling, the HA
should insert original IP address of the CN in the Hop-by-Hop
Options Header in the outer IP header of the tunnelling packet.
In the case when the CN is a mobile node itself and away from its
home network, the CN may need to insert its Home IP address in
the Hop-by-Hop Options Field for packets sent to the MN's Home
IP address. The HA, as an intermediate IPv6 node, will read the
Hop-by-Hop Options Field and access the information and then
put the original IP address (the Home IP address) of the (mobile)
MN in the Hop-by-Hop Options Header in the outer header of the
tunnelling packets.
6.1.2 The Recommended Practice in case of Route Optimisation
For a CN communicating to a MN using route optimisation
to send packets directly to the MN, the CN should insert its IP
address in the Hop-by-Hop Options Header. In the case where the CN
is a mobile itself and away from its network, the CN should insert
its Home IP address in the Options filed in the Hop-by-Hop Options
Header.
6.2 MIPv6 Interworking with Destination IP Address based Egress
Filtering
For a CN communicating to a MN using Route Optimisation
to send packets directly to the MN, the CN should insert
the Home IP Address of the MN in the Hop-by-Hop Options Header
using standard IPv6 operations.
The above recommended practice will enable the gateway node, such
as the GGSN in GPRS/UMTS network, to perform destination
address based Egress Filtering such as SBLP because a standard
IPv6 gateway node, as an intermediate node, is able to access the
information in the Hopy-by-Hop Options Field using standard IPv6
operations.
Xiaobao Chen et al Expires 17 December 2003 [Page 5]
INTERNET-DRAFT MIPv6 Interworking with Packet Filtering
6.3 MIPv6 Interworking with Source and Destination IP Address based
Packet Filtering
It is likely that a packet sent from the HA or the CN to the MN
may need to pass through Egress Filtering (for packets leaving
the network where the CN or the HA is located) as well as Ingress
Filtering (for packets coming into the network where the MN is
located). Both the gateway node performing the Egress Filtering
and the one performing Ingress Filtering will need to acquire the
necessary information to perform the filtering function. It is
recommended that the CN and HA (in the case when the HA
tunneling is used) should insert the both the IP
address of the CN and the Home IP address of the MN in the Options
Field of Hop-by-Hop Options Header. The CN's IP Address is
placed before the MN's IP Address.
The above recommended operation is applied only to the outer IP
header of the packet when HA tunnelling is used.
The gateway node that performs the packet filtering will read the
data in the first 16 octets of the option field as the source IP
Address and the data in the following 16 octets of the option
field as the destination IP address.
7. Security Considerations
7.1 Ingress Filtering
It may well be likely that a malicious node launches attacks
against the MN by spoofing the Original Source IP Address (the
legitimate CN) or/and the Original Destination Address (the Home
IP Address of the MN) in its Hop-by-Hop Options Field to pass the
gateways that performs ingress packet filtering.
The recommended practice to tackle this problem is using the
Ingress Packet Filtering described in RFC2827[2]. The Ingress
gateway checks if the packet has the topologically correct
source IP address representing a legitimate CN or HA in the
network from which the packet comes from.
7.2 Egress Filtering
A potential risk may arise for operators running IMS with SBLP when
the GGSN checks the Hop-by-Hop Options Header for the destination
address (Sections 4.2, 6.2). After initial successful IMS SBLP
authorisation, a CN attached to a GPRS/UMTS network may insert
the address of an unauthorised destination (e.g. sites barred by
the operator) in the IPv6 basic header while it inserts the
authorised MN's home address in the Hop-by-Hop Options Field. This
will enable the packets to pass the SBLP based packet filtering at
the GGSN to reach un-authorised destinations.
To tackle this potential risk, the GGSN should associate the
current destination address of the MN, i.e. its CoA, with the
original destination address, i.e. the MN's home address of the MN
that is authorised by the IMS SBLP. The following approach may be
used by GGSN to establish such an association.
A MN attached to a foreign network may send a Binding Update
Xiaobao Chen et al Expires 17 December 2003 [Page 6]
INTERNET-DRAFT MIPv6 Interworking with Packet Filtering
message [1] to the CN attached to the GPRS/UMTS network. The
binding update message using the MN's CoA as the Source Address
may therefore be blocked by the GGSN's TFT packet filtering
function. Instead of blocking the packet, the GGSN may
also need to check if the packet carries the Binding Update
Message by looking at the MH Type Value. If it is "5"[1], the
GGSN recognises that it is a binding update message and record the
Source Address of the binding update message as the
current address of the MN.
To guarantee that the recorded address obtained from the Binding
Update Message is the MN's current address, the GGSN may need to
wait until a Binding Acknowledgement Message is sent from the CN
withe MH Type Value "6". The GGSN will establish an association
between the MN's current address (CoA) to be used by the CN in
IPv6 basic header and the MN's Home Address in the Hop-by-Hop
Options Field for sending packets to the MN.
For a secure SBLP operation, the GGSN will check both the
destination address in the IPv6 basic header and the Hop-by-Hop
Options Field in the IPv6 extension headers. Those packets found
with destination address unmatching the association with
the MN's Home Address will be blocked by the GGSN.
8. Acknowledgment
The authors would like to thank Phil Roberts and James Kemp for
their valuable comments and feedbacks on the issues.
Acknowledgements are made to Paul Reynolds, Ric Bailey, Ronan
Le Bras, Graham Fisher, Stuart Shutt, Steve Blythe and Rob Allan
for their constant and valuable support for the work.
9. References
[1] D. Johnson, C. Parkins. J. Arkko. "Mobility Support in IPv6",
Internet Draft, Internet Engineering Task Force, May 26, 2003
[2] P. Ferguson, D. Senie. "Network Ingress Filtering: Defeating
Denial of Service Attacks which employ IP Source Address
Spoofing. RFC2827, BCP38 Internet Engineering Task Force, May 2002
[3] F. Baker. "Requirements for IP Version 4 Routers", RFC1812, June 1995.
Xiaobao Chen et al Expires 17 December 2003 [Page 7]
NTERNET-DRAFT MIPv6 Interworking with Packet Filtering
[4] 3GPP TS23.060, "3rd Generation Partnership Project;
Technical Specification Group Services and System Aspects; General
Packet Radio Services (GPRS); Service Description; Stage 2 (Release
1999)".
[5] 3GPP TS23.008, "3rd Generation Partnership Project;
Technical Specification Group Core Network; Mobile Radio Interface Layer
3 Specifications; Core Network Protocols - Stage 3 (Release 1999)".
[6] 3GPP TS23.228, "3rd Generation Partnership Project;
Technical Specification Group Services and System Aspects; (Release 5)".
[7] 3GPP TS23.207, "3rd Generation Partnership Project;
Technical Specification Group Services and System Aspects;End-to-End
QoS Concept and Architecture (Release 5)".
[8] 3GPP TS29.207, "3rd Generation Partnership Project;
Technical Specification Group Core Network; Policy Control over Go
Interface (Release 5)".
9 Authors' Addresses
Xiaobao Chen
Orange PCS Ltd.
Keypoint
St. James Court, Almondsbury Park
Bradley Stoke, Bristol, BS32 4QJ
UK
Phone: +0044 (0)7989 477 679
EMail: xiaobao.chen@orange.co.uk
Martin Harris
Orange PCS Ltd.
Keypoint
St. James Court, Almondsbury Park
Bradley Stoke, Bristol BS32 4QJ
UK
Phone: +0044 (0)7974 365 080
EMail: martin.harris@orange.co.uk
Nick Sampson
Orange PCS Ltd.
Keypoint
St. James Court,Almondsbury Park
Bradley Stoke, Bristol BS32 4QJ
UK
Phone: +0044 (0)7973 963 519
EMail: nick.sampson@orange.co.uk
