From ssm-interest-owner@cisco.com Tue Dec 3 17:25:45 2002 Received: from domohead.cisco.com (domohead.cisco.com [161.44.11.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22521 for ; Tue, 3 Dec 2002 17:25:44 -0500 (EST) Received: (from daemon@localhost) by domohead.cisco.com (8.12.2/8.12.2) id gB3Kx13g011489; Tue, 3 Dec 2002 15:59:01 -0500 (EST) Date: Tue, 3 Dec 2002 15:59:01 -0500 (EST) Message-Id: <200212032059.gB3Kx13g011489@domohead.cisco.com> To: ssm-interest@cisco.com From: holbrook@cisco.com Subject: test of ssm-interest list, [sorry, pls ignore] -Hugh From ssm-interest-owner@cisco.com Fri Dec 13 17:57:53 2002 Received: from domohead.cisco.com (domohead.cisco.com [161.44.11.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08221 for ; Fri, 13 Dec 2002 17:57:53 -0500 (EST) Received: (from daemon@localhost) by domohead.cisco.com (8.12.2/8.12.2) id gBDLLqeN019063; Fri, 13 Dec 2002 16:21:52 -0500 (EST) Date: Fri, 13 Dec 2002 16:21:52 -0500 (EST) Message-Id: <200212132121.gBDLLqeN019063@domohead.cisco.com> To: ssm-interest@cisco.com From: holbrook@cisco.com Subject: Re [ correcting a typo in the mailing address, cicso->cisco.] My responses to Pavlin's IPv6-related comments on the ssm-arch draft are inline. cc'ing Dave and Brian for confirmation. Pavlin wrote: > * In Section 1, the draft says that FF3x::/32 is reserved for SSM, > and cites reference [IPV6-UBM] for that (RFC 3306). However, one > of the examples in Section 7 in RFC 3306 is: > "SSM - All IPv6 SSM multicast addresses will have the format > FF3x::/96" > which I find confusing. My confusion is primarily based on the > potential ambiguity of the "x" in the above notation: is this > always the 4-bit address scope, or sometimes it could be > everything up to the 96-th bit? My initial understanding was that > "x" is always the 4-bit address scope, but then Section 3 of RFC > 3307 mentions FF3x::/96 as the SSM address range. > Maybe the draft should clarify the IPv6 SSM address range with > some specific examples that also clarify the meaning of "x". "x" is only supposed to be one of the valid 4-bit scope values, as stated in RFC3306. I think the problem is that RFC3306 is confusing because it says in Section 6: > 6. Source-Specific Multicast Addresses > > The unicast prefix-based IPv6 multicast address format supports > Source-specific multicast addresses, as defined by [SSM ARCH]. To > accomplish this, a node MUST: > > o Set P = 1. > o Set plen = 0. > o Set network prefix = 0. > > These settings create an SSM range of FF3x::/32 (where 'x' is any > valid scope value). But by setting plen and network prefix to zero, you create a range of FF3x::/96, not FF3x::/32. My understanding of RFC3306, from discussions with the authors, was that the intention of RFC3306 is to reserve all of FF3x::/32 (whenever P=1 and T=1 and plen=0) for SSM addresses. Although this is not really what the draft says. However, RFC3307 specifies that all current allocations of v6 SSM addresses must also set network prefix (bits 32 to 96) to zero as well. I think the idea was that in the future there may be some reason to allocate from the broader FF3x::/32 space. Therefore, applications must treat FF3x::/32 as an SSM address, although currently network prefix is always zero. Dave or Brian, could you comment on whether I've got this straight. Assuming I've got this right, I'd propose to add some text basically stating what I said in the paragraph above to this document. This is not the first time this has come up, and my feeling is that this needs to be clarified. Anyone else have comments on this point? > * Use consistent notation for the IPv6 hex addresses. E.g., the > draft has addresses like FF3x::7fff:ffff which mixes capital with > small letters. Done. > * In the examples in Section 2, is address FF23::1234 a valid > SSM destination address? I.e., if the P bit is set, then the T > bit MUST also be set!? (according to Section 4 in RFC 3306). Oops. This should be FF33::1234. See next point. > * In Section 4.3, the address range in > "... IPv6 SSM address range FF2x::" > is confusing: is this FF2x::/32 or FF2x::/96 or something else? > Also, earlier you say that the IPv6 SSM address range is > FF3x::/32, so FF2x:: does not fail within the "SSM address > range", unless "x" in FF2x:: does not mean "scope identifier" > only. > Similar question about the mention of FF2x:: in Section 9. > Further, the above comment about the P and T bits from RFC 3306 > applies for FF2x:: as well. On both of these above points, you're right. FF2* should be replaced universally with FF3*, both in the examples and in the text. This text was based on an early draft of RFC3306 where the fact that the T bit had to be set was not clear, and it slipped by in the last round of revisions. > * When a host allocates locally an IPv6 SSM destination address, > should the chosen destination address try to include the network > prefix as well inside (similar to the unicast-prefix-based IPv6 > mcast addresses described in RFC 3306)? E.g., in Section 4.3 the > recommendation is that "... the randomization should apply to the > lower 32 bits of the address", but it doesn't say about the upper > bits (between the 32nd and 96th bits). Bits 32 to 96 should be zero (because the PLEN needs to be zero for an SSM address, as stated in Section 6 of RFC3306, modulo the comments above. I didn't want to restate that here. I think if we clarify the issue you raised above, we won't need to say anything about this. Thanks for the comments. I'll definitely submit a revised draft as a result. -Hugh > Thanks, > Pavlin > From ssm-interest-owner@cisco.com Fri Dec 13 22:13:40 2002 Received: from domohead.cisco.com (domohead.cisco.com [161.44.11.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14646 for ; Fri, 13 Dec 2002 22:13:40 -0500 (EST) Received: (from daemon@localhost) by domohead.cisco.com (8.12.2/8.12.2) id gBE1ok5G003660; Fri, 13 Dec 2002 20:50:46 -0500 (EST) Date: Fri, 13 Dec 2002 20:50:46 -0500 (EST) Message-Id: <200212140150.gBE1ok5G003660@domohead.cisco.com> To: ssm-interest@cisco.com From: bkhabs@nc.rr.com Subject: ReMIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Comments in-line... Hugh Holbrook wrote: > My responses to Pavlin's IPv6-related comments on the ssm-arch draft > are inline. cc'ing Dave and Brian for confirmation. > > Pavlin wrote: > >> * In Section 1, the draft says that FF3x::/32 is reserved for SSM, >> and cites reference [IPV6-UBM] for that (RFC 3306). However, one >> of the examples in Section 7 in RFC 3306 is: >> "SSM - All IPv6 SSM multicast addresses will have the format >> FF3x::/96" >> which I find confusing. My confusion is primarily based on the >> potential ambiguity of the "x" in the above notation: is this >> always the 4-bit address scope, or sometimes it could be >> everything up to the 96-th bit? My initial understanding was that >> "x" is always the 4-bit address scope, but then Section 3 of RFC >> 3307 mentions FF3x::/96 as the SSM address range. >> Maybe the draft should clarify the IPv6 SSM address range with >> some specific examples that also clarify the meaning of "x". > x is the 4-bit scope id. Since it is part of the prefix, it is hard to represent its concrete meaning without text. The base IPv6 address architecture uses the same notation. > > "x" is only supposed to be one of the valid 4-bit scope values, as > stated in RFC3306. I think the problem is that RFC3306 is confusing > because it says in Section 6: > > >> 6. Source-Specific Multicast Addresses >> >> The unicast prefix-based IPv6 multicast address format supports >> Source-specific multicast addresses, as defined by [SSM ARCH]. To >> accomplish this, a node MUST: >> >> o Set P = 1. >> o Set plen = 0. >> o Set network prefix = 0. >> >> These settings create an SSM range of FF3x::/32 (where 'x' is any >> valid scope value). > > > But by setting plen and network prefix to zero, you create a range of > FF3x::/96, not FF3x::/32. > > My understanding of RFC3306, from discussions with the authors, was > that the intention of RFC3306 is to reserve all of FF3x::/32 (whenever > P=1 and T=1 and plen=0) for SSM addresses. Although this is not > really what the draft says. However, RFC3307 specifies that all > current allocations of v6 SSM addresses must also set network prefix > (bits 32 to 96) to zero as well. I think the idea was that in the > future there may be some reason to allocate from the broader FF3x::/32 > space. Therefore, applications must treat FF3x::/32 as an SSM > address, although currently network prefix is always zero. > > Dave or Brian, could you comment on whether I've got this straight. Correct. We reserved the /32 but all allocations will come out of the /96. That will allow us to grow the 32-bit group id if we come up with a new mapping strategy for IP->MAC address mapping. > > Assuming I've got this right, I'd propose to add some text basically > stating what I said in the paragraph above to this document. This is > not the first time this has come up, and my feeling is that this needs > to be clarified. Anyone else have comments on this point? > This doc is as good a place as any. > >> * Use consistent notation for the IPv6 hex addresses. E.g., the >> draft has addresses like FF3x::7fff:ffff which mixes capital with >> small letters. > > > Done. > > >> * In the examples in Section 2, is address FF23::1234 a valid >> SSM destination address? I.e., if the P bit is set, then the T >> bit MUST also be set!? (according to Section 4 in RFC 3306). > > > Oops. This should be FF33::1234. See next point. > > >> * In Section 4.3, the address range in >> "... IPv6 SSM address range FF2x::" >> is confusing: is this FF2x::/32 or FF2x::/96 or something else? >> Also, earlier you say that the IPv6 SSM address range is >> FF3x::/32, so FF2x:: does not fail within the "SSM address >> range", unless "x" in FF2x:: does not mean "scope identifier" >> only. >> Similar question about the mention of FF2x:: in Section 9. >> Further, the above comment about the P and T bits from RFC 3306 >> applies for FF2x:: as well. > > > On both of these above points, you're right. FF2* should be replaced > universally with FF3*, both in the examples and in the text. This > text was based on an early draft of RFC3306 where the fact that the T > bit had to be set was not clear, and it slipped by in the last round > of revisions. > > >> * When a host allocates locally an IPv6 SSM destination address, >> should the chosen destination address try to include the network >> prefix as well inside (similar to the unicast-prefix-based IPv6 >> mcast addresses described in RFC 3306)? E.g., in Section 4.3 the >> recommendation is that "... the randomization should apply to the >> lower 32 bits of the address", but it doesn't say about the upper >> bits (between the 32nd and 96th bits). > > > Bits 32 to 96 should be zero (because the PLEN needs to be zero for an > SSM address, as stated in Section 6 of RFC3306, modulo the comments > above. I didn't want to restate that here. I think if we clarify the > issue you raised above, we won't need to say anything about this. Agreed. Without having PLEN set it is difficult to parse out the correct prefix. Brian From ssm-interest-owner@cisco.com Tue Dec 17 05:57:56 2002 Received: from domohead.cisco.com (domohead.cisco.com [161.44.11.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11268 for ; Tue, 17 Dec 2002 05:57:56 -0500 (EST) Received: (from daemon@localhost) by domohead.cisco.com (8.12.2/8.12.2) id gBH9ZG4d003943; Tue, 17 Dec 2002 04:35:16 -0500 (EST) Date: Tue, 17 Dec 2002 04:35:16 -0500 (EST) Message-Id: <200212170935.gBH9ZG4d003943@domohead.cisco.com> To: ssm-interest@cisco.com From: pekkas@netcore.fi Subject: a few ssm comments MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, I quickly read the two SSM drafts properly for the first time. A few minor comments. ssm-overview-04: Thus the complexity of the multicast routing infrastructure for SSM is low, making it viable for immediate deployment. Note that MBGP is still required for distribution of multicast reachability information. ==> I would dispute the last sentence a bit. It's not really necessary to use MBGP at all if you're using PIM. 6.3. SSM-Aware Applications -- An application that wants to received an SSM session must first ==> s/received/receive/ ssm-arch-01: ==> In many places, there if a referrence to "IPv6 SSM address range FF2x::". According to e.g. RFC3306, this perhaps should be FF3x:: -- or a lot of clarification is required! No globally agreed-upon administratively-scoped address range [ADMIN- SCOPE] is currently defined for source-specific multicast. Note that there is no possibility of address conflict between hosts in different administrative domains (or between two hosts of any kind). Administrative scoping of SSM addresses can be implemented within an administrative domain by filtering at domain boundary routers. ==> this seems to be an obvious oversight. Administrative scoping for SSM is very much existant for IPv6. Source Routing [RFC791] (both Loose and Strict) in combination with source address spoofing may be used to allow an impostor of the true channel source to inject packets onto an SSM channel. An SSM router MUST have a configuration option to disable source routing to an SSM destination addresses, and the default value SHOULD be to disable Source Routing to an SSM destination address. Anti-source spoofing mechanisms like source address filtering at the edges of the network are also strongly encouraged. ==> this seems overly specificative to me. IMO, if the default is to disable source routing to multicast addresses, I believe there is no need for a knob. In any case, this is a bit like an implementation issue. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From ssm-interest-owner@cisco.com Tue Dec 17 13:33:37 2002 Received: from domohead.cisco.com (domohead.cisco.com [161.44.11.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19764 for ; Tue, 17 Dec 2002 13:33:37 -0500 (EST) Received: (from daemon@localhost) by domohead.cisco.com (8.12.2/8.12.2) id gBHH0QEj010406; Tue, 17 Dec 2002 12:00:26 -0500 (EST) Date: Tue, 17 Dec 2002 12:00:26 -0500 (EST) Message-Id: <200212171700.gBHH0QEj010406@domohead.cisco.com> To: ssm-interest@cisco.com From: bkhabs@nc.rr.com Subject: ReMIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Tom Pusateri wrote: > In message <200212170935.gBH9ZG4d003943@domohead.cisco.com> you write: > >>Hello, >> >>I quickly read the two SSM drafts properly for the first time. A few >>minor comments. >> >>ssm-overview-04: >> >> Thus >> the complexity of the multicast routing infrastructure for SSM is >> low, making it viable for immediate deployment. Note that MBGP is >> still required for distribution of multicast reachability >> information. >> >>==> I would dispute the last sentence a bit. It's not really necessary to >>use MBGP at all if you're using PIM. > > > Agreed. I think the point is that if you want others to know about your > SSM sources, you better advertise your prefix in MBGP or noone will know > how to get to you. > > >>==> In many places, there if a referrence to "IPv6 SSM address range >>FF2x::". According to e.g. RFC3306, this perhaps should be FF3x:: -- or a >>lot of clarification is required! > It should be FF3x::. This was noted in the auth48 review and is being corrected. > > RFC 3306 also says that 'x' can be any valid scope. I think this also > needs more clarification. Does this mean I should force FF3[0-F]:: to > be SSM addresses in the router or is something in the range 0-F > known to be "not valid"? How does one determine the validity of a scope? Two points. First, F is undefined, 0 & 1 are "node-internal" and should never be seen on the wire, and 2 is link-local and should not be routed. Second, the mere use of FF3x:: does not indicate an SSM address. RFC 3306 points out that SSM addresses have the FF3x:: prefix and the "plen" field is 0. Brian From ssm-interest-owner@cisco.com Tue Dec 17 15:08:39 2002 Received: from domohead.cisco.com (domohead.cisco.com [161.44.11.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22032 for ; Tue, 17 Dec 2002 15:08:39 -0500 (EST) Received: (from daemon@localhost) by domohead.cisco.com (8.12.2/8.12.2) id gBHIexWj016501; Tue, 17 Dec 2002 13:40:59 -0500 (EST) Date: Tue, 17 Dec 2002 13:40:59 -0500 (EST) Message-Id: <200212171840.gBHIexWj016501@domohead.cisco.com> To: ssm-interest@cisco.com From: holbrook@cisco.com Subject: NOTE A mailing list meta-comment. It seems that the mail server for the ssm-interest list is rewriting the destination address of mails sent to the list to ssm-interest@cisco.com (from ssm-interest@external.cisco.com). Mail sent to ssm-interest@cisco.com will bounce. I'm trying to get this resolved ASAP, but in the meantime please take care -- you may need to manually edit the address to include @external.cisco.com. If I can't resolve this quickly, I will probably be moving the list to one of the IETF servers. Thanks, -Hugh From ssm-interest-owner@cisco.com Tue Dec 17 15:52:14 2002 Received: from domohead.cisco.com (domohead.cisco.com [161.44.11.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23348 for ; Tue, 17 Dec 2002 15:52:14 -0500 (EST) Received: (from daemon@localhost) by domohead.cisco.com (8.12.2/8.12.2) id gBHJIA1k019995; Tue, 17 Dec 2002 14:18:10 -0500 (EST) Date: Tue, 17 Dec 2002 14:18:10 -0500 (EST) Message-Id: <200212171918.gBHJIA1k019995@domohead.cisco.com> To: ssm-interest@cisco.com From: holbrook@cisco.com Subject: Re Hi, Pekka. My replies, re the ssm-arch draft: > ssm-arch-01: > > ==> In many places, there if a referrence to "IPv6 SSM address range > FF2x::". According to e.g. RFC3306, this perhaps should be FF3x:: -- or a > lot of clarification is required! You're right. As I said in a recent reply to the list these should all be FF3x: and will be in the next revision. > No globally agreed-upon administratively-scoped address range [ADMIN- > SCOPE] is currently defined for source-specific multicast. Note that > there is no possibility of address conflict between hosts in different > administrative domains (or between two hosts of any kind). > Administrative scoping of SSM addresses can be implemented within an > administrative domain by filtering at domain boundary routers. > > ==> this seems to be an obvious oversight. > Administrative scoping for SSM is very much existant for IPv6. It's there in v6 because it just falls out of the IPv6 addressing architecture. I'm not personally convinced that there is a need for an administratively scoped SSM address range. I'd like to hear arguments, though. If the working group comes to an agreement that we should provide admin scoping for SSM in IPv4, I'd like to defer the details to a separate draft and not hold this one up. I think it will be fairly contentious trying to nail down the specific admin-scoped SSM address ranges. Assuming that we defer admin-scoping to a separate draft, is there any text change you'd like to see in *this* draft? > Source Routing [RFC791] (both Loose and Strict) in combination with > source address spoofing may be used to allow an impostor of the true > channel source to inject packets onto an SSM channel. An SSM router > MUST have a configuration option to disable source routing to an SSM > destination addresses, and the default value SHOULD be to disable Source > Routing to an SSM destination address. Anti-source spoofing mechanisms > like source address filtering at the edges of the network are also > strongly encouraged. > > ==> this seems overly specificative to me. IMO, if the default is to > disable source routing to multicast addresses, I believe there is no need > for a knob. In any case, this is a bit like an implementation > issue. I think I agree with you, that mandating a configuration option is not really the right way to say this. Trying to translate your comments into text: Source Routing [RFC791] (both Loose and Strict) in combination with source address spoofing may be used to allow an impostor of the true channel source to inject packets onto an SSM channel. An SSM router SHOULD by default disallow source routing to an SSM destination addresses. A router MAY have a configuration option to allow source routing. Anti-source spoofing mechanisms such as source address filtering at the edges of the network are also strongly encouraged. Comments? Hugh > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > From ssm-interest-owner@cisco.com Tue Dec 17 17:15:20 2002 Received: from domohead.cisco.com (domohead.cisco.com [161.44.11.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25418 for ; Tue, 17 Dec 2002 17:15:20 -0500 (EST) Received: (from daemon@localhost) by domohead.cisco.com (8.12.2/8.12.2) id gBHKj7Jl029372; Tue, 17 Dec 2002 15:45:07 -0500 (EST) Date: Tue, 17 Dec 2002 15:45:07 -0500 (EST) Message-Id: <200212172045.gBHKj7Jl029372@domohead.cisco.com> To: ssm-interest@cisco.com From: pekkas@netcore.fi Subject: ReMIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Comments below. I just noted one additional issue: Note that there is no possibility of address conflict between hosts in different administrative domains (or between two hosts of any kind). ==> this does not seem to hold if S is of non-global scope, ie. site-local IPv6 address or RFC1918 IPv4 address. Has this been considered at some point? On Tue, 17 Dec 2002, Hugh Holbrook wrote: > > No globally agreed-upon administratively-scoped address range [ADMIN- > > SCOPE] is currently defined for source-specific multicast. Note that > > there is no possibility of address conflict between hosts in different > > administrative domains (or between two hosts of any kind). > > Administrative scoping of SSM addresses can be implemented within an > > administrative domain by filtering at domain boundary routers. > > > > ==> this seems to be an obvious oversight. > > Administrative scoping for SSM is very much existant for IPv6. > > It's there in v6 because it just falls out of the IPv6 addressing > architecture. I'm not personally convinced that there is a need for > an administratively scoped SSM address range. I'd like to hear > arguments, though. > > If the working group comes to an agreement that we should provide > admin scoping for SSM in IPv4, I'd like to defer the details to a > separate draft and not hold this one up. I think it will be fairly > contentious trying to nail down the specific admin-scoped SSM address > ranges. > > Assuming that we defer admin-scoping to a separate draft, is there any > text change you'd like to see in *this* draft? I totally agree that we should not try to specify IPv4 admin-scoped SSM addresses (I fail to see many uses for these -- perhaps a hesitancy to just pick something from the SSM /8 to use with you S). But concerning IPv6 -- perhaps replace: No globally agreed-upon administratively-scoped address range [ADMIN- SCOPE] is currently defined for source-specific multicast. Note that there is no possibility of address conflict between hosts in different administrative domains (or between two hosts of any kind). Administrative scoping of SSM addresses can be implemented within an administrative domain by filtering at domain boundary routers. with: No globally agreed-upon administratively-scoped address range [ADMIN- SCOPE] is currently defined for source-specific IPv4 multicast. Note that there is no possibility of address conflict between hosts in different administrative domains (or between two hosts of any kind). Administrative scoping of SSM addresses can be implemented within an administrative domain by filtering at domain boundary routers. However, as every IPv6 multicast address includes 4-bit scope value, administrative scoping of IPv6 SSM addresses can also be done by choosing an appropriate scope value. ... Hmm.. I wonder whether this leaves too many assumptions about implementations actually honoring those scope values -- and whether this would have to be reflected in the security considerations, with like: If an IPv6 SSM (S,G) channel is administratively scoped using only the scope value, there is a possibility of them leaking outside of the scope, the same as with Any-Source Multicast. > > Source Routing [RFC791] (both Loose and Strict) in combination with > > source address spoofing may be used to allow an impostor of the true > > channel source to inject packets onto an SSM channel. An SSM router > > MUST have a configuration option to disable source routing to an SSM > > destination addresses, and the default value SHOULD be to disable Source > > Routing to an SSM destination address. Anti-source spoofing mechanisms > > like source address filtering at the edges of the network are also > > strongly encouraged. > > > > ==> this seems overly specificative to me. IMO, if the default is to > > disable source routing to multicast addresses, I believe there is no need > > for a knob. In any case, this is a bit like an implementation > > issue. > > I think I agree with you, that mandating a configuration option is not > really the right way to say this. Trying to translate your comments > into text: > > Source Routing [RFC791] (both Loose and Strict) in combination with > source address spoofing may be used to allow an impostor of the true > channel source to inject packets onto an SSM channel. An SSM router > SHOULD by default disallow source routing to an SSM destination > addresses. A router MAY have a configuration option to allow source > routing. Anti-source spoofing mechanisms such as source address > filtering at the edges of the network are also strongly encouraged. > > Comments? Seems good to me. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From ssm-interest-owner@cisco.com Tue Dec 17 17:56:54 2002 Received: from domohead.cisco.com (domohead.cisco.com [161.44.11.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26089 for ; Tue, 17 Dec 2002 17:56:54 -0500 (EST) Received: (from daemon@localhost) by domohead.cisco.com (8.12.2/8.12.2) id gBHLMXa5002627; Tue, 17 Dec 2002 16:22:33 -0500 (EST) Date: Tue, 17 Dec 2002 16:22:33 -0500 (EST) Message-Id: <200212172122.gBHLMXa5002627@domohead.cisco.com> To: ssm-interest@cisco.com From: bkhabs@nc.rr.com Subject: ReMIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit holbrook@cisco.com wrote: > Hi, Pekka. My replies, re the ssm-arch draft: > > >>ssm-arch-01: >> >>==> In many places, there if a referrence to "IPv6 SSM address range >>FF2x::". According to e.g. RFC3306, this perhaps should be FF3x:: -- or a >>lot of clarification is required! > > > You're right. As I said in a recent reply to the list these should > all be FF3x: and will be in the next revision. > > >>No globally agreed-upon administratively-scoped address range [ADMIN- >>SCOPE] is currently defined for source-specific multicast. Note that >>there is no possibility of address conflict between hosts in different >>administrative domains (or between two hosts of any kind). >>Administrative scoping of SSM addresses can be implemented within an >>administrative domain by filtering at domain boundary routers. >> >>==> this seems to be an obvious oversight. >>Administrative scoping for SSM is very much existant for IPv6. > > > It's there in v6 because it just falls out of the IPv6 addressing > architecture. I'm not personally convinced that there is a need for > an administratively scoped SSM address range. I'd like to hear > arguments, though. > > If the working group comes to an agreement that we should provide > admin scoping for SSM in IPv4, I'd like to defer the details to a > separate draft and not hold this one up. I think it will be fairly > contentious trying to nail down the specific admin-scoped SSM address > ranges. > > Assuming that we defer admin-scoping to a separate draft, is there any > text change you'd like to see in *this* draft? > I don't see a need for additional text in this document. > >>Source Routing [RFC791] (both Loose and Strict) in combination with >>source address spoofing may be used to allow an impostor of the true >>channel source to inject packets onto an SSM channel. An SSM router >>MUST have a configuration option to disable source routing to an SSM >>destination addresses, and the default value SHOULD be to disable Source >>Routing to an SSM destination address. Anti-source spoofing mechanisms >>like source address filtering at the edges of the network are also >>strongly encouraged. >> >>==> this seems overly specificative to me. IMO, if the default is to >>disable source routing to multicast addresses, I believe there is no need >>for a knob. In any case, this is a bit like an implementation >>issue. > > > I think I agree with you, that mandating a configuration option is not > really the right way to say this. Trying to translate your comments > into text: > > Source Routing [RFC791] (both Loose and Strict) in combination with > source address spoofing may be used to allow an impostor of the true > channel source to inject packets onto an SSM channel. An SSM router > SHOULD by default disallow source routing to an SSM destination > addresses. A router MAY have a configuration option to allow source > routing. Anti-source spoofing mechanisms such as source address > filtering at the edges of the network are also strongly encouraged. > > Comments? The IPv6 spec (RFC 2460) specifically forbids the use of multicast addresses in the routing header. But, I don't see a comparable restriction for v4. And I would assume that the above text would go in the Security Considerations section. Brian From ssm-interest-owner@cisco.com Tue Dec 17 18:37:08 2002 Received: from domohead.cisco.com (domohead.cisco.com [161.44.11.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26725 for ; Tue, 17 Dec 2002 18:37:07 -0500 (EST) Received: (from daemon@localhost) by domohead.cisco.com (8.12.2/8.12.2) id gBHMC4A0006474; Tue, 17 Dec 2002 17:12:04 -0500 (EST) Date: Tue, 17 Dec 2002 17:12:04 -0500 (EST) Message-Id: <200212172212.gBHMC4A0006474@domohead.cisco.com> To: ssm-interest@cisco.com From: holbrook@cisco.com Subject: Re > Date: Tue, 17 Dec 2002 16:18:22 -0500 > From: Brian Haberman > > The IPv6 spec (RFC 2460) specifically forbids the use of multicast > addresses in the routing header. But, I don't see a comparable > restriction for v4. > > And I would assume that the above text would go in the Security > Considerations section. Yes, this text is in the Security Considerations section. -Hugh From ssm-interest-owner@cisco.com Wed Dec 18 03:23:57 2002 Received: from domohead.cisco.com (domohead.cisco.com [161.44.11.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29500 for ; Wed, 18 Dec 2002 03:23:57 -0500 (EST) Received: (from daemon@localhost) by domohead.cisco.com (8.12.2/8.12.2) id gBI76NWF015685; Wed, 18 Dec 2002 02:06:23 -0500 (EST) Date: Wed, 18 Dec 2002 02:06:23 -0500 (EST) Message-Id: <200212180706.gBI76NWF015685@domohead.cisco.com> To: ssm-interest@cisco.com From: holbrook@cisco.com Subject: Re > Date: Tue, 17 Dec 2002 15:45:07 -0500 (EST) > From: pekkas@netcore.fi > > > Comments below. > > I just noted one additional issue: > > Note that > there is no possibility of address conflict between hosts in different > administrative domains (or between two hosts of any kind). > > ==> this does not seem to hold if S is of non-global scope, ie. site-local > IPv6 address or RFC1918 IPv4 address. Has this been considered at some > point? I will grant you that this paragaph doesn't really adequately address IPv6, given that scoping *does* exist for IPv6. I'll fix that. In the context of IPv4, I think I was trying to make the following point with this rather cryptic sentence: At least one of the reasons to use scoping in ASM doesn't apply to SSM. In ASM, one of the benefits of scoped addresses is that they allow hosts in two different domains to be able to allocate multicast addresses for local use in their respective domains without talking to one another (or to Dave Meyer) and without risking that they may choose conflicting addresses. But this use of scoping doesn't apply to SSM because you already get uniqueness of channels by piggybacking on the uniqueness of source addresses. I could put a paragraph stating this into the draft, but this argument isn't really even conclusive, and I'm afraid it would raise as many questions as it answers: What other motivations for admin scoping might apply other than this one? Do we really need admin scoping for IPv4? What applications might use scoping and what range the addresses would the scoped addresses ranges come from and so on... I don't want to go there in this document. So in the interests of keeping the draft short, and given that the sentence is confusing and doesn't really add information, how about if I just strike it. Here's a proposed change that is pretty close to what you wrote below. For IPv6, administratively scoped SSM addresses are created by choosing an appropriate scope identifier for the SSM destination address. Normal IPv6 scope boundaries are applied to traffic sent to an SSM destination address. No globally agreed-upon administratively-scoped address range [ADMIN-SCOPE] is currently defined for IPv4 source-specific multicast. For IPv4, administrative scoping of SSM addresses can be implemented within an administrative domain by filtering outgoing SSM traffic sent to a scoped address at the domain's boundary routers. > On Tue, 17 Dec 2002, Hugh Holbrook wrote: > > > No globally agreed-upon administratively-scoped address range [ADMIN- > > > SCOPE] is currently defined for source-specific multicast. Note that > > > there is no possibility of address conflict between hosts in different > > > administrative domains (or between two hosts of any kind). > > > Administrative scoping of SSM addresses can be implemented within an > > > administrative domain by filtering at domain boundary routers. > > > > > > ==> this seems to be an obvious oversight. > > > Administrative scoping for SSM is very much existant for IPv6. > > > > It's there in v6 because it just falls out of the IPv6 addressing > > architecture. I'm not personally convinced that there is a need for > > an administratively scoped SSM address range. I'd like to hear > > arguments, though. > > > > If the working group comes to an agreement that we should provide > > admin scoping for SSM in IPv4, I'd like to defer the details to a > > separate draft and not hold this one up. I think it will be fairly > > contentious trying to nail down the specific admin-scoped SSM address > > ranges. > > > > Assuming that we defer admin-scoping to a separate draft, is there any > > text change you'd like to see in *this* draft? > > I totally agree that we should not try to specify IPv4 admin-scoped SSM > addresses (I fail to see many uses for these -- perhaps a hesitancy to > just pick something from the SSM /8 to use with you S). > > But concerning IPv6 -- perhaps replace: > > No globally agreed-upon administratively-scoped address range [ADMIN- > SCOPE] is currently defined for source-specific multicast. Note that > there is no possibility of address conflict between hosts in different > administrative domains (or between two hosts of any kind). > Administrative scoping of SSM addresses can be implemented within an > administrative domain by filtering at domain boundary routers. > > with: > > No globally agreed-upon administratively-scoped address range [ADMIN- > SCOPE] is currently defined for source-specific IPv4 multicast. Note that > there is no possibility of address conflict between hosts in different > administrative domains (or between two hosts of any kind). Administrative > scoping of SSM addresses can be implemented within an administrative > domain by filtering at domain boundary routers. However, as every IPv6 > multicast address includes 4-bit scope value, administrative scoping of > IPv6 SSM addresses can also be done by choosing an appropriate scope > value. > > ... > > Hmm.. I wonder whether this leaves too many assumptions about > implementations actually honoring those scope values -- and whether this > would have to be reflected in the security considerations, with like: > > If an IPv6 SSM (S,G) channel is administratively scoped using only the > scope value, there is a possibility of them leaking outside of the scope, > the same as with Any-Source Multicast. I don't think we need say this -- there are no new security considerations for scoping and SSM that don't already apply to ASM. Thanks for the comments and careful reading. -Hugh From ssm-interest-owner@cisco.com Wed Dec 18 03:27:56 2002 Received: from domohead.cisco.com (domohead.cisco.com [161.44.11.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29533 for ; Wed, 18 Dec 2002 03:27:56 -0500 (EST) Received: (from daemon@localhost) by domohead.cisco.com (8.12.2/8.12.2) id gBI7Elp2017103; Wed, 18 Dec 2002 02:14:47 -0500 (EST) Date: Wed, 18 Dec 2002 02:14:47 -0500 (EST) Message-Id: <200212180714.gBI7Elp2017103@domohead.cisco.com> To: ssm-interest@cisco.com From: holbrook@cisco.com Subject: Re > Date: Tue, 17 Dec 2002 15:45:07 -0500 (EST) > From: pekkas@netcore.fi > > > Comments below. > > I just noted one additional issue: > > Note that > there is no possibility of address conflict between hosts in different > administrative domains (or between two hosts of any kind). > > ==> this does not seem to hold if S is of non-global scope, ie. site-local > IPv6 address or RFC1918 IPv4 address. Has this been considered at some > point? I will grant you that this paragaph doesn't really adequately address IPv6 -- I'll fix that. Regarding IPv4, I think I was trying to make the following point with this rather cryptic sentence: At least one of the reasons to use scoping in ASM doesn't apply to SSM. In ASM, one of the benefits of scoped addresses is that they allow hosts in two different domains to be able to allocate multicast addresses for local use in their respective domains without talking to one another (or to Dave Meyer) and without risking that they may choose conflicting addresses. But this use of scoping doesn't apply to SSM because you already get uniqueness of channels by piggybacking on the uniqueness of source addresses. I could put a paragraph stating the above into the draft, but I'm afraid this argument raises more questions than it answers: What other motivations for admin scoping might apply other than this one? Do we really need admin scoping for IPv4? What applications might use scoping and what range the addresses would the scoped addresses ranges come from and so on... I don't want to go there in this document. So in the interests of keeping the draft short, and given that the sentence is confusing and adds little, how about if I just strike it. Here's a proposed change that is pretty close to what you wrote below. For IPv6, administratively scoped SSM addresses are created by choosing an appropriate scope identifier for the SSM destination address. Normal IPv6 scope boundaries are applied to traffic sent to an SSM destination address. No globally agreed-upon administratively-scoped address range [ADMIN-SCOPE] is currently defined for IPv4 source-specific multicast. For IPv4, administrative scoping of SSM addresses can be implemented within an administrative domain by filtering outgoing SSM traffic sent to a scoped address at the domain's boundary routers. > On Tue, 17 Dec 2002, Hugh Holbrook wrote: > > > No globally agreed-upon administratively-scoped address range [ADMIN- > > > SCOPE] is currently defined for source-specific multicast. Note that > > > there is no possibility of address conflict between hosts in different > > > administrative domains (or between two hosts of any kind). > > > Administrative scoping of SSM addresses can be implemented within an > > > administrative domain by filtering at domain boundary routers. > > > > > > ==> this seems to be an obvious oversight. > > > Administrative scoping for SSM is very much existant for IPv6. > > > > It's there in v6 because it just falls out of the IPv6 addressing > > architecture. I'm not personally convinced that there is a need for > > an administratively scoped SSM address range. I'd like to hear > > arguments, though. > > > > If the working group comes to an agreement that we should provide > > admin scoping for SSM in IPv4, I'd like to defer the details to a > > separate draft and not hold this one up. I think it will be fairly > > contentious trying to nail down the specific admin-scoped SSM address > > ranges. > > > > Assuming that we defer admin-scoping to a separate draft, is there any > > text change you'd like to see in *this* draft? > > I totally agree that we should not try to specify IPv4 admin-scoped SSM > addresses (I fail to see many uses for these -- perhaps a hesitancy to > just pick something from the SSM /8 to use with you S). > > But concerning IPv6 -- perhaps replace: > > No globally agreed-upon administratively-scoped address range [ADMIN- > SCOPE] is currently defined for source-specific multicast. Note that > there is no possibility of address conflict between hosts in different > administrative domains (or between two hosts of any kind). > Administrative scoping of SSM addresses can be implemented within an > administrative domain by filtering at domain boundary routers. > > with: > > No globally agreed-upon administratively-scoped address range [ADMIN- > SCOPE] is currently defined for source-specific IPv4 multicast. Note that > there is no possibility of address conflict between hosts in different > administrative domains (or between two hosts of any kind). Administrative > scoping of SSM addresses can be implemented within an administrative > domain by filtering at domain boundary routers. However, as every IPv6 > multicast address includes 4-bit scope value, administrative scoping of > IPv6 SSM addresses can also be done by choosing an appropriate scope > value. > > ... > > Hmm.. I wonder whether this leaves too many assumptions about > implementations actually honoring those scope values -- and whether this > would have to be reflected in the security considerations, with like: > > If an IPv6 SSM (S,G) channel is administratively scoped using only the > scope value, there is a possibility of them leaking outside of the scope, > the same as with Any-Source Multicast. I don't think we need say this -- there are no new security considerations for scoping and SSM that don't already apply to ASM. Thanks, -Hugh From ssm-interest-owner@cisco.com Wed Dec 18 04:15:01 2002 Received: from domohead.cisco.com (domohead.cisco.com [161.44.11.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00311 for ; Wed, 18 Dec 2002 04:15:00 -0500 (EST) Received: (from daemon@localhost) by domohead.cisco.com (8.12.2/8.12.2) id gBI81R7T023428; Wed, 18 Dec 2002 03:01:27 -0500 (EST) Date: Wed, 18 Dec 2002 03:01:27 -0500 (EST) Message-Id: <200212180801.gBI81R7T023428@domohead.cisco.com> To: ssm-interest@cisco.com From: holbrook@cisco.com Subject: Fwd Yikes. I made a typo in the destination address when I responded to Pavlin's mail, so this never went out to the list. -Hugh ------- Forwarded Message ------- From: Hugh Holbrook To: holbrook@cisco.com Cc: ssm-interest@external.cicso.com, pavlin@icir.org, holbrook@cisco.com, dthaler@microsoft.com Subject: Re: Fwd: Re: draft-ietf-ssm-arch-01, wg last call deadline 12/9/2002 Reply-To: holbrook@cisco.com Message-Id: <20021213202557.677B710B7A7@holbrook-laptop.cisco.com> Date: Fri, 13 Dec 2002 15:25:57 -0500 (EST) Thanks for the detailed comments, Pavlin. Responses to your non-IPv6 related comments are inline. I'll follow up separately with responses to your IPv6 comments. -Hugh > ------- Forwarded Message ------- > Message-Id: <200211210052.gAL0qDoo082003@possum.icir.org> > To: holbrook@cisco.com > Cc: ssm-interest@cisco.com > Subject: Re: draft-ietf-ssm-arch-01, wg last call deadline 12/9/2002 > Date: Wed, 20 Nov 2002 16:52:13 -0800 > From: Pavlin Radoslavov > > > There is a new revision of the SSM architecture draft in the ID > > archives: > > > > draft-ietf-ssm-arch-01.txt > > > > Please consider this email as notice of an SSM working group last call > > for comments on this document. Send comments by 12/9/2002. > > Several comments (in no particular order): > > * You may want to check the I-D against the nits in > http://www.ietf.org/ID-nits.html > E.g, don't use citations in the Abstract. Thanks. I did that. In addition to the citations that you pointed out, I added Copyright and IPR sections and changed the example IPv4 addresses to conform to rfc3330 (use 192.0.2.*) > * Should the draft include a recommendation that if a host is > updated to support SSM, then ASM (*,G) join request by an > application for a multicast group that fails within the SSM range > should return an error? I think this is a good suggestion. Brian and I also discussed something like this in the context of the IGMPv3/MLDv2 draft. When we originally wrote the -arch draft, it was not clear how a host would really know the SSM address range (other than by configuration). Now, there is the (proposed) MRD option for the SSM range advertisement, and we've put in text about possible manual configuration also. So I think it would make sense to specify this. How about adding the following text to the second to last paragraph of 4.1 (the one that mentions the MSFAPI) as follows: When a host has been configured to know the SSM address range, either manually or using a protocol, then the host's operating system SHOULD return an error to an application that makes a non-source-specific request to receive data sent to an SSM destination address. I'm interested in hearing opinions on this from the list. > * After enumerating the benefits of the SSM model in Section 1, > what about enumerating its limitations/drawbacks? :) Fair enough. I'll come up with something. > * Reference [IANA-ALLOCATION] should point to > http://www.iana.org/assignments/multicast-addresses Done. > * Use consistent notation for the IPv6 hex addresses. E.g., the > draft has addresses like FF3x::7fff:ffff which mixes capital with > small letters. Done > Thanks, > Pavlin > From ssm-interest-owner@cisco.com Wed Dec 18 12:54:23 2002 Received: from domohead.cisco.com (domohead.cisco.com [161.44.11.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14029 for ; Wed, 18 Dec 2002 12:54:23 -0500 (EST) Received: (from daemon@localhost) by domohead.cisco.com (8.12.2/8.12.2) id gBIGYQ28002452; Wed, 18 Dec 2002 11:34:26 -0500 (EST) Date: Wed, 18 Dec 2002 11:34:26 -0500 (EST) Message-Id: <200212181634.gBIGYQ28002452@domohead.cisco.com> To: ssm-interest@cisco.com From: pekkas@netcore.fi Subject: ReMIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 18 Dec 2002 holbrook@cisco.com wrote: > I will grant you that this paragaph doesn't really adequately address > IPv6, given that scoping *does* exist for IPv6. I'll fix that. Ok. > In the context of IPv4, I think I was trying to make the following > point with this rather cryptic sentence: > > At least one of the reasons to use scoping in ASM doesn't apply to > SSM. In ASM, one of the benefits of scoped addresses is that they > allow hosts in two different domains to be able to allocate multicast > addresses for local use in their respective domains without talking to > one another (or to Dave Meyer) and without risking that they may > choose conflicting addresses. But this use of scoping doesn't apply > to SSM because you already get uniqueness of channels by piggybacking > on the uniqueness of source addresses. > > I could put a paragraph stating this into the draft, but this argument > isn't really even conclusive, and I'm afraid it would raise as many > questions as it answers: What other motivations for admin scoping > might apply other than this one? Do we really need > admin scoping for IPv4? What applications might use scoping and > what range the addresses would the scoped addresses ranges come from > and so on... I don't want to go there in this document. > > So in the interests of keeping the draft short, and given that the > sentence is confusing and doesn't really add information, how about if > I just strike it. Agree. > Here's a proposed change that is pretty close to what you wrote below. > > For IPv6, administratively scoped SSM addresses are created by > choosing an appropriate scope identifier for the SSM destination > address. Normal IPv6 scope boundaries are applied to > traffic sent to an SSM destination address. > > No globally agreed-upon administratively-scoped address range > [ADMIN-SCOPE] is currently defined for IPv4 source-specific multicast. > For IPv4, administrative scoping of SSM addresses > can be implemented within an administrative domain by filtering > outgoing SSM traffic sent to a scoped address > at the domain's boundary routers. Sounds good to me. (Note: I'd perhaps s/Normal IPv6 scope/Normal IPv6 multicast scope/ to strike the point). -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords