Internet Area C. Ng
Internet-Draft B. Lim
Intended status: Informational M. Jeyatharan
Expires: April 30, 2009 Panasonic
October 27, 2008
Tunnel Loops and its Detection
draft-ng-intarea-tunnel-loop-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 obsoleted 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.
This Internet-Draft will expire on April 30, 2009.
Ng, et al. Expires April 30, 2009 [Page 1]
Internet-Draft Tunnel Loops Detection October 2008
Abstract
Many protocols in the Internet Protocol suite use packet
encapsulations. This runs into the danger of forming a tunnel loop.
Since each tunnel entry point encapsulates the inner packet with a
tunnel packet header that contains a new hop count, a packet entering
a tunnel loop may be routed infinitely, consuming network resources.
Although there exist methods to cause a packet in a tunnel loop to be
discarded eventually, it would be more desirable to detect the
presence of a tunnel loop and act accordingly. This draft explores
the possibility for tunnel entry points to detect the presence of a
tunnel loop by using an extra identifier tagged to the outer packet
header.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Example Scenarios . . . . . . . . . . . . . . . . . . . . 3
1.3. Existing Control Measures . . . . . . . . . . . . . . . . 4
1.4. Inadequacies . . . . . . . . . . . . . . . . . . . . . . . 5
2. Basic Approach . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Approach for IPv6 . . . . . . . . . . . . . . . . . . . . 6
2.1.1. Extending the Tunnel Encapsulation Limit Option . . . 6
2.1.2. Using Multiple Tunnel Encapsulation Limit Options . . 7
2.1.3. New Tunnel Identifier Option . . . . . . . . . . . . . 8
2.2. Approach for IPv4 . . . . . . . . . . . . . . . . . . . . 8
2.3. Types of Identifier . . . . . . . . . . . . . . . . . . . 9
3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Informative Reference . . . . . . . . . . . . . . . . . . . . 10
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Ng, et al. Expires April 30, 2009 [Page 2]
Internet-Draft Tunnel Loops Detection October 2008
1. Introduction
1.1. Background
Many protocols in the Internet Protocol suite use packet
encapsulation [1][2]. For instance, Virtual Private Network (VPN)
relies on tunneling technology to interconnect two or more networks
at different locations to form a large enterprise private network.
Mobility Support in IPv6 (MIPv6) [3] and Network Mobility [4] uses
tunneling between mobile nodes and home agents to allow a mobile node
(or network) to be always reachable at its home address (or network
prefix). The transition from IPv4 to IPv6 itself relies on tunneling
[5] in order to be seamless.
Because tunneling hides the source and destination addresses of the
inner packet (which may be encrypted), the existing routing
infrastructure can only make routing decision based on the outer
packet. This may lead to a phenomenon known as tunnel loop when a
tunnel packet is routed back to the tunnel entry node before reaching
the tunnel exit node. Tunnel loop is more likely to happen if a
packet needs to go through several levels of encapsulation. Figure 1
and Figure 2 show two example scenarios where tunnel loop can occur.
1.2. Example Scenarios
Packet forwrading for HoA-1
BCE of HA1 +------>-------->-----+ BCE of HA2
+---------------+ | | +---------------+
| HoA | CoA | +--+--+ +--v--+ | HoA | CoA |
+-------+-------+ | HA1 | | HA2 | +-------+-------+
| HoA-1 | HoA-2 | +--^--+ +--+--+ | HoA-2 | HoA-1 |
+---------------+ | | +---------------+
+-----<--------<------+
Packet forwarding for HoA-2
Figure 1: Tunnel Loop Formed with MIPv6
In Figure 1, a mobile node has two home agents, HA1 and HA2, from
different service providers. It is assigned home address HoA-1 from
HA1 and HoA-2 from HA2. The mobile node then proceeds to bind HoA-2
as a care-of address for HoA-1 at HA1 and bind HoA-1 as a care-of
address for HoA-2 at HA2. This will form a tunnel loop as packets
forwarded by HA1 will be re-routed back to HA1 by HA2 with an
additional encapsulation. This is also noted in the current 3GPP TS
24.303 [6].
Ng, et al. Expires April 30, 2009 [Page 3]
Internet-Draft Tunnel Loops Detection October 2008
Bi-directional HA-MN Tunnel
BCE of PDNGW +----->------>----+ IPSec Mapping
+---------------+ | | +--------------------+
| HoA | CoA | +---+---+ +---v--+ | Nomadic | Assigned |
+-------+-------+ | PDNGW | | ePDG | +---------+----------+
| HoA-1 | Addr1 | +---^---+ +--+---+ | HoA-1 | Addr1 |
+---------------+ | | +--------------------+
+----<------<----+
IP-Sec Tunnel for Mobike Access
Figure 2: Tunnel Loop Formed with Mobike and MIPv6 in 3GPP
In Figure 2, a 3GPP User Equipment (UE) gains access to the Evolved
Packet Core (EPC) by setting up an IPSec tunnel with a evolved Packet
Distribution Gateway (ePDG) possibly via Mobike. The UE is assigned
HoA-1 from the Packet Distribution Network Gateway (PDNGW) and Addr1
by the ePDG. The UE then proceeds to bind Addr1 as care-of address
to HoA-1 at the PDNGW and re-map its Mobike IPSec tunnel with HoA-1
as the nomadic address. This will form a tunnel loop as packets
forwarded by PDNGW will be re-routed back to PDNGW by the ePDG with
an additional IPSec encapsulation.
1.3. Existing Control Measures
Since each encapsulation conceals the source address of the inner
packet, a tunnel entry node may not realize that it has already
tunneled a packet previously. Tunnel loop is highly undesirable
because it quickly eats up network resources. A packet in a tunnel
loop gets routed infinitely because each encapsulation packet will
have a new Hop Limit field, thus rendering the existing mechanism of
using Hop Limit to safeguard against routing loop ineffective.
Furthermore, each encapsulation adds an extra packet header to the
packet, causing the packet to grow in size. The packet size may grow
so large that fragmentation occurs, effectively introducing another
packet into the tunnel loop.
To prevent the catastrophic consequences of a tunnel loop, RFC 2473
[1] specifies the use of a Tunnel Encapsulation Limit (TEL) option
for IPv6 which is a destination header option that contains the
maximum number of encapsulations a packet can undergo. It is
required that all tunnel entry nodes to inspect the destination
header of a packet before encapsulation. If a TEL option is found in
the packet, the tunnel entry node must first check that the maximum
number of encapsulations allowed in the TEL option (given in the TEL
value) is not zero before encapsulation. If the TEL value is zero,
the tunnel entry node will discard the packet and sent to the
originator an Internet Control Message Protocol (ICMP) error
Ng, et al. Expires April 30, 2009 [Page 4]
Internet-Draft Tunnel Loops Detection October 2008
informing the originator of the problem. If the TEL value is non-
zero, the tunnel entry node will proceed with encapsulating the
packet, and add a TEL option to the new tunnel packet header
containing the value equals to the original TEL value minus one. On
the other hand, if the original packet does not contain a TEL option,
the tunnel entry node proceeds with encapsulation and adds to the
tunnel packet header a TEL option containing a default (operator
configured) number of maximum encapsulations.
A similar mechanism (RFC 1701 [2]) is used in IPv4 whereby a 3-bit
recursion field is used to limit the number of further encapsulations
permitted on a packet.
1.4. Inadequacies
Although the use of TEL option (and Recur field) prevents a packet in
a tunnel loop from being routed indefinitely, it is an inadequate
solution to a complex problem. In particular, the use of TEL option
does not allow the recipient of an ICMP error to determine the cause
of TEL value reaching zero is due to a tunnel loop, or merely due to
the initial TEL value is insufficient for the number of tunnels a
packet need to traverse to reach its final destination. Thus, it is
unclear how a tunnel entry node should respond to an ICMP error that
says the tunnel encapsulation limit has been reached. The tunnel
entry node could increase its default TEL value in an attempt to
allow the packet to get through. This may lead to an infinite
sequence of receiving ICMP error and increasing the default TEL
value, if there is indeed a tunnel loop. Alternatively, the tunnel
entry node can simply refuse to tunnel packets with the same
destination address, assuming that there is a tunnel loop. However,
this may cause unnecessary denial-of service when the actual reason
for ICMP error was because the number of tunnels a packet needs to
traverse is greater than the TEL value set in order for the packet to
reach its final destination.
From the above discussion, one can see that the problem with using
the TEL option (and Recur field) is that it does not contain
sufficient information for a tunnel entry node to differentiate
between the case where a tunnel loop has formed, and the case where
the number of tunnels a packet needs to traverse is greater than the
default TEL value set. With that in mind, this draft explores the
possibilities of adding an identifier field to the outer packet to
enable tunnel entry points to reliably detect the presence of a
tunnel loop.
Ng, et al. Expires April 30, 2009 [Page 5]
Internet-Draft Tunnel Loops Detection October 2008
2. Basic Approach
In order for a tunnel loop to be detected by tunnel entry points, we
proposed that a tunnel identifier to be added to the outer packet of
a tunnel. The basic idea is for the tunnel entry point to monitor
this tunnel identifier on received packets, and flag a "Loop
Detected" error when packets with certain tunnel identifier values
are received.
The basic approach will be for a tunnel entry point to first inspect
the header of a packet received that is to be tunneled, and check if
an tunnel identifier is present. If a tunnel identifier is present,
the tunnel entry point checks if the tunnel identifier indicates the
presence of a tunnel loop. If so, error is flagged. Else, the
received packet is processed, and the tunnel identifier is added to
the outer header before sending it out. On the other hand, if a
tunnel identifier cannot be found in the received packet, the tunnel
entry point generates a tunnel identifier to be added to the outer
header.
With this basic approach, we will next see how we can implement it
for both IPv6 and IPv4.
2.1. Approach for IPv6
For IPv6 tunneling, the Generic IPv6 Tunneling [1] should be used.
Hence, the obvious approach is for the tunnel entry point to insert
the generated identifier in the TEL Option. This will also allow the
tunnel packet to have the benefit of the TEL Option of limiting the
number of encapsulations that can be performed on the packet. There
are two sub-approaches to do so: firstly, we can extend the TEL
Option to include an identifier field; or secondly, we can use
multiple TEL Options to encode the identifier field. A third
approach is to use an entirely new Destination Header option to carry
the identifier.
These are discussed briefly in the following sub-sections.
2.1.1. Extending the Tunnel Encapsulation Limit Option
Since each tunnel entry point is expected to inspect the Tunnel
Encapsulation Limit Option, adding the identifier into the TEL Option
is a natural extension. This can be done by appending a Tunnel
Encapsulation Identifier field to the TEL Option as illustrated in
Figure 3 below.
Ng, et al. Expires April 30, 2009 [Page 6]
Internet-Draft Tunnel Loops Detection October 2008
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+
| Type | Length | Tun Encap Lim | Tun Encap ID ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+
Figure 3: Extending the TEL Option
Type
The Option Type containing the octet 00000100 in binary (decimal
value 4), where the highest-order two bits are set to zero to
indicate the option is skipped if not recognized, the third
highest-order bit is set to zero to indicate this option does not
change en-route, and the remaining 5 bits identify the option as
the TEL option.
Length
The Option Length specifies the length of the option in octets
excluding the Option Type and Length fields. This value is
variable depending on the length of the Tunnel Encapsulation
Identifier field.
Tunnel Encapsulation Limit (Tun Encap Lim)
The Tunnel Encapsulation Limit is a 8-bit unsigned integer
specifying how many further levels of encapsulation are permitted
for the packet.
Tunnel Encapsulation Identifier (Tun Encap ID)
The Tunnel Encapsulation Identifier (TEI) is the identifier
inserted by the first tunnel entry point, and copied by subsequent
tunnel entry points. The length of this field is TBD.
2.1.2. Using Multiple Tunnel Encapsulation Limit Options
The problem with extending TEL option as described in Section 2.1.1
is that legacy tunnel entry point would not be able to process the
new TEI field, and would thus omit copying the field when adding an
extra level of encapsulation, thereby rendering the approach
ineffective. To resolve this, it is possible to use multiple TEL
options to encode the identifier. The trick here is to use the first
TEL option as the base, and add the identifier value to the TEL field
of subsequent TEL options.
Ng, et al. Expires April 30, 2009 [Page 7]
Internet-Draft Tunnel Loops Detection October 2008
As an example, consider a tunnel entry point adding a 16-bits
identifier 0x1234 to a tunnel packet. It can add three TEL options
to the packet illustrated in Figure 4 below.
Outer IPv6 Header
Destination Header {
TEL Option {
Option Type = 0x04
Option Length = 1
Tun Encap Lim = 5
}
TEL Option {
Option Type = 0x04
Option Length = 1
Tun Encap Lim = 0x12+5 = 0x17
}
TEL Option {
Option Type = 0x04
Option Length = 1
Tun Encap Lim = 0x34+5 = 0x39
}
}
Inner Packet
Figure 4: Using Multiple TEL Options
In this way, when subsequent tunnel entry points decrement the TEL
value for each options, the identifier can still be derived by taking
the difference between the TEL values in subsequent TEL options with
the TEL value of the first TEL option.
2.1.3. New Tunnel Identifier Option
A third approach is to have a new Destination Header Option that
carries the identifier. This is similar to the approach used in
Section 2.1.1 except that the Tunnel Encapsulation Identifier field
is carried in a new option called the Tunnel Encapsulation Identifier
Option. This option should be simply copied to the outer packet by
subsequent tunnel entry points.
2.2. Approach for IPv4
The situation for IPv4 tunneling is a bit more complicated, as there
is no independent Destination Header that one can rely on. Hence,
each tunneling protocol will have to be extended separately in order
to detect the presence of a tunneling loop. This will be an almost
impossible task, in view of the number of different protocols and
Ng, et al. Expires April 30, 2009 [Page 8]
Internet-Draft Tunnel Loops Detection October 2008
legacy nodes already deployed. Nonetheless, since most tunneling
mechanisms in IPv4 utilizes the Generic Routing Encapsulation (GRE)
defined in RFC 1701 [2], we could extend the protocol and enable
majority of the IPv4 tunnel entry points to detect tunneling loops.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|R|K|S|s|Recur| Flags | Ver | Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum (optional) | Offset (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Routing (optional)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: GRE Header
Figure 5 shows the basic header for GRE as defined RFC 1701. Note
that RFC 2784 [7] simplified the informational GRE header described
in RFC 1701 and reduces the header to only contains the Checksum
field (omitting the Key, Sequence Number, and Routing fields).
Later, RFC 2890 [8] updates the proposed standard and re-introduces
the Key and Sequence Number fields. It is possible to re-use the key
and sequence number field to act as an identifier field for the
purpose of loop detection, and maintain compatibility with legacy
nodes that already implements RFC 2890 or RFC 1701.
2.3. Types of Identifier
Different types of identifier can be used to detect tunnel loop, such
as a unique identifier associated with each tunnel entry point, a
hash value generated based on the contents of the innermost packet,
or a randomly generated number. Factors to consider when selecting
the type of identifiers include the possibility of erroneously
detecting a loop, the possibility of failing to detect a loop and the
overhead added. Analysis of the type of identifiers is left for
future version.
Ng, et al. Expires April 30, 2009 [Page 9]
Internet-Draft Tunnel Loops Detection October 2008
3. Conclusion
This memo highlights the problem of tunnel loops, and demonstrated
the need for not only limiting the number of encapsulations on a
packet (as is available in current standards) but also the need to
detect tunnel loops so that appropriate actions may be taken. To do
so, we proposed that an identifier be inserted into the outer packet
header which should be copied by subsequent tunnel entry points.
This will enable a tunnel entry point to detect that a packet it is
about to encapsulate has already been encapsulated by itself before,
and thus signal the presence of a tunnel loop.
4. Informative Reference
[1] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6
Specification", RFC 2473, December 1998.
[2] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic
Routing Encapsulation (GRE)", RFC 1701, October 1994.
[3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[4] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
[5] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for
IPv6 Hosts and Routers", RFC 4213, October 2005.
[6] "Mobility Management based on Dual-Stack Mobile IPv6", 3GPP TS
24.303, ver 1.3.0, October 2008.
[7] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina,
"Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[8] Dommety, G., "Key and Sequence Number Extensions to GRE",
RFC 2890, September 2000.
Appendix A. Change Log
o draft-ng-intarea-tunnel-loop-00:
* Initial version.
Ng, et al. Expires April 30, 2009 [Page 10]
Internet-Draft Tunnel Loops Detection October 2008
Authors' Addresses
Chan-Wah Ng
Panasonic Singapore Laboratories Pte Ltd
Blk 1022 Tai Seng Ave #06-3530
Tai Seng Industrial Estate
Singapore 534415
SG
Phone: +65 65505420
Email: chanwah.ng@sg.panasonic.com
Benjamin Lim
Panasonic Singapore Laboratories Pte Ltd
Blk 1022 Tai Seng Ave #06-3530
Tai Seng Industrial Estate
Singapore 534415
SG
Phone: +65 65505478
Email: benjamin.limck@sg.panasonic.com
Mohana Jeyatharan
Panasonic Singapore Laboratories Pte Ltd
Blk 1022 Tai Seng Ave #06-3530
Tai Seng Industrial Estate
Singapore 534415
SG
Phone: +65 65505494
Email: mohana.jeyatharan@sg.panasonic.com
Ng, et al. Expires April 30, 2009 [Page 11]
Internet-Draft Tunnel Loops Detection October 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Ng, et al. Expires April 30, 2009 [Page 12]