Re: Re: [ssm] another last call for draft-ietf-ssm-arch - ending 3/24
Hugh Holbrook <holbrook@cisco.com> Thu, 06 March 2003 17:41 UTC
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02236 for <ssm-archive@odin.ietf.org>; Thu, 6 Mar 2003 12:41:50 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26Hqvb29165 for ssm-archive@odin.ietf.org; Thu, 6 Mar 2003 12:52:57 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26HqvO29162 for <ssm-web-archive@optimus.ietf.org>; Thu, 6 Mar 2003 12:52:57 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02194 for <ssm-web-archive@ietf.org>; Thu, 6 Mar 2003 12:41:18 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26HqJO29125; Thu, 6 Mar 2003 12:52:19 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26HpuO29103 for <ssm@optimus.ietf.org>; Thu, 6 Mar 2003 12:51:56 -0500
Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02156 for <ssm@ietf.org>; Thu, 6 Mar 2003 12:40:17 -0500 (EST)
Received: from holbrook-laptop.cisco.com (dhcp-171-69-119-37.cisco.com [171.69.119.37]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h26HgKv2014797; Thu, 6 Mar 2003 09:42:20 -0800 (PST)
Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id BE63210B7A7; Thu, 6 Mar 2003 09:38:11 -0800 (PST)
From: Hugh Holbrook <holbrook@cisco.com>
To: Pekka Savola <pekkas@netcore.fi>
Cc: Hugh Holbrook <holbrook@cisco.com>, ssm@ietf.org
In-reply-to: <Pine.LNX.4.44.0303061227210.15024-100000@netcore.fi>
Subject: Re: Re: [ssm] another last call for draft-ietf-ssm-arch - ending 3/24
Reply-To: holbrook@cisco.com
Message-Id: <20030306173811.BE63210B7A7@holbrook-laptop.cisco.com>
Date: Thu, 06 Mar 2003 09:38:11 -0800
Sender: ssm-admin@ietf.org
Errors-To: ssm-admin@ietf.org
X-BeenThere: ssm@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ssm>, <mailto:ssm-request@ietf.org?subject=unsubscribe>
List-Id: Source-Specific Multicast <ssm.ietf.org>
List-Post: <mailto:ssm@ietf.org>
List-Help: <mailto:ssm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ssm>, <mailto:ssm-request@ietf.org?subject=subscribe>
Thanks for your comments, Pekka. My responses inline. > Date: Thu, 6 Mar 2003 12:31:55 +0200 (EET) > From: Pekka Savola <pekkas@netcore.fi> > Cc: ssm@ietf.org > > On Sun, 2 Mar 2003, Hugh Holbrook wrote: > > I've just submitted draft-ietf-ssm-arch-02.txt to the internet draft > > repository. Until it shows up, you can retrieve it from > > > > http://sith.maoz.com/SSM/draft-ietf-ssm-arch-02.txt > > > > There were enough changes to the draft that I'd like to do one more > > working group last call. I've included below the list of changes from > > my last mail. The only other change was that I changed a SHOULD (for > > ignoring non-source-specific requests) in section 8 to a MUST, to be > > consistent with Section 5.2. > > > > I would particularly appreciate any comments on the Security > > Considerations section, as this has seen the least review. > > I've reviewed the draft. It looks mainly good, but unless I > misunderstand, there are still a few issues. > > One particularly big issue is how to deal with IPv6's non-globally scoped > addresses (sigh!). You asked for sec cons review, so here's some.. :-) > > substantial > ----------- > > Security Considerations > > ==> should one mention again the fact that IPv4 admin scoping is to be done > differently for SSM if it is requested? Sure, we could more or less repeat the text from 4.3 again in the Security Considerations, although part of why I didn't mention it there is that the Security Considerations section of RFC 2365 (The admin-scoping RFC) is very clear that they administrative scoping should not be used as a security measure. (Although I think in practice people use it that way often enough.) So I'm having a hard time figuring out what the message should be on this point. Perhaps something to the effect of: Admin-Scoping is not a security measure, but in case you are using it as one anyway, remember that SSM doesn't have an admin-scoped range. (obviously not this exact text.) If you have some specific ideas for text, that would help. > ==> (also a part of the main doc, but..) one thing I'd maybe like to see is > how SSM is treated with non-global IPv6 addresses. Perhaps it has to say > something like that the scoping must also be done based on the rules for > unicast addresses of S. In particular, (S,G) = (fe80::1%eth0, ff3e::1) is > clearly invalid outside of the link-local zone where it originated. So, today the document says this "Normal IPv6 multicast scope boundaries are applied to traffic sent to an SSM destination address." I thought this was sufficient -- as I understand it, a router isn't allowed to forward an SSM packet across a scope boundary of either the source or the destination address. I think this is exactly how scoped unicast works (and how ASM works), so do we really need any special rules for SSM? > Another > potential issue is whether the unicast scope must at least equal that of the > multicast address. There are also some other unicast scoping issues to > consider, but they might make the those are rather complex and maybe not > worth the effort. I thought about this and looked at the IPv6 default address selection document (draft-ietf-ipv6-default-addr-select-09.txt) for guidance when I last revved the document. My rationale for *not* saying that the unicast scope must be as large as the multicast scope is that this restriction does not appear to be required (as far as I can tell) for IPv6 unicast or IPv6 ASM, and I didn't see a reason for SSM to be special in this regard. On a host with multiple addresses, I suppose we could say that the source address selection rules of draft-ietf-ipv6-default-addr-select-09 probably SHOULD be followed when picking the SSM source, but again, I don't really think this is an SSM-specific issue. But I'm open to ideas. > ... > > Addresses in the range 232.0.0.1 through 232.0.0.255 and IPv6 addresses > with prefix FF3x:: are reserved for services with wide applicability > > ==> the prefix length is FF3x::/32, I think, must state here! > > Addresses in the > range FF3x::0000:0000 through FF3x::3FFF:FFFF are invalid IPv6 SSM > addresses, per [IPV6-UBM]. The treatment of a packet sent to such an > invalid address is undefined -- a router or host MAY choose to drop such > a packet. > > ==> the above seem to be clearly wrong -- I see *nothing* in IPV6-UBM that > says so!? Ok, so you're right about this not being stated in IPv6-UBM. It is actually the combination of [IPV6-UBM] and [IPV6-MALLOC] that together imply that these are invalid SSM addresses. The problem is that IPV6-MALLOC says that the 0x00000001 to 0x3fffffff must have P=0 and T=0, but IPv6-UBM says that all SSM addresses must set P=1 and T=1. This is the rationale for calling these invalid addresses. So perhaps this needs to be clarified in the document, then. > An incoming datagram destined to an SSM address MUST be delivered by the > IP module to all sockets that have indicated (via Subscribe) a desire to > receive data that matches the datagram's source address, destination > address, and arriving interface. It MUST NOT be delivered to other > sockets. > > ==> is arriving interface checked for ASM? I'm not sure -- if not, I don't > see why it should be done for SSM. I think it is -- it's part of the service interface specified in IGMPv3: Here's a quote from RFC3376, section 2, under the "interface" bullet. ... a system's IP service interface must support the following operation: IPMulticastListen ( socket, interface, multicast-address, filter-mode, source-list ) where: ... o "interface" is a local identifier of the network interface on which reception of the specified multicast address is to be enabled or... If reception of the same multicast address is desired on more than one interface, IPMulticastListen is invoked separately for each desired interface. I think it's pretty clear from the last sentence that reception is specific to the interface on which it is requested. A scenario where this might matter is the one in which a host has two interfaces pointing into two private networks, both using site-local addresses with potentially overlapping SSM channels. > editorial: > ---------- I will look at the editorial comments and respond in a separate email. They all look helpful. Thanks again, Pekka. -Hugh > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [RFC 2119]. > > ==> I believe this should be at the end of Introduction, but not sure..? > > designated as source-specific multicast (SSM) destination addresses and > are reserved for use by source-specific applications and protocols. For > IP version 6 (IPv6), the address prefix FF3x::/32 is reserved for > Source-Specific Multicast use. It defines an extension to the Internet > > ==> source-specific multicast vs Source-Specific Multicast -- pick one for > consistancy > > Using the terminology of [IPv6-UBM], this means that P=1, T=1, and > plen=0 for any SSM address. > > ==> "means that x=y for any address", is ok but could be a bit better, > maybe: > > Using the terminology of [IPv6-UBM], all SSM addresses must have P=1, T=1, and > plen=0. > > within the FF3x::/96 range, but a system should treat all of FF3x::/32 > as an SSM address, to allow for compatibility with possible future uses > > ==> s/an SSM address/SSM addresses/ > > referred to as a "channel." In contrast to the ASM model of RFC 1112, > > ==> s/."/"./ ? > > Identifier: G S,G > Receiver Operations: join, leave subscribe, unsubscribe > > ==> s/subscribe/Subscribe/, s/unsubscribe/Unsubscribe/ > > host IP module sends an unsubscription request for that channel out > interface I. > > ==> s/interface/the interface/, or "on interface". > > address range for IPv4). For IPv6, the randomization should apply to > the lower 32 bits of the address. > > ==> s/lower/lowest/ ? > > subscriber would be delivered to another's IP module, which would then > have to reject the datagram. > > ==> perhaps s/reject/discard/ would be slightly better? > > specify the required modifications to those protocols to support SSM. > > ==> s/required /required / (extra space) > > 7. Security Considerations > > ==> add a 1-2 line summary of the subsections here. > > To reduce the damage from such an attack, a router MAY have > configuration options to limit the following items: > > ==> s/limit/limit, for example,/ ? the list is not meant to be exclusive, > and it's a MAY after all.. > > risks unduly burdening the network infrastructure by deliver (S,G) > > ==> s/deliver/delivering/ > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > _______________________________________________ > ssm mailing list > ssm@ietf.org > https://www1.ietf.org/mailman/listinfo/ssm _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm
- [ssm] another last call for draft-ietf-ssm-arch -… Hugh Holbrook
- Re: [ssm] another last call for draft-ietf-ssm-ar… Pekka Savola
- Re: Re: [ssm] another last call for draft-ietf-ss… Hugh Holbrook
- Re: Re: [ssm] another last call for draft-ietf-ss… Pekka Savola
- Re: [ssm] another last call for draft-ietf-ssm-ar… Brian Haberman
- Re: [ssm] another last call for draft-ietf-ssm-ar… Pekka Savola
- Re: [ssm] another last call for draft-ietf-ssm-ar… Brian Haberman
- Re: [ssm] another last call for draft-ietf-ssm-ar… Pekka Savola
- Re: [ssm] another last call for draft-ietf-ssm-ar… Brian Haberman
- Re: Re: Re: [ssm] another last call for draft-iet… Hugh Holbrook
- [ssm] what to say about scoping for v6 [was ...la… Hugh Holbrook
- [ssm] permanent ipv6 ssm addresses [was ...last c… Hugh Holbrook
- Re: [ssm] permanent ipv6 ssm addresses [was ...la… Brian Haberman
- Re: [ssm] another last call for draft-ietf-ssm-ar… Brian Haberman
- Re: [ssm] what to say about scoping for v6 [was .… Brian Haberman
- Re: Re: [ssm] permanent ipv6 ssm addresses [was .… Hugh Holbrook
- Re: [ssm] what to say about scoping for v6 [was .… Pekka Savola
- Re: Re: [ssm] what to say about scoping for v6 [w… Hugh Holbrook
- Re: [ssm] what to say about scoping for v6 [was .… Brian Haberman
- Re: Re: [ssm] what to say about scoping for v6 [w… Pekka Savola
- Re: [ssm] what to say about scoping for v6 Hitoshi Asaeda
- Re: Re: Re: [ssm] what to say about scoping for v… Hugh Holbrook
- Re: [ssm] what to say about scoping for v6 Pekka Savola
- Re: [ssm] what to say about scoping for v6 [was .… Brian Haberman
- Re: [ssm] what to say about scoping for v6 [was .… Pekka Savola
- Re: Re: [ssm] what to say about scoping for v6 [w… Hugh Holbrook
- Re: Re: [ssm] what to say about scoping for v6 [w… Pekka Savola
- Re: Re: [ssm] another last call for draft-ietf-ss… Hugh Holbrook