Re: But are we talking IPv6 only? That's how I read the draft. (Re: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03)

Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org> Wed, 27 August 2008 21: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 A80133A635F for <ietfarch-v6ops-archive@core3.amsl.com>; Wed, 27 Aug 2008 14:45:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.275
X-Spam-Level:
X-Spam-Status: No, score=-0.275 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_AU=0.377, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1, RELAY_IS_203=0.994]
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 Wn4WeQjz4DCI for <ietfarch-v6ops-archive@core3.amsl.com>; Wed, 27 Aug 2008 14:45:49 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 62DA73A6407 for <v6ops-archive@lists.ietf.org>; Wed, 27 Aug 2008 14:45:39 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-v6ops@ops.ietf.org>) id 1KYSmK-000OO3-3I for v6ops-data@psg.com; Wed, 27 Aug 2008 21:42:12 +0000
Received: from [203.6.132.75] (helo=smtp1.mail.adnap.net.au) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from <ipng@69706e6720323030352d30312d31340a.nosense.org>) id 1KYSmF-000ONS-O9 for v6ops@ops.ietf.org; Wed, 27 Aug 2008 21:42:10 +0000
Received: from 219-90-160-185.ip.adam.com.au ([219.90.160.185] helo=mail.nosense.org) by smtp1.mail.adnap.net.au with esmtp (Exim 4.63 (FreeBSD)) (envelope-from <ipng@69706e6720323030352d30312d31340a.nosense.org>) id 1KYSmD-000Orz-Bo; Thu, 28 Aug 2008 07:12:05 +0930
Received: from ubu.nosense.org (localhost.localdomain [127.0.0.1]) by mail.nosense.org (Postfix) with SMTP id E4683C34B; Thu, 28 Aug 2008 07:12:00 +0930 (CST)
Date: Thu, 28 Aug 2008 07:12:00 +0930
From: Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org>
To: james woodyatt <jhw@apple.com>
Cc: IPv6 Operations <v6ops@ops.ietf.org>
Subject: Re: But are we talking IPv6 only? That's how I read the draft. (Re: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03)
Message-Id: <20080828071200.212c7910.ipng@69706e6720323030352d30312d31340a.nosense.org>
In-Reply-To: <CD947C45-58F7-47F1-807F-A276490B1E39@apple.com>
References: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org> <48B1CCE8.1070305@gmail.com> <01af01c9065b$b4602440$c2f0200a@cisco.com> <48B23391.1090503@gmail.com> <01cd01c90672$a57c8790$c2f0200a@cisco.com> <48B31DA3.6080001@gmail.com> <07d201c906f7$50a85e30$c2f0200a@cisco.com> <48B32B43.5010103@gmail.com> <084c01c906fe$f9bf1840$c2f0200a@cisco.com> <48B33430.40704@gmail.com> <A31EB889-2BD9-4283-A408-AB6DCC1D568A@suspicious.org> <08be01c90712$d876cd40$c2f0200a@cisco.com> <20080827194713.23271bd1.ipng@69706e6720323030352d30312d31340a.nosense.org> <CD947C45-58F7-47F1-807F-A276490B1E39@apple.com>
X-Mailer: Sylpheed 2.5.0 (GTK+ 2.12.11; i686-pc-linux-gnu)
X-Location: Lower Mitcham, South Australia, 5062
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Hi James,

On Wed, 27 Aug 2008 12:12:28 -0700
james woodyatt <jhw@apple.com> wrote:

> On Aug 27, 2008, at 03:17, Mark Smith wrote:
> > * Native IPv6 CPE security, plus IPv4 security/functionality
> > requirements to support IPv6 transition via IPv4 tunnelling
> 
> It was my understanding that this is the proper scope, not the  
> alternatives you mentioned.
> 

In that case, I'd still strongly suggest limiting the IPv6 in IPv6
tunnel support to authenticated protocols only. Bypassing the CPE
security using a linux box (or anything else that supports end-user
manually configured tunnels, on which the user has admin priviledges)
will be as simple as something like this (syntax probably not right ,
but that's because I've got a few minutes before I need to get ready for
work):

# ip -6 tunnel add v6cpe-bypass  remote 2001:<public node address>
# nmap -e v6cpe-bypass

As I understand the current draft, this would completely bypass any and
all of the IPv6 security mechanisms in the device - and because it's so
easy to do, anybody who wants to make an attempt at attacking an
end-node will do so this way. Only permitting inbound authenticated
tunneling protocols like IPsec, l2tp or pptp would easily defeat that.

Regards,
Mark.