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> Mon, 01 September 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 BAFEB3A6A70 for <ietfarch-v6ops-archive@core3.amsl.com>; Mon, 1 Sep 2008 14:45:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.281
X-Spam-Level: *
X-Spam-Status: No, score=1.281 tagged_above=-999 required=5 tests=[AWL=-0.756, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_EQ_AU=0.377, MIME_8BIT_HEADER=0.3, 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 X41FNP-LkqpX for <ietfarch-v6ops-archive@core3.amsl.com>; Mon, 1 Sep 2008 14:45:56 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4DF603A68A8 for <v6ops-archive@lists.ietf.org>; Mon, 1 Sep 2008 14:45:56 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-v6ops@ops.ietf.org>) id 1KaH5g-00015E-UP for v6ops-data@psg.com; Mon, 01 Sep 2008 21:37:40 +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 1KaH5d-00014N-3P for v6ops@ops.ietf.org; Mon, 01 Sep 2008 21:37:39 +0000
Received: from 219-90-184-193.ip.adam.com.au ([219.90.184.193] helo=mail.nosense.org) by smtp1.mail.adnap.net.au with esmtp (Exim 4.63 (FreeBSD)) (envelope-from <ipng@69706e6720323030352d30312d31340a.nosense.org>) id 1KaH5Z-0002AG-LR; Tue, 02 Sep 2008 07:07:33 +0930
Received: from ubu.nosense.org (localhost.localdomain [127.0.0.1]) by mail.nosense.org (Postfix) with SMTP id 0832BC343; Tue, 2 Sep 2008 07:07:19 +0930 (CST)
Date: Tue, 02 Sep 2008 07:07:19 +0930
From: Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org>
To: Rémi Denis-Courmont <rdenis@simphalempin.com>
Cc: james woodyatt <jhw@apple.com>, 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: <20080902070719.79b27288.ipng@69706e6720323030352d30312d31340a.nosense.org>
In-Reply-To: <0a778520d314db21a197b978a43b8644@chewa.net>
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> <20080828071200.212c7910.ipng@69706e6720323030352d30312d31340a.nosense.org> <0a778520d314db21a197b978a43b8644@chewa.net>
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="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>
On Thu, 28 Aug 2008 09:48:25 +0200 Rémi Denis-Courmont <rdenis@simphalempin.com> wrote: > > On Thu, 28 Aug 2008 07:12:00 +0930, Mark Smith > > <ipng@69706e6720323030352d30312d31340a.nosense.org> wrote: > > > 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): > > > > This is silly. If the user wants to bypass the CPE, (s)he can do it anyway. > > The point of a CPE is to provide security that the user _wants_ to have, > > not force security upon the user. > > I'm specificly talking about the *external to internal* direction. Note the text doesn't specify a direction for these tunnelled protocols: "Therefore, this document recommends the DEFAULT operating mode for residential IPv6 simple security is to permit all virtual private networking tunnel protocols to pass through the stateful filtering function. These include IPsec transport and tunnel modes as well as other IP-in-IP protocols." This would seem to me to allow unsolicited inbound tunnel encapsulated traffic from any source, via any of the stateless over-IPv6 tunnelling protocols or methods. I don't think that's very good security at all, going slightly higher level than my earlier example, here's the attack: (1) purchase a banner add on a popular webpage, with the advertisement image coming from your server, and use that to record valid and current global unicast IPv6 addresses. (2) attack those recorded addresses. Bypass all the v6 CPE security measures specified in this draft by sending your malicious packets inside an IPv6 in IPv6 or GRE in IPv6 tunnel. With luck, the end-node has its own firewalling, and I think that is fairly likely. The concern I have is that the CPE devices that will be built to this draft will have a big "security" sticker on the box, and yet it is so easy to bypass if we continue to permit all unsolicited inbound stateless tunnelling protocols. If people see a big "security" sticker on their CPE they may turn off their end-node security, "because they don't need it anymore." I think a false sense of security is worse than no security at all, because you think you've got it when you actually don't. I agree with the fundamental intention of the text I quoted above - I'm just concerned at how permissive it is. Limiting it to authenticated or negotiated state/session based tunnelling protocols would seem to me to limiting this firewall bypass method significantly without limiting too much the functionality that is intended by permitting these exterior initiated tunnels. Regards, Mark. > > We are talking about simple CPEs - not corporate firewalls! > > > > Blocking automatic tunneling (6to4 and/or Teredo) might make sense, but > > blocking manually configured tunnel does not - regardless of > > authentication. > > > > -- > > Rémi Denis-Courmont > >
- Fwd: Some suggestions for draft-ietf-v6ops-cpe-si… Fred Baker
- Some suggestions for draft-ietf-v6ops-cpe-simple-… Mark Smith
- Re: Some suggestions for draft-ietf-v6ops-cpe-sim… Brian E Carpenter
- RE: Some suggestions for draft-ietf-v6ops-cpe-sim… Dan Wing
- Re: Some suggestions for draft-ietf-v6ops-cpe-sim… Brian E Carpenter
- RE: Some suggestions for draft-ietf-v6ops-cpe-sim… Dan Wing
- Re: Some suggestions for draft-ietf-v6ops-cpe-sim… Mark Smith
- Re: Some suggestions for draft-ietf-v6ops-cpe-sim… EricLKlein
- Re: Some suggestions for draft-ietf-v6ops-cpe-sim… Brian E Carpenter
- RE: Some suggestions for draft-ietf-v6ops-cpe-sim… Dan Wing
- Re: Some suggestions for draft-ietf-v6ops-cpe-sim… Brian E Carpenter
- RE: Some suggestions for draft-ietf-v6ops-cpe-sim… Dan Wing
- Re: Some suggestions for draft-ietf-v6ops-cpe-sim… Brian E Carpenter
- RE: Some suggestions for draft-ietf-v6ops-cpe-sim… Dan Wing
- Re: Some suggestions for draft-ietf-v6ops-cpe-sim… Truman Boyes
- RE: Some suggestions for draft-ietf-v6ops-cpe-sim… Dan Wing
- Re: Some suggestions for draft-ietf-v6ops-cpe-sim… Brian E Carpenter
- Re: Some suggestions for draft-ietf-v6ops-cpe-sim… Gert Doering
- RE: Some suggestions for draft-ietf-v6ops-cpe-sim… Dan Wing
- Re: Some suggestions for draft-ietf-v6ops-cpe-sim… Rémi Després
- Re: Some suggestions for draft-ietf-v6ops-cpe-sim… Rémi Després
- Re: Some suggestions for draft-ietf-v6ops-cpe-sim… Gert Doering
- Re: Some suggestions for draft-ietf-v6ops-cpe-sim… Rémi Denis-Courmont
- But are we talking IPv6 only? That's how I read t… Mark Smith
- RE: Some suggestions for draft-ietf-v6ops-cpe-sim… teemu.savolainen
- Re: Some suggestions for draft-ietf-v6ops-cpe-sim… Rémi Després
- RE: Some suggestions for draft-ietf-v6ops-cpe-sim… Rémi Denis-Courmont
- Re: Some suggestions for draft-ietf-v6ops-cpe-sim… Rémi Denis-Courmont
- RE: Some suggestions for draft-ietf-v6ops-cpe-sim… Dan Wing
- RE: But are we talking IPv6 only? That's how I re… Dan Wing
- Re: Some suggestions for draft-ietf-v6ops-cpe-sim… james woodyatt
- Re: Some suggestions for draft-ietf-v6ops-cpe-sim… james woodyatt
- Re: But are we talking IPv6 only? That's how I re… james woodyatt
- RE: Some suggestions for draft-ietf-v6ops-cpe-sim… Dan Wing
- Re: But are we talking IPv6 only? That's how I re… Mark Smith
- Purpose of ALD (was Re: Some suggestions for draf… james woodyatt
- Re: But are we talking IPv6 only? That's how I re… james woodyatt
- RE: Purpose of ALD (was Re: Some suggestions for … Dan Wing
- RE: But are we talking IPv6 only? That's how I re… Dan Wing
- Re: But are we talking IPv6 only? That's how I re… james woodyatt
- RE: But are we talking IPv6 only? That's how I re… Dan Wing
- Re: But are we talking IPv6 only? That's how I re… Rémi Denis-Courmont
- RE: But are we talking IPv6 only? That's how I re… Templin, Fred L
- RE: But are we talking IPv6 only? That's how I re… Dan Wing
- RE: But are we talking IPv6 only? That's how I re… Templin, Fred L
- Re: But are we talking IPv6 only? That's how I re… james woodyatt
- RE: But are we talking IPv6 only? That's how I re… Templin, Fred L
- Re: But are we talking IPv6 only? That's how I re… james woodyatt
- RE: But are we talking IPv6 only? That's how I re… Templin, Fred L
- Re: But are we talking IPv6 only? That's how I re… Rémi Després
- RE: But are we talking IPv6 only? That's how I re… Dan Wing
- RE: But are we talking IPv6 only? That's how I re… Templin, Fred L
- Re: But are we talking IPv6 only? That's how I re… Rémi Després
- RE: But are we talking IPv6 only? That's how I re… Templin, Fred L
- RE: But are we talking IPv6 only? That's how I re… Dan Wing
- Re: But are we talking IPv6 only? That's how I re… Mark Smith
- Re: But are we talking IPv6 only? That's how I re… Mark Smith
- Re: tunnel protocols (draft-ietf-v6ops-cpe-simple… james woodyatt