Re: [MBONED] draft-ietf-v6ops-cpe-simple-security-12.txt feedback
Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org> Sun, 08 August 2010 10:00 UTC
Return-Path: <ipng@69706e6720323030352d30312d31340a.nosense.org>
X-Original-To: mboned@core3.amsl.com
Delivered-To: mboned@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05FD03A698A for <mboned@core3.amsl.com>; Sun, 8 Aug 2010 03:00:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327]
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 UrrQF0qCv0W4 for <mboned@core3.amsl.com>; Sun, 8 Aug 2010 03:00:37 -0700 (PDT)
Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by core3.amsl.com (Postfix) with ESMTP id C1B273A6868 for <mboned@ietf.org>; Sun, 8 Aug 2010 03:00:36 -0700 (PDT)
Received: from 219-90-255-65.ip.adam.com.au ([219.90.255.65] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from <ipng@69706e6720323030352d30312d31340a.nosense.org>) id 1Oi2gi-0003nO-8X; Sun, 08 Aug 2010 19:31:04 +0930
Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 54EF83B325; Sun, 8 Aug 2010 19:30:41 +0930 (CST)
Date: Sun, 08 Aug 2010 19:30:40 +0930
From: Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org>
To: Fred Baker <fred@cisco.com>
Message-ID: <20100808193040.1063ffb1@opy.nosense.org>
In-Reply-To: <F8471906-675A-478C-B86B-C6940A580E32@cisco.com>
References: <20100728072319.GU26000@cisco.com> <430696D0-EA0E-438A-B46F-D6DCD00652E0@apple.com> <20100728080009.GZ26000@cisco.com> <99D85A94-0DDF-4950-8151-035024CE8105@apple.com> <0D448E93-070E-478D-911F-60606DFE3441@cisco.com> <62860430-A9D7-46E2-8600-298810C18089@apple.com> <20100807101911.2dbbd430@opy.nosense.org> <F8471906-675A-478C-B86B-C6940A580E32@cisco.com>
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; x86_64-unknown-linux-gnu)
X-Location: Lower Mitcham, South Australia, 5062
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Mon, 09 Aug 2010 15:10:17 -0700
Cc: Operations <v6ops@ops.ietf.org>, mboned@ietf.org, james woodyatt <jhw@apple.com>, IPv6
Subject: Re: [MBONED] draft-ietf-v6ops-cpe-simple-security-12.txt feedback
X-BeenThere: mboned@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mail List for the Mboned Working Group <mboned.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mboned>, <mailto:mboned-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mboned>
List-Post: <mailto:mboned@ietf.org>
List-Help: <mailto:mboned-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mboned>, <mailto:mboned-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Aug 2010 10:00:38 -0000
Hi Fred, On Sat, 7 Aug 2010 06:06:20 +0200 Fred Baker <fred@cisco.com> wrote: > On Aug 6, 2010, at 10:20 PM, james woodyatt wrote: > > > I'm really not sure why people seem to think that subscribers ought to be lumped into the same organizational zone as their service provider. I must need to be educated about operational considerations again. > > On Aug 7, 2010, at 2:49 AM, Mark Smith wrote: > > > There's quite a lot of IPTV interest in the .au market at the moment, > > and one of the branded service wholesale IPTV providers to ISPs is > > using IPv4 multicast to deliver it. The provider is originating the > > multicast traffic outside the ISP networks, so in an IPv6 context I > > think the scope for that traffic would need to be global. > > OK, Mark, what are you arguing here? > > I *think* you are arguing that the router SHOULD be configurable by some means (manual? UPnP? what?) to accept a multicast from the ISP and repeat it on the (a?) local LAN, or more generally, that a CPE router SHOULD be configurable to forward an identified class of multicast traffic between subnets to which it is attached. Is that correct? If so, I'll suggest we think about that recommendation for the CPE Router discussion that we just initiated. > Yes. I would assume that the multicast functionality would be achieved by having the CPE act as an MLD proxy. > With respect to security, which is the subject of this draft, how would you recommend identifying the class of traffic? Are you suggesting that a simple home firewall should prevent the home from being ddos'd using unicast but should be default be ddos-able using multicast? No. Firstly I think the upstream network's multicast forwarding capability provides a level of protection. If the upstream ISP network doesn't support multicast forwarding, then the CPE would only receive multicast traffic on it's WAN interface from on-link peers. If the CPE is acting as an MLD proxy, then that multicast traffic would only be forwarded onto the LAN ports if there were subscriptions for groups towards which this malicious multicast traffic were being sent to. So current threat from malicious multicast traffic is quite low level. Even if the upstream ISPs network is multicast enabled, the Internet isn't, so the threat isn't a global one. Secondly, when the ISPs network is configured to multicast route, for multicast traffic inbound towards the home LAN, it would seem to me that MLD / MLD proxy would in effect serve as a "multicast firewall configuration" protocol. Traffic for groups that are subscribed to, regardless of their scope, could be permitted to be forwarded by the CPE from the WAN to appropriate LAN interfaces. Any other inbound multicast traffic not be forwarded. I can't really think of a use for outbound multicast i.e. the unique multicast source is attached to the home LAN. However, with IPv6 restoring or attempting to restore the peer-to-peer communications nature of the Internet, the are probably some use cases. They're probably worth trying to avoid constraining if doing so doesn't reduce security unacceptably. In the context of this draft, I think CPE multicast security is possibly is not simple enough to just use multicast address scopes as security discriminators in determining if the traffic should be forwarded or not. It might be better to say in this draft something like, "all multicast traffic is not to be forwarded by the CPE, unless appropriate multicast traffic security mechanisms have been implemented. Such multicast security mechanisms are out of scope for this memo." (or addressed in a multicast security RFC that I'm not aware of.) Regards, Mark.
- [MBONED] draft-ietf-v6ops-cpe-simple-security-12.… Toerless Eckert
- Re: [MBONED] draft-ietf-v6ops-cpe-simple-security… Toerless Eckert
- Re: [MBONED] draft-ietf-v6ops-cpe-simple-security… Toerless Eckert
- Re: [MBONED] draft-ietf-v6ops-cpe-simple-security… Tim Chown
- Re: [MBONED] draft-ietf-v6ops-cpe-simple-security… Fred Baker
- Re: [MBONED] draft-ietf-v6ops-cpe-simple-security… Fred Baker
- Re: [MBONED] draft-ietf-v6ops-cpe-simple-security… Fred Baker
- Re: [MBONED] draft-ietf-v6ops-cpe-simple-security… Fred Baker
- Re: [MBONED] draft-ietf-v6ops-cpe-simple-security… Fred Baker
- Re: [MBONED] draft-ietf-v6ops-cpe-simple-security… Fred Baker
- Re: [MBONED] draft-ietf-v6ops-cpe-simple-security… Mark Smith
- Re: [MBONED] draft-ietf-v6ops-cpe-simple-security… james woodyatt
- Re: [MBONED] draft-ietf-v6ops-cpe-simple-security… james woodyatt
- Re: [MBONED] draft-ietf-v6ops-cpe-simple-security… james woodyatt
- Re: [MBONED] draft-ietf-v6ops-cpe-simple-security… james woodyatt
- Re: [MBONED] draft-ietf-v6ops-cpe-simple-security… Mark Smith
- Re: [MBONED] draft-ietf-v6ops-cpe-simple-security… Mark Smith