Skip to main content

Security Concerns with IP Tunneling
RFC 6169


(Ron Bonica)

No Objection

(Dan Romascanu)
(Peter Saint-Andre)
(Russ Housley)
(Sean Turner)

Note: This ballot was opened for revision 04 and is now closed.

Jari Arkko Former IESG member
Yes (2011-01-05) Unknown
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.)
Ron Bonica Former IESG member
Yes () Unknown

Adrian Farrel Former IESG member
(was Discuss) No Objection
No Objection (2011-01-17) Unknown
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?
Dan Romascanu Former IESG member
No Objection
No Objection () Unknown

Peter Saint-Andre Former IESG member
No Objection
No Objection () Unknown

Russ Housley Former IESG member
(was Discuss) No Objection
No Objection () Unknown

Sean Turner Former IESG member
No Objection
No Objection () Unknown

Stewart Bryant Former IESG member
No Objection
No Objection (2011-01-05) Unknown
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.

Tim Polk Former IESG member
No Objection
No Objection (2011-01-05) Unknown
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?