Document Action: 'Security Concerns With IP Tunneling' to Informational RFC (draft-ietf-v6ops-tunnel-security-concerns-04.txt)

[The IESG <[e-mail]>]

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

   Relevant content can frequently be found in the abstract
   and/or introduction of the document.  If not, this may be 
   an indication that there are deficiencies in the abstract
   or introduction.

Working Group Summary

   Was there anything in the WG process that is worth noting?
   For example, was there controversy about particular points 
   or were there decisions where the consensus was
   particularly rough? 

Document Quality

   Are there existing implementations of the protocol?  Have a 
   significant number of vendors indicated their plan to
   implement the specification?  Are there any reviewers that
   merit special mention as having done a thorough review,
   e.g., one that resulted in important changes or a
   conclusion that the document had no substantive issues?  If
   there was a MIB Doctor, Media Type, or other Expert Review,
   what was its course (briefly)?  In the case of a Media Type
   Review, on what date was the request posted?

Personnel

   Who is the Document Shepherd for this document?  Who is the 
   Responsible Area Director?  If the document requires IANA
   experts(s), insert 'The IANA Expert(s) for the registries
   in this document are <TO BE ADDED BY THE AD>.'

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.