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 10:20 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 267723A6AD0 for <ietfarch-v6ops-archive@core3.amsl.com>; Wed, 27 Aug 2008 03:20:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.53
X-Spam-Level:
X-Spam-Status: No, score=0.53 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, 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 1PDZoYRvEuWR for <ietfarch-v6ops-archive@core3.amsl.com>; Wed, 27 Aug 2008 03:20:24 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 331763A680C for <v6ops-archive@lists.ietf.org>; Wed, 27 Aug 2008 03:20:24 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-v6ops@ops.ietf.org>) id 1KYI5p-0007DQ-8q for v6ops-data@psg.com; Wed, 27 Aug 2008 10:17:37 +0000
Received: from [203.6.132.90] (helo=mistral.mail.adnap.net.au) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from <ipng@69706e6720323030352d30312d31340a.nosense.org>) id 1KYI5g-0007C8-PM for v6ops@ops.ietf.org; Wed, 27 Aug 2008 10:17:35 +0000
Received: from 219-90-160-185.ip.adam.com.au ([219.90.160.185] helo=mail.nosense.org) by mistral.mail.adnap.net.au with esmtp (Exim 4.69 (FreeBSD)) (envelope-from <ipng@69706e6720323030352d30312d31340a.nosense.org>) id 1KYICM-000FvE-Ex; Wed, 27 Aug 2008 19:54:22 +0930
Received: from ubu.nosense.org (localhost.localdomain [127.0.0.1]) by mail.nosense.org (Postfix) with SMTP id DF50CC34B; Wed, 27 Aug 2008 19:47:13 +0930 (CST)
Date: Wed, 27 Aug 2008 19:47:13 +0930
From: Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org>
To: Dan Wing <dwing@cisco.com>
Cc: 'Truman Boyes' <truman@suspicious.org>, 'Brian E Carpenter' <brian.e.carpenter@gmail.com>, jhw@apple.com, 'IPv6 Operations' <v6ops@ops.ietf.org>
Subject: 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: <20080827194713.23271bd1.ipng@69706e6720323030352d30312d31340a.nosense.org>
In-Reply-To: <08be01c90712$d876cd40$c2f0200a@cisco.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>
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>

On Mon, 25 Aug 2008 17:29:47 -0700
"Dan Wing" <dwing@cisco.com> wrote:

> > On 25/08/2008, at 6:37 PM, Brian E Carpenter wrote:
> > > But blocking tunnels by default, although it's simple, also
> > > blocks innovation. That worries me.
> > >
> > >    Brian
> > 
> > I agree with this stance. Blocking tunnels, although possibly more  
> > secure is going to make it very difficult to solve real world  
> > problems. We have enough trouble today with IPv4 Port forwarding in  
> > CPEs and the fact that some devices do not by default pass VPN  
> > traffic. I believe internal to external tunnel flow/solicitation  
> > should be permitted by default.
> 
> Internalt to external is permitted, by default, in the current document.
> 
> We are discussing external to internal.  
> 

external to interal what? IPv6 in IPv4, IPv6 in GRE in IPv4, IPv6 in
IPsec in IPv4, IPv6 in L2TP in IPv4, IPv6 in IPv6, IPv6 in GRE in IPv6
etc. etc.

The draft seems to be limited to specifying IPv6 only CPE
security functionality. My comments about limiting uninspected
inbound tunnel encapsuluation to authenticated protocols were only
regarding IPv6 in IPv6 (or IPsec over IPv6, or GRE over IPv6)
tunneling. No IPv4 involved or seen.

All the discussion that has occured since seems to be discussing IPv6
over IPv4, and IMHO that is not within scope the way the draft
is currently written.

So it seems to me that before this discussion goes on too much more, we
should agree on exactly what we're talking about and what we understand
the draft is to cover. Namely, is it:

* IPv6 only CPE security functionality
* Native IPv6 CPE security, plus IPv4 security/functionality
requirements to support IPv6 transition via IPv4 tunnelling
* Native IPv6, plus IPv4 security/functionality requirements to support
IPv6 transition, and IPv4 security in both IPv4 NAT and Non-NAT
scenarios.

I certainly think the last point is out of scope. However, if the
second one is the scope, then I think the draft will have to deal with
 and specify all the various IPv4 NAT/NAPT/No NAT tunnelling scenarios
and security issues related to tunnelling IPv6 over IPv4.

Regards,
Mark.