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

Nathan Ward <v6ops@daork.net> Mon, 13 October 2008 07:45 UTC

Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B5623A68F7 for <ietfarch-v6ops-archive@core3.amsl.com>; Mon, 13 Oct 2008 00:45:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.361
X-Spam-Level:
X-Spam-Status: No, score=-5.361 tagged_above=-999 required=5 tests=[AWL=-0.313, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4MiCHAtsAzU for <ietfarch-v6ops-archive@core3.amsl.com>; Mon, 13 Oct 2008 00:45:45 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E7CA13A681B for <v6ops-archive@lists.ietf.org>; Mon, 13 Oct 2008 00:45:44 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-v6ops@ops.ietf.org>) id 1KpI3n-000LJO-0r for v6ops-data@psg.com; Mon, 13 Oct 2008 07:41:47 +0000
Received: from [60.234.76.2] (helo=unobtainium.braintrust.co.nz) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from <v6ops@daork.net>) id 1KpI3g-000LIk-HY for v6ops@ops.ietf.org; Mon, 13 Oct 2008 07:41:43 +0000
Received: from [192.168.0.51] (ip-118-90-104-146.xdsl.xnet.co.nz [118.90.104.146]) by unobtainium.braintrust.co.nz (Postfix) with ESMTP id D04052793F; Mon, 13 Oct 2008 20:41:38 +1300 (NZDT)
Cc: Kurt Zeilenga <Kurt.Zeilenga@Isode.com>, Pasi Eronen <Pasi.Eronen@nokia.com>, Tim Polk <tim.polk@nist.gov>, secdir@mit.edu, Jim_Hoagland@symantec.com, dthaler@microsoft.com, v6ops@ops.ietf.org
Message-Id: <D6947E23-5209-4767-882A-7EBA645B3DCB@daork.net>
From: Nathan Ward <v6ops@daork.net>
To: Suresh Krishnan <suresh.krishnan@ericsson.com>
In-Reply-To: <48F2C29B.8090900@ericsson.com>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: Re: SECDIR review: draft-ietf-v6ops-tunnel-concerns-00
Date: Mon, 13 Oct 2008 20:41:37 +1300
References: <8B128AB2-BBD9-49B9-A837-F00DD80BF5D3@Isode.com> <48F2C29B.8090900@ericsson.com>
X-Mailer: Apple Mail (2.929.2)
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

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

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

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.

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

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