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.