Re: draft-ietf-v6ops-cpe-simple-security-04 WGLC
Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 21 April 2009 01:56 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 B6D813A6832 for <ietfarch-v6ops-archive@core3.amsl.com>; Mon, 20 Apr 2009 18:56:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.787
X-Spam-Level:
X-Spam-Status: No, score=-0.787 tagged_above=-999 required=5 tests=[AWL=-1.492, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_16=0.6, RDNS_NONE=0.1, SARE_BAYES_5x7=0.6]
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 BWlUrlNbCwwO for <ietfarch-v6ops-archive@core3.amsl.com>; Mon, 20 Apr 2009 18:56:51 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8EEA43A680B for <v6ops-archive@lists.ietf.org>; Mon, 20 Apr 2009 18:56:51 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-v6ops@ops.ietf.org>) id 1Lw59Z-000IrS-PC for v6ops-data0@psg.com; Tue, 21 Apr 2009 01:52:05 +0000
Received: from [209.85.198.238] (helo=rv-out-0506.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from <brian.e.carpenter@gmail.com>) id 1Lw59M-000IqM-OS for v6ops@ops.ietf.org; Tue, 21 Apr 2009 01:51:59 +0000
Received: by rv-out-0506.google.com with SMTP id g37so811470rvb.41 for <v6ops@ops.ietf.org>; Mon, 20 Apr 2009 18:51:52 -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=a4WlF7yliPXna5GzWMvLQATFnw26OpKWLb5bIMWQMUM=; b=r/AcHMwfnhZELvEX/ANNIGOjqC+BCfHWF6PaKfhREXLBCD98xwfhMcFrjZDaYbsZs1 JV4X3VXitUP9iFJLv2GTxhNtBowVfXfajpYhhWVVhPFExl9trdsAnyK4et1DaiVvaxUc Zgy6cKJuPYz2rOv7PsayGTilCswoGSPzK6HTw=
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=GeZVpIB/k9k+b/kYUX1uk9J3McFf3l/X5nbPYSYjidV4V3Hq7KrpdZu30rMrxDYd+k 29ZJDupMT02F4qB+g7OUKyl4KPjx/Rxe8vBpuzyDy70/oa3jhmGHhBTWGOxOktSv0//j O7zt+oVRMMNke2sxSPB059V0fWf5/sFccFKJo=
Received: by 10.141.106.12 with SMTP id i12mr2700738rvm.270.1240278711974; Mon, 20 Apr 2009 18:51:51 -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 g22sm16705334rvb.27.2009.04.20.18.51.49 (version=SSLv3 cipher=RC4-MD5); Mon, 20 Apr 2009 18:51:51 -0700 (PDT)
Message-ID: <49ED26BC.4020902@gmail.com>
Date: Tue, 21 Apr 2009 13:51:56 +1200
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: james woodyatt <jhw@apple.com>
CC: IPv6 Operations <v6ops@ops.ietf.org>, Fred Baker <fred@cisco.com>, Kurt Erik Lindqvist <kurtis@kurtis.pp.se>, Ron Bonica <rbonica@juniper.net>
Subject: Re: draft-ietf-v6ops-cpe-simple-security-04 WGLC
References: <32129337-7BED-4D7A-AF06-BC5ABB37D994@cisco.com> <49E7BEC5.5070300@gmail.com> <36FA1A22-914E-479E-BB4B-9FBAC63B89A6@apple.com>
In-Reply-To: <36FA1A22-914E-479E-BB4B-9FBAC63B89A6@apple.com>
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>
James, Eliding the points that seem to be resolved... On 2009-04-18 08:03, james woodyatt wrote: > On Apr 16, 2009, at 16:27, Brian E Carpenter wrote: ... >> "2.1. Basic Sanitation >> >> In addition to the functions required of all Internet routers >> [RFC4294], residential gateways are expected to have basic stateless >> filters for prohibiting certains kinds of traffic with invalid >> headers, e.g. martian packets, spoofs, routing header type code zero, >> etc." >> >> I think 'martian' needs a definition. > > Hmmm. That could be an interesting tangent. I thought I mostly covered > the bases of what constitutes the martian addresses in IPv6 in section > 3.1, but I suppose I could have added an explicit prohibition of packets > with V4MAPPED addresses. I didn't think that was necessary, and the > design team didn't consider it, but I wouldn't object to adding it if > there were calls for it here. A forward ref to section 3.1 would cover it just fine. > >> Also, should this section say something about ICMP in general? Still open. >> >> >> In section 2.2: ... >> Also, should this topic also cover 6to4? Hosts behind an IPv6 CPE >> SHOULD NOT use host 6to4 based on RFC3068. > > My assumption was that residential IPv6 CPE would normally prevent this > by using RFC 1918 addressing behind their IPv4 NAT. An explicit > deprecation would only seem necessary in the case of IPv4/NAT gateways > that translate between global addresses across the realm boundary. I > don't think those are very common, are they? Maybe it doesn't need to be formally deprecated - just point out that host 6to4 isn't expected to be relevant when there's an IPv6 CPE. >> However, I have to wonder why this whole topic (Teredo+6to4) is >> relevant to this document. Shouldn't it be in the CPE requirements >> document instead? Still open. >> >> "R2: Packets bearing in their outer IPv6 headers multicast destination >> addresses of equal or narrower scope that the configured scope >> boundary level of the gateway MUST NOT be forwarded in any direction. >> The DEFAULT scope boundary level SHOULD be organization-local scope." >> >> I can't find a definition of "organization-local scope" or even what >> is meant by "configured scope boundary level". Probably the document >> needs >> a short discussion of what it means by "scope". Still open. >> >> "3.3.2. SCTP Filters" >> >> Reading this section, I wondered whether there is anything to say >> about SHIM6? A TCP session over SHIM6 could simply appear, with >> no SYN/ACK, or disappear, as the shim switches addresses. Still open. >> >> "R31: Gateways MUST implement a protocol to permit applications to >> solicit inbound traffic without advance knowledge of the addresses of >> exterior nodes with which they expect to communicate. This protocol >> MUST have a specification that meets the requirements of [RFC5378], >> [RFC3979], [RFC4748] and [RFC4879]." > > I think I should relax both these MUST instances to SHOULD instances > here. The second sentence should probably have an 'if implemented' > conditional phrase after the subject. > >> It sounds good but it doesn't tell a CPE implementor what to code. > > We can't very well tell them to code UPnP IGD for IPv6 until the UPnP > Forum publishes a specification that meets our requirements. We can't > tell them to code ALD, because it's just a draft, and an expired one at > that. We might try to tell them to code MIDCOM, but I say good luck > with that. > > This recommendation is basically a stand-in for a more concrete > recommendation once some kind of de facto standard, if any, emerges. Right, which is why I wonder whether it is a recommendation at all. It seems more like a placeholder. >> I fear you will need to insert the pre-RFC5378 disclaimer. > > Why do you think this may be necessary? " Much of the text describing the detailed requirements for TCP and UDP filtering is derived or transposed from [RFC5382] and [RFC4787], and some form of attribution here may therefore be appopriate." Do you have permissions from those authors? If not, you need the disclaimer. Brian
- draft-ietf-v6ops-cpe-simple-security-04 WGLC Fred Baker
- RE: draft-ietf-v6ops-cpe-simple-security-04 WGLC Hemant Singh (shemant)
- Re: draft-ietf-v6ops-cpe-simple-security-04 WGLC james woodyatt
- Re: draft-ietf-v6ops-cpe-simple-security-04 WGLC Fred Baker
- Re: draft-ietf-v6ops-cpe-simple-security-04 WGLC Brian E Carpenter
- Re: draft-ietf-v6ops-cpe-simple-security-04 WGLC Fred Baker
- Re: draft-ietf-v6ops-cpe-simple-security-04 WGLC james woodyatt
- Re: draft-ietf-v6ops-cpe-simple-security-04 WGLC Brian E Carpenter
- RE: draft-ietf-v6ops-cpe-simple-security-04 WGLC teemu.savolainen
- RE: draft-ietf-v6ops-cpe-simple-security-04 WGLC Dan Wing
- Re: draft-ietf-v6ops-cpe-simple-security-04 WGLC Fred Baker
- Re: draft-ietf-v6ops-cpe-simple-security-04 WGLC james woodyatt
- RE: draft-ietf-v6ops-cpe-simple-security-04 WGLC Dan Wing
- RE: draft-ietf-v6ops-cpe-simple-security-04 WGLC teemu.savolainen
- Re: draft-ietf-v6ops-cpe-simple-security-04 WGLC Joel Jaeggli
- Re: draft-ietf-v6ops-cpe-simple-security-04 WGLC james woodyatt
- Re: draft-ietf-v6ops-cpe-simple-security-04 WGLC Fred Baker