Skip to main content

Security Concerns with IP Tunneling
draft-ietf-v6ops-tunnel-security-concerns-04

Revision differences

Document history

Date Rev. By Action
2012-08-22
04 (System) post-migration administrative database adjustment to the No Objection position for Adrian Farrel
2012-08-22
04 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2011-02-10
04 Cindy Morgan State changed to RFC Ed Queue from Approved-announcement sent.
2011-02-08
04 Cindy Morgan IESG state changed to Approved-announcement sent
2011-02-08
04 Cindy Morgan IESG has approved the document
2011-02-08
04 Cindy Morgan Approval announcement text changed
2011-02-08
04 Cindy Morgan Ballot writeup text changed
2011-02-08
04 Amy Vezza State changed to RFC Ed Queue from Approved-announcement sent.
2011-02-07
04 (System) IANA Action state changed to No IC from In Progress
2011-02-07
04 (System) IANA Action state changed to In Progress
2011-02-07
04 Cindy Morgan IESG state changed to Approved-announcement sent
2011-02-07
04 Cindy Morgan IESG has approved the document
2011-02-07
04 Cindy Morgan Closed "Approve" ballot
2011-02-07
04 Cindy Morgan Approval announcement text regenerated
2011-02-07
04 Cindy Morgan Ballot writeup text changed
2011-02-07
04 Ron Bonica State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup.
2011-02-07
04 Ron Bonica Ballot writeup text changed
2011-01-19
04 David Harrington Closed request for Last Call review by TSVDIR with state 'No Response'
2011-01-17
04 Adrian Farrel [Ballot Position Update] Position for Adrian Farrel has been changed to No Objection from Discuss
2011-01-17
04 Ron Bonica Ballot writeup text changed
2011-01-17
04 Adrian Farrel
[Ballot comment]
Document title

I find the current title, with the revised scope of the document may be misleading.

---

Is it right that Section …
[Ballot comment]
Document title

I find the current title, with the revised scope of the document may be misleading.

---

Is it right that Section 2.3 is limited only to source routing? Isn't it the case that tunneling can be used to inject any IP option into a network and cause trouble?
2011-01-17
04 Adrian Farrel
[Ballot discuss]
Discuss updated aligned with RFC Editor Note

I think this is a worthwhile and useful document

I would like to see a little …
[Ballot discuss]
Discuss updated aligned with RFC Editor Note

I think this is a worthwhile and useful document

I would like to see a little more clarity on the meaning of "IP tunnels". I think you are trying to discuss situations where an IP packet can contain, through some form of encapsulation, another IP packet. It would be really nice to make this crystal clear.

Joel said:
> To borrow from rfc 2003, an ip tunnel generically,
>
> "specifies a method by which an IP datagram may be encapsulated
> (carried as payload) within an IP datagram.
>
> I think we could use that definition without sparking a controversy.

I think this scope would be very helpful (for a start, it would stop me worrying about MPLS LSP tunnels).
2011-01-17
04 Ron Bonica Ballot writeup text changed
2011-01-10
04 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Kurt Zeilenga.
2011-01-07
04 (System) Removed from agenda for telechat - 2011-01-06
2011-01-06
04 Cindy Morgan State changed to IESG Evaluation::AD Followup from IESG Evaluation.
2011-01-06
04 Russ Housley
[Ballot comment]
Please consider the concern raised by Brian Carpenter in his Gen-ART
  Review. His concern is not technical, rather it deals with the …
[Ballot comment]
Please consider the concern raised by Brian Carpenter in his Gen-ART
  Review. His concern is not technical, rather it deals with the tone.
  He says:
  >
  > I have a concern that the document may be read entirely negatively
  > as advice to block all tunnels, whereas in fact Section 7 (briefly)
  > describes precautions that would make the use of tunnels relatively
  > safe as part of v4/v6 coexistence. After a short dialogue with one
  > of the authors (Suresh), I would like to see the reader's attention
  > drawn to this early in the document.
2011-01-06
04 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss
2011-01-06
04 Adrian Farrel
[Ballot comment]
Section 2.1.1

  This reduces defense in depth
  and may cause security gaps.

I can't parse this :-( Do you mean...

This …
[Ballot comment]
Section 2.1.1

  This reduces defense in depth
  and may cause security gaps.

I can't parse this :-( Do you mean...

This reduces the depth of security available, and may cause security gaps.

---

Is it right that Section 2.3 is limited only to source routing? Isn't it the case that tunneling can be used to inject any IP option into a network and cause trouble?
2011-01-06
04 Adrian Farrel
[Ballot discuss]
I think this is a worthwhile and useful document

I *think* that the scope of this document is intended to be "security considerations …
[Ballot discuss]
I think this is a worthwhile and useful document

I *think* that the scope of this document is intended to be "security considerations for the use of IP tunnels in IPv6 migration scenarios."

It looks like the document goes on mainly to consider the issues that arise in such situations, although the title and abstract etc. are not clear on this limitation, and some places in the text seem to open the discussion up more general tunneling applications.

While v6ops is a good home for a document with limited scope, it worries me that the more general discussion is restricted to that working group. The shepherd write-up declares "The document has been quite extensively socialized", without explaining where this socialization took place.

In short, scoped so widely (i.e., not limited to the applicability of tunnels to v6 migration strategies) this document appears to be out of scope for the v6ops working group.

There would appear to be two solutions:
1. Add a few small changes to make clear that the scope is limited to                         
  v6 migration (or maybe to v6 use of tunnels)
2. Find the right review forums within the IETF to ensure proper
  breadth of review (opsec, WGs responsible for the main tunneling
  protocols, ...)

Note that I do not consider that the IETF last call on a document with a file name starting "draft-ietf-v6ops-..." guarantees broad enough review.

---

I would like to see a little more clarity on the meaning of "IP tunnels". I think you are trying to discuss situations where an IP packet can contain, through some form of encapsulation, another IP packet. It would be really nice to make this crystal clear.
2011-01-06
04 Ron Bonica Ballot writeup text changed
2011-01-05
04 Jari Arkko [Ballot Position Update] New position, Yes, has been recorded by Jari Arkko
2011-01-05
04 Jari Arkko
[Ballot comment]
Section 6.1.1 attack does not appear to be any worse than the assumptions
required for this attack to be possible. If you can …
[Ballot comment]
Section 6.1.1 attack does not appear to be any worse than the assumptions
required for this attack to be possible. If you can spoof the victim's
DNS, you can hijack the victim's communications, tunnels or no tunnels.

In this light the recommendation to prefer IPv4 over tunneled IPv6
is odd. Also, its not clear that whoever is selecting which addresses
to use is aware of whether tunneling is being done or not (host vs.
router, for instance).

(This recommendation may be good for other reasons, of course.)
2011-01-05
04 Jari Arkko
[Ballot comment]
Section 6.1.1 attack does not appear to be any worse than the assumptions
required for this attack to be possible. If you can …
[Ballot comment]
Section 6.1.1 attack does not appear to be any worse than the assumptions
required for this attack to be possible. If you can spoof the victim's
DNS, you can hijack the victim's communications, tunnels or no tunnels.
2011-01-05
04 Peter Saint-Andre [Ballot Position Update] New position, No Objection, has been recorded
2011-01-05
04 Sean Turner [Ballot Position Update] New position, No Objection, has been recorded
2011-01-05
04 Adrian Farrel
[Ballot comment]
Section 2.1.1

  This reduces defense in depth
  and may cause security gaps.

I can't parse this :-( Do you mean...

This …
[Ballot comment]
Section 2.1.1

  This reduces defense in depth
  and may cause security gaps.

I can't parse this :-( Do you mean...

This reduces the depth of security available, and may cause security
gaps.

---

Is it right that Section 2.3 is limited only to source routing? Isn't
it the case that tunneling can be used to inject any IP option into a
network and cause trouble?
2011-01-05
04 Adrian Farrel
[Ballot discuss]
I think this is a worthwhile and useful document

I *think* that the scope of this document is intended to be "security
considerations …
[Ballot discuss]
I think this is a worthwhile and useful document

I *think* that the scope of this document is intended to be "security
considerations for the use of IP tunnels in IPv6 migration scenarios."

It looks like the document goes on mainly to consider the issues that
arise in such situations, although the title and abstract etc. are
not clear on this limitation, and some places in the text seem to
open the discussion up more general tunneling applications.

While v6ops is a good home for a document with limited scope, it
worries me that the more general discussion is restricted to that               
working group. The shepherd write-up declares "The document has been
quite extensively socialized", without explaining where this
socialization took place.

In short, scoped so widely (i.e., not limited to the applicability of
tunnels to v6 migration strategies) this document appears to be out of
scope for the v6ops working group.

There would appear to be two solutions:
1. Add a few small changes to make clear that the scope is limited to                         
  v6 migration (or maybe to v6 use of tunnels)
2. Find the right review forums within the IETF to ensure proper
  breadth of review (opsec, WGs responsible for the main tunneling
  protocols, ...)

Note that I do not consider that the IETF last call on a document with
a file name starting "draft-ietf-v6ops-..." guarantees broad enough
review.

---

I would like to see a little more clarity on the meaning of "IP
tunnels". I think you are trying to discuss situations where an IP
packet can contain, through some form of encapsulation, another IP
packet. It would be really nice to make this crystal clear.
2011-01-05
04 Adrian Farrel [Ballot Position Update] New position, Discuss, has been recorded
2011-01-05
04 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded
2011-01-05
04 Russ Housley
[Ballot discuss]
The Gen-ART Review by Joel Halpern on 28-Dec-2010 raises a question
  that has not been answered.  I think that a response is …
[Ballot discuss]
The Gen-ART Review by Joel Halpern on 28-Dec-2010 raises a question
  that has not been answered.  I think that a response is needed.

  Joel says:
  > It is unclear in the document what assumptions section 3.1 makes
  > about the relationship between supported tunnels and checked
  > embedded addresses.  Is there an assumption that the router only has
  > to check for addresses in the format and prefix it supports?
2011-01-05
04 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded
2011-01-05
04 Stewart Bryant
[Ballot comment]
There are a lot of tunnel mechanisms are being deployed simply so that end users can work around the fact that they do …
[Ballot comment]
There are a lot of tunnel mechanisms are being deployed simply so that end users can work around the fact that they do not have enough IP addresses by creating a  private overlay network.

The document seems to miss the opportunity to say that by deploying IPv6 the need for many of these tunnels can be removed.
2011-01-05
04 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded
2011-01-05
04 Tim Polk
[Ballot comment]
This is a useful document and I support its publication.  I believe this could be a better and more useful document
if the …
[Ballot comment]
This is a useful document and I support its publication.  I believe this could be a better and more useful document
if the authors could address a few issues before publication:

Issue #1

I think the intended scope of this document is not consistently stated (explicitly and implicitly):
(1) the document title is "Tunneling Security Concerns";
(2) the abstract states "The primary intent of this document is to raise the awareness level ..."
(3) the introduction states "This document discusses security concerns ... and includes recommendations
where relevant."
(4) the introduction also states "The primary intent is to help improve security deployments ..."

Based on the title and the abstract, I was expecting a problem statement draft.  The first bit I quoted from the
intro implies that this is a problem statement draft, and the recommendations are an afterthought.  The last bit
says the recommendations are the whole point of the document.

IMHO, the recommendations are the most important contribution made by this document.  I would like to see
edits in the abstract and intro to clearly state that.  It may be too late to address the title, but "Mitigating
Tunneling Security Concerns" would also clearly demonstrate that scope.

Issue #2

The document presents a collection of network architecture and network administration recommendations,
but readers might really benefit from some summary recommendations.  I was hoping for a section that
moved the document from a laundry list to a methodology of sorts that worked through the architectural
decisions first, then moved on to mitigating the specific problems remaining after the architectural decisions
are made.  For example, it seems that architecting your network so that tunnels don't cross security
boundaries is a key first step.  If you don't follow that recommendation, everything else is harder, isn't it?

Issue #3

The introduction closes with "The intended audience ... includes network administrators and future protocol
developers."  I had a hard time understanding what the lessons are for future protocol developers.

Perhaps a paragraph or two summarizing recommendations for protocol developers would be useful here.

Issue #3

Section 5.1 is conspicuous in its structure: it includes a "5.1.1 Problem", but omits the expected
"5.1.2 Discussion" and "5.1.3 Recommendations".  Is it true that there is nothing to say here?
2011-01-05
04 Tim Polk
[Ballot comment]
This is a useful document and I support its publication.  I believe this could be a better and more useful document if the …
[Ballot comment]
This is a useful document and I support its publication.  I believe this could be a better and more useful document if the authors could address a few issues before publication:

Issue #1

I think the intended scope of this document is not consistently stated (explicitly and implicitly):
(1) the document title is "Tunneling Security Concerns";
(2) the abstract states "The primary intent of this document is to raise the awareness level ..."
(3) the introduction states "This document discusses security concerns ... and includes recommendations where relevant."
(4) the introduction also states "The primary intent is to help improve security deployments ..."

Based on the title and the abstract, I was expecting a problem statement draft.  The first bit I quoted from the intro implies that this is a problem statement draft, and the recommendations are an afterthought.  The last bit says the recommendations are the whole point of the document.

IMHO, the recommendations are the most important contribution made by this document.  I would like to see edits in the abstract and intro to clearly state that.  It may be too late to address the title, but "Mitigating Tunneling Security Concerns" would also clearly demonstrate that scope.

Issue #2

The document presents a collection of network architecture and network administration recommendations, but readers might really benefit from some summary recommendations.  I was hoping for a section that moved the document from a laundry list to a methodology of sorts that worked through the architectural decisions first, then moved on to mitigating the specific problems remaining after the architectural decisions are made.  For example, it seems that architecting your network so that tunnels don't cross security boundaries is a key first step.  If you don't follow that recommendation, everything else is harder, isn't it?

Issue #3

The introduction closes with "The intended audience ... includes network administrators and future protocol developers."  I had a hard time understanding what the lessons are for future protocol developers.

Perhaps a paragraph or two summarizing recommendations for protocol developers would be useful here.

Issue #3

Section 5.1 is conspicuous in its structure: it includes a "5.1.1 Problem", but omits the expected "5.1.2 Discussion" and "5.1.3 Recommendations".  Is it true that there is nothing to say here?
2011-01-05
04 Tim Polk [Ballot Position Update] New position, No Objection, has been recorded
2011-01-01
04 Ron Bonica State changed to IESG Evaluation from Waiting for AD Go-Ahead.
2010-12-29
04 (System) State changed to Waiting for AD Go-Ahead from In Last Call.
2010-12-27
04 Ron Bonica Placed on agenda for telechat - 2011-01-06 by Ron Bonica
2010-12-27
04 Ron Bonica [Ballot Position Update] New position, Yes, has been recorded for Ronald Bonica
2010-12-27
04 Ron Bonica Ballot has been issued by Ron Bonica
2010-12-27
04 Ron Bonica Created "Approve" ballot
2010-12-21
04 Amanda Baber We understand that this document does not require any IANA actions.
2010-12-17
04 David Harrington Request for Last Call review by TSVDIR is assigned to Brian Pawlowski
2010-12-17
04 David Harrington Request for Last Call review by TSVDIR is assigned to Brian Pawlowski
2010-12-16
04 Samuel Weiler Request for Last Call review by SECDIR is assigned to Kurt Zeilenga
2010-12-16
04 Samuel Weiler Request for Last Call review by SECDIR is assigned to Kurt Zeilenga
2010-12-15
04 Cindy Morgan Last call sent
2010-12-15
04 Cindy Morgan
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: …
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Security Concerns With IP Tunneling) to Informational RFC


The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- 'Security Concerns With IP Tunneling'
  as an Informational
RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2010-12-29. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-tunnel-security-concerns/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-tunnel-security-concerns/
2010-12-15
04 Ron Bonica Last Call was requested
2010-12-15
04 Ron Bonica State changed to Last Call Requested from Publication Requested.
2010-12-15
04 (System) Ballot writeup text was added
2010-12-15
04 (System) Last call text was added
2010-12-15
04 (System) Ballot approval text was added
2010-10-27
04 Amy Vezza
This is the document shepherd writeup for
draft-ietf-v6ops-tunnel-security-concerns-04 (Security Concerns With IP
Tunneling) prepared 10/27/2010.

1.a

Joel Jaeggli v6ops wg cochair is the document shepherd. …
This is the document shepherd writeup for
draft-ietf-v6ops-tunnel-security-concerns-04 (Security Concerns With IP
Tunneling) prepared 10/27/2010.

1.a

Joel Jaeggli v6ops wg cochair is the document shepherd. The document
shepherd has reviewed the draft and observed the wg progress and
concluded that the draft is ready for publication.

1.b

The v6ops working group has extensively reviewed the document. during
last call review and comentary from erik kline and fernando gont were
incorporated into the current draft-04, a full review was performed by
fred templin on draft-02.

1.c

The document shepherd has no such concerns, given the intended status
and the goals of the document, IETF last call will be adequate. The
document has been quite extensively socialized up to this point.

1.d

The document shepherd has no such concerns.

1.e

No significant concerns with the document became apparent during working
group last call. some corrections were applied.

1.f

No appeals are forseen.

1.g

Four warnings related to references, no nits that should preclude
advancement.

1.h

References are entirely and corretly identified as informative.

1.i

Document does not request any consideration on the part of IANA

1.j

No format language is present to require validation

1.k

Technical Summary

A number of security concerns with IP tunnels are documented in this
memo. The intended audience of this document includes network
administrators and future protocol developers. The primary intent of
this document is to raise the awareness level regarding the security
issues with IP tunnels as deployed today.

Working Group Summary

The document draft-ietf-v6ops-tunnel-security-concerns was accepted as
working group document in july 2008. Last call following three revisions
was completed 9/14. minor changes were made due to last call input and
document was submitted to IESG on 10/27.

Document Quality

The document draft-ietf-v6ops-tunnel-security-concerns, addresses
significant problems presented by ipv6 tunnels in an ipv4 and ipv6
security context. Since this document was conceived and initially
socialized awareness of the problems and recommendations that the
document contains has increased significantly. The document provides a
problem statement and recommendations at a critical juncture and it's
utility is straight-forward.
2010-10-27
04 Amy Vezza Draft Added by Amy Vezza in state Publication Requested
2010-10-27
04 Amy Vezza [Note]: 'Joel Jaeggli (joelja@bogus.com) v6ops wg cochair is the document shepherd.' added by Amy Vezza
2010-10-25
04 (System) New version available: draft-ietf-v6ops-tunnel-security-concerns-04.txt
2010-10-21
03 (System) New version available: draft-ietf-v6ops-tunnel-security-concerns-03.txt
2010-03-08
02 (System) New version available: draft-ietf-v6ops-tunnel-security-concerns-02.txt
2008-10-15
01 (System) New version available: draft-ietf-v6ops-tunnel-security-concerns-01.txt
2008-09-05
04 Samuel Weiler Request for Early review by SECDIR Completed. Reviewer: Kurt Zeilenga.
2008-08-06
04 Samuel Weiler Request for Early review by SECDIR is assigned to Kurt Zeilenga
2008-08-06
04 Samuel Weiler Request for Early review by SECDIR is assigned to Kurt Zeilenga
2008-07-07
00 (System) New version available: draft-ietf-v6ops-tunnel-security-concerns-00.txt