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

[Suresh Krishnan <[e-mail]>]

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