Subject: [Int-area] [Fwd: I-D Action:draft-ng-intarea-tunnel-loop-00.txt]

From: Chan-Wah Ng <[email-masked]>
Date: Tue, 28 Oct 2008 10:21:25 +0800

Hello all,

We have written a draft on the formation of tunnel loops, and possible
approaches on loop detection.

As it is a general problem for tunneling protocols, the draft was
written for intarea.  However, there has been recent discussions on the
Mobility Extension WG on the HA loop threat, and even more recently in
3GPP CT1.  Hence, this announcement is cross-posted to Mext as well.

We would like to solicit for comments on the draft, and suggestions on
possible way forward.

/rgds
/cwng 

-------- Forwarded Message --------
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]
Subject: I-D Action:draft-ng-intarea-tunnel-loop-00.txt
Date: Sun, 26 Oct 2008 19:45:02 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Tunnel Loops and its Detection
	Author(s)       : C. Ng, et al.
	Filename        : draft-ng-intarea-tunnel-loop-00.txt
	Pages           : 12
	Date            : 2008-10-26

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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ng-intarea-tunnel-loop-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluCkNvbnRlbnQtSUQ6IDwyMDA4LTEwLTI2MTkzOTQ4Lkkt
REBpZXRmLm9yZz4KCg==

_______________________________________________
Int-area mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-area

---

From: Pekka Savola <[email-masked]>
Date: Tue, 28 Oct 2008 08:07:33 +0200 (EET)

> We would like to solicit for comments on the draft, and suggestions on

As you point out, IPv6 tunnel spec already has tunnel encapsulation 
limit, which you point out, could be even better.  But my concern is 
how much this is a problem in practise.  Among those IPv6 tunnel 
implementations I've looked at, none of them implemented tunnel 
encapsulation limit.  I wonder -- if they didn't bother to implement 
that, what would make them to bother implement this?

It appears there was a -00 I-D in IPng WG in 2002, which the probable 
intent of getting the IPv6 tunnel spec to draft standard, but the work 
dried up.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
Int-area mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-area

---

From: Chan-Wah Ng <[email-masked]>
Date: Tue, 28 Oct 2008 15:04:35 +0800

Hello Pekka,

Thank you for the response.

> that, what would make them to bother implement this?
AFAIK, Linux has always implemented the TEL option
in /net/ipv6/ip6_tunnel.c since the early 2.6.0 days.

In any case, a lack of implementation should not be used as an argument
against a possible fix to the problem -- especially if it is IPv6 we are
talking about (which is still far from being as pervasive as it should
be). 

As to whether there is a practical need to fix this problem, it is up to
the IETF community to decide. The information I can provide to help make
that decision is both Mext WG and 3GPP CT1 has acknowledged it as a
problem.

/rgds
/cwng

---

From: Mark Townsley <[email-masked]>
Date: Wed, 29 Oct 2008 15:54:34 -0500

When tunnels are well-scoped and rather static, or accompanied with 
tightly coupled control planes which can include their own control-level 
loop prevention during setup, tunnel loops on data packets are less 
likely - which is probably why you do not see much extra effort at an 
optimized check for them on the data path. Loops are more likely when 
tunnels encapsulations are used liberally, automatically, and allowed to 
operate in a multihop fashion. The future may be different, but at the 
moment I believe we see less of this kind of situation in practice.

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Wed, 29 Oct 2008 15:56:14 -0500

> that decision is both Mext WG and 3GPP CT1 has acknowledged it as a
What are the specific situations where tunnel loops have been seen in 
practice? Was there a control plane setting up the tunnel which could be 
used to prevent the creation of the loop in the first place?

- Mark

---

From: Chan-Wah Ng <[email-masked]>
Date: Thu, 30 Oct 2008 12:10:29 +0800

Hello Mark,

Thank you for the comments.

> moment I believe we see less of this kind of situation in practice.

True.  For cases such as enterprise networks where IPSec tunnels are
created over the global internet, or with layer 2 tunneling is used in
telecommunications network, such tunnel are statically configured and
loops are avoided at creation time.

For dynamic cases, one example that immediately come to mind is Mobile
IP tunneling (one reason why this is cross posted to Mext).  A tunnel is
created at the point of reception of a BU.

> used to prevent the creation of the loop in the first place?
We have described two examples in the draft, both related to mobility.
The first case is loop formation between two (or more) home agents.  The
second case is the formation of loop between a IPSec (Mobike) gateway
and the home agent.

In 3GPP, there is a clear separation of control and data plane.
However, those are generally for 3GPP access.  For non-3GPP access
(which is the case where DSMIP is used), the separation is a bit more
fuzzy. 

Based on discussion in other SDO, the case where the loop is formed
within an operator's domain (eg the loop between DSMIP and Mobike) can
be averted with additional checks.  However, there is also the case
where the loop is formed using entities from different domains (eg.
between a 3GPP PDNGW and a HA provided by independent Mobility Service
Provider).  Here, there are no control plane signaling to employ to
prevent the formation of a loop.  In such cases, the best thing an
operator could do is to protect its own network by detecting the loop
once it is formed and perform counter-measures.

/rgds
/cwng