Security Concerns with IP Tunneling
RFC 6169

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>,
    v6ops mailing list <v6ops@ietf.org>,
    v6ops chair <v6ops-chairs@tools.ietf.org>
Subject: Resend: Document Action: 'Security Concerns With IP Tunneling' to Informational RFC (draft-ietf-v6ops-tunnel-security-concerns-04.txt)

The IESG has approved the following document:
- 'Security Concerns With IP Tunneling'
  (draft-ietf-v6ops-tunnel-security-concerns-04.txt) as an Informational
RFC

This document is the product of the IPv6 Operations Working Group.

The IESG contact persons are Ron Bonica and Dan Romascanu.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-v6ops-tunnel-security-concerns/


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. 

Personnel

Joel Jaeggli is the document shepherd.  Ron Bonica is the responsible Area Director.

RFC Editor Note


* In the Abstract

OLD:

The primary intent of this document is to raise the awareness level regarding the security issues with IP tunnels as deployed today.

NEW:

The primary intent of this document is to raise the awareness level regarding the security issues with IP tunnels as deployed and propose strategies for the mitigation of those issues.



* After Section 5.1.1.

OLD:
<empty>

NEW:

5.1.2. Discussion

Several tunnel protocols use endpoint addresses that can be algorithmically derived from some known values. These addresses are structured and the fields contained in them can be fairly predictable. 
This reduces the search space for an attacker and reduces the resistance of the address to scanning attacks. e.g. Teredo addresses are formed using a well known prefix, client and server IPv4 addresses, the client port and a few flags. With a fairly narrow search space for most of these fields, it is easy to guess the tunnel endpoint address.

5.1.3. Recommendations

It is recommended that the tunnel protocol developers use tunnel endpoint addresses that are not easily guessable. When the tunnel endpoint addresses are structured and fairly guessable, it is recommended that the implementation use any unused fields in the address to provide additional entropy to the address  in order to reduce the address-scanning risks. e.g. This could be done by setting these unused fields to some random values.




* In Section 6.1.3

OLD:
    The scope of the attack can also be reduced by limiting tunneling use
    in general but especially in preferring native IPv4 to tunneled IPv6;
    this is because it is reasonable to expect that banks and similar web
    sites will continue to be accessible over IPv4 for as long as a
    significant fraction of their customers are still IPv4-only.

NEW:

    The scope of the attack can also be reduced by limiting tunneling use
    in general but especially in preferring native IPv4 to tunneled IPv6
    while connecting to peers who are accessible over IPv4, as doing so
    precludes attacks that are facilitated by changing the tunnel server
    setting.