Security Concerns with IP Tunneling
RFC 6169
Yes
No Objection
Note: This ballot was opened for revision 04 and is now closed.
(Jari Arkko; former steering group member) Yes
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 steering group member) Yes
(Adrian Farrel; former steering group member) (was Discuss) No Objection
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 steering group member) No Objection
(Peter Saint-Andre; former steering group member) No Objection
(Russ Housley; former steering group member) (was Discuss) No Objection
(Sean Turner; former steering group member) No Objection
(Stewart Bryant; former steering group member) No Objection
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 steering group member) No Objection
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?