From mailman-admin@ietf.org Sat Mar 1 13:07:37 2003 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 NAA13671 for ; Sat, 1 Mar 2003 13:07:37 -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 h21IGhp11889 for ; Sat, 1 Mar 2003 13:16:43 -0500 Date: Sat, 01 Mar 2003 13:16:43 -0500 Message-ID: <20030301181643.26394.85491.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: ssm-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, ssm-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for ssm-archive@lists.ietf.org: List Password // URL ---- -------- ssm@ietf.org mifemu https://www1.ietf.org/mailman/options/ssm/ssm-archive%40lists.ietf.org From ssm-admin@ietf.org Sun Mar 2 05:14:01 2003 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 FAA09229 for ; Sun, 2 Mar 2003 05:14:01 -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 h22AN7p27445; Sun, 2 Mar 2003 05:23:07 -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 h22AFYp27269 for ; Sun, 2 Mar 2003 05:15:34 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09175 for ; Sun, 2 Mar 2003 05:05:36 -0500 (EST) Received: from holbrook-laptop.cisco.com (sjc-vpn3-258.cisco.com [10.21.65.2]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h22A7KP7007149 for ; Sun, 2 Mar 2003 02:07:20 -0800 (PST) Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id 4979A10B7A7; Sun, 2 Mar 2003 02:03:37 -0800 (PST) From: Hugh Holbrook To: ssm@ietf.org Reply-To: holbrook@cisco.com Message-Id: <20030302100337.4979A10B7A7@holbrook-laptop.cisco.com> Date: Sun, 2 Mar 2003 02:03:37 -0800 (PST) Subject: [ssm] another last call for draft-ietf-ssm-arch - ending 3/24 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: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , Hi, folks. 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. This last call expires March 24th. -Hugh -------------------------------- - [pavlin] Added text: OS API should return an error for a (*,G) request on an SSM address. - [pavlin] Added a note about limitations of SSM. (1) Any multi-source aspect apps must be implemented in the application layer. (2) SSM does not support network-layer resource discovery. - [pekka/brian] Added clarification about the SSM address range FF3x::/32 is reserved for SSM P=1 and T=1 and plen=0 is required. Thus, FF3x::/96 is the actual range today because network prefix field must be zero But we leave open the possibility of putting something else in the network prefix field. - [pavlin] Changed erroneous FF2x:: to FF3x:: - [pekka] New text on administrative scoping to describe admin-scoping in v6 and to clarify that there is none for IPv4. - [pekka] New text on source routing: A router SHOULD NOT allow source-routing to an SSM addr; MAY have a config option to allow it - [me/bweis/mbaugher] Add security considerations text describing the IPSec/SSM issue. - Minor things: - [pavlin] Use consistent capitalization on v6 addresses - [me] Use consistent capitalization of Source-Specific - [pavlin] id-nits - Removed references from abstract and shortened it - Modified address ranges - Added IPR notice and Copyright Statement. - [brad] Changed author mailing address _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Sun Mar 2 05:17:44 2003 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 FAA09262 for ; Sun, 2 Mar 2003 05:17:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h22ARAB27589 for ssm-archive@odin.ietf.org; Sun, 2 Mar 2003 05:27:10 -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 h22AR9p27586 for ; Sun, 2 Mar 2003 05:27:09 -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 FAA09255 for ; Sun, 2 Mar 2003 05:17:12 -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 h22AN7p27445; Sun, 2 Mar 2003 05:23:07 -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 h22AFYp27269 for ; Sun, 2 Mar 2003 05:15:34 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09175 for ; Sun, 2 Mar 2003 05:05:36 -0500 (EST) Received: from holbrook-laptop.cisco.com (sjc-vpn3-258.cisco.com [10.21.65.2]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h22A7KP7007149 for ; Sun, 2 Mar 2003 02:07:20 -0800 (PST) Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id 4979A10B7A7; Sun, 2 Mar 2003 02:03:37 -0800 (PST) From: Hugh Holbrook To: ssm@ietf.org Reply-To: holbrook@cisco.com Message-Id: <20030302100337.4979A10B7A7@holbrook-laptop.cisco.com> Date: Sun, 2 Mar 2003 02:03:37 -0800 (PST) Subject: [ssm] another last call for draft-ietf-ssm-arch - ending 3/24 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: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , Hi, folks. 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. This last call expires March 24th. -Hugh -------------------------------- - [pavlin] Added text: OS API should return an error for a (*,G) request on an SSM address. - [pavlin] Added a note about limitations of SSM. (1) Any multi-source aspect apps must be implemented in the application layer. (2) SSM does not support network-layer resource discovery. - [pekka/brian] Added clarification about the SSM address range FF3x::/32 is reserved for SSM P=1 and T=1 and plen=0 is required. Thus, FF3x::/96 is the actual range today because network prefix field must be zero But we leave open the possibility of putting something else in the network prefix field. - [pavlin] Changed erroneous FF2x:: to FF3x:: - [pekka] New text on administrative scoping to describe admin-scoping in v6 and to clarify that there is none for IPv4. - [pekka] New text on source routing: A router SHOULD NOT allow source-routing to an SSM addr; MAY have a config option to allow it - [me/bweis/mbaugher] Add security considerations text describing the IPSec/SSM issue. - Minor things: - [pavlin] Use consistent capitalization on v6 addresses - [me] Use consistent capitalization of Source-Specific - [pavlin] id-nits - Removed references from abstract and shortened it - Modified address ranges - Added IPR notice and Copyright Statement. - [brad] Changed author mailing address _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-admin@ietf.org Sun Mar 2 05:19:03 2003 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 FAA09292 for ; Sun, 2 Mar 2003 05:19:03 -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 h22ASDp27626; Sun, 2 Mar 2003 05:28:13 -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 h22ALup27405 for ; Sun, 2 Mar 2003 05:21:57 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09202 for ; Sun, 2 Mar 2003 05:12:00 -0500 (EST) Received: from holbrook-laptop.cisco.com (sjc-vpn3-258.cisco.com [10.21.65.2]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h22ADx56020396 for ; Sun, 2 Mar 2003 02:13:59 -0800 (PST) Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id 1B39310B7A7; Sun, 2 Mar 2003 02:10:02 -0800 (PST) From: Hugh Holbrook To: ssm@ietf.org Reply-To: holbrook@cisco.com Message-Id: <20030302101002.1B39310B7A7@holbrook-laptop.cisco.com> Date: Sun, 2 Mar 2003 02:10:02 -0800 (PST) Subject: [ssm] draft-holbrook-idmr-igmpv3-04.txt is available 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: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , I just submitted a new revision of the SSM-with-IGMPv3/MLDv2 document to the ID archives. Until it shows up, you can retrieve it at http://sith.maoz.com/SSM/draft-holbrook-idmr-igmpv3-04.txt This is a magma working group document. It's feeling pretty final to me, and I expect this document to be going through a working group last call shortly. Comments appreciated. Cheers, -Hugh -------------------------------- The major changes in the -04 version: Updated to reflect ID-nits. Rewrote Abstract, added Security Considerations, IPR, and Copyright statements. Clarified the notion of an "SSM-aware" host as being a host with an address range configuration option. Clarified that CHANGE_TO_INCLUDE_MODE may be sent when the address range configuration changes. Eliminated the mention of the option to ignore older version queriers -- this conflicts the IGMPv3 spec and creates a bunch of bad scenarios for ASM. Updated and split references to normative/informative. _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Sun Mar 2 05:22:47 2003 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 FAA09363 for ; Sun, 2 Mar 2003 05:22:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h22AWCJ27810 for ssm-archive@odin.ietf.org; Sun, 2 Mar 2003 05:32:12 -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 h22AWCp27807 for ; Sun, 2 Mar 2003 05:32:12 -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 FAA09352 for ; Sun, 2 Mar 2003 05:22:15 -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 h22ASDp27626; Sun, 2 Mar 2003 05:28:13 -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 h22ALup27405 for ; Sun, 2 Mar 2003 05:21:57 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09202 for ; Sun, 2 Mar 2003 05:12:00 -0500 (EST) Received: from holbrook-laptop.cisco.com (sjc-vpn3-258.cisco.com [10.21.65.2]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h22ADx56020396 for ; Sun, 2 Mar 2003 02:13:59 -0800 (PST) Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id 1B39310B7A7; Sun, 2 Mar 2003 02:10:02 -0800 (PST) From: Hugh Holbrook To: ssm@ietf.org Reply-To: holbrook@cisco.com Message-Id: <20030302101002.1B39310B7A7@holbrook-laptop.cisco.com> Date: Sun, 2 Mar 2003 02:10:02 -0800 (PST) Subject: [ssm] draft-holbrook-idmr-igmpv3-04.txt is available 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: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , I just submitted a new revision of the SSM-with-IGMPv3/MLDv2 document to the ID archives. Until it shows up, you can retrieve it at http://sith.maoz.com/SSM/draft-holbrook-idmr-igmpv3-04.txt This is a magma working group document. It's feeling pretty final to me, and I expect this document to be going through a working group last call shortly. Comments appreciated. Cheers, -Hugh -------------------------------- The major changes in the -04 version: Updated to reflect ID-nits. Rewrote Abstract, added Security Considerations, IPR, and Copyright statements. Clarified the notion of an "SSM-aware" host as being a host with an address range configuration option. Clarified that CHANGE_TO_INCLUDE_MODE may be sent when the address range configuration changes. Eliminated the mention of the option to ignore older version queriers -- this conflicts the IGMPv3 spec and creates a bunch of bad scenarios for ASM. Updated and split references to normative/informative. _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Thu Mar 6 05:33:16 2003 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 FAA01080 for ; Thu, 6 Mar 2003 05:33:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26AiEt22896 for ssm-archive@odin.ietf.org; Thu, 6 Mar 2003 05:44:14 -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 h26AiDO22893 for ; Thu, 6 Mar 2003 05:44:13 -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 FAA01058 for ; Thu, 6 Mar 2003 05:32:44 -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 h26AhfO22861; Thu, 6 Mar 2003 05:43:41 -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 h26AgmO22828 for ; Thu, 6 Mar 2003 05:42:48 -0500 Received: from netcore.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01032 for ; Thu, 6 Mar 2003 05:31:18 -0500 (EST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h26AVte15228; Thu, 6 Mar 2003 12:31:55 +0200 Date: Thu, 6 Mar 2003 12:31:55 +0200 (EET) From: Pekka Savola To: Hugh Holbrook cc: ssm@ietf.org Subject: Re: [ssm] another last call for draft-ietf-ssm-arch - ending 3/24 In-Reply-To: <20030302100337.4979A10B7A7@holbrook-laptop.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , 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? ==> (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. 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. ... 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!? 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. editorial: ---------- 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 From mailnull@www1.ietf.org Thu Mar 6 06:49:37 2003 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 GAA05650 for ; Thu, 6 Mar 2003 06:49:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26C0bv28384 for ssm-archive@odin.ietf.org; Thu, 6 Mar 2003 07:00:37 -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 h26C0bO28381 for ; Thu, 6 Mar 2003 07:00:37 -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 GAA05620 for ; Thu, 6 Mar 2003 06:49:06 -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 h26C03O28194; Thu, 6 Mar 2003 07:00:03 -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 h26BegO26662 for ; Thu, 6 Mar 2003 06:40:42 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03460; Thu, 6 Mar 2003 06:29:12 -0500 (EST) Message-Id: <200303061129.GAA03460@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ssm@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 06 Mar 2003 06:29:12 -0500 Subject: [ssm] I-D ACTION:draft-ietf-ssm-arch-02.txt 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: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source-Specific Multicast Working Group of the IETF. Title : Source-Specific Multicast for IP Author(s) : H. Holbrook, B. Cain Filename : draft-ietf-ssm-arch-02.txt Pages : 16 Date : 2003-3-5 IP addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are 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 network service that applies to datagrams sent to SSM addresses and defines the host and router requirements to support this extension. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ssm-arch-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ssm-arch-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ssm-arch-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-5141251.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ssm-arch-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ssm-arch-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-5141251.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Thu Mar 6 12:41:50 2003 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 ; 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 ; 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 ; 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 ; 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 ; 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 To: Pekka Savola Cc: Hugh Holbrook , ssm@ietf.org In-reply-to: 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, 6 Mar 2003 09:38:11 -0800 (PST) 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: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , Thanks for your comments, Pekka. My responses inline. > Date: Thu, 6 Mar 2003 12:31:55 +0200 (EET) > From: Pekka Savola > 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 From mailnull@www1.ietf.org Fri Mar 7 03:16:47 2003 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 DAA14209 for ; Fri, 7 Mar 2003 03:16:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h278SCS28319 for ssm-archive@odin.ietf.org; Fri, 7 Mar 2003 03:28:12 -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 h278SCO28316 for ; Fri, 7 Mar 2003 03:28:12 -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 DAA14196 for ; Fri, 7 Mar 2003 03:16:16 -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 h278RnO28288; Fri, 7 Mar 2003 03:27:49 -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 h278Q7O28210 for ; Fri, 7 Mar 2003 03:26:07 -0500 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14161 for ; Fri, 7 Mar 2003 03:14:11 -0500 (EST) Received: from flame.cs.columbia.edu (flame.cs.columbia.edu [128.59.16.145]) by cs.columbia.edu (8.12.8/8.12.6) with ESMTP id h278GGSx022890 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Fri, 7 Mar 2003 03:16:16 -0500 (EST) Received: from dynasty.cs.columbia.edu (dynasty.cs.columbia.edu [128.59.16.5]) by flame.cs.columbia.edu (8.12.8/8.12.6) with ESMTP id h278GGbD013973 for ; Fri, 7 Mar 2003 03:16:16 -0500 (EST) Date: Fri, 7 Mar 2003 03:16:16 -0500 (EST) From: Paulo Mendes To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [ssm] (no subject) 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: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , unsubscribe ssm mendes@cs.columbia.edu _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Sat Mar 8 09:34:13 2003 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 JAA23726 for ; Sat, 8 Mar 2003 09:34:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h28EkEj06997 for ssm-archive@odin.ietf.org; Sat, 8 Mar 2003 09:46:14 -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 h28EkEO06994 for ; Sat, 8 Mar 2003 09:46:14 -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 JAA23598 for ; Sat, 8 Mar 2003 09:33:40 -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 h28EjmO06963; Sat, 8 Mar 2003 09:45:48 -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 h28EgqO06641 for ; Sat, 8 Mar 2003 09:42:52 -0500 Received: from netcore.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22966 for ; Sat, 8 Mar 2003 09:30:18 -0500 (EST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h28EWDa03576; Sat, 8 Mar 2003 16:32:13 +0200 Date: Sat, 8 Mar 2003 16:32:13 +0200 (EET) From: Pekka Savola To: Hugh Holbrook cc: ssm@ietf.org, Subject: Re: Re: [ssm] another last call for draft-ietf-ssm-arch - ending 3/24 In-Reply-To: <20030306173811.BE63210B7A7@holbrook-laptop.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , Hi, sorry for delay, (Brian: sorry for the intrusion, note an issue about IPv6 Scoped Address Architecture below.) On Thu, 6 Mar 2003, Hugh Holbrook wrote: > > ==> 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. Yeah, it is used too much as a rough security mechanism, so I think some text is would be good. What you say above looks quite good, perhaps like: Administrative scoping should not relied upon as a security measure [ADMIN-SCOPE]; however, in many cases it is at least a part of security solutions. It should be noted that no administrative scoping exists for IPv4 source-specific multicast. An alternative approach is to configure manual access-lists to create such scoping if necessary. > > ==> (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? Perhaps Brian Haberman, as a co-author of scoped address architecture, can comment on this. You're right that this is not really SSM-specific except in one fashion: sources indicate interest in (S,G) channels, not just G. So, what if on a web page someone publishes a channel with (fe80::1, ff3e::1) -- or the same for site-local addresses? This is one area which does seem SSM-specific. > > 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. The problem as above seems to be that the source address for a channel needs to be published in some fashion. Publication of non-unique (S,G) may be a problem. Of course, one could argue that this is not so much different from publisting an admin-scoped ASM G.. I'm not sure what to think of this issue -- so other comments would be useful. > > 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. It seems to me that this would imply that no such reserved range exists for SSM? This seems like an issue that we must be very careful of, so that no one could say this document is trying to usurp either Proposed Standard. Brian as an author for both can probably clarify at least on the intent. > > 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. Agree, no changes etc. needed. HTH, thanks. -- 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 From mailnull@www1.ietf.org Sat Mar 8 15:39:57 2003 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 PAA03834 for ; Sat, 8 Mar 2003 15:39:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h28Kq6A02939 for ssm-archive@odin.ietf.org; Sat, 8 Mar 2003 15:52:06 -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 h28Kq6O02936 for ; Sat, 8 Mar 2003 15:52:06 -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 PAA03729 for ; Sat, 8 Mar 2003 15:39:23 -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 h28KpUO02845; Sat, 8 Mar 2003 15:51:30 -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 h28KnAO02733 for ; Sat, 8 Mar 2003 15:49:10 -0500 Received: from ms-smtp-03.southeast.rr.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03191 for ; Sat, 8 Mar 2003 15:36:29 -0500 (EST) Received: from mail4.nc.rr.com (fe4 [24.93.67.51]) by ms-smtp-03.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h28KbTH4022835; Sat, 8 Mar 2003 15:37:29 -0500 (EST) Received: from nc.rr.com ([66.26.252.32]) by mail4.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Sat, 8 Mar 2003 15:39:58 -0500 Message-ID: <3E6A5445.1030500@nc.rr.com> Date: Sat, 08 Mar 2003 15:36:21 -0500 From: Brian Haberman Organization: Me? Organized?? User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: Hugh Holbrook , ssm@ietf.org Subject: Re: [ssm] another last call for draft-ietf-ssm-arch - ending 3/24 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pekka Savola wrote: >>>==> (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? > > > Perhaps Brian Haberman, as a co-author of scoped address architecture, can > comment on this. > > You're right that this is not really SSM-specific except in one fashion: > sources indicate interest in (S,G) channels, not just G. So, what if on a > web page someone publishes a channel with (fe80::1, ff3e::1) -- or the > same for site-local addresses? This is one area which does seem > SSM-specific. Actually it is not SSM specific. Someone could publish an FTP link on a webpage that specifies FE80::5 as the target. If you reach the webpage using a global address, there is nothing that can be done about it. Also consider that the rules in RFC 3306 state that the scope of the multicast address cannot exceed the scope of the unicast prefix from which it derives. Even though it is not specifically stated for SSM, it applies. So, an SSM channel cannot have a group address that exceeds the scope of the unicast address. > > >>>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. > > > The problem as above seems to be that the source address for a channel > needs to be published in some fashion. Publication of non-unique (S,G) > may be a problem. Of course, one could argue that this is not so much > different from publisting an admin-scoped ASM G.. > > I'm not sure what to think of this issue -- so other comments would be > useful. > As stated above RFC 3306 does have restrictions on what the scope of the group address can be. > >>>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. > > > It seems to me that this would imply that no such reserved range exists > for SSM? > > This seems like an issue that we must be very careful of, so that no one > could say this document is trying to usurp either Proposed Standard. > > Brian as an author for both can probably clarify at least on the intent. Not sure I quite understand the issue. The SSM range is to be allocated out of FF3x::/96, however 3306 reserves the entire /32 for use later on with bigger group ID values. Now, RFC 3307 reserves 0x00000001 to 0x3FFFFFFF for use with permanently allocated IPv6 multicast addresses. This is for consistency with permanent IPv4 multicast addresses. That means that T=0 in the flags field. I would expect that SSM applications would allocate group IDs out of the 0x80000000 to 0xFFFFFFFF range for SSM channels. Brian _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Sun Mar 9 15:56:22 2003 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 PAA04066 for ; Sun, 9 Mar 2003 15:56:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h29L90O05755 for ssm-archive@odin.ietf.org; Sun, 9 Mar 2003 16:09:00 -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 h29L90O05750 for ; Sun, 9 Mar 2003 16:09:00 -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 PAA03948 for ; Sun, 9 Mar 2003 15:55:48 -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 h29L8WO05728; Sun, 9 Mar 2003 16:08:32 -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 h29L6IO04910 for ; Sun, 9 Mar 2003 16:06:18 -0500 Received: from netcore.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03308 for ; Sun, 9 Mar 2003 15:53:07 -0500 (EST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h29KscT20692; Sun, 9 Mar 2003 22:54:38 +0200 Date: Sun, 9 Mar 2003 22:54:37 +0200 (EET) From: Pekka Savola To: Brian Haberman cc: Hugh Holbrook , Subject: Re: [ssm] another last call for draft-ietf-ssm-arch - ending 3/24 In-Reply-To: <3E6A5445.1030500@nc.rr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , On Sat, 8 Mar 2003, Brian Haberman wrote: > > Perhaps Brian Haberman, as a co-author of scoped address architecture, can > > comment on this. > > > > You're right that this is not really SSM-specific except in one fashion: > > sources indicate interest in (S,G) channels, not just G. So, what if on a > > web page someone publishes a channel with (fe80::1, ff3e::1) -- or the > > same for site-local addresses? This is one area which does seem > > SSM-specific. > > Actually it is not SSM specific. Someone could publish an FTP link > on a webpage that specifies FE80::5 as the target. If you reach the > webpage using a global address, there is nothing that can be done > about it. This is slightly different: the addrarch document is relatively clear on how the routers should handle such an address. Is the SSM document clear on how (fe80::1, ff3e::1) is handled? I'm not sure. > Also consider that the rules in RFC 3306 state that the scope of > the multicast address cannot exceed the scope of the unicast prefix > from which it derives. Even though it is not specifically stated > for SSM, it applies. So, an SSM channel cannot have a group address > that exceeds the scope of the unicast address. More specifically it states: The scope of the unicast-prefix based multicast address MUST NOT exceed the scope of the unicast prefix embedded in the multicast address. note: "embedded in the multicast address". But as you should note here, an address (particularly _SSM_, which is really not derived from the unicast prefix) does not. So, I think this is *not* clear. > > The problem as above seems to be that the source address for a channel > > needs to be published in some fashion. Publication of non-unique (S,G) > > may be a problem. Of course, one could argue that this is not so much > > different from publisting an admin-scoped ASM G.. > > > > I'm not sure what to think of this issue -- so other comments would be > > useful. > > > > As stated above RFC 3306 does have restrictions on what the scope > of the group address can be. As above, I'm not sure how this applies to RFC3306 addresses which do not depend on the prefix, ie. SSM. > > It seems to me that this would imply that no such reserved range exists > > for SSM? > > > > This seems like an issue that we must be very careful of, so that no one > > could say this document is trying to usurp either Proposed Standard. > > > > Brian as an author for both can probably clarify at least on the intent. > > Not sure I quite understand the issue. The SSM range is to be > allocated out of FF3x::/96, however 3306 reserves the entire /32 > for use later on with bigger group ID values. Yes. > Now, RFC 3307 reserves 0x00000001 to 0x3FFFFFFF for use with > permanently allocated IPv6 multicast addresses. This is for > consistency with permanent IPv4 multicast addresses. That > means that T=0 in the flags field. I would expect that SSM > applications would allocate group IDs out of the 0x80000000 to > 0xFFFFFFFF range for SSM channels. But RFC3306 addresses, including SSM, *MUST* have T=1, so one could argue that the reservation does not hold. IMO, reserving 0x8... to 0xf for apps would be a bad decision. SSM is _source_ specific. It makes very much sense for apps/users to use as simple addresses as possible, like FF3X::1, FF3X:::2, ..., *not* like FF3X::8000:0001, FF3X::8000:0002, etc. There doesn't seem to be need for this kind of address reservation is necessary for SSM; if, for some particular reason, reservation is necessary, it would seem to be better done at the end of the address space. -- 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 From mailnull@www1.ietf.org Sun Mar 9 20:34:13 2003 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 UAA23258 for ; Sun, 9 Mar 2003 20:34:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2A1kvq21497 for ssm-archive@odin.ietf.org; Sun, 9 Mar 2003 20:46: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 h2A1kvO21494 for ; Sun, 9 Mar 2003 20:46: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 UAA23166 for ; Sun, 9 Mar 2003 20:33:41 -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 h2A1kVO21478; Sun, 9 Mar 2003 20:46:31 -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 h2A1jZO21425 for ; Sun, 9 Mar 2003 20:45:35 -0500 Received: from ms-smtp-03.southeast.rr.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22942 for ; Sun, 9 Mar 2003 20:32:20 -0500 (EST) Received: from mail5.nc.rr.com (fe5 [24.93.67.52]) by ms-smtp-03.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h2A1XHH6009182; Sun, 9 Mar 2003 20:33:17 -0500 (EST) Received: from nc.rr.com ([66.26.252.32]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Sun, 9 Mar 2003 20:32:03 -0500 Message-ID: <3E6BEB1A.4060807@nc.rr.com> Date: Sun, 09 Mar 2003 20:32:10 -0500 From: Brian Haberman Organization: Me? Organized?? User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: Hugh Holbrook , ssm@ietf.org Subject: Re: [ssm] another last call for draft-ietf-ssm-arch - ending 3/24 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pekka Savola wrote: > On Sat, 8 Mar 2003, Brian Haberman wrote: > >>>Perhaps Brian Haberman, as a co-author of scoped address architecture, can >>>comment on this. >>> >>>You're right that this is not really SSM-specific except in one fashion: >>>sources indicate interest in (S,G) channels, not just G. So, what if on a >>>web page someone publishes a channel with (fe80::1, ff3e::1) -- or the >>>same for site-local addresses? This is one area which does seem >>>SSM-specific. >> >>Actually it is not SSM specific. Someone could publish an FTP link >>on a webpage that specifies FE80::5 as the target. If you reach the >>webpage using a global address, there is nothing that can be done >>about it. > > > This is slightly different: the addrarch document is relatively clear on > how the routers should handle such an address. > > Is the SSM document clear on how (fe80::1, ff3e::1) is handled? I'm not > sure. > See below. > >>Also consider that the rules in RFC 3306 state that the scope of >>the multicast address cannot exceed the scope of the unicast prefix >>from which it derives. Even though it is not specifically stated >>for SSM, it applies. So, an SSM channel cannot have a group address >>that exceeds the scope of the unicast address. > > > More specifically it states: > > The scope of the unicast-prefix based multicast address MUST NOT > exceed the scope of the unicast prefix embedded in the multicast > address. > > note: "embedded in the multicast address". But as you should note here, > an address (particularly _SSM_, which is really not derived from the > unicast prefix) does not. The intent was that the scope of the SSM group address would not exceed the scope of the SSM source address. The scoped addr arch forwarding rules *WILL* prevent a scoped address from leaking out of the administrative zone. The overall issue though is not SSM-specific. That is, the scoped addr arch is responsible for determining the forwarding issues around scoped addresses. I don't see a need for putting any type of scoped address issues in the SSM doc. > > So, I think this is *not* clear. > > >>>The problem as above seems to be that the source address for a channel >>>needs to be published in some fashion. Publication of non-unique (S,G) >>>may be a problem. Of course, one could argue that this is not so much >>>different from publisting an admin-scoped ASM G.. >>> >>>I'm not sure what to think of this issue -- so other comments would be >>>useful. >>> As stated above, I don't see a reason to deal with scoped addresses in the SSM arch doc. >> >>As stated above RFC 3306 does have restrictions on what the scope >>of the group address can be. > > > As above, I'm not sure how this applies to RFC3306 addresses which do not > depend on the prefix, ie. SSM. > I consider the source address of an SSM group to be equivalent to the unicast prefix used in an RFC 3306 generated address. > >>>It seems to me that this would imply that no such reserved range exists >>>for SSM? >>> >>>This seems like an issue that we must be very careful of, so that no one >>>could say this document is trying to usurp either Proposed Standard. >>> >>>Brian as an author for both can probably clarify at least on the intent. >> >>Not sure I quite understand the issue. The SSM range is to be >>allocated out of FF3x::/96, however 3306 reserves the entire /32 >>for use later on with bigger group ID values. > > > Yes. > > >>Now, RFC 3307 reserves 0x00000001 to 0x3FFFFFFF for use with >>permanently allocated IPv6 multicast addresses. This is for >>consistency with permanent IPv4 multicast addresses. That >>means that T=0 in the flags field. I would expect that SSM >>applications would allocate group IDs out of the 0x80000000 to >>0xFFFFFFFF range for SSM channels. > > > But RFC3306 addresses, including SSM, *MUST* have T=1, so one could argue > that the reservation does not hold. Not sure what you mean here. 3307 is very explicit in what IANA is reserving for group IDs. > > IMO, reserving 0x8... to 0xf for apps would be a bad decision. SSM is > _source_ specific. It makes very much sense for apps/users to use as > simple addresses as possible, like FF3X::1, FF3X:::2, ..., *not* like > FF3X::8000:0001, FF3X::8000:0002, etc. But there is a bigger issue. One of the goals of 3307 is to help prevent collisions at the layer-2 mapping of group addresses. By having separate 32-bit ranges for the group IDs, it is possible to minimize the number of collisions that occur at the MAC layer. > > There doesn't seem to be need for this kind of address reservation is > necessary for SSM; if, for some particular reason, reservation is > necessary, it would seem to be better done at the end of the address > space. > But, the end of the address range collides with existing assignments already delegated in RFC 2375. That is why 3307 uses the low end of the range for permanent group IDs. Brian _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Mon Mar 10 02:28:39 2003 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 CAA08988 for ; Mon, 10 Mar 2003 02:28:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2A7fUu19953 for ssm-archive@odin.ietf.org; Mon, 10 Mar 2003 02:41:30 -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 h2A7fUO19950 for ; Mon, 10 Mar 2003 02:41:30 -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 CAA08890 for ; Mon, 10 Mar 2003 02:28:08 -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 h2A7f6O19933; Mon, 10 Mar 2003 02:41:06 -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 h2A7dRO19802 for ; Mon, 10 Mar 2003 02:39:27 -0500 Received: from netcore.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08518 for ; Mon, 10 Mar 2003 02:26:05 -0500 (EST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2A7Rt524033; Mon, 10 Mar 2003 09:27:55 +0200 Date: Mon, 10 Mar 2003 09:27:55 +0200 (EET) From: Pekka Savola To: Brian Haberman cc: Hugh Holbrook , Subject: Re: [ssm] another last call for draft-ietf-ssm-arch - ending 3/24 In-Reply-To: <3E6BEB1A.4060807@nc.rr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , On Sun, 9 Mar 2003, Brian Haberman wrote: > > The scope of the unicast-prefix based multicast address MUST NOT > > exceed the scope of the unicast prefix embedded in the multicast > > address. > > > > note: "embedded in the multicast address". But as you should note here, > > an address (particularly _SSM_, which is really not derived from the > > unicast prefix) does not. > > The intent was that the scope of the SSM group address would > not exceed the scope of the SSM source address. The scoped addr > arch forwarding rules *WILL* prevent a scoped address from leaking > out of the administrative zone. > > The overall issue though is not SSM-specific. Yes and no: in ASM, the DR only checks that G is ok; not it must check that both S and G are ok. > That is, the > scoped addr arch is responsible for determining the forwarding > issues around scoped addresses. I don't see a need for putting > any type of scoped address issues in the SSM doc. ... > As stated above, I don't see a reason to deal with scoped addresses > in the SSM arch doc. I understand this argument and I agree with it, mostly: at this point, we may end up doing some nasty things (in ipv6 w.g.) with scoped address architecture anyway, so trying to specify everything in detail in the specs before we know we have to do it seems premature. So, I can support putting considerations like these in the scoped address architecture document, but IMO, there *must* be a brief mention of the issues and a pointer in e.g. Security Considerations section. > >>As stated above RFC 3306 does have restrictions on what the scope > >>of the group address can be. > > > > > > As above, I'm not sure how this applies to RFC3306 addresses which do not > > depend on the prefix, ie. SSM. > > I consider the source address of an SSM group to be equivalent to > the unicast prefix used in an RFC 3306 generated address. One could consider so, but as was noted earlier, I didn't see it that way, and many others probably won't either -- unless clarified. More work for scoped addrarch, I suppose. > >>Now, RFC 3307 reserves 0x00000001 to 0x3FFFFFFF for use with > >>permanently allocated IPv6 multicast addresses. This is for > >>consistency with permanent IPv4 multicast addresses. That > >>means that T=0 in the flags field. I would expect that SSM > >>applications would allocate group IDs out of the 0x80000000 to > >>0xFFFFFFFF range for SSM channels. > > > > But RFC3306 addresses, including SSM, *MUST* have T=1, so one could argue > > that the reservation does not hold. > > Not sure what you mean here. 3307 is very explicit in what IANA > is reserving for group IDs. 3307 says: 4.1 Permanent IPv6 Multicast Addresses Permanent multicast addresses, like those defined in [RFC 2375], are allocated by IANA. These addresses will be assigned with group ID's, in the range of 0x00000001 to 0x3FFFFFFF, on an Expert Review basis. Multicast addresses assigned by IANA MUST have the T bit set to 0 and the P bit set to 0. ==> the last sentence does not hold for SSM; the IANA considerations section itself is quite explicit. > > IMO, reserving 0x8... to 0xf for apps would be a bad decision. SSM is > > _source_ specific. It makes very much sense for apps/users to use as > > simple addresses as possible, like FF3X::1, FF3X:::2, ..., *not* like > > FF3X::8000:0001, FF3X::8000:0002, etc. > > But there is a bigger issue. One of the goals of 3307 is to help > prevent collisions at the layer-2 mapping of group addresses. By > having separate 32-bit ranges for the group IDs, it is possible to > minimize the number of collisions that occur at the MAC layer. Ok, I can accept that, I think. > > There doesn't seem to be need for this kind of address reservation is > > necessary for SSM; if, for some particular reason, reservation is > > necessary, it would seem to be better done at the end of the address > > space. > > > > But, the end of the address range collides with existing assignments > already delegated in RFC 2375. That is why 3307 uses the low end of > the range for permanent group IDs. Ok; so, if a user manually configures an SSM address to be used, he must use ones from the dynamic range? (even though the dynamicity is arguable.) -- 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 From mailnull@www1.ietf.org Mon Mar 10 08:31:20 2003 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 IAA15803 for ; Mon, 10 Mar 2003 08:31:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2ADiI411413 for ssm-archive@odin.ietf.org; Mon, 10 Mar 2003 08:44:18 -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 h2ADiIO11410 for ; Mon, 10 Mar 2003 08:44:18 -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 IAA15681 for ; Mon, 10 Mar 2003 08:30:48 -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 h2ADhYO11358; Mon, 10 Mar 2003 08:43:34 -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 h2ADgSO11268 for ; Mon, 10 Mar 2003 08:42:28 -0500 Received: from ms-smtp-02.southeast.rr.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15207 for ; Mon, 10 Mar 2003 08:28:58 -0500 (EST) Received: from mail3.nc.rr.com (fe3 [24.93.67.50]) by ms-smtp-02.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h2ADST1I016859; Mon, 10 Mar 2003 08:29:24 -0500 (EST) Received: from nc.rr.com ([63.109.132.2]) by mail3.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 10 Mar 2003 07:59:44 -0500 Message-ID: <3E6C8CBD.1090508@nc.rr.com> Date: Mon, 10 Mar 2003 08:01:49 -0500 From: Brian Haberman Organization: No Organization Here User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: Hugh Holbrook , ssm@ietf.org Subject: Re: [ssm] another last call for draft-ietf-ssm-arch - ending 3/24 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pekka Savola wrote: > On Sun, 9 Mar 2003, Brian Haberman wrote: > >>> The scope of the unicast-prefix based multicast address MUST NOT >>> exceed the scope of the unicast prefix embedded in the multicast >>> address. >>> >>>note: "embedded in the multicast address". But as you should note here, >>>an address (particularly _SSM_, which is really not derived from the >>>unicast prefix) does not. >> >>The intent was that the scope of the SSM group address would >>not exceed the scope of the SSM source address. The scoped addr >>arch forwarding rules *WILL* prevent a scoped address from leaking >>out of the administrative zone. >> >>The overall issue though is not SSM-specific. > > > Yes and no: in ASM, the DR only checks that G is ok; not it must check > that both S and G are ok. > Actually, the DR has to check both S and G to ensure that it does not send a PIM Join across a scope zone boundary regardless of it being ASM or SSM. There was some text in the original PIM for v6 draft a long time ago. > >>That is, the >>scoped addr arch is responsible for determining the forwarding >>issues around scoped addresses. I don't see a need for putting >>any type of scoped address issues in the SSM doc. > > ... > >>As stated above, I don't see a reason to deal with scoped addresses >>in the SSM arch doc. > > > I understand this argument and I agree with it, mostly: at this point, we > may end up doing some nasty things (in ipv6 w.g.) with scoped address > architecture anyway, so trying to specify everything in detail in the > specs before we know we have to do it seems premature. Agreed. :) > > So, I can support putting considerations like these in the scoped address > architecture document, but IMO, there *must* be a brief mention of the > issues and a pointer in e.g. Security Considerations section. > I don't see a problem with doing that. The security section can mention the issue and say that it is out of scope for this doc and is being addressed elsewhere. > >>>>As stated above RFC 3306 does have restrictions on what the scope >>>>of the group address can be. >>> >>> >>>As above, I'm not sure how this applies to RFC3306 addresses which do not >>>depend on the prefix, ie. SSM. >> >>I consider the source address of an SSM group to be equivalent to >>the unicast prefix used in an RFC 3306 generated address. > > > One could consider so, but as was noted earlier, I didn't see it that way, > and many others probably won't either -- unless clarified. > > More work for scoped addrarch, I suppose. > Long-term it should be fixed in a revision of 3306. Near-term we could add text to this doc in section 4.3 clarifying the allocation issue on scopes. > >>>>Now, RFC 3307 reserves 0x00000001 to 0x3FFFFFFF for use with >>>>permanently allocated IPv6 multicast addresses. This is for >>>>consistency with permanent IPv4 multicast addresses. That >>>>means that T=0 in the flags field. I would expect that SSM >>>>applications would allocate group IDs out of the 0x80000000 to >>>>0xFFFFFFFF range for SSM channels. >>> >>>But RFC3306 addresses, including SSM, *MUST* have T=1, so one could argue >>>that the reservation does not hold. >> >>Not sure what you mean here. 3307 is very explicit in what IANA >>is reserving for group IDs. > > > 3307 says: > > 4.1 Permanent IPv6 Multicast Addresses > > Permanent multicast addresses, like those defined in [RFC 2375], are > allocated by IANA. These addresses will be assigned with group ID's, > in the range of 0x00000001 to 0x3FFFFFFF, on an Expert Review basis. > > Multicast addresses assigned by IANA MUST have the T bit set to 0 and > the P bit set to 0. > > ==> the last sentence does not hold for SSM; the IANA considerations > section itself is quite explicit. > SSM addresses are not restricted to the completely dynamic addresses. An SSM app could request a permanent group ID as defined in section 4.2. > >>>IMO, reserving 0x8... to 0xf for apps would be a bad decision. SSM is >>>_source_ specific. It makes very much sense for apps/users to use as >>>simple addresses as possible, like FF3X::1, FF3X:::2, ..., *not* like >>>FF3X::8000:0001, FF3X::8000:0002, etc. >> >>But there is a bigger issue. One of the goals of 3307 is to help >>prevent collisions at the layer-2 mapping of group addresses. By >>having separate 32-bit ranges for the group IDs, it is possible to >>minimize the number of collisions that occur at the MAC layer. > > > Ok, I can accept that, I think. > > >>>There doesn't seem to be need for this kind of address reservation is >>>necessary for SSM; if, for some particular reason, reservation is >>>necessary, it would seem to be better done at the end of the address >>>space. >>> >> >>But, the end of the address range collides with existing assignments >>already delegated in RFC 2375. That is why 3307 uses the low end of >>the range for permanent group IDs. > > > Ok; so, if a user manually configures an SSM address to be used, he must > use ones from the dynamic range? (even though the dynamicity is > arguable.) > As noted above, the user could request a permanent group ID for the application. Brian _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Tue Mar 11 01:54:03 2003 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 BAA29287 for ; Tue, 11 Mar 2003 01:54:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2B77OU29116 for ssm-archive@odin.ietf.org; Tue, 11 Mar 2003 02:07:24 -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 h2B77OO29105 for ; Tue, 11 Mar 2003 02:07:24 -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 BAA29251 for ; Tue, 11 Mar 2003 01:53:32 -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 h2B76uO28258; Tue, 11 Mar 2003 02:06:56 -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 h2B75lO27200 for ; Tue, 11 Mar 2003 02:05:47 -0500 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29234 for ; Tue, 11 Mar 2003 01:51:55 -0500 (EST) Received: from holbrook-laptop.cisco.com (sjc-vpn2-31.cisco.com [10.21.112.31]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2B6s1hs013691; Mon, 10 Mar 2003 22:54:02 -0800 (PST) Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id AFB8210B7A7; Mon, 10 Mar 2003 22:49:38 -0800 (PST) From: Hugh Holbrook To: Pekka Savola Cc: Hugh Holbrook , ssm@ietf.org, In-reply-to: Subject: Re: Re: Re: [ssm] another last call for draft-ietf-ssm-arch - ending 3/24 Reply-To: holbrook@cisco.com Message-Id: <20030311064938.AFB8210B7A7@holbrook-laptop.cisco.com> Date: Mon, 10 Mar 2003 22:49:38 -0800 (PST) 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: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , > Date: Sat, 8 Mar 2003 16:32:13 +0200 (EET) > From: Pekka Savola > Cc: ssm@ietf.org, > > > > ==> 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. > > Yeah, it is used too much as a rough security mechanism, so I think some > text is would be good. What you say above looks quite good, perhaps like: > > Administrative scoping should not relied upon as a security measure > [ADMIN-SCOPE]; however, in many cases it is at least a part of security > solutions. It should be noted that no administrative scoping exists for > IPv4 source-specific multicast. An alternative approach is to configure > manual access-lists to create such scoping if necessary. This text looks pretty good to me. I will add it to the Security Considerations section, barring any objects. -Hugh _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Tue Mar 11 02:34:17 2003 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 CAA11765 for ; Tue, 11 Mar 2003 02:34:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2B7lbP06539 for ssm-archive@odin.ietf.org; Tue, 11 Mar 2003 02:47:37 -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 h2B7laO06536 for ; Tue, 11 Mar 2003 02:47:36 -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 CAA11752 for ; Tue, 11 Mar 2003 02:33:44 -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 h2B7lDO06502; Tue, 11 Mar 2003 02:47:13 -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 h2B7kIO06451 for ; Tue, 11 Mar 2003 02:46:18 -0500 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11721 for ; Tue, 11 Mar 2003 02:32:25 -0500 (EST) Received: from holbrook-laptop.cisco.com (sjc-vpn2-31.cisco.com [10.21.112.31]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2B7YUhs007190; Mon, 10 Mar 2003 23:34:31 -0800 (PST) Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id 5ECC310B7A7; Mon, 10 Mar 2003 23:30:08 -0800 (PST) From: Hugh Holbrook To: Brian Haberman , Pekka Savola Cc: ssm@ietf.org In-reply-to: <3E6C8CBD.1090508@nc.rr.com> Reply-To: holbrook@cisco.com Message-Id: <20030311073008.5ECC310B7A7@holbrook-laptop.cisco.com> Date: Mon, 10 Mar 2003 23:30:08 -0800 (PST) Subject: [ssm] what to say about scoping for v6 [was ...last call...] 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: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , [ ... Snipping just the thread on scoping for ssm ] My comments inline... > Date: Mon, 10 Mar 2003 08:01:49 -0500 > From: Brian Haberman > Cc: Hugh Holbrook , ssm@ietf.org > > Pekka Savola wrote: > > On Sun, 9 Mar 2003, Brian Haberman wrote: > > > >>> The scope of the unicast-prefix based multicast address MUST NOT > >>> exceed the scope of the unicast prefix embedded in the multicast > >>> address. > >>> > >>>note: "embedded in the multicast address". But as you should note here, > >>>an address (particularly _SSM_, which is really not derived from the > >>>unicast prefix) does not. > >> > >>The intent was that the scope of the SSM group address would > >>not exceed the scope of the SSM source address. The scoped addr > >>arch forwarding rules *WILL* prevent a scoped address from leaking > >>out of the administrative zone. > >> > >>The overall issue though is not SSM-specific. > > > > > > Yes and no: in ASM, the DR only checks that G is ok; not it must check > > that both S and G are ok. > > > > Actually, the DR has to check both S and G to ensure that it does > not send a PIM Join across a scope zone boundary regardless of it > being ASM or SSM. There was some text in the original PIM for v6 > draft a long time ago. > > > > >>That is, the > >>scoped addr arch is responsible for determining the forwarding > >>issues around scoped addresses. I don't see a need for putting > >>any type of scoped address issues in the SSM doc. > > > > ... > > > >>As stated above, I don't see a reason to deal with scoped addresses > >>in the SSM arch doc. > > > > > > I understand this argument and I agree with it, mostly: at this point, we > > may end up doing some nasty things (in ipv6 w.g.) with scoped address > > architecture anyway, so trying to specify everything in detail in the > > specs before we know we have to do it seems premature. > > Agreed. :) > > > > > So, I can support putting considerations like these in the scoped address > > architecture document, but IMO, there *must* be a brief mention of the > > issues and a pointer in e.g. Security Considerations section. > > A pointer to what? draft-ietf-ipngwg-scoping-arch-04.txt? > I don't see a problem with doing that. The security section can mention > the issue and say that it is out of scope for this doc and is being > addressed elsewhere. So I'm trying to convert this discussion about scoping to concrete text. Here's what the doc currently says about v6 scoped addresses. For IPv6, administratively scoped SSM addresses are created by choosing an appropriate scope identifier for the SSM destination address. Normal IPv6 multicast scope boundaries are applied to traffic sent to an SSM destination address. I note that this paragraph is confusing because it says you can make a "scoped SSM addresses" when what it should say is "scoped SSM channel addresses". Here is proposed text to incorporate what I think Pekka is suggesting. For IPv6, administratively scoped SSM channel addresses are created by choosing an appropriate scope identifier for the SSM destination address. Normal IPv6 multicast scope boundaries are applied to traffic sent to an SSM destination address, including any relevant boundaries applied to both the source and destination address. Question 1: Do you accept the above text? I'm not sure I captured the issue, so I'd appreciate a better alternative if you see one. Question 2: If not, is there an appropriate reference for "Normal IPv6 multicast scope boundaries," or is it preferable to intentionally leave the document without a reference? Question 3: Should we add text to clarify the "embedded address" text in RFC3306. I can think of three options: Either prohibit it: For IPv6, senders MUST ensure that the scope of a channel destination address does not exceed the scope of the channel source address. Or allow it: For IPv6, the scope of a channel destination address MAY exceed the scope of the channel source address. Normal forwarding rules for scoped traffic apply to a packet sent to such a channel. Normal multicast scoping rules apply for any routing protocol messages (e.g., "joins") referring to such a channel. Or say nothing: I am inclined to do the latter, and I think this is what both of you are saying. Am I right? > >>>>As stated above RFC 3306 does have restrictions on what the scope > >>>>of the group address can be. > >>> > >>> > >>>As above, I'm not sure how this applies to RFC3306 addresses which do not > >>>depend on the prefix, ie. SSM. > >> > >>I consider the source address of an SSM group to be equivalent to > >>the unicast prefix used in an RFC 3306 generated address. > > > > > > One could consider so, but as was noted earlier, I didn't see it that way, > > and many others probably won't either -- unless clarified. > > > > More work for scoped addrarch, I suppose. > > > > Long-term it should be fixed in a revision of 3306. Near-term we > could add text to this doc in section 4.3 clarifying the allocation > issue on scopes. > > > > >>>>Now, RFC 3307 reserves 0x00000001 to 0x3FFFFFFF for use with > >>>>permanently allocated IPv6 multicast addresses. This is for > >>>>consistency with permanent IPv4 multicast addresses. That > >>>>means that T=0 in the flags field. I would expect that SSM > >>>>applications would allocate group IDs out of the 0x80000000 to > >>>>0xFFFFFFFF range for SSM channels. > >>> > >>>But RFC3306 addresses, including SSM, *MUST* have T=1, so one could argue > >>>that the reservation does not hold. > >> > >>Not sure what you mean here. 3307 is very explicit in what IANA > >>is reserving for group IDs. _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Tue Mar 11 03:06:08 2003 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 DAA12443 for ; Tue, 11 Mar 2003 03:06:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2B8JTw08666 for ssm-archive@odin.ietf.org; Tue, 11 Mar 2003 03:19:29 -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 h2B8JSO08663 for ; Tue, 11 Mar 2003 03:19:28 -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 DAA12399 for ; Tue, 11 Mar 2003 03:05:36 -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 h2B8JFO08649; Tue, 11 Mar 2003 03:19:15 -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 h2B8IPO08625 for ; Tue, 11 Mar 2003 03:18:25 -0500 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12388 for ; Tue, 11 Mar 2003 03:04:32 -0500 (EST) Received: from holbrook-laptop.cisco.com (sjc-vpn2-31.cisco.com [10.21.112.31]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2B86bhs024584; Tue, 11 Mar 2003 00:06:38 -0800 (PST) Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id C911910B7A7; Tue, 11 Mar 2003 00:02:14 -0800 (PST) From: Hugh Holbrook To: Brian Haberman Cc: Pekka Savola , Hugh Holbrook , ssm@ietf.org In-reply-to: <3E6C8CBD.1090508@nc.rr.com> Reply-To: holbrook@cisco.com Message-Id: <20030311080214.C911910B7A7@holbrook-laptop.cisco.com> Date: Tue, 11 Mar 2003 00:02:14 -0800 (PST) Subject: [ssm] permanent ipv6 ssm addresses [was ...last call..] 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: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , [snipping just the thread on allocating permanent ipv6 addresses] Thanks for your input, Pekka and Brian. Exactly -- the idea is that an application that requires, for some reason, that the same channel destination address be used on all hosts providing that channel would be allocated from 0x40000000-0x7fffffff. Any other channel destination addresses, regardless of lifetime, must come from the 0x80000000-0xffffffff space. Section 4.3 states that a host OS SHOULD provide an interface to allocate a random address, and that this information must be stored in a database that persists across reboots. The idea is that this is the mechanism that an application or user uses to allocate an SSM address. I think this is probably already clear, but I want to underscore the importance of using random allocation for SSM addresses. It is not a good idea (and is in fact specifically disallowed in section 4.3) for a host, host application, or host OS, to deterministically pick FF3x::1 or FF3x::2, or *any* fixed value as the channel destination address on all hosts for some application -- because of the link-layer collision issue. -------------------------------- So to summarize on the text changes, the only textual change I currently think is warranted is to clarify in 4.3 and in the IANA Considerations section the use of the 4000:0000 to 7fff:ffff In 4.3, change this: The SSM destination address 232.0.0.0 is reserved, and systems MUST NOT send datagrams with destination address of 232.0.0.0. The address range 232.0.0.1-232.0.0.255 is currently reserved for allocation by IANA. The IPv6 SSM address range FF3x::/32 is reserved for IANA allocation. to correctly call out the 0x4000000-7fffffff range. The SSM destination address 232.0.0.0 is reserved, and systems MUST NOT send datagrams with destination address of 232.0.0.0. The address range 232.0.0.1-232.0.0.255 is currently reserved for allocation by IANA. SSM destination addresses in the range FF3x::4000:0000 through FF3x::7FFF:FFFF are similarly reserved for IANA allocation. I'm not sure where the FF3x::/32 came from, but I think it is a vestige of an earlier revision that was less clear on the /96 vs /32 distinction. And a similar fix IANA Considerations. 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 that either require or would strongly benefit if all hosts used a well-known SSM destination address for that service. to read Addresses in the range 232.0.0.1 through 232.0.0.255 and IPv6 addresses in the range FF3x:4000:0000 to FF3x::7FFF:FFFF are reserved for services with wide applicability that either require or would strongly benefit if all hosts used a well-known SSM destination address for that service. Any objections to these changes? -Hugh > Date: Mon, 10 Mar 2003 08:01:49 -0500 > From: Brian Haberman > Cc: Hugh Holbrook , ssm@ietf.org > > Pekka Savola wrote: > > On Sun, 9 Mar 2003, Brian Haberman wrote: > >>>>Now, RFC 3307 reserves 0x00000001 to 0x3FFFFFFF for use with > >>>>permanently allocated IPv6 multicast addresses. This is for > >>>>consistency with permanent IPv4 multicast addresses. That > >>>>means that T=0 in the flags field. I would expect that SSM > >>>>applications would allocate group IDs out of the 0x80000000 to > >>>>0xFFFFFFFF range for SSM channels. > >>> > >>>But RFC3306 addresses, including SSM, *MUST* have T=1, so one could argue > >>>that the reservation does not hold. > >> > >>Not sure what you mean here. 3307 is very explicit in what IANA > >>is reserving for group IDs. > > > > > > 3307 says: > > > > 4.1 Permanent IPv6 Multicast Addresses > > > > Permanent multicast addresses, like those defined in [RFC 2375], are > > allocated by IANA. These addresses will be assigned with group ID's, > > in the range of 0x00000001 to 0x3FFFFFFF, on an Expert Review basis. > > > > Multicast addresses assigned by IANA MUST have the T bit set to 0 and > > the P bit set to 0. > > > > ==> the last sentence does not hold for SSM; the IANA considerations > > section itself is quite explicit. > > > > SSM addresses are not restricted to the completely dynamic addresses. > An SSM app could request a permanent group ID as defined in section > 4.2. > > > > >>>IMO, reserving 0x8... to 0xf for apps would be a bad decision. SSM is > >>>_source_ specific. It makes very much sense for apps/users to use as > >>>simple addresses as possible, like FF3X::1, FF3X:::2, ..., *not* like > >>>FF3X::8000:0001, FF3X::8000:0002, etc. > >> > >>But there is a bigger issue. One of the goals of 3307 is to help > >>prevent collisions at the layer-2 mapping of group addresses. By > >>having separate 32-bit ranges for the group IDs, it is possible to > >>minimize the number of collisions that occur at the MAC layer. > > > > > > Ok, I can accept that, I think. > > > > > >>>There doesn't seem to be need for this kind of address reservation is > >>>necessary for SSM; if, for some particular reason, reservation is > >>>necessary, it would seem to be better done at the end of the address > >>>space. > >>> > >> > >>But, the end of the address range collides with existing assignments > >>already delegated in RFC 2375. That is why 3307 uses the low end of > >>the range for permanent group IDs. > > > > > > Ok; so, if a user manually configures an SSM address to be used, he must > > use ones from the dynamic range? (even though the dynamicity is > > arguable.) > > > > As noted above, the user could request a permanent group ID for the > application. _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Tue Mar 11 08:06:30 2003 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 IAA18155 for ; Tue, 11 Mar 2003 08:06:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BDJxO28686 for ssm-archive@odin.ietf.org; Tue, 11 Mar 2003 08:19:59 -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 h2BDJxO28683 for ; Tue, 11 Mar 2003 08:19:59 -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 IAA18131 for ; Tue, 11 Mar 2003 08:05:59 -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 h2BDJSO28585; Tue, 11 Mar 2003 08:19:28 -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 h2BDIOO28447 for ; Tue, 11 Mar 2003 08:18:24 -0500 Received: from ms-smtp-03.southeast.rr.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18039 for ; Tue, 11 Mar 2003 08:04:24 -0500 (EST) Received: from mail3.nc.rr.com (fe3 [24.93.67.50]) by ms-smtp-03.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h2BD5MHG023756; Tue, 11 Mar 2003 08:05:24 -0500 (EST) Received: from nc.rr.com ([63.109.132.2]) by mail3.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 11 Mar 2003 07:58:07 -0500 Message-ID: <3E6DDDDD.2050908@nc.rr.com> Date: Tue, 11 Mar 2003 08:00:13 -0500 From: Brian Haberman Organization: No Organization Here User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: holbrook@cisco.com CC: Pekka Savola , ssm@ietf.org Subject: Re: [ssm] permanent ipv6 ssm addresses [was ...last call..] References: <20030311080214.C911910B7A7@holbrook-laptop.cisco.com> In-Reply-To: <20030311080214.C911910B7A7@holbrook-laptop.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hugh Holbrook wrote: > [snipping just the thread on allocating permanent ipv6 addresses] > > Thanks for your input, Pekka and Brian. > > Exactly -- the idea is that an application that requires, for some > reason, that the same channel destination address be used on all hosts > providing that channel would be allocated from 0x40000000-0x7fffffff. > Any other channel destination addresses, regardless of lifetime, must > come from the 0x80000000-0xffffffff space. > > Section 4.3 states that a host OS SHOULD provide an interface to > allocate a random address, and that this information must be stored in > a database that persists across reboots. The idea is that this is the > mechanism that an application or user uses to allocate an SSM address. > > I think this is probably already clear, but I want to underscore the > importance of using random allocation for SSM addresses. It is not a > good idea (and is in fact specifically disallowed in section 4.3) for > a host, host application, or host OS, to deterministically pick > FF3x::1 or FF3x::2, or *any* fixed value as the channel destination > address on all hosts for some application -- because of the link-layer > collision issue. > > -------------------------------- > > So to summarize on the text changes, the only textual change I > currently think is warranted is to clarify in 4.3 and in the IANA > Considerations section the use of the 4000:0000 to 7fff:ffff > > In 4.3, change this: > > The SSM destination address 232.0.0.0 is reserved, and systems MUST NOT > send datagrams with destination address of 232.0.0.0. The address range > 232.0.0.1-232.0.0.255 is currently reserved for allocation by IANA. The > IPv6 SSM address range FF3x::/32 is reserved for IANA allocation. > > to correctly call out the 0x4000000-7fffffff range. > > The SSM destination address 232.0.0.0 is reserved, and systems MUST NOT > send datagrams with destination address of 232.0.0.0. The address range > 232.0.0.1-232.0.0.255 is currently reserved for allocation by IANA. SSM > destination addresses in the range FF3x::4000:0000 through > FF3x::7FFF:FFFF are similarly reserved for IANA allocation. Seems reasonable to me. > > I'm not sure where the FF3x::/32 came from, but I think it is a > vestige of an earlier revision that was less clear on the /96 vs /32 > distinction. I agree. RFC 3306 reserves the entire /32 so that group IDs can grow beyond the lower 32 bits of the group address. RFC 3307 then states that allocations must be done out of the /96 (for the time being). > > And a similar fix IANA Considerations. > > 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 that either require or would strongly benefit if all > hosts used a well-known SSM destination address for that service. > > to read > > Addresses in the range 232.0.0.1 through 232.0.0.255 and IPv6 > addresses in the range FF3x:4000:0000 to FF3x::7FFF:FFFF are > reserved for services with wide applicability that either require or > would strongly benefit if all hosts used a well-known SSM > destination address for that service. > > Any objections to these changes? I don't have any objections. Brian _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Tue Mar 11 09:11:05 2003 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 JAA19969 for ; Tue, 11 Mar 2003 09:11:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BEOXM00627 for ssm-archive@odin.ietf.org; Tue, 11 Mar 2003 09:24:33 -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 h2BEOWO00624 for ; Tue, 11 Mar 2003 09:24:32 -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 JAA19942 for ; Tue, 11 Mar 2003 09:10:33 -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 h2BEMGO00531; Tue, 11 Mar 2003 09:22:16 -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 h2BELGO00497 for ; Tue, 11 Mar 2003 09:21:16 -0500 Received: from ms-smtp-03.southeast.rr.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19898 for ; Tue, 11 Mar 2003 09:07:17 -0500 (EST) Received: from mail4.nc.rr.com (fe4 [24.93.67.51]) by ms-smtp-03.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h2BDIaHU003192; Tue, 11 Mar 2003 08:19:40 -0500 (EST) Received: from nc.rr.com ([63.109.132.2]) by mail4.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 11 Mar 2003 07:50:17 -0500 Message-ID: <3E6DDB30.5040704@nc.rr.com> Date: Tue, 11 Mar 2003 07:48:48 -0500 From: Brian Haberman Organization: No Organization Here User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: holbrook@cisco.com CC: Pekka Savola , ssm@ietf.org Subject: Re: [ssm] another last call for draft-ietf-ssm-arch - ending 3/24 References: <20030311064938.AFB8210B7A7@holbrook-laptop.cisco.com> In-Reply-To: <20030311064938.AFB8210B7A7@holbrook-laptop.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hugh Holbrook wrote: >>Administrative scoping should not relied upon as a security measure >>[ADMIN-SCOPE]; however, in many cases it is at least a part of security >>solutions. It should be noted that no administrative scoping exists for >>IPv4 source-specific multicast. An alternative approach is to configure >>manual access-lists to create such scoping if necessary. > > > This text looks pretty good to me. I will add it to the Security > Considerations section, barring any objects. Looks fine to me. Brian _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Tue Mar 11 09:23:44 2003 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 JAA20314 for ; Tue, 11 Mar 2003 09:23:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BEbCa01462 for ssm-archive@odin.ietf.org; Tue, 11 Mar 2003 09:37:12 -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 h2BEbCO01451 for ; Tue, 11 Mar 2003 09:37:12 -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 JAA20301 for ; Tue, 11 Mar 2003 09:23:12 -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 h2BEZ9O01156; Tue, 11 Mar 2003 09:35:09 -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 h2BEYbO01095 for ; Tue, 11 Mar 2003 09:34:37 -0500 Received: from ms-smtp-03.southeast.rr.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20253 for ; Tue, 11 Mar 2003 09:20:37 -0500 (EST) Received: from mail4.nc.rr.com (fe4 [24.93.67.51]) by ms-smtp-03.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h2BELNHE007428; Tue, 11 Mar 2003 09:21:33 -0500 (EST) Received: from nc.rr.com ([63.109.132.2]) by mail4.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 11 Mar 2003 09:09:30 -0500 Message-ID: <3E6DEDC1.7050301@nc.rr.com> Date: Tue, 11 Mar 2003 09:08:01 -0500 From: Brian Haberman Organization: No Organization Here User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: holbrook@cisco.com CC: Pekka Savola , ssm@ietf.org Subject: Re: [ssm] what to say about scoping for v6 [was ...last call...] References: <20030311073008.5ECC310B7A7@holbrook-laptop.cisco.com> In-Reply-To: <20030311073008.5ECC310B7A7@holbrook-laptop.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hugh Holbrook wrote: > [ ... Snipping just the thread on scoping for ssm ] > > My comments inline... > > >>Date: Mon, 10 Mar 2003 08:01:49 -0500 >>From: Brian Haberman >>Cc: Hugh Holbrook , ssm@ietf.org >> >>Pekka Savola wrote: >> >>>On Sun, 9 Mar 2003, Brian Haberman wrote: >>> >>> >>>>> The scope of the unicast-prefix based multicast address MUST NOT >>>>> exceed the scope of the unicast prefix embedded in the multicast >>>>> address. >>>>> >>>>>note: "embedded in the multicast address". But as you should note here, >>>>>an address (particularly _SSM_, which is really not derived from the >>>>>unicast prefix) does not. >>>> >>>>The intent was that the scope of the SSM group address would >>>>not exceed the scope of the SSM source address. The scoped addr >>>>arch forwarding rules *WILL* prevent a scoped address from leaking >>>>out of the administrative zone. >>>> >>>>The overall issue though is not SSM-specific. >>> >>> >>>Yes and no: in ASM, the DR only checks that G is ok; not it must check >>>that both S and G are ok. >>> >> >>Actually, the DR has to check both S and G to ensure that it does >>not send a PIM Join across a scope zone boundary regardless of it >>being ASM or SSM. There was some text in the original PIM for v6 >>draft a long time ago. >> >> >>>>That is, the >>>>scoped addr arch is responsible for determining the forwarding >>>>issues around scoped addresses. I don't see a need for putting >>>>any type of scoped address issues in the SSM doc. >>> >>>... >>> >>> >>>>As stated above, I don't see a reason to deal with scoped addresses >>>>in the SSM arch doc. >>> >>> >>>I understand this argument and I agree with it, mostly: at this point, we >>>may end up doing some nasty things (in ipv6 w.g.) with scoped address >>>architecture anyway, so trying to specify everything in detail in the >>>specs before we know we have to do it seems premature. >> >>Agreed. :) >> >> >>>So, I can support putting considerations like these in the scoped address >>>architecture document, but IMO, there *must* be a brief mention of the >>>issues and a pointer in e.g. Security Considerations section. >>> > > > A pointer to what? draft-ietf-ipngwg-scoping-arch-04.txt? > That would be the beast. RFC 3484 references it when discussing the issue of scope within the source address selection policy. It can be an informative reference here. > >>I don't see a problem with doing that. The security section can mention >>the issue and say that it is out of scope for this doc and is being >>addressed elsewhere. > > > So I'm trying to convert this discussion about scoping to concrete > text. Here's what the doc currently says about v6 scoped addresses. > > For IPv6, administratively scoped SSM addresses are created by choosing > an appropriate scope identifier for the SSM destination address. Normal > IPv6 multicast scope boundaries are applied to traffic sent to an SSM > destination address. > > I note that this paragraph is confusing because it says you can make a > "scoped SSM addresses" when what it should say is "scoped SSM channel > addresses". Here is proposed text to incorporate what I think Pekka > is suggesting. > > For IPv6, administratively scoped SSM channel addresses are created > by choosing an appropriate scope identifier for the SSM destination > address. Normal IPv6 multicast scope boundaries are applied to > traffic sent to an SSM destination address, including any relevant > boundaries applied to both the source and destination address. > > Question 1: Do you accept the above text? I'm not sure I captured the > issue, so I'd appreciate a better alternative if you see one. I am ok with it, but I didn't raise the issue either. So, I would like Pekka's assessment before we declare victory. :) > > Question 2: If not, is there an appropriate reference for "Normal IPv6 > multicast scope boundaries," or is it preferable to intentionally > leave the document without a reference? I don't see a problem with having an informative reference for the scoped addr arch doc. > > Question 3: Should we add text to clarify the "embedded address" text > in RFC3306. I can think of three options: > > Either prohibit it: > > For IPv6, senders MUST ensure that the scope of a channel > destination address does not exceed the scope of the channel source > address. > > Or allow it: > > For IPv6, the scope of a channel destination address MAY exceed the > scope of the channel source address. Normal forwarding rules for > scoped traffic apply to a packet sent to such a channel. Normal > multicast scoping rules apply for any routing protocol messages > (e.g., "joins") referring to such a channel. > > Or say nothing: > > I am inclined to do the latter, and I think this is what both of you > are saying. Am I right? > I agree, the latter works for me. Should we add a reference to RFC 3484 as a note on how the address selection could occur? Brian _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Wed Mar 12 02:24:09 2003 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 CAA18217 for ; Wed, 12 Mar 2003 02:24:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2C7bxm20382 for ssm-archive@odin.ietf.org; Wed, 12 Mar 2003 02:37:59 -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 h2C7bxO20377 for ; Wed, 12 Mar 2003 02:37:59 -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 CAA17681 for ; Wed, 12 Mar 2003 02:23:37 -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 h2C7bIO19975; Wed, 12 Mar 2003 02:37:18 -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 h2C7ZmO19545 for ; Wed, 12 Mar 2003 02:35:48 -0500 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15405 for ; Wed, 12 Mar 2003 02:21:26 -0500 (EST) Received: from holbrook-laptop.cisco.com (sjc-vpn3-863.cisco.com [10.21.67.95]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2C7NWhs004336; Tue, 11 Mar 2003 23:23:33 -0800 (PST) Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id 40B0E10B7A7; Tue, 11 Mar 2003 23:19:09 -0800 (PST) From: Hugh Holbrook To: Brian Haberman Cc: holbrook@cisco.com, Pekka Savola , ssm@ietf.org In-reply-to: <3E6DDDDD.2050908@nc.rr.com> Subject: Re: Re: [ssm] permanent ipv6 ssm addresses [was ...last call..] Reply-To: holbrook@cisco.com Message-Id: <20030312071909.40B0E10B7A7@holbrook-laptop.cisco.com> Date: Tue, 11 Mar 2003 23:19:09 -0800 (PST) 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: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , Cool, thanks. I've made both of these changes to my working copy. -Hugh > Date: Tue, 11 Mar 2003 08:00:13 -0500 > From: Brian Haberman > Cc: Pekka Savola , ssm@ietf.org > > Hugh Holbrook wrote: > > [snipping just the thread on allocating permanent ipv6 addresses] > > > > Thanks for your input, Pekka and Brian. > > > > Exactly -- the idea is that an application that requires, for some > > reason, that the same channel destination address be used on all hosts > > providing that channel would be allocated from 0x40000000-0x7fffffff. > > Any other channel destination addresses, regardless of lifetime, must > > come from the 0x80000000-0xffffffff space. > > > > Section 4.3 states that a host OS SHOULD provide an interface to > > allocate a random address, and that this information must be stored in > > a database that persists across reboots. The idea is that this is the > > mechanism that an application or user uses to allocate an SSM address. > > > > I think this is probably already clear, but I want to underscore the > > importance of using random allocation for SSM addresses. It is not a > > good idea (and is in fact specifically disallowed in section 4.3) for > > a host, host application, or host OS, to deterministically pick > > FF3x::1 or FF3x::2, or *any* fixed value as the channel destination > > address on all hosts for some application -- because of the link-layer > > collision issue. > > > > -------------------------------- > > > > So to summarize on the text changes, the only textual change I > > currently think is warranted is to clarify in 4.3 and in the IANA > > Considerations section the use of the 4000:0000 to 7fff:ffff > > > > In 4.3, change this: > > > > The SSM destination address 232.0.0.0 is reserved, and systems MUST NOT > > send datagrams with destination address of 232.0.0.0. The address range > > 232.0.0.1-232.0.0.255 is currently reserved for allocation by IANA. The > > IPv6 SSM address range FF3x::/32 is reserved for IANA allocation. > > > > to correctly call out the 0x4000000-7fffffff range. > > > > The SSM destination address 232.0.0.0 is reserved, and systems MUST NOT > > send datagrams with destination address of 232.0.0.0. The address range > > 232.0.0.1-232.0.0.255 is currently reserved for allocation by IANA. SSM > > destination addresses in the range FF3x::4000:0000 through > > FF3x::7FFF:FFFF are similarly reserved for IANA allocation. > > Seems reasonable to me. > > > > > I'm not sure where the FF3x::/32 came from, but I think it is a > > vestige of an earlier revision that was less clear on the /96 vs /32 > > distinction. > > I agree. RFC 3306 reserves the entire /32 so that group IDs can > grow beyond the lower 32 bits of the group address. RFC 3307 then > states that allocations must be done out of the /96 (for the time > being). > > > > > And a similar fix IANA Considerations. > > > > 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 that either require or would strongly benefit if all > > hosts used a well-known SSM destination address for that service. > > > > to read > > > > Addresses in the range 232.0.0.1 through 232.0.0.255 and IPv6 > > addresses in the range FF3x:4000:0000 to FF3x::7FFF:FFFF are > > reserved for services with wide applicability that either require or > > would strongly benefit if all hosts used a well-known SSM > > destination address for that service. > > > > Any objections to these changes? > > I don't have any objections. > > Brian > > _______________________________________________ > 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 From mailnull@www1.ietf.org Wed Mar 12 05:41:53 2003 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 FAA28503 for ; Wed, 12 Mar 2003 05:41:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CAtlg00705 for ssm-archive@odin.ietf.org; Wed, 12 Mar 2003 05:55:47 -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 h2CAtlO00702 for ; Wed, 12 Mar 2003 05:55:47 -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 FAA28475 for ; Wed, 12 Mar 2003 05:41:22 -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 h2CAtNO00684; Wed, 12 Mar 2003 05:55:23 -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 h2CAsgO00632 for ; Wed, 12 Mar 2003 05:54:42 -0500 Received: from netcore.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28434 for ; Wed, 12 Mar 2003 05:40:17 -0500 (EST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2CAgBa12317; Wed, 12 Mar 2003 12:42:11 +0200 Date: Wed, 12 Mar 2003 12:42:11 +0200 (EET) From: Pekka Savola To: Brian Haberman cc: holbrook@cisco.com, Subject: Re: [ssm] what to say about scoping for v6 [was ...last call...] In-Reply-To: <3E6DEDC1.7050301@nc.rr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , On Tue, 11 Mar 2003, Brian Haberman wrote: > > A pointer to what? draft-ietf-ipngwg-scoping-arch-04.txt? > > > > That would be the beast. RFC 3484 references it when discussing > the issue of scope within the source address selection policy. It > can be an informative reference here. Agree. > > So I'm trying to convert this discussion about scoping to concrete > > text. Here's what the doc currently says about v6 scoped addresses. > > > > For IPv6, administratively scoped SSM addresses are created by choosing > > an appropriate scope identifier for the SSM destination address. Normal > > IPv6 multicast scope boundaries are applied to traffic sent to an SSM > > destination address. > > > > I note that this paragraph is confusing because it says you can make a > > "scoped SSM addresses" when what it should say is "scoped SSM channel > > addresses". Here is proposed text to incorporate what I think Pekka > > is suggesting. > > > > For IPv6, administratively scoped SSM channel addresses are created > > by choosing an appropriate scope identifier for the SSM destination > > address. Normal IPv6 multicast scope boundaries are applied to > > traffic sent to an SSM destination address, including any relevant > > boundaries applied to both the source and destination address. > > > > Question 1: Do you accept the above text? I'm not sure I captured the > > issue, so I'd appreciate a better alternative if you see one. > > I am ok with it, but I didn't raise the issue either. So, I would > like Pekka's assessment before we declare victory. :) I can live with it, with the inclusion of the reference. However, I'd like a statement in the security considerations, perhaps along the lines of: One should note that the use of IPv6 scoped addresses either in S or G may cause significant complexities, for example regarding mismatching scopes between S and G or regarding forwarding decisions for a scoped (S,G). The implications of scoped addresses are described in other documents [REF:SCOPED-ARCH] > > Question 2: If not, is there an appropriate reference for "Normal IPv6 > > multicast scope boundaries," or is it preferable to intentionally > > leave the document without a reference? > > I don't see a problem with having an informative reference for the > scoped addr arch doc. I think an informational reference is necessary. (Actually, it should be "almost" normative, but we don't want to have SSM arch get stuck due to scoped addrarch, so..) > > Question 3: Should we add text to clarify the "embedded address" text > > in RFC3306. I can think of three options: > > > > Either prohibit it: > > > > For IPv6, senders MUST ensure that the scope of a channel > > destination address does not exceed the scope of the channel source > > address. > > > > Or allow it: > > > > For IPv6, the scope of a channel destination address MAY exceed the > > scope of the channel source address. Normal forwarding rules for > > scoped traffic apply to a packet sent to such a channel. Normal > > multicast scoping rules apply for any routing protocol messages > > (e.g., "joins") referring to such a channel. > > > > Or say nothing: > > > > I am inclined to do the latter, and I think this is what both of you > > are saying. Am I right? > > I agree, the latter works for me. I'm ok with leaving the text out. It is up to RFC3306bis and clarification of it in scoped addrarch. > Should we add a reference to RFC > 3484 as a note on how the address selection could occur? I'm ok with it but don't see where it would fit nicely. -- 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 From mailnull@www1.ietf.org Wed Mar 12 13:16:49 2003 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 NAA14492 for ; Wed, 12 Mar 2003 13:16:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CIUqi01421 for ssm-archive@odin.ietf.org; Wed, 12 Mar 2003 13:30:52 -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 h2CIUqO01418 for ; Wed, 12 Mar 2003 13:30:52 -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 NAA14479 for ; Wed, 12 Mar 2003 13:16:16 -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 h2CITYO01310; Wed, 12 Mar 2003 13:29:34 -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 h2CIOuO01023 for ; Wed, 12 Mar 2003 13:24:56 -0500 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14275 for ; Wed, 12 Mar 2003 13:10:21 -0500 (EST) Received: from holbrook-laptop.cisco.com (sjc-vpn1-426.cisco.com [10.21.97.170]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2CICSEY015725; Wed, 12 Mar 2003 10:12:28 -0800 (PST) Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id 1788F10B7A7; Wed, 12 Mar 2003 10:08:04 -0800 (PST) From: Hugh Holbrook To: Pekka Savola Cc: Brian Haberman , holbrook@cisco.com, In-reply-to: Subject: Re: Re: [ssm] what to say about scoping for v6 [was ...last call...] Reply-To: holbrook@cisco.com Message-Id: <20030312180804.1788F10B7A7@holbrook-laptop.cisco.com> Date: Wed, 12 Mar 2003 10:08:04 -0800 (PST) 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: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , > > > So I'm trying to convert this discussion about scoping to concrete > > > text. Here's what the doc currently says about v6 scoped addresses. > > > > > > For IPv6, administratively scoped SSM addresses are created by choosing > > > an appropriate scope identifier for the SSM destination address. Normal > > > IPv6 multicast scope boundaries are applied to traffic sent to an SSM > > > destination address. > > > > > > I note that this paragraph is confusing because it says you can make a > > > "scoped SSM addresses" when what it should say is "scoped SSM channel > > > addresses". Here is proposed text to incorporate what I think Pekka > > > is suggesting. > > > > > > For IPv6, administratively scoped SSM channel addresses are created > > > by choosing an appropriate scope identifier for the SSM destination > > > address. Normal IPv6 multicast scope boundaries are applied to > > > traffic sent to an SSM destination address, including any relevant > > > boundaries applied to both the source and destination address. > > > > > > Question 1: Do you accept the above text? I'm not sure I captured the > > > issue, so I'd appreciate a better alternative if you see one. > > > > I am ok with it, but I didn't raise the issue either. So, I would > > like Pekka's assessment before we declare victory. :) > > I can live with it, with the inclusion of the reference. Done. I massaged the English of the last sentence to make it a bit more direct, without changing the wording. The text now reads For IPv6, administratively scoped SSM channel addresses are created by choosing an appropriate scope identifier for the SSM destination address. Normal IPv6 multicast scope boundaries [SCOPINGV6] are applied to traffic sent to an SSM destination address. Boundaries are applied to both the source and destination address. ... [SCOPINGV6] Deering, S. et. al, "IP Version 6 Scoped Address Architecture", Work in Progress. > However, I'd like a statement in the security considerations, perhaps > along the lines of: > > One should note that the use of IPv6 scoped addresses either in S or G may > cause significant complexities, for example regarding mismatching scopes > between S and G or regarding forwarding decisions for a scoped (S,G). > The implications of scoped addresses are described in other documents > [REF:SCOPED-ARCH] Isn't the scoping behavior simply that the most restrictive (smallest) scope applies. A packet is forwarded neither across a source-scope boundary nor across a destination-scope boundary. Unless I'm missing something, this actually sounds rather uncomplicated to me. Is there something that makes this tricky? Is there something about this that makes it a Security Considerations issue? > > > Question 2: If not, is there an appropriate reference for "Normal IPv6 > > > multicast scope boundaries," or is it preferable to intentionally > > > leave the document without a reference? > > > > I don't see a problem with having an informative reference for the > > scoped addr arch doc. > > I think an informational reference is necessary. (Actually, it should be > "almost" normative, but we don't want to have SSM arch get stuck due to > scoped addrarch, so..) Ok. I'm fine with referring to that document, as above. > > > Question 3: Should we add text to clarify the "embedded address" text > > > in RFC3306. I can think of three options: > > > > > > Either prohibit it: > > > > > > For IPv6, senders MUST ensure that the scope of a channel > > > destination address does not exceed the scope of the channel source > > > address. > > > > > > Or allow it: > > > > > > For IPv6, the scope of a channel destination address MAY exceed the > > > scope of the channel source address. Normal forwarding rules for > > > scoped traffic apply to a packet sent to such a channel. Normal > > > multicast scoping rules apply for any routing protocol messages > > > (e.g., "joins") referring to such a channel. > > > > > > Or say nothing: > > > > > > I am inclined to do the latter, and I think this is what both of you > > > are saying. Am I right? > > > > I agree, the latter works for me. > > I'm ok with leaving the text out. It is up to RFC3306bis and > clarification of it in scoped addrarch. Ok. Agreed on that. > > Should we add a reference to RFC > > 3484 as a note on how the address selection could occur? > > I'm ok with it but don't see where it would fit nicely. Ok. The resolution is to not say anything about address selection rules for SSM. Thanks. > -- > 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 From mailnull@www1.ietf.org Wed Mar 12 13:50:15 2003 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 NAA16015 for ; Wed, 12 Mar 2003 13:50:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CJ4Ja04172 for ssm-archive@odin.ietf.org; Wed, 12 Mar 2003 14:04: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 h2CJ4JO04169 for ; Wed, 12 Mar 2003 14:04:19 -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 NAA15967 for ; Wed, 12 Mar 2003 13:49:43 -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 h2CJ3ZO04050; Wed, 12 Mar 2003 14:03:35 -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 h2CIw3O03825 for ; Wed, 12 Mar 2003 13:58:03 -0500 Received: from ms-smtp-02.southeast.rr.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15820 for ; Wed, 12 Mar 2003 13:43:28 -0500 (EST) Received: from mail4.nc.rr.com (fe4 [24.93.67.51]) by ms-smtp-02.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h2CIhHgQ004897; Wed, 12 Mar 2003 13:43:17 -0500 (EST) Received: from nc.rr.com ([63.109.132.2]) by mail4.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Wed, 12 Mar 2003 13:46:22 -0500 Message-ID: <3E6F8024.40405@nc.rr.com> Date: Wed, 12 Mar 2003 13:44:52 -0500 From: Brian Haberman Organization: No Organization Here User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: holbrook@cisco.com CC: Pekka Savola , ssm@ietf.org Subject: Re: [ssm] what to say about scoping for v6 [was ...last call...] References: <20030312180804.1788F10B7A7@holbrook-laptop.cisco.com> In-Reply-To: <20030312180804.1788F10B7A7@holbrook-laptop.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hugh Holbrook wrote: >>However, I'd like a statement in the security considerations, perhaps >>along the lines of: >> >>One should note that the use of IPv6 scoped addresses either in S or G may >>cause significant complexities, for example regarding mismatching scopes >>between S and G or regarding forwarding decisions for a scoped (S,G). >>The implications of scoped addresses are described in other documents >>[REF:SCOPED-ARCH] > > > Isn't the scoping behavior simply that the most restrictive (smallest) > scope applies. A packet is forwarded neither across a source-scope > boundary nor across a destination-scope boundary. Unless I'm missing > something, this actually sounds rather uncomplicated to me. Is there > something that makes this tricky? Not that I am aware of. > > Is there something about this that makes it a Security Considerations > issue? I don't see a huge need for it. Especially since it affects all forwarding of scoped addresses, not just multicast. Brian _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Wed Mar 12 14:44:08 2003 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 OAA18024 for ; Wed, 12 Mar 2003 14:44:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CJwDk08227 for ssm-archive@odin.ietf.org; Wed, 12 Mar 2003 14:58:13 -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 h2CJwDO08224 for ; Wed, 12 Mar 2003 14:58:13 -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 OAA17995 for ; Wed, 12 Mar 2003 14:43:37 -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 h2CJvMO08155; Wed, 12 Mar 2003 14:57:22 -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 h2CJtDO08064 for ; Wed, 12 Mar 2003 14:55:13 -0500 Received: from netcore.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17905 for ; Wed, 12 Mar 2003 14:40:35 -0500 (EST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2CJfRK15899; Wed, 12 Mar 2003 21:41:27 +0200 Date: Wed, 12 Mar 2003 21:41:27 +0200 (EET) From: Pekka Savola To: Hugh Holbrook cc: Brian Haberman , Subject: Re: Re: [ssm] what to say about scoping for v6 [was ...last call...] In-Reply-To: <20030312180804.1788F10B7A7@holbrook-laptop.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , On Wed, 12 Mar 2003, Hugh Holbrook wrote: > > One should note that the use of IPv6 scoped addresses either in S or G may > > cause significant complexities, for example regarding mismatching scopes > > between S and G or regarding forwarding decisions for a scoped (S,G). > > The implications of scoped addresses are described in other documents > > [REF:SCOPED-ARCH] > > Isn't the scoping behavior simply that the most restrictive (smallest) > scope applies. A packet is forwarded neither across a source-scope > boundary nor across a destination-scope boundary. Unless I'm missing > something, this actually sounds rather uncomplicated to me. Is there > something that makes this tricky? At the moment, in practise (=implementation), everything related to scoping is *undefined*, it seems to me. How your SSM-enabled router will/would react now, or in 1-2 years is a complete question mark. > Is there something about this that makes it a Security Considerations > issue? Yes, but only slightly: if people use e.g. site-local addresses as a security measure, and use SSM with like (, global-scope-SSM) -- for whatever reason, e.g. the use of the same application (and subsequent G) both site-locally and globally, the forwarding of such multicasts might *NOT* be limited to your site-local S scope. This is an uncertainty as the implementation is unclear. On the hindsight, the text I proposed above seems better fit to some other section, and something different might be more applicable to security considerations, like: Note that when forwarding or processing SSM, the scope of both S and G may have to be considered [SCOPED-ARCH]; in particular, if the unicast scope of S is smaller than respective multicast scope of G, the packets might end up forwarded outside of the scope of S. Therefore, limited scopes should be avoided and must not be used as a security mechanism. .. I wonder if that's any better .. -- 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 From mailnull@www1.ietf.org Wed Mar 12 15:18:44 2003 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 PAA20455 for ; Wed, 12 Mar 2003 15:18:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CKWoZ10768 for ssm-archive@odin.ietf.org; Wed, 12 Mar 2003 15:32:50 -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 h2CKWoO10765 for ; Wed, 12 Mar 2003 15:32:50 -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 PAA20434 for ; Wed, 12 Mar 2003 15:18:13 -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 h2CKWVO10745; Wed, 12 Mar 2003 15:32:31 -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 h2CKVdO10625 for ; Wed, 12 Mar 2003 15:31:39 -0500 Received: from sophia.inria.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20388 for ; Wed, 12 Mar 2003 15:17:01 -0500 (EST) Received: from localhost (odie.inria.fr [138.96.88.52]) by sophia.inria.fr (8.12.8/8.12.5) with ESMTP id h2CKCke8012211; Wed, 12 Mar 2003 21:12:46 +0100 X-Authentication-Warning: sophia.inria.fr: Host odie.inria.fr [138.96.88.52] claimed to be localhost Date: Wed, 12 Mar 2003 21:12:45 +0100 (MET) Message-Id: <20030312.211245.31557846.Hitoshi.Asaeda@sophia.inria.fr> To: pekkas@netcore.fi Cc: holbrook@cisco.com, bkhabs@nc.rr.com, ssm@ietf.org Subject: Re: [ssm] what to say about scoping for v6 From: Hitoshi Asaeda In-Reply-To: References: <20030312180804.1788F10B7A7@holbrook-laptop.cisco.com> X-Mailer: Mew version 2.2rc1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Note that when forwarding or processing SSM, the scope of both S and G > may have to be considered [SCOPED-ARCH]; in particular, if the unicast > scope of S is smaller than respective multicast scope of G, the packets > might end up forwarded outside of the scope of S. Therefore, limited > scopes should be avoided and must not be used as a security mechanism. Although I didn't completely follow every mail of this subject, for me, it is simple that; an end-node should not request any (S,G) join whose unicast address scope and multicast address scope are not same. If the kernel receives such request, it should discard it. Likewise, if a router receives such join request, it should also discard it. Why isn't it reasonable? -- Hitoshi Asaeda _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Wed Mar 12 15:21:21 2003 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 PAA20605 for ; Wed, 12 Mar 2003 15:21:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CKZRS10975 for ssm-archive@odin.ietf.org; Wed, 12 Mar 2003 15:35:27 -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 h2CKZRO10972 for ; Wed, 12 Mar 2003 15:35:27 -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 PAA20550 for ; Wed, 12 Mar 2003 15:20:49 -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 h2CKZ2O10952; Wed, 12 Mar 2003 15:35:02 -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 h2CKYfO10925 for ; Wed, 12 Mar 2003 15:34:41 -0500 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20517 for ; Wed, 12 Mar 2003 15:20:03 -0500 (EST) Received: from holbrook-laptop.cisco.com (sjc-vpn1-426.cisco.com [10.21.97.170]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2CKM5hs018554; Wed, 12 Mar 2003 12:22:11 -0800 (PST) Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id 6AA9510B7A7; Wed, 12 Mar 2003 12:17:41 -0800 (PST) From: Hugh Holbrook To: Pekka Savola Cc: Hugh Holbrook , Brian Haberman , In-reply-to: Subject: Re: Re: Re: [ssm] what to say about scoping for v6 [was ...last call...] Reply-To: holbrook@cisco.com Message-Id: <20030312201741.6AA9510B7A7@holbrook-laptop.cisco.com> Date: Wed, 12 Mar 2003 12:17:41 -0800 (PST) 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: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , > Date: Wed, 12 Mar 2003 21:41:27 +0200 (EET) > From: Pekka Savola > Cc: Brian Haberman , > > On Wed, 12 Mar 2003, Hugh Holbrook wrote: > > > One should note that the use of IPv6 scoped addresses either in S or G may > > > cause significant complexities, for example regarding mismatching scopes > > > between S and G or regarding forwarding decisions for a scoped (S,G). > > > The implications of scoped addresses are described in other documents > > > [REF:SCOPED-ARCH] > > > > Isn't the scoping behavior simply that the most restrictive (smallest) > > scope applies. A packet is forwarded neither across a source-scope > > boundary nor across a destination-scope boundary. Unless I'm missing > > something, this actually sounds rather uncomplicated to me. Is there > > something that makes this tricky? > > At the moment, in practise (=implementation), everything related to > scoping is *undefined*, it seems to me. > > How your SSM-enabled router will/would react now, or in 1-2 years is a > complete question mark. Perhaps I'm not creative enough, but I can't imagine any implementation of scoped addresses that would not apply scope limits to both the source and destination. > > Is there something about this that makes it a Security Considerations > > issue? > > Yes, but only slightly: if people use e.g. site-local addresses as a > security measure, and use SSM with like (, global-scope-SSM) > -- for whatever reason, e.g. the use of the same application (and > subsequent G) both site-locally and globally, the forwarding of such > multicasts might *NOT* be limited to your site-local S scope. This is an > uncertainty as the implementation is unclear. I don't dispute that implementations are not complete, but I can't see how the IETF could endorse a scheme in which a join for a site-local address S would allowed to be routed through a scoped boundary for S. S refers to two totally diferent hosts on the two sides of the scope boundary, so it's like sending the join to the wrong host. In fact, I would be ok with putting in text saying that for SSM joins and data, the scope boundaries MUST be applied to the source address in addition to the destination address. > On the hindsight, the text I proposed above seems better fit to some other > section, and something different might be more applicable to security > considerations, like: > > Note that when forwarding or processing SSM, the scope of both S and G > may have to be considered [SCOPED-ARCH]; in particular, if the unicast > scope of S is smaller than respective multicast scope of G, the packets > might end up forwarded outside of the scope of S. Therefore, limited I would prefer not to say this because I think it is not likely to ever be allowed. I'd be happy saying just that "scopes should not be used as a security mechanism..." and leaving it at that. I think it's overkill to say that limited scope addresses must be avoided with SSM, because I think they work fine as long as boundaries are applied to the source as well. -Hugh > scopes should be avoided and must not be used as a security mechanism. > > .. I wonder if that's any better .. > > -- > 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 From mailnull@www1.ietf.org Wed Mar 12 15:29:23 2003 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 PAA20873 for ; Wed, 12 Mar 2003 15:29:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CKhTT12238 for ssm-archive@odin.ietf.org; Wed, 12 Mar 2003 15:43:29 -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 h2CKhTO12235 for ; Wed, 12 Mar 2003 15:43:29 -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 PAA20841 for ; Wed, 12 Mar 2003 15:28:52 -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 h2CKhBO12199; Wed, 12 Mar 2003 15:43:11 -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 h2CKglO12120 for ; Wed, 12 Mar 2003 15:42:47 -0500 Received: from netcore.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20785 for ; Wed, 12 Mar 2003 15:28:08 -0500 (EST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2CKSX416135; Wed, 12 Mar 2003 22:28:33 +0200 Date: Wed, 12 Mar 2003 22:28:33 +0200 (EET) From: Pekka Savola To: Hitoshi Asaeda cc: holbrook@cisco.com, , Subject: Re: [ssm] what to say about scoping for v6 In-Reply-To: <20030312.211245.31557846.Hitoshi.Asaeda@sophia.inria.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , On Wed, 12 Mar 2003, Hitoshi Asaeda wrote: > > Note that when forwarding or processing SSM, the scope of both S and G > > may have to be considered [SCOPED-ARCH]; in particular, if the unicast > > scope of S is smaller than respective multicast scope of G, the packets > > might end up forwarded outside of the scope of S. Therefore, limited > > scopes should be avoided and must not be used as a security mechanism. > > Although I didn't completely follow every mail of this subject, for > me, it is simple that; > > an end-node should not request any (S,G) join whose unicast > address scope and multicast address scope are not same. If the > kernel receives such request, it should discard it. Likewise, > if a router receives such join request, it should also discard > it. > > Why isn't it reasonable? What corresponds to organization-local multicast scope? (seriously, one of the points in this doc was trying to avoid normative language on unicast scoping issues, and leave it to the scoped address architecture.) -- 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 From mailnull@www1.ietf.org Wed Mar 12 15:53:19 2003 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 PAA21786 for ; Wed, 12 Mar 2003 15:53:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CL7QS14124 for ssm-archive@odin.ietf.org; Wed, 12 Mar 2003 16:07:26 -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 h2CL7QO14113 for ; Wed, 12 Mar 2003 16:07:26 -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 PAA21748 for ; Wed, 12 Mar 2003 15:52:48 -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 h2CL78O13683; Wed, 12 Mar 2003 16:07:08 -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 h2CL6VO13425 for ; Wed, 12 Mar 2003 16:06:31 -0500 Received: from ms-smtp-03.southeast.rr.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21712 for ; Wed, 12 Mar 2003 15:51:52 -0500 (EST) Received: from mail3.nc.rr.com (fe3 [24.93.67.50]) by ms-smtp-03.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h2CKpRm0002724; Wed, 12 Mar 2003 15:51:27 -0500 (EST) Received: from nc.rr.com ([63.109.132.2]) by mail3.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Wed, 12 Mar 2003 15:50:25 -0500 Message-ID: <3E6F9E10.3010907@nc.rr.com> Date: Wed, 12 Mar 2003 15:52:32 -0500 From: Brian Haberman Organization: No Organization Here User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: holbrook@cisco.com CC: Pekka Savola , ssm@ietf.org Subject: Re: [ssm] what to say about scoping for v6 [was ...last call...] References: <20030312201741.6AA9510B7A7@holbrook-laptop.cisco.com> In-Reply-To: <20030312201741.6AA9510B7A7@holbrook-laptop.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hugh Holbrook wrote: >>Date: Wed, 12 Mar 2003 21:41:27 +0200 (EET) >>From: Pekka Savola >>Cc: Brian Haberman , >> >>On Wed, 12 Mar 2003, Hugh Holbrook wrote: >> >>>>One should note that the use of IPv6 scoped addresses either in S or G may >>>>cause significant complexities, for example regarding mismatching scopes >>>>between S and G or regarding forwarding decisions for a scoped (S,G). >>>>The implications of scoped addresses are described in other documents >>>>[REF:SCOPED-ARCH] >>> >>>Isn't the scoping behavior simply that the most restrictive (smallest) >>>scope applies. A packet is forwarded neither across a source-scope >>>boundary nor across a destination-scope boundary. Unless I'm missing >>>something, this actually sounds rather uncomplicated to me. Is there >>>something that makes this tricky? >> >>At the moment, in practise (=implementation), everything related to >>scoping is *undefined*, it seems to me. >> >>How your SSM-enabled router will/would react now, or in 1-2 years is a >>complete question mark. > > > Perhaps I'm not creative enough, but I can't imagine any > implementation of scoped addresses that would not apply scope limits > to both the source and destination. > Neither can I. In fact, that is one of the items in the scoped addressing architecture that everyone agrees on. Both S & G have to be checked when a scoped boundary is encountered. > >>>Is there something about this that makes it a Security Considerations >>>issue? >> >>Yes, but only slightly: if people use e.g. site-local addresses as a >>security measure, and use SSM with like (, global-scope-SSM) >>-- for whatever reason, e.g. the use of the same application (and >>subsequent G) both site-locally and globally, the forwarding of such >>multicasts might *NOT* be limited to your site-local S scope. This is an >>uncertainty as the implementation is unclear. > > > I don't dispute that implementations are not complete, but I can't see > how the IETF could endorse a scheme in which a join for a site-local > address S would allowed to be routed through a scoped boundary for S. > S refers to two totally diferent hosts on the two sides of the scope > boundary, so it's like sending the join to the wrong host. > I agree that would be dangerous. The situation is a little muddled though, in that the PIM protocol would have to do checking of S & G within the PIM Join/Prune messages. Of course, the actual routing protocols will have to do the same too. So, it seems that the scenario is already covered and is much larger than SSM. > In fact, I would be ok with putting in text saying that for SSM joins > and data, the scope boundaries MUST be applied to the source address > in addition to the destination address. > That is what the scoped addressing architecture already says. Do we need to repeat it? > >>On the hindsight, the text I proposed above seems better fit to some other >>section, and something different might be more applicable to security >>considerations, like: >> >> Note that when forwarding or processing SSM, the scope of both S and G >> may have to be considered [SCOPED-ARCH]; in particular, if the unicast >> scope of S is smaller than respective multicast scope of G, the packets >> might end up forwarded outside of the scope of S. Therefore, limited > > > I would prefer not to say this because I think it is not likely to > ever be allowed. I'd be happy saying just that "scopes should not be > used as a security mechanism..." and leaving it at that. I think > it's overkill to say that limited scope addresses must be avoided with > SSM, because I think they work fine as long as boundaries are applied > to the source as well. > I agree with Hugh on this point. Brian _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Wed Mar 12 16:25:21 2003 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 QAA23664 for ; Wed, 12 Mar 2003 16:25:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CLdRq17311 for ssm-archive@odin.ietf.org; Wed, 12 Mar 2003 16:39:27 -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 h2CLdRO17308 for ; Wed, 12 Mar 2003 16:39:27 -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 QAA23632 for ; Wed, 12 Mar 2003 16:24:50 -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 h2CLdGO17291; Wed, 12 Mar 2003 16:39:16 -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 h2CLc8O17174 for ; Wed, 12 Mar 2003 16:38:08 -0500 Received: from netcore.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23528 for ; Wed, 12 Mar 2003 16:23:28 -0500 (EST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2CLNQQ16561; Wed, 12 Mar 2003 23:23:26 +0200 Date: Wed, 12 Mar 2003 23:23:26 +0200 (EET) From: Pekka Savola To: Brian Haberman cc: holbrook@cisco.com, Subject: Re: [ssm] what to say about scoping for v6 [was ...last call...] In-Reply-To: <3E6F9E10.3010907@nc.rr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , On Wed, 12 Mar 2003, Brian Haberman wrote: > >>How your SSM-enabled router will/would react now, or in 1-2 years is a > >>complete question mark. > > > > > > Perhaps I'm not creative enough, but I can't imagine any > > implementation of scoped addresses that would not apply scope limits > > to both the source and destination. Different unicast and multicast codepaths? Or.. > Neither can I. In fact, that is one of the items in the scoped > addressing architecture that everyone agrees on. Both S & G have > to be checked when a scoped boundary is encountered. .. not *implementing* scoped address architecture at all while supporting SSM? I certainly don't want to require scoped addrarch for SSM implementation; moreover, I don't want to give users the expectation that using e.g. (fec0::1, ff3e::1) would just somehow magically get discarded somewhere near the manually configured site border by SSM routers. I see a lot of cases. Most IPv6 routers today, as far as I've looked, forward site-local source addresses quite nicely anywhere I want.. > > In fact, I would be ok with putting in text saying that for SSM joins > > and data, the scope boundaries MUST be applied to the source address > > in addition to the destination address. > > > > That is what the scoped addressing architecture already says. > Do we need to repeat it? I'd like a mention of why it is a problem better, and leaving the actual behaviour undefined or TBD in scoped addrarch. > >> Note that when forwarding or processing SSM, the scope of both S and G > >> may have to be considered [SCOPED-ARCH]; in particular, if the unicast > >> scope of S is smaller than respective multicast scope of G, the packets > >> might end up forwarded outside of the scope of S. Therefore, limited > > > > > > I would prefer not to say this because I think it is not likely to > > ever be allowed. I agree here: it's not likely be allowed, but the *security considerations* part of it is that it *does* happen when/if scoped addrarch hasn't been implemented in the designated routers etc. -- this was a balance between specification status and operational reality. > > I'd be happy saying just that "scopes should not be > > used as a security mechanism..." and leaving it at that. If a variation of that where it's explicit that it applies to the source address is added, that's ~ok. > > I think > > it's overkill to say that limited scope addresses must be avoided with > > SSM, because I think they work fine as long as boundaries are applied > > to the source as well. (For what it's worth, I was referring to unicast S scoped *only*, if it makes any difference.) The point is that I'm having some doubts whether boundaries *are* actually applied to the source.. -- 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 From mailnull@www1.ietf.org Wed Mar 12 18:15:48 2003 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 SAA29085 for ; Wed, 12 Mar 2003 18:15:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CNTvc25007 for ssm-archive@odin.ietf.org; Wed, 12 Mar 2003 18:29: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 h2CNTuO25004 for ; Wed, 12 Mar 2003 18:29: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 SAA28993 for ; Wed, 12 Mar 2003 18:15:16 -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 h2CNTZO24961; Wed, 12 Mar 2003 18:29:35 -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 h2CNITO24471 for ; Wed, 12 Mar 2003 18:18:29 -0500 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27575 for ; Wed, 12 Mar 2003 18:03:48 -0500 (EST) Received: from holbrook-laptop.cisco.com (sjc-vpn1-426.cisco.com [10.21.97.170]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2CN5shs007577; Wed, 12 Mar 2003 15:05:55 -0800 (PST) Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id 0B9C910B7A7; Wed, 12 Mar 2003 15:01:30 -0800 (PST) From: Hugh Holbrook To: Pekka Savola Cc: Brian Haberman , holbrook@cisco.com, In-reply-to: Subject: Re: Re: [ssm] what to say about scoping for v6 [was ...last call...] Reply-To: holbrook@cisco.com Message-Id: <20030312230130.0B9C910B7A7@holbrook-laptop.cisco.com> Date: Wed, 12 Mar 2003 15:01:30 -0800 (PST) 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: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , Thanks again for your comments, Pekka. It sounds like you're primarily concerned with the scenario where some router either does not implement scoping as per [SCOPED-ARCH], or only implements part of it (either for unicast or for dest addrs). I see how such an implementation can violate scoped boundaries, but I'm having a hard time coming up with any text that is not a tautology. I keep getting writing non-informative sentences like "if source address scoping is not implemented on domain border routers, then source address scopes will not be enforced for SSM traffic." Here's the best I've been able to come up with so far. Does this capture you're concerns. Neither source nor destination address scoping should not be used as a security measure. In some (many?) currently-deployed IPv6 routers (that do not conform to [SCOPED-ARCH]), scope boundaries are not applied to the source address. Such a router may incorrectly forward an SSM channel (S,G) through a scope boundary for S. (Of course this is less likely to happen than one might think at first because, when forwarding a join, a router typically does a destination lookup on S to figure out the next hop....) This is slightly less tautological, I guess. I'd welcome improvements or any alternative text, though. -Hugh ---------------------------------------------------------------- > Date: Wed, 12 Mar 2003 23:23:26 +0200 (EET) > From: Pekka Savola > Cc: holbrook@cisco.com, > > On Wed, 12 Mar 2003, Brian Haberman wrote: > > >>How your SSM-enabled router will/would react now, or in 1-2 years is a > > >>complete question mark. > > > > > > > > > Perhaps I'm not creative enough, but I can't imagine any > > > implementation of scoped addresses that would not apply scope limits > > > to both the source and destination. > > Different unicast and multicast codepaths? Or.. > > > Neither can I. In fact, that is one of the items in the scoped > > addressing architecture that everyone agrees on. Both S & G have > > to be checked when a scoped boundary is encountered. > > .. not *implementing* scoped address architecture at all while supporting > SSM? I guess I don't consider this "an implementation of scoped addressing." > I certainly don't want to require scoped addrarch for SSM implementation; > moreover, I don't want to give users the expectation that using e.g. > (fec0::1, ff3e::1) would just somehow magically get discarded somewhere > near the manually configured site border by SSM routers. > > I see a lot of cases. Most IPv6 routers today, as far as I've looked, > forward site-local source addresses quite nicely anywhere I want.. > > > > In fact, I would be ok with putting in text saying that for SSM joins > > > and data, the scope boundaries MUST be applied to the source address > > > in addition to the destination address. > > > > > > > That is what the scoped addressing architecture already says. > > Do we need to repeat it? > > I'd like a mention of why it is a problem better, and leaving the actual > behaviour undefined or TBD in scoped addrarch. > > > >> Note that when forwarding or processing SSM, the scope of both S and G > > >> may have to be considered [SCOPED-ARCH]; in particular, if the unicast > > >> scope of S is smaller than respective multicast scope of G, the packets > > >> might end up forwarded outside of the scope of S. Therefore, limited > > > > > > > > > I would prefer not to say this because I think it is not likely to > > > ever be allowed. > > I agree here: it's not likely be allowed, but the *security > considerations* part of it is that it *does* happen when/if scoped > addrarch hasn't been implemented in the designated routers etc. -- this > was a balance between specification status and operational reality. > > > > I'd be happy saying just that "scopes should not be > > > used as a security mechanism..." and leaving it at that. > > If a variation of that where it's explicit that it applies to the source > address is added, that's ~ok. > > > > I think > > > it's overkill to say that limited scope addresses must be avoided with > > > SSM, because I think they work fine as long as boundaries are applied > > > to the source as well. > > (For what it's worth, I was referring to unicast S scoped *only*, if it > makes any difference.) > > The point is that I'm having some doubts whether boundaries *are* actually > applied to the source.. > > -- > 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 From mailnull@www1.ietf.org Thu Mar 13 13:58:51 2003 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 NAA12843 for ; Thu, 13 Mar 2003 13:58:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DJDOU21832 for ssm-archive@odin.ietf.org; Thu, 13 Mar 2003 14:13:24 -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 h2DJDOO21829 for ; Thu, 13 Mar 2003 14:13:24 -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 NAA12819 for ; Thu, 13 Mar 2003 13:58:20 -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 h2DJCgO21781; Thu, 13 Mar 2003 14:12:42 -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 h2DJBLO21679 for ; Thu, 13 Mar 2003 14:11:21 -0500 Received: from netcore.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12753 for ; Thu, 13 Mar 2003 13:56:17 -0500 (EST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2DIvD123975; Thu, 13 Mar 2003 20:57:13 +0200 Date: Thu, 13 Mar 2003 20:57:13 +0200 (EET) From: Pekka Savola To: Hugh Holbrook cc: Brian Haberman , Subject: Re: Re: [ssm] what to say about scoping for v6 [was ...last call...] In-Reply-To: <20030312230130.0B9C910B7A7@holbrook-laptop.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , On Wed, 12 Mar 2003, Hugh Holbrook wrote: > Neither source nor destination address scoping should not be used as > a security measure. In some (many?) currently-deployed IPv6 routers (that > do not conform to [SCOPED-ARCH]), scope boundaries are not applied > to the source address. Such a router may incorrectly forward an > SSM channel (S,G) through a scope boundary for S. > > (Of course this is less likely to happen than one might think at first > because, when forwarding a join, a router typically does a destination > lookup on S to figure out the next hop....) > > This is slightly less tautological, I guess. I'd welcome improvements > or any alternative text, though. This is OK by me, but I might propose a slight modification, s/are not applied/are not always applied/ (ie. it's typical to filter out link-locals because they're "easy" but it's not an all or nothing issue). -- 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 From mailnull@www1.ietf.org Mon Mar 17 17:49:10 2003 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 RAA05549 for ; Mon, 17 Mar 2003 17:49:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2HN5js11320 for ssm-archive@odin.ietf.org; Mon, 17 Mar 2003 18:05:45 -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 h2HN5jO11317 for ; Mon, 17 Mar 2003 18:05:45 -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 RAA05534 for ; Mon, 17 Mar 2003 17:48:39 -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 h2HN3dO11120; Mon, 17 Mar 2003 18:03:39 -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 h2HN0EO10859 for ; Mon, 17 Mar 2003 18:00:15 -0500 Received: from raven.uoregon.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05262 for ; Mon, 17 Mar 2003 17:43:09 -0500 (EST) Received: from raven.uoregon.edu (localhost [127.0.0.1]) by raven.uoregon.edu (8.12.3/8.12.3/Debian-5) with ESMTP id h2HMjLTq009848; Mon, 17 Mar 2003 14:45:21 -0800 Received: from localhost (hak@localhost) by raven.uoregon.edu (8.12.3/8.12.3/Debian-5) with ESMTP id h2HMjL1p009845; Mon, 17 Mar 2003 14:45:21 -0800 X-Authentication-Warning: raven.uoregon.edu: hak owned process doing -bs Date: Mon, 17 Mar 2003 14:45:21 -0800 (PST) From: Hans Kuhn To: ssm@ietf.org cc: multicast@lists.uoregon.edu, Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [ssm] SSM sources for IETF 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: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , *, After the rousing discussion in mboned about SSM vs. ASM, I've decided to mirror the IETF multicast sessions to SSM. The addresses are listed below, and Joel's putting SDP files on http://videolab.uoregon.edu/ in a moment. Hans SSM, its not just a good idea -- it's the law. -- Hans Kuhn, Academic User Services office (541) 346-1714 University of Oregon, 237 CC fax (541) 346-4397 Key fingerprint = 1E BC 32 03 AC E9 82 6C 44 4A CD 63 BB 2D 51 89 Channel One ---------------- H.261 source - 128.223.162.20 video - 233.55.123.2/61010 audio - 233.55.123.2/21010 MPEG-1 source - 128.223.162.20 video - 233.55.123.4/61030 audio - 233.55.123.4/21030 Channel Two --------------- H.261 source - 128.223.162.20 video - 233.55.123.3/61020 audio - 233.55.123.3/21020 MPEG-1 source - 128.223.162.20 video - 233.55.123.5/61040 audio - 233.55.123.5/21040 -- Hans Kuhn, Academic User Services office (541) 346-1714 University of Oregon, 237 CC fax (541) 346-4397 Key fingerprint = 1E BC 32 03 AC E9 82 6C 44 4A CD 63 BB 2D 51 89 _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm