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. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
