[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SECDIR review: draft-ietf-v6ops-tunnel-concerns-00

Hi Kurt,
  Thank you very much for your detailed review and sorry for the long
delay in our response. We have modified the draft to address some of
your concerns. We also had a few questions for you. Please find our
responses inline.

Kurt Zeilenga wrote:
I have reviewed this document as part of the security directorate's ongoing review efforts. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like they would treat comments from any other IETF contributor. 

This document discusses "Security Concerns with [IP] Tunnels".
I suggest the Security AD pay particular attention to this I-D. Given it purports to discuss security concerns applicable to a wide range of [IP] tunneling solutions, it may be appropriate for this I-D to be assigned to additional secdir reviewers. 

Comments:
The title and abstract apply this document discusses a wide range of tunnel technologies, but the text seems focused on IP Tunnels (though I guess some of the concerns might apply to various non-IP network tunnels). It might be appropriate to change the title to "Security Concerns with IP Tunneling", and to clarify the abstract.
We have changed the title to "Security Concerns With IP Tunneling" as you suggested. 



My comments assume "IP tunneling" was meant.
It's not clear what track this I-D is targeted for. I will assume Informational. 

Yes. This is meant to be informational


The abstract seems a bit short.
The abstract starts off with:

A number of security concerns with tunnels are documented.
where? In this document or elsewhere? If elsewhere, I would hope the body will detail and provide references to where these concerns are documented. 

In this document. We have fixed the abstract to say this. The new
abstract is attached below



The abstract ends with:

   The
primary intent of this document is to raise the awareness regarding the security issues with tunnels as deployed today.
It's not clear who the intended audience is of this document. Implementors? Network Operators? Deployers? Etc. But it does say "as deployed today", which I take as meaning that this document focuses on security issues in existing IP tunneling solutions. 

The intended audience is network admins and future protocol developers.
We have changed the abstract to read:

"   A number of security concerns with IP tunnels are documented in this
   document.  The intended audience of this document includes network
   administrators and future protocol developers.  The primary intent of
   this document is to raise the awareness regarding the security issues
   with IP tunnels as deployed today. "



The Introduction says:
The primary intent of this document is to provide information that can be used in any new or updated tunnel protocol specification.
I don't read either of these 'primary intent' statements as being equivalent to the other. 
2.1.2 says,

   Evasion by tunneling is often a problem for network-based security
   devices such as network firewalls, intrusion detection and prevention
   systems, and router controls.


which leads to 2.1.3 recommendation:

   Security administrators who do not consider tunneling an acceptable
   risk should disable tunnel functionality unless their network-based
   security controls adequately recognize the tunneled traffic.
If the network-based security controls don't have adequate ability to recognize tunneled traffic, how does the security administrator go about disabling tunneled traffic? Is the administrator to turn off everything that might carry a tunnel? If so, wouldn't that be just about everything? 

One way to go about doing this is to disable the specific tunneling
method on the end-hosts. We have added the following text

"  Security administrators who do not consider tunneling an acceptable
   risk should disable tunnel functionality either on the end-nodes
   (hosts) or on the network nodes."

to mention this possibility.


In 2.1.3 says:

   To minimize security exposure due to tunnels, we recommend that a
   tunnel be an interface of last resort, independent of IP version.
   Specifically, we suggest that when both native and tunneled access to
   a remote host is available, that the native-based access be used in
   preference to tunneled access.  This should also promote greater
   efficiency and reliability.
This recommendation appears to ignore cases where the tunnel offers data protective services not available natively. 

We have changed

"  Specifically, we suggest that when both native and tunneled access to
   a remote host is available, that the native access be used in
   preference to tunneled access."

to

"  Specifically, we suggest that when both native and tunneled access to
   a remote host is available, that the native access be used in
   preference to tunneled access except when the tunnel endpoint is
   known to not bypass security (e.g., an IPsec tunnel to a gateway
   provided by the security administrator of the network)."

in order to allow tunnels offering protective service to still be preferred.




   Given concerns about tunnel security or a network's lack of
   preparedness for tunnels, a network administrator may wish to simply
   block all use of tunnels.  He or she may wish to do so using network
   controls; this could be either due to not having confidence in the
   ability to disable it on all hosts attached to the network or due to
   wanting an extra layer of prevention.
It may be appropriate to note here that by "simply blocking all use of tunnels", the network administrator hinders the ability of users from taking steps to gain security benefit provided by use of tunnels. 

We have added the phrase "that subvert security" to the end of this
sentence so that it reads

"  Given concerns about tunnel security or a network's lack of
   preparedness for tunnels, a network administrator may wish to simply
   block all use of tunnels that subvert security."




   One simple method to do that is easy to employ for many tunnel
   protocols is to block outbound packets to the UDP or TCP port used
   (e.g., UDP port 3544 for Teredo, UDP port 1701 for L2TP, etc.).
The description of this method is not precise. Is the method to block dest ports, with these source ports, or either, or both? 

The method is to block destination ports. We have changed this sentence
to read
(e.g., destination UDP port is 3544 for Teredo, UDP port 1701 for
   L2TP, etc.)
It is not known if blocking all traffic to a given outbound port will interfere with 
   non-tunneled traffic.
Actually, I think it is generally known that blocking all traffic to a given outbound port may very well interfere with non-tunnel traffic. The document statement seems to discount operational experience of simply blocking all traffic to a given outbound port may be harmful. 

We have changed this text to read

"  In some cases, however, blocking all traffic to a given outbound port
   (e.g., port 80) may interfere with non-tunneled traffic so this
   should be used with caution."



In 3.1.3,

   Tunneling over UDP or TCP (including HTTP) to reach the Internet is
   not recommended as a solution for managed networks.
First, I'm going to read the sentence as if the word 'managed' was not used as I think all networks on the Internet are 'managed' to some degree. If the authors had a particular definition of the term 'managed network' in mind, they should define it.
So reading the sentence without the term 'managed', this is basically a general applicability statement that use of tunneling over UDP or TCP is not recommend for use to 'reach the Internet'. I don't see this recommendation as being appropriate given the issue. 

We have changed this text to read

"  Tunneling over UDP or TCP (including HTTP) to reach the Internet is
   not recommended as a solution for networks that wish to enforce
   security polcies on the user traffic.  (Windows, for example,
   disables Teredo by default if it detects that it is within an
   enterprise network that contains a Windows domain controller.)"



In 3.2.3,

   As illustrated above, it should be clear that inspecting the contents
   of tunneled data packets is highly complex and often impractical.
I would argue that inspecting the contents of non-tunneled data packets is also highly complex and often impractical. 

We agree with you and we are not claiming otherwise.


   For this reason, if a network wishes to monitor IP traffic, tunneling
   is not recommended.
I think it depends on what kind of IP traffic monitoring one wants to do. Also, if the user doesn't want there data monitored, recommending use of tunneling with data confidential protections seems quite appropriate.
The term "NAT" appears to be used to refer to a device (e.g., "a NAT") not a process (of address translation). This seems improper given that NAT expands to Network Address Translation. 

We have changed the document to say "NAT device" when we talk about the
device and NAT when we talk about the process, as you stated.


Many acronyms are not spelled out.
Given this document provides only only a high-level discussion, why are there so many normative references? Why does a reader need to read, for instance, RFC 1918, to understand this document? Seems RFC 1918 only provides information in support of an example. Seems there is significant over use of normative references here. I think most of the references listed as normative are more appropriately listed as informative. 

Agreed. All the references have been moved to informative.



In the paragraphs:

      Protocols that embed an IPv4 address in a tunneled IPv6 address
      directly between peers often do filtering based on checking the
      correpondence.

      Protocols that accept tunneled packets directly from a server or
      relay do filtering the same way as it would be done on a native
      link with traffic from a router.
the text implies the protocols do filtering. Is this correct? It seems more likely that the devices implementing the protocol do the filtering. 

You are right. We have fixed the text to read

"     Implementations of protocols that embed an IPv4 address in a
      tunneled IPv6 address directly between peers often do filtering
      based on checking the correspondence.

      Implementations of protocols that accept tunneled packets directly
      from a server or relay do filtering the same way as it would be
      done on a native link with traffic from a router."




      To do host-based filtering with protocols that allow both other
      hosts and a router over a common tunnel (e.g., 6to4 [RFC3056],
      Teredo, ISATAP [RFC4214], and 6over4 [RFC2529]), hosts would need
      to be able to know the outer IP address of all routers from which
      it could receive traffic.

I am having a hard time parsing this sentence.


We have split this sentence into two parts and reworded it. The new text
reads

"     Some protocols such as 6to4 [RFC3056], Teredo, ISATAP [RFC4214],
      and 6over4 [RFC2529] allow both other hosts and a router over a
      common tunnel To perform host-based filtering with such protocols
      a host would need to know the outer IP address of each router from
      which it could receive traffic, so that packets from hosts beyond
      the router will be accepted even though the source address would
      not embed the router's IP address.  Router addresses might be
      learned via Secure Neighbor Discovery (SEND) [RFC3971] or some
      other mechanism (e.g., [RFC4214] section 8.3.2)."

Thanks
Suresh