Re: SECDIR review: draft-ietf-v6ops-tunnel-concerns
Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 22 October 2008 20:25 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 97A7828C0FC for <ietfarch-v6ops-archive@core3.amsl.com>; Wed, 22 Oct 2008 13:25:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.546
X-Spam-Level:
X-Spam-Status: No, score=-1.546 tagged_above=-999 required=5 tests=[AWL=-1.051, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 t4Lq9XbNPmj8 for <ietfarch-v6ops-archive@core3.amsl.com>; Wed, 22 Oct 2008 13:25:42 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7674A3A6A97 for <v6ops-archive@lists.ietf.org>; Wed, 22 Oct 2008 13:25:41 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-v6ops@ops.ietf.org>) id 1KskBj-000Nwe-Ko for v6ops-data@psg.com; Wed, 22 Oct 2008 20:20:15 +0000
Received: from [209.85.217.20] (helo=mail-gx0-f20.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from <brian.e.carpenter@gmail.com>) id 1KskBc-000Nw9-FI for v6ops@ops.ietf.org; Wed, 22 Oct 2008 20:20:12 +0000
Received: by gxk13 with SMTP id 13so8199210gxk.17 for <v6ops@ops.ietf.org>; Wed, 22 Oct 2008 13:20:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=/uoRPRq8x4yh9euQOshuI6QEd3Qa7Y75PwiiOFRtV64=; b=e5NbrS194sOV2viBQEdkvLJO1UZns9YUmJPVukrvd7QGLXKBQ//debitZ38c27GaeG uLrIBiVZVdQsDPexkw/1gauwheAoTr+PUco8S8nci0rlsLE1MJcrv6h6lHDi9IsVFFfu 7an5VTPh2UF9Vf486C3ouqgDDtLhfFqocGGEQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=BMuXRtHuy81rVFrfaFFylXWrRVWa/qp7mNZKrUCAnxazUFSygH/wOn0qWzk1AIqCOF 4/lwSYCUdIOFM2oMyYoJmqBsym9OCenJgXEehzdmsbSnRkv1VlXweM7CsBQJLgaDizCO 6sDc/LHP82CWjRIvHgZZ9AJpqa+GGIrVAxbHY=
Received: by 10.143.35.4 with SMTP id n4mr4561992wfj.64.1224706807011; Wed, 22 Oct 2008 13:20:07 -0700 (PDT)
Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 28sm22227652wfg.15.2008.10.22.13.20.03 (version=SSLv3 cipher=RC4-MD5); Wed, 22 Oct 2008 13:20:06 -0700 (PDT)
Message-ID: <48FF8AEC.9060708@gmail.com>
Date: Thu, 23 Oct 2008 09:19:56 +1300
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Nathan Ward <v6ops@daork.net>
CC: Suresh Krishnan <suresh.krishnan@ericsson.com>, Christian Huitema <huitema@windows.microsoft.com>, Kurt Zeilenga <Kurt.Zeilenga@Isode.com>, Pasi Eronen <Pasi.Eronen@nokia.com>, Tim Polk <tim.polk@nist.gov>, "secdir@mit.edu" <secdir@mit.edu>, "Jim_Hoagland@symantec.com" <Jim_Hoagland@symantec.com>, Dave Thaler <dthaler@windows.microsoft.com>, "v6ops@ops.ietf.org" <v6ops@ops.ietf.org>
Subject: Re: SECDIR review: draft-ietf-v6ops-tunnel-concerns
References: <8B128AB2-BBD9-49B9-A837-F00DD80BF5D3@Isode.com> <48F2C29B.8090900@ericsson.com> <D6947E23-5209-4767-882A-7EBA645B3DCB@daork.net> <48F8EE0D.4060307@ericsson.com> <48FB9A79.8040407@gmail.com> <8EFB68EAE061884A8517F2A755E8B60A134A70E895@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <48FDFBCB.1090508@ericsson.com> <48FE4681.4070006@gmail.com> <5333EA69-337F-4373-A247-1852B61D96C0@daork.net>
In-Reply-To: <5333EA69-337F-4373-A247-1852B61D96C0@daork.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>
Hi Nathan, On 2008-10-22 18:59, Nathan Ward wrote: > On 22/10/2008, at 10:15 AM, Brian E Carpenter wrote: > >> Suresh, >> >> You wrote to Christian: >> >>> 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. >> >> 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. > > 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. 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 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. > > > 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. 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
- Re: SECDIR review: draft-ietf-v6ops-tunnel-concer… Suresh Krishnan
- Re: SECDIR review: draft-ietf-v6ops-tunnel-concer… Nathan Ward
- Re: SECDIR review: draft-ietf-v6ops-tunnel-concer… Suresh Krishnan
- Re: SECDIR review: draft-ietf-v6ops-tunnel-concer… Brian E Carpenter
- RE: SECDIR review: draft-ietf-v6ops-tunnel-concer… Christian Huitema
- Re: SECDIR review: draft-ietf-v6ops-tunnel-concer… Suresh Krishnan
- Re: SECDIR review: draft-ietf-v6ops-tunnel-concer… Suresh Krishnan
- Re: SECDIR review: draft-ietf-v6ops-tunnel-concer… Brian E Carpenter
- RE: SECDIR review: draft-ietf-v6ops-tunnel-concer… Christian Huitema
- Re: SECDIR review: draft-ietf-v6ops-tunnel-concer… Nathan Ward
- Re: SECDIR review: draft-ietf-v6ops-tunnel-concer… Brian E Carpenter
- Re: SECDIR review: draft-ietf-v6ops-tunnel-concer… Truman Boyes
- Re: [secdir] SECDIR review: draft-ietf-v6ops-tunn… Brian E Carpenter
- Re: SECDIR review: draft-ietf-v6ops-tunnel-concer… Nathan Ward
- Re: SECDIR review: draft-ietf-v6ops-tunnel-concer… Brian E Carpenter
- Re: SECDIR review: draft-ietf-v6ops-tunnel-concer… Nathan Ward
- RE: SECDIR review: draft-ietf-v6ops-tunnel-concer… Templin, Fred L
- Re: SECDIR review: draft-ietf-v6ops-tunnel-concer… Nathan Ward
- Re: SECDIR review: draft-ietf-v6ops-tunnel-concer… Brian E Carpenter
- RE: SECDIR review: draft-ietf-v6ops-tunnel-concer… Templin, Fred L