Subject: Re: [secdir] SECDIR review: draft-ietf-v6ops-tunnel-concerns-00

From: Suresh Krishnan <[email-masked]>
Date: Sun, 12 Oct 2008 23:38:03 -0400

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

_______________________________________________
secdir mailing list
[email-masked]
https://mailman.mit.edu/mailman/listinfo/secdir
_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir

---

From: Nathan Ward <[email-masked]>
Date: Mon, 13 Oct 2008 20:41:37 +1300

On 13/10/2008, at 4:38 PM, Suresh Krishnan wrote:

>> The description of this method is not precise.  Is the method to  
>> block dest ports, with these source ports, or either, or both?
>

This makes me squirm a bit.

It seems silly to promote blocking discrete ports, when a user could  
simply run their own Teredo server on a different port and tunnel out  
with that, or run any other proxy or tunnel server of some kind on any  
port they wanted. We've all run PPP over SSH before, it's not hard to  
do this stuff, there are tools to do it automatically.

If an organisation is concerned about people tunnelling through their  
firewalls, they must use default-deny if they want to have any effect.

>> 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.
>

Why tunnelling over UDP or TCP? Why not tunnelling in IP as in 6to4?
I don't imagine that UDP makes it any more difficult to inspect than  
an IP protocol.

I think this statement should be changed to "Tunnelling through a  
security device (ie. firewall) is not recommended for.. " etc.

--
Nathan Ward

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 17 Oct 2008 15:57:01 -0400

Hi Nathan,
   Thanks for your comments. Please see responses inline.

Nathan Ward wrote:
> port they wanted. We've all run PPP over SSH before, it's not hard to do 
> this stuff, there are tools to do it automatically.

You are right. This will not stop people from tunneling over other 
ports. But what would you propose to be done instead?

> firewalls, they must use default-deny if they want to have any effect.

Given the savvy user you mentioned above, I don't understand how this 
will have any effect either. The users can still tunnel over anything 
that has been permitted ahead of the default deny.

>>> 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.
>>
> I don't imagine that UDP makes it any more difficult to inspect than an 
> IP protocol.
> 

Sounds good. We will make this change.

Cheers
Suresh

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 20 Oct 2008 09:37:13 +1300

...
> Sounds good. We will make this change.

Now you have me worried enough to say something I've been feeling
ever since I really read this draft carefully.

To exaggerate, <sarcasm> why not just rename it "tunneling considered
harmful" and chop it down to one paragraph? </sarcasm>

I think there's a real risk of this document being misunderstood
by typical site IT managers, and being used simply as an excuse
to block all kinds of tunnel-based v4/v6 coexistence. But tunnels
are a legitimate coexistence strategy. I'd much rather see
this document talking more about how to make the use of tunnels
safe as part of v4/v6 coexistence. There is some of that material
in the document, but the impression the draft leaves is now of
a succession of warnings to block tunnels.

    Brian

---

From: Christian Huitema <[email-masked]>
Date: Sun, 19 Oct 2008 21:40:20 -0700

> a succession of warnings to block tunnels.

Actually, it is a succession of warning to block standardized tunnels, those that are well documented and have a clear signature. By doing so, we are pushing application developers to just "roll their own technologies", and indeed to use evasive techniques such as encrypted packets, random port numbers or tunneling of HTTP. I am not sure that network managers are going to like the result...

-- Christian Huitema

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 21 Oct 2008 11:16:52 -0400

Hi Brian,

> harmful" and chop it down to one paragraph? </sarcasm>

The draft is about security concerns with tunnels. It discusses concerns 
and associated recommendations if the concern is considered valid by an 
admin. It was not our goal to say "tunneling considered harmful" but 
rather to say "If you want to do foo, tunneling might prevent you from 
doing foo. So disable tunnels" or "If you don't want your users to do 
foo, tunneling might allow them to do foo. So disable tunnels".

> a succession of warnings to block tunnels.

Although the draft started out as security concerns related to Teredo 
tunnels, it has been generalized to all kinds of tunnels and not limited 
to v4/v6 transition tunnels. The draft lists problems and possible 
solutions to those problems. If you think there is a problem with the 
tone of the document, I am sure we can work on fixing it, but I 
sincerely believe that all the stated concerns are real and not FUD.

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 21 Oct 2008 11:56:59 -0400

Hi Christian,
   Thanks for your comments. Please see my response inline

Christian Huitema wrote:
> Actually, it is a succession of warning to block standardized tunnels, 
> those that are well documented and have a clear signature. 
 > By doing so, we are pushing application developers to just "roll
> their own technologies", and indeed to use evasive techniques such as
 > encrypted packets, random port numbers or tunneling of HTTP. I am not
 > sure that network managers are going to like the result...

While I agree with you about the possibility of an "arms race" I really 
do not see anything we can do about this. What would you recommend 
instead? I am really open to suggestions.

Thanks
Suresh

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 22 Oct 2008 10:15:45 +1300

Suresh,

> instead? I am really open to suggestions.

My feeling is that we need to tell IT managers something like
"If your users have a need for IPv6 tunnels, here is how to
make them as safe as possible:

 <description of mechanisms, e.g. for detecting DoS,...>

and after that, explain the threats, and state that tunnels
should be disabled if you are not protected against the threats.

There are also other positive suggestions, like operating
an on-site 6to4 relay and/or Teredo server, so that those
mechanisms don't cross the border router.

I agree with you that there are real threats (or will be, once
there is enough deployment to make IPv6 tunnels an interesting
target). It's quite appropriate to document them.

    Brian

---

From: Christian Huitema <[email-masked]>
Date: Tue, 21 Oct 2008 14:20:53 -0700

>  <description of mechanisms, e.g. for detecting DoS,...>

I agree. Change the message to a positive tone. Start with the assumption that tunnels are going to happen one way or another, then work from there to specify the safe deployment guidelines, as appropriate for the various deployment cases.

-- Christian Huitema

---

From: Nathan Ward <[email-masked]>
Date: Wed, 22 Oct 2008 18:59:36 +1300

> mechanisms don't cross the border router.

Operating a Teredo server on site does not help unfortunately.

It helps an administrator filter outbound packets when sent to an IPv6  
address outside 2001::/32. It does not help an administrator filter  
inbound packets, or packets to/from other Teredo hosts.

> target). It's quite appropriate to document them.

I need to preface these remarks by say that I haven't read the  
document apart from a quick skim read, so sorry if I'm saying  
something that's already in there, or is not relevant.

I think it's important to distinguish between tunnels that end users'  
systems create automatically (ala 6to4, Teredo in Vista), and tunnels  
that end users create to work around firewalls.

The former is easy to document solutions for, in fact, it seems to me  
that any tunnelling protocol RFC should include details as to how a  
network administrator can prevent these protocols passing through  
their network. For Teredo this means blocking port 3544/3545. For 6to4  
this means blocking protocol 41 (preferably returning ICMPv6 messages  
encapsulated in 6to4 so the the application is told about it..). This  
is more about blocking things that do not work or perform poorly in a  
certain environment, rather than trying to secure a network.

The latter is not so easy, and I think this document should simply  
point out that the only way to really do this is to completely control  
the end users' machines, and not allow any third party software or  
configuration changes. Anything else is instilling a false sense of  
security in the minds of network administrators who perhaps are not as  
fluent in these things as we are.

--
Nathan Ward

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 23 Oct 2008 09:19:56 +1300

Hi Nathan,

> inbound packets, or packets to/from other Teredo hosts.

As far as I can see, there's a general problem in attempting
to detect and block Teredo packets (I mean UDP/IPv4 packets
in Teredo format). But it seems to me that by running an
internal Teredo server, a site is much better placed to
track and trace Teredo users. This is important as Teredo
users really need to be running an IPv6-savvy host firewall.

> I need to preface these remarks by say that I haven't read the document
> apart from a quick skim read, so sorry if I'm saying something that's
> already in there, or is not relevant.
> 
> network administrator can prevent these protocols passing through their
> network. For Teredo this means blocking port 3544/3545. For 6to4 this
> means blocking protocol 41 (preferably returning ICMPv6 messages
> encapsulated in 6to4 so the the application is told about it..). This is
> more about blocking things that do not work or perform poorly in a
> The latter is not so easy, and I think this document should simply point
> out that the only way to really do this is to completely control the end
> users' machines, and not allow any third party software or configuration
> changes. Anything else is instilling a false sense of security in the
> minds of network administrators who perhaps are not as fluent in these
> things as we are.

Yes, but there are plenty of environments where that's impossible,
and default deny is unacceptable because it blocks legitimate usage.
I think the document needs to steer between the extremes, and suggest
scenarios that are reasonably safe.

    Brian