From mailman-admin@ietf.org Thu May 1 10:23: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 KAA13282 for ; Thu, 1 May 2003 10:23:48 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41ETp809337 for ; Thu, 1 May 2003 10:29:51 -0400 Date: Thu, 01 May 2003 10:29:51 -0400 Message-ID: <20030501142951.17986.93550.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 mailnull@www1.ietf.org Thu May 1 15:45: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 PAA04724 for ; Thu, 1 May 2003 15:45:19 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41JpTF27076 for ssm-archive@odin.ietf.org; Thu, 1 May 2003 15:51:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41JpT827073 for ; Thu, 1 May 2003 15:51:29 -0400 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 PAA04684 for ; Thu, 1 May 2003 15:44:49 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41JdO822432; Thu, 1 May 2003 15:39:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41JWP818826 for ; Thu, 1 May 2003 15:32:25 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02732; Thu, 1 May 2003 15:25:42 -0400 (EDT) Message-Id: <200305011925.PAA02732@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, 01 May 2003 15:25:42 -0400 Subject: [ssm] I-D ACTION:draft-ietf-ssm-overview-05.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 : An Overview of Source-Specific Multicast(SSM) Author(s) : S. Bhattacharyya et al. Filename : draft-ietf-ssm-overview-05.txt Pages : 13 Date : 2003-5-1 The purpose of this document is to provide an overview of Source- Specific Multicast (SSM) and issues related to its deployment. It discusses how the SSM service model addresses the challenges faced in inter-domain multicast deployment, changes needed to routing protocols and applications to deploy SSM and interoperability issues with current multicast service models. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ssm-overview-05.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-overview-05.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-overview-05.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-5-1153704.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ssm-overview-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ssm-overview-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-1153704.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Fri May 2 17:14: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 RAA03000 for ; Fri, 2 May 2003 17:14:22 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h42LL3229182 for ssm-archive@odin.ietf.org; Fri, 2 May 2003 17:21:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42LKI829124 for ; Fri, 2 May 2003 17:20:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02962 for ; Fri, 2 May 2003 17:13:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Bhr0-0000DB-00 for ssm-web-archive@ietf.org; Fri, 02 May 2003 17:14:02 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Bhqq-0000D1-00 for ssm-web-archive@ietf.org; Fri, 02 May 2003 17:13:52 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42LEl828813; Fri, 2 May 2003 17:14:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NCQw819544 for ; Wed, 23 Apr 2003 08:26:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15009 for ; Wed, 23 Apr 2003 08:14:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198JB9-0003EK-00 for ssm@ietf.org; Wed, 23 Apr 2003 08:16:47 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com ident=root) by ietf-mx with esmtp (Exim 4.12) id 198JB8-0003EH-00 for ssm@ietf.org; Wed, 23 Apr 2003 08:16:46 -0400 Received: from [68.100.8.94] (account marshall_eubanks HELO multicasttech.com) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 1677733; Wed, 23 Apr 2003 07:45:25 -0400 Date: Wed, 23 Apr 2003 08:17:17 -0400 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: ssm@ietf.org, mboned@network-services.uoregon.edu To: Ross Finlayson From: Marshall Eubanks In-Reply-To: <4.3.1.1.20030423030316.00b66140@laptop-localhost> Message-Id: <86495EF6-7585-11D7-92AE-0003936D71EA@multicasttech.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [ssm] Re: FYI: Updated SSM-capable applications 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 Dear Ross; Is there any authentication applied to the unicast SSM rtcp reports, which can be used for a denial of service attacks ? Regards Marshall Eubanks On Wednesday, April 23, 2003, at 06:33 AM, Ross Finlayson wrote: > Some of you who are working with Source-Specific Multicast may be > interested in new versions of several multicast applications, which I > have recently updated to conform to the latest SSM-relevant Internet > Drafts: > > 1/ SSM sending applications > (i) When generating SDP descriptions, include appropriate > a=source-filter: incl ... > and > a=rtcp: unicast reflection > lines. > (ii) Receive incoming RTCP Reception Reports via unicast, and > 'reflect' them > back to the group via multicast. > > - "vobStreamer" (a DVD audio/video streaming tool): > > - "liveCaster" (a MP3 RTP streaming tool - SSM sending is optional): > > - "testMP3Streamer", "testMPEGVideoStreamer", > "testMPEGAudioVideoStreamer" (various streaming test programs - SSM > sending is optional): > > 2/ SSM receiving applications > (i) Use the IP_ADD_SOURCE_MEMBERSHIP and IP_DROP_SOURCE_MEMBERSHIP > "setsockopt()" calls (instead of the regular IP_ADD_MEMBERSHIP and > IP_DROP_MEMBERSHIP, but falling back to using these if the *SOURCE* > versions aren't supported). > (ii) Send back RTCP Reception Reports via unicast rather than > multicast. > > - "MPlayer" (a media player - will use SSM if specified by RTSP and/or > SDP): > - The "in_rtp.dll" MP3/RTP plugin for Winamp: > > - "playRTPMPEG" (a MP3/RTP receiving tool): > > - "testMP3Receiver", "testMPEGVideoReceiver" (various receiving test > programs - SSM is optional): > > Ross. > > T.M. Eubanks Multicast Technologies, Inc. e-mail : tme@multicasttech.com http://www.multicasttech.com Our New Multicast Workshop : http://www.multicasttech.com/workshop Test your network for multicast : http://www.multicasttech.com/mt/ _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Thu May 8 00:52: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 AAA00457 for ; Thu, 8 May 2003 00:52:39 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4851vf26954 for ssm-archive@odin.ietf.org; Thu, 8 May 2003 01:01:57 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4851u826951 for ; Thu, 8 May 2003 01:01:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00450 for ; Thu, 8 May 2003 00:52:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DdQ4-0007gU-00 for ssm-web-archive@ietf.org; Thu, 08 May 2003 00:54:12 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DdQ3-0007gQ-00 for ssm-web-archive@ietf.org; Thu, 08 May 2003 00:54:11 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h484w3826745; Thu, 8 May 2003 00:58:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h484ui826684 for ; Thu, 8 May 2003 00:56:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00396 for ; Thu, 8 May 2003 00:46:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DdL1-0007fQ-00 for ssm@ietf.org; Thu, 08 May 2003 00:48:59 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by ietf-mx with esmtp (Exim 4.12) id 19DdL0-0007fN-00 for ssm@ietf.org; Thu, 08 May 2003 00:48:59 -0400 Received: from holbrook-laptop.cisco.com (sjc-vpn3-623.cisco.com [10.21.66.111]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h484nJFf028390; Wed, 7 May 2003 21:49:20 -0700 (PDT) Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id 4D77310B7A7; Wed, 7 May 2003 21:41:32 -0700 (PDT) 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: <20030508044132.4D77310B7A7@holbrook-laptop.cisco.com> Date: Wed, 7 May 2003 21:41:32 -0700 (PDT) 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: , Hey, Pekka. I was just finishing up the final tweaks to the draft realize that I never responded to your editorial comments from a few months back. I took pretty much all of your suggestions. For the record, here's what I did. -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..? RFC2119 says anywhere near the beginning is ok. > 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. Done > ==> "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. Done > 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/ Done. > referred to as a "channel." In contrast to the ASM model of RFC 1112, > > ==> s/."/"./ ? I think ." is actually the right punctuation. > Identifier: G S,G > Receiver Operations: join, leave subscribe, unsubscribe > > ==> s/subscribe/Subscribe/, s/unsubscribe/Unsubscribe/ Done. > host IP module sends an unsubscription request for that channel out > interface I. > > ==> s/interface/the interface/, or "on interface". I used "to interface." > address range for IPv4). For IPv6, the randomization should apply to > the lower 32 bits of the address. > > ==> s/lower/lowest/ ? Done. > 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? Done. > specify the required modifications to those protocols to support SSM. > > ==> s/required /required / (extra space) Done > 7. Security Considerations > > ==> add a 1-2 line summary of the subsections here. How's this? This section outlines security issues pertaining to SSM. The following topics are addressed: limitations of IPSec, denial of service attacks, source spoofing, and security issues related to administrative scoping. > 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) Done. > ==> s/deliver/delivering/ Done. > -- > 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 Thu May 8 15:42:25 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 PAA06472 for ; Thu, 8 May 2003 15:42:25 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h48Jq1E12065 for ssm-archive@odin.ietf.org; Thu, 8 May 2003 15:52:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48Jq1812062 for ; Thu, 8 May 2003 15:52:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06441 for ; Thu, 8 May 2003 15:41:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DrJ7-0005Pg-00 for ssm-web-archive@ietf.org; Thu, 08 May 2003 15:43:57 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DrJ7-0005Pd-00 for ssm-web-archive@ietf.org; Thu, 08 May 2003 15:43:57 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48JkS811697; Thu, 8 May 2003 15:46:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48JjM811660 for ; Thu, 8 May 2003 15:45:22 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06175; Thu, 8 May 2003 15:35:16 -0400 (EDT) Message-Id: <200305081935.PAA06175@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, 08 May 2003 15:35:15 -0400 Subject: [ssm] I-D ACTION:draft-ietf-ssm-arch-03.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-03.txt Pages : 17 Date : 2003-5-8 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-03.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-03.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-03.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-5-8130621.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ssm-arch-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ssm-arch-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-8130621.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 May 8 16:45: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 QAA10143 for ; Thu, 8 May 2003 16:45:17 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h48Ksth17326 for ssm-archive@odin.ietf.org; Thu, 8 May 2003 16:54:55 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48Kst817323 for ; Thu, 8 May 2003 16:54:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10122 for ; Thu, 8 May 2003 16:44:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DsHy-0006LZ-00 for ssm-web-archive@ietf.org; Thu, 08 May 2003 16:46:50 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DsHx-0006LW-00 for ssm-web-archive@ietf.org; Thu, 08 May 2003 16:46:49 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48KpI817095; Thu, 8 May 2003 16:51:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48Km4816928 for ; Thu, 8 May 2003 16:48:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09877 for ; Thu, 8 May 2003 16:37:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DsBL-0006I7-00 for ssm@ietf.org; Thu, 08 May 2003 16:39:59 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by ietf-mx with esmtp (Exim 4.12) id 19DsBK-0006Hl-00 for ssm@ietf.org; Thu, 08 May 2003 16:39:58 -0400 Received: from holbrook-laptop.cisco.com (dhcp-171-69-113-120.cisco.com [171.69.113.120]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h48KeMwE001530; Thu, 8 May 2003 13:40:22 -0700 (PDT) Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id 418DA10B7A7; Thu, 8 May 2003 13:32:37 -0700 (PDT) From: Hugh Holbrook To: ssm@ietf.org Cc: supratik@sprintlabs.com Reply-To: holbrook@cisco.com Message-Id: <20030508203237.418DA10B7A7@holbrook-laptop.cisco.com> Date: Thu, 8 May 2003 13:32:37 -0700 (PDT) Subject: [ssm] short last call (again) for draft-ietf-ssm-arch-03.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: , A new version of the SSM architecture document is now available in the ID archives at: http://www.ietf.org/internet-drafts/draft-ietf-ssm-arch-03.txt This is a working group last call for changs. Since the changes have been pretty small since the last revision, I am making this a short last call, ending on May 15. I believe this draft addresses all of the issues raised during the previous last call. All document changes are summarized below, and I've included the diffs of the nroff source relative to the -02 version, for people who don't want to re-read the whole document. Please send any comments if you have them. Thanks! -Hugh ---------------------------------------------------------------- Changes since the -02 revision and the wg last call. Section 1: Explained why FF3x::0000:0001 to FF3x::3FFF:FFFF are invalid addresses. Section 4.3: Corrections: randomization applies to the lowest 31 bits of the IPv6 address. Previously we said the "lower 32" which was imprecise and wrong (only 31 bits are randomly selected). Section 4.3: Added a note that v6 scoping may have to be applied to both S and G.. Section 7.0: Added a two-sentence intro to Security Considerations. Section 7.4: Add an entirely new section discussing Admin Scoping to Security Considerations. Section 9.0: IANA Considerations. Added a note about the fact that FF3x::4000:0000 to FF3x::7FFF:FFFF are IANA allocated and the allocation policy. Everywhere: A few minor editorial changes, mostly from Pekka, and a few that I found along the way. ---------------------------------------------------------------- =================================================================== RCS file: RCS/draft-ietf-ssm-arch.nroff,v retrieving revision 1.3 diff -uw -r1.3 draft-ietf-ssm-arch.nroff --- draft-ietf-ssm-arch.nroff 2003/03/02 09:43:56 1.3 +++ draft-ietf-ssm-arch.nroff 2003/05/08 06:29:55 @@ -9,22 +9,22 @@ .ds RF PUTFFHERE[Page %] .ds CF .ds LH INTERNET-DRAFT -.ds RH 2 Mar 2003 +.ds RH 7 May 2003 .ds CH Source-Specific Multicast .ad l .in 0 .na INTERNET-DRAFT Source-Specific Multicast H. Holbrook -Expires Sep 2, 2003 Cisco Systems +Expires Nov 7, 2003 Cisco Systems B. Cain Storigen Systems - 2 Mar 2003 + 7 May 2003 .sp 2 .nr PI 0n .ce Source-Specific Multicast for IP .ce - + .sp .in 0 .ne 4 @@ -63,8 +63,8 @@ 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. +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. @@ -82,7 +82,7 @@ This model supports both one-to-many and many-to-many group communication. This document uses the term "Any-Source -Multicast" (ASM) to refer to the RFC 1112 model of multicast. +Multicast" (ASM) to refer to model of multicast defined in RFC 1112. RFC 2373 [RFC2373] specifies the form of IPv6 multicast addresses with ASM semantics. .PP @@ -94,24 +94,28 @@ .PP For IPv6, the address prefix FF3x::/32 is reserved for source-specific multicast use, where 'x' is any valid scope identifier, by [IPV6-UBM]. -Using the terminology of [IPv6-UBM], this means that P=1, T=1, and -plen=0 for any SSM address. +Using the terminology of [IPv6-UBM], all SSM addresses must have P=1, T=1, and +plen=0. [IPv6-MALLOC] mandates that the network prefix field of an SSM address also be set to zero, hence all SSM addresses fall in the FF3x::/96 range. Future documents may allow a non-zero network prefix field if, for instance, a new IP address to MAC address mapping is defined. Thus, address allocation should occur within the FF3x::/96 range, but -a system should treat all of FF3x::/32 as an SSM address, to allow +a system should treat all of FF3x::/32 as SSM addresses, to allow for compatibility with possible future uses of the network prefix field. .PP Addresses in the range FF3x::4000:0000 through FF3x::7FFF:FFFF are -reserved for allocation by IANA, and -addresses in the range FF3x::8000:0000 through FF3x::FFFF:FFFF are +reserved in [IPv6-MALLOC] for allocation by IANA. +Addresses in the range FF3x::8000:0000 through FF3x::FFFF:FFFF are allowed for dynamic allocation by a host, as described in [IPV6-MALLOC]. 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 +addresses. ([IPV6-MALLOC] indicates +that FF3x::0000:0001 to FF3x:3FFF:FFFF must set P=0 and T=0, but +for SSM, [IPV6-UBM] mandates that P=1 and T=1, hence their designation +as invalid). +The treatment of a packet sent to such an invalid address is undefined -- a router or host MAY choose to drop such a packet. .PP @@ -216,7 +220,7 @@ The extended interface is defined in section 4.1. It is meaningless for an application or host to request reception of datagrams sent to an SSM destination address G, -as is supported in the Any-Source Multicast model, +as is supported in the any-source multicast model, without also specifying a corresponding source address, and routers MUST ignore any such request. .\" pursuant to [GMPSSM]. @@ -257,8 +261,8 @@ .NH 1 Terminology .PP -To reduce confusion when talking about the Any-Source -and Source-Specific Multicast models, +To reduce confusion when talking about the any-source +and source-specific multicast models, we use different terminology when discussing them. We use the term "channel" to refer to the @@ -284,13 +288,13 @@ The following table summarizes the terminology: .IP "" 2 -Service Model: Any-Source Source-Specific +Service Model: any-source source-specific .br Network Abstraction: group channel .br Identifier: G S,G .br -Receiver Operations: join, leave subscribe, unsubscribe +Receiver Operations: Join, Leave Subscribe, Unsubscribe .br .PP We note that, although this document specifies a new @@ -301,7 +305,7 @@ Host Requirements .PP This section describes requirements on hosts that -support Source-Specific Multicast, including: +support source-specific multicast, including: .IP "" 2 - Extensions to the IP Module Interface @@ -376,10 +380,10 @@ request on interface I to indicate to neighboring routers that the host wishes to receive traffic sent by source S -to source-specific destination G. +to source-specific multicast destination G. Similarly, when the last socket on a host unsubscribes from a channel on interface I, the host IP module -sends an unsubscription request for that channel out interface I. +sends an unsubscription request for that channel to interface I. .PP These requests will typically be Internet Group Management Protocol version 3 messages for IPv4, or Multicast Listener Discovery @@ -390,11 +394,14 @@ Allocation of Source-Specific Multicast Addresses .PP The SSM destination address 232.0.0.0 is reserved, -and systems MUST NOT send datagrams -with destination address of 232.0.0.0. +and a system MUST NOT send a datagram +with a 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. +SSM +destination addresses in the range FF3x::4000:0000 through +FF3x::7FFF:FFFF are similarly reserved for IANA allocation +[IPv6-MALLOC]. .PP The policy for allocating the rest of the SSM addresses to sending applications is strictly locally determined by the sending host. @@ -405,8 +412,8 @@ It is RECOMMENDED to allocate SSM addresses to applications randomly, while ensuring that allocated addresses are not given simultaneously to multiple applications -(and avoiding the reserved address range for IPv4). -For IPv6, the randomization should apply to the lower 32 bits of the +(and avoiding the reserved addresses). +For IPv6, the randomization should apply to the lowest 31 bits of the address. .PP As described in Section 6, the mapping of @@ -422,7 +429,7 @@ As a result, traffic destined for one channel subscriber would be delivered to another's IP module, which would then -have to reject the datagram. +have to discard the datagram. .PP A host operating system SHOULD provide an interface to allow an application to @@ -445,10 +452,11 @@ If this interface is used, the starting address of the range SHOULD be selected at random by the application. .PP -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. +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, including any relevant +boundaries applied to both the source and destination address. .PP No globally agreed-upon administratively-scoped address range [ADMIN-SCOPE] is currently defined for IPv4 source-specific multicast. @@ -477,7 +485,7 @@ to support SSM. .PP A network can concurrently support SSM in the SSM address range and -Any-Source Multicast +any-source multicast in the rest of the multicast address space, and it is expected that this will be commonplace. In such a network, a @@ -518,6 +526,11 @@ them to the socket layer. .NH 1 Security Considerations +.PP +This section outlines security issues pertaining to SSM. The +following topics are addressed: limitations of IPSec, +denial of service attacks, source spoofing, and security +issues related to administrative scoping. .NH 2 IPSec and SSM .PP @@ -588,13 +601,13 @@ source-specific state, using router CPU and network bandwidth .PP To reduce the damage from such an attack, a router MAY have -configuration options to limit the following items: +configuration options to limit, for example, the following items: .IP "" 4 - The total rate at which all hosts on any one interface are allowed to initiate subscriptions (to limit the damage caused by forged source-address attacks) -- The total number of subscriptions that can be initated from any +- The total number of subscriptions that can be initiated from any single interface or host. .PP Any decision by an implementor to artificially limit the rate or @@ -609,7 +622,7 @@ Failure to do so would exacerbate a spoofed-source address attack. .PP We note that these attacks are not unique to SSM -- they are also present -for Any-Source Multicast. +for any-source multicast. .NH 2 Spoofed Source Addresses .PP @@ -641,6 +654,23 @@ routing. Anti-source spoofing mechanisms such as source address filtering at the edges of the network are also strongly encouraged. +.NH 2 +Administrative Scoping +.PP +Administrative scoping should not relied upon as a security measure +[ADMIN-SCOPE]; however, in some cases it is part of a security +solution. It should be noted that no administrative scoping exists for +IPv4 source-specific multicast. An alternative approach is to manually +configure traffic filters on routers to create such scoping if necessary. +.PP +Furthermore, for IPv6, neither source nor destination address scoping +should be used as a security measure. In some currently-deployed IPv6 +routers (those that do not conform to [SCOPED-ARCH]), scope boundaries +are not always applied to all source address (for instance, an +implentation may filter link-local addresses but nothing else). Such +a router may incorrectly forward an SSM channel (S,G) through a scope +boundary for S. +.PP .NH 1 Transition Considerations .PP @@ -650,7 +680,7 @@ As stated above, a router that receives a non-source-specific (e.g., IGMPv1 or IGMPv2 or MLDv1) host report for a -source-specific destination addresses +source-specific multicast destination address MUST ignore these reports. Failure to do so would violate the SSM service model promised to the sender: that a packet sent to (S,G) would only be delivered to hosts @@ -661,7 +691,7 @@ by simply forwarding any packet destined to G to all hosts that have requested subscription of (S,G) for any S. However, this implementation risks unduly -burdening the network infrastructure by deliver (S,G) datagrams to hosts +burdening the network infrastructure by delivering (S,G) datagrams to hosts that did not request them. Such an implementation for addresses in the SSM range is specifically not compliant with Section 5.2 of this document. @@ -669,7 +699,7 @@ IANA Considerations .PP Addresses in the range 232.0.0.1 through 232.0.0.255 and IPv6 -addresses with prefix FF3x:: +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 @@ -692,19 +722,21 @@ SSM destination address to a particular entity or application. To do so would compromise one of the important benefits of the source-specific model: the ability for a host to simply and -autonomously allocate a source-specific address from a large flat address +autonomously allocate a source-specific multicast +address from a large flat address space. .NH 1 Acknowledgments .PP The SSM service model draws on a variety of prior work on alternative -aproaches to IP multicast, including the EXPRESS multicast model of +approaches to IP multicast, including the EXPRESS multicast model of Holbrook and Cheriton [EXPRESS], Green's [SMRP] and the Simple Multicast proposal of Perlman et. al. [SIMPLE]. We would also like to thank Jon Postel and David Cheriton for their support in reassigning the 232/8 address range to SSM. Brian Haberman contributed to the IPv6 portion of this document. +Thanks to Pekka Savola for a careful review. .NH 1 Normative References .PP @@ -771,6 +803,9 @@ .PP [RFC2771] Finlayson, R., "An Abstract API for Multicast Address Allocation," RFC 2771, February 2000. .PP +[SCOPINGV6] Deering, S. et. al, "IP Version 6 Scoped Address Architecture", +Work in Progress. +.PP [SIMPLE] R. Perlman, C-Y Lee, A. Ballardie, J. Crowcroft, Z. Wang, T. Maufer, C. Diot, and M. Green. "Simple Multicast: A Design for Simple, Low-Overhead Multicast." Work in Progress. .PP @@ -850,5 +885,5 @@ .\" .bp .\" .ls 1 .\" Comment out the table of contents for now .PX -This document expires Sep 2, 2003. +This document expires Nov 7, 2003. _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm