From mailman-admin@ietf.org Sun Jun 1 10:01:54 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 KAA09955 for ; Sun, 1 Jun 2003 10:01:54 -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 h51E1SB00519 for ; Sun, 1 Jun 2003 10:01:28 -0400 Date: Sun, 01 Jun 2003 10:01:28 -0400 Message-ID: <20030601140128.11734.99249.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 Wed Jun 4 01:56:46 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 BAA08049 for ; Wed, 4 Jun 2003 01:56:46 -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 h545qiB01019; Wed, 4 Jun 2003 01:52:44 -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 h545pBB00949 for ; Wed, 4 Jun 2003 01:51:11 -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 BAA07949 for ; Wed, 4 Jun 2003 01:51:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NR9B-0006BM-00 for ssm@ietf.org; Wed, 04 Jun 2003 01:49:17 -0400 Received: from h-135-207-24-32.research.att.com ([135.207.24.32] helo=mailman.research.att.com) by ietf-mx with esmtp (Exim 4.12) id 19NR9B-0006B0-00 for ssm@ietf.org; Wed, 04 Jun 2003 01:49:17 -0400 Received: from unixmail.research.att.com (unixmail.research.att.com [135.207.26.71]) by mailman.research.att.com (8.12.8/8.12.8) with ESMTP id h545jo3j014929 for ; Wed, 4 Jun 2003 01:45:50 -0400 Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by unixmail.research.att.com (8.12.8+Sun/8.8.7) with ESMTP id h545n9Xs029971 for ; Wed, 4 Jun 2003 01:49:09 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id h545oaD08547; Tue, 3 Jun 2003 22:50:36 -0700 (PDT) Message-Id: <200306040550.h545oaD08547@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: ssm@ietf.org Date: Tue, 3 Jun 2003 22:50:35 -0700 Versions: dmail (solaris) 2.5a/makemail 2.9d Subject: [ssm] Document Action: An Overview of Source-Specific Multicast(SSM) Deployment to Informational 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: , For some reason, this went to the wrong address. The IESG has approved the SSM overview draft. Bill ----- Begin forwarded message: From: The IESG Subject: Document Action: An Overview of Source-Specific Multicast(SSM) Deployment to Informational Date: Thu, 29 May 2003 09:40:39 -0400 To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , ssm-interest@external.cisco.com The IESG has approved the Internet-Draft 'An Overview of Source-Specific Multicast(SSM) Deployment' as an Informational RFC. This document is the product of the Source-Specific Multicast Working Group. The IESG contact persons are Bill Fenner and Alex Zinin. COMMENTS: ========= Scott: 9 authors is kinda over the guidelines otherwise a useful document RFC Editor Note: Replace the author list with: Supratik Bhattacharyya (Editor) Sprint Section 6.1, para 1, line 4: OLD: policies being proposed [20], which recommends ... ^^ NEW: policies being proposed [9], which recommends ... Section 6.4, para 1, line 6: OLD: provided by IGMP version 3 [3] and MLD version 2 [22]. These ^^ NEW: provided by IGMP version 3 [3] and MLD version 2 [20]. These Section 7, para 2, line 4: OLD: [20] states ... ^^ NEW: [9] states ... Section 9. Acknowledgments ADD right after the section name: Christophe Diot, Leonard Giuliano, Rob Rockell, John Meylor, David Meyer, Greg Shepherd, and Brian Haberman were the major contributors to the document. Section 10 Change section name to "Informative References" Section 12. Author information: Leave only info for Supratik. Put information about others in a new section called "13. Contributors" ----- End forwarded message: _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Wed Jun 4 01:57: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 BAA08078 for ; Wed, 4 Jun 2003 01:57:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h545utk01222 for ssm-archive@odin.ietf.org; Wed, 4 Jun 2003 01:56: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 h545utB01219 for ; Wed, 4 Jun 2003 01:56: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 BAA08067 for ; Wed, 4 Jun 2003 01:56:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NREk-0006E0-00 for ssm-web-archive@ietf.org; Wed, 04 Jun 2003 01:55:02 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NREj-0006Dw-00 for ssm-web-archive@ietf.org; Wed, 04 Jun 2003 01:55:01 -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 h545qiB01019; Wed, 4 Jun 2003 01:52:44 -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 h545pBB00949 for ; Wed, 4 Jun 2003 01:51:11 -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 BAA07949 for ; Wed, 4 Jun 2003 01:51:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NR9B-0006BM-00 for ssm@ietf.org; Wed, 04 Jun 2003 01:49:17 -0400 Received: from h-135-207-24-32.research.att.com ([135.207.24.32] helo=mailman.research.att.com) by ietf-mx with esmtp (Exim 4.12) id 19NR9B-0006B0-00 for ssm@ietf.org; Wed, 04 Jun 2003 01:49:17 -0400 Received: from unixmail.research.att.com (unixmail.research.att.com [135.207.26.71]) by mailman.research.att.com (8.12.8/8.12.8) with ESMTP id h545jo3j014929 for ; Wed, 4 Jun 2003 01:45:50 -0400 Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by unixmail.research.att.com (8.12.8+Sun/8.8.7) with ESMTP id h545n9Xs029971 for ; Wed, 4 Jun 2003 01:49:09 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id h545oaD08547; Tue, 3 Jun 2003 22:50:36 -0700 (PDT) Message-Id: <200306040550.h545oaD08547@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: ssm@ietf.org Date: Tue, 3 Jun 2003 22:50:35 -0700 Versions: dmail (solaris) 2.5a/makemail 2.9d Subject: [ssm] Document Action: An Overview of Source-Specific Multicast(SSM) Deployment to Informational 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: , For some reason, this went to the wrong address. The IESG has approved the SSM overview draft. Bill ----- Begin forwarded message: From: The IESG Subject: Document Action: An Overview of Source-Specific Multicast(SSM) Deployment to Informational Date: Thu, 29 May 2003 09:40:39 -0400 To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , ssm-interest@external.cisco.com The IESG has approved the Internet-Draft 'An Overview of Source-Specific Multicast(SSM) Deployment' as an Informational RFC. This document is the product of the Source-Specific Multicast Working Group. The IESG contact persons are Bill Fenner and Alex Zinin. COMMENTS: ========= Scott: 9 authors is kinda over the guidelines otherwise a useful document RFC Editor Note: Replace the author list with: Supratik Bhattacharyya (Editor) Sprint Section 6.1, para 1, line 4: OLD: policies being proposed [20], which recommends ... ^^ NEW: policies being proposed [9], which recommends ... Section 6.4, para 1, line 6: OLD: provided by IGMP version 3 [3] and MLD version 2 [22]. These ^^ NEW: provided by IGMP version 3 [3] and MLD version 2 [20]. These Section 7, para 2, line 4: OLD: [20] states ... ^^ NEW: [9] states ... Section 9. Acknowledgments ADD right after the section name: Christophe Diot, Leonard Giuliano, Rob Rockell, John Meylor, David Meyer, Greg Shepherd, and Brian Haberman were the major contributors to the document. Section 10 Change section name to "Informative References" Section 12. Author information: Leave only info for Supratik. Put information about others in a new section called "13. Contributors" ----- End forwarded message: _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-admin@ietf.org Fri Jun 6 14:58: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 OAA07333 for ; Fri, 6 Jun 2003 14:58:17 -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 h56IueB19978; Fri, 6 Jun 2003 14:56:40 -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 h56IqlB19857 for ; Fri, 6 Jun 2003 14:52:47 -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 OAA07172 for ; Fri, 6 Jun 2003 14:52:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OMIY-0005Qh-00 for ssm@ietf.org; Fri, 06 Jun 2003 14:50:46 -0400 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx with esmtp (Exim 4.12) id 19OMIX-0005Qd-00 for ssm@ietf.org; Fri, 06 Jun 2003 14:50:45 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 9FF837B4A8; Fri, 6 Jun 2003 14:52:37 -0400 (EDT) Received: from magic.internet2.edu (aa106.internet2.edu [207.75.164.106]) by basie.internet2.edu (Postfix) with ESMTP id 90C157B484; Fri, 6 Jun 2003 14:52:36 -0400 (EDT) Message-Id: <5.1.0.14.2.20030606144813.01d03370@mail.internet2.edu> X-Sender: jzeeff@mail.internet2.edu X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 06 Jun 2003 14:52:33 -0400 To: Bill Fenner , ssm@ietf.org From: Jon Zeeff Subject: Re: [ssm] Document Action: An Overview of Source-Specific Multicast(SSM) Deployment to Informational In-Reply-To: <200306040550.h545oaD08547@windsor.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by AMaViS 0.3.12pre8 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: , Where is a good source of information on the details of migrating to SSM on real-world LANs? I've seen switches that crash when they see a IGMPv3 packet. Apparently XP doesn't send IGMPv3 packets when it sees certain traffic on an existing LAN. Apparently routers stop using IGMPv3 when they see IGMPv2 traffic (sounds an easy inadvertent DOS attack). Please tell me I'm wrong and that a gradual migration from ASM to SSM is easy.... _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Fri Jun 6 14:59:02 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 OAA07366 for ; Fri, 6 Jun 2003 14:59:02 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56Iwb120060 for ssm-archive@odin.ietf.org; Fri, 6 Jun 2003 14:58:37 -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 h56IwbB20057 for ; Fri, 6 Jun 2003 14:58:37 -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 OAA07355 for ; Fri, 6 Jun 2003 14:58:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OMOC-0005T1-00 for ssm-web-archive@ietf.org; Fri, 06 Jun 2003 14:56:36 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OMOB-0005Sx-00 for ssm-web-archive@ietf.org; Fri, 06 Jun 2003 14:56:35 -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 h56IueB19978; Fri, 6 Jun 2003 14:56:40 -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 h56IqlB19857 for ; Fri, 6 Jun 2003 14:52:47 -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 OAA07172 for ; Fri, 6 Jun 2003 14:52:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OMIY-0005Qh-00 for ssm@ietf.org; Fri, 06 Jun 2003 14:50:46 -0400 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx with esmtp (Exim 4.12) id 19OMIX-0005Qd-00 for ssm@ietf.org; Fri, 06 Jun 2003 14:50:45 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 9FF837B4A8; Fri, 6 Jun 2003 14:52:37 -0400 (EDT) Received: from magic.internet2.edu (aa106.internet2.edu [207.75.164.106]) by basie.internet2.edu (Postfix) with ESMTP id 90C157B484; Fri, 6 Jun 2003 14:52:36 -0400 (EDT) Message-Id: <5.1.0.14.2.20030606144813.01d03370@mail.internet2.edu> X-Sender: jzeeff@mail.internet2.edu X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 06 Jun 2003 14:52:33 -0400 To: Bill Fenner , ssm@ietf.org From: Jon Zeeff Subject: Re: [ssm] Document Action: An Overview of Source-Specific Multicast(SSM) Deployment to Informational In-Reply-To: <200306040550.h545oaD08547@windsor.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by AMaViS 0.3.12pre8 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: , Where is a good source of information on the details of migrating to SSM on real-world LANs? I've seen switches that crash when they see a IGMPv3 packet. Apparently XP doesn't send IGMPv3 packets when it sees certain traffic on an existing LAN. Apparently routers stop using IGMPv3 when they see IGMPv2 traffic (sounds an easy inadvertent DOS attack). Please tell me I'm wrong and that a gradual migration from ASM to SSM is easy.... _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-admin@ietf.org Fri Jun 6 16:22:33 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 QAA11253 for ; Fri, 6 Jun 2003 16:22:33 -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 h56KLeB26472; Fri, 6 Jun 2003 16:21:40 -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 h56KKBB26404 for ; Fri, 6 Jun 2003 16:20:11 -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 QAA11220 for ; Fri, 6 Jun 2003 16:20:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ONfB-00067q-00 for ssm@ietf.org; Fri, 06 Jun 2003 16:18:13 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by ietf-mx with esmtp (Exim 4.12) id 19ONfA-00067B-00 for ssm@ietf.org; Fri, 06 Jun 2003 16:18:12 -0400 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h56KJcjc014424; Fri, 6 Jun 2003 13:19:38 -0700 (PDT) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id NAA10460; Fri, 6 Jun 2003 13:19:36 -0700 (PDT) Date: Fri, 6 Jun 2003 13:19:36 -0700 From: Toerless Eckert To: Jon Zeeff Cc: Bill Fenner , ssm@ietf.org Subject: Re: [ssm] Document Action: An Overview of Source-Specific Multicast(SSM) Deployment to Informational Message-ID: <20030606201936.GI16697@cypher.cisco.com> References: <200306040550.h545oaD08547@windsor.research.att.com> <5.1.0.14.2.20030606144813.01d03370@mail.internet2.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20030606144813.01d03370@mail.internet2.edu> User-Agent: Mutt/1.4i 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 Fri, Jun 06, 2003 at 02:52:33PM -0400, Jon Zeeff wrote: > > Where is a good source of information on the details of migrating to SSM on > real-world LANs? You may have found a good place already. > I've seen switches that crash when they see a IGMPv3 packet. Apparently XP > doesn't send > IGMPv3 packets when it sees certain traffic on an existing LAN. Apparently > routers > stop using IGMPv3 when they see IGMPv2 traffic (sounds an easy inadvertent > DOS attack). >From my experience, windows XP does send IGMPv2 reports if it sees IGMPv2 queries. It MUST do this according to the IGMPv3 spec. Wether or not other hosts send IGMPv2 membership reports does not seem to change windows XP behaviors if i remember it correctly. It is allowed to do this according to the IGMPv3 spec, and this certainly is the best and luckily also the easiest option to implement on the host side. > Please tell me I'm wrong and that a gradual migration from ASM to SSM is > easy.... Unfortunately, this was never an argument in the design of IGMPv3. SSM itself was never an argument for the design of IGMPv3. IGMPv3 started out as being source filtering for ASM at a time when SSM was not even invented. Then it lingered around quite some time (years?) in the IETF, and then people started to see that one could do a cool thing called SSM by leveraging IGMPv3. That's when more work was put into pushing IGMPv3 through the IETF. Unfortunately is was only pushing, it was never really any redesign for the benefit of SSM. We already had a hard time to get certain protocol details out of IGMPv3 that were extremely detremental to SSM (hosts announcing EXCLUDE mode if the source list became too long and the like). So, as far as easy gradual migration to SSM with DoS attack prevention is concerned, this has almost completely been ignored by the IETF process. The best i can offer you is to recommend talking to your vendors of choice and ask them what their solution offers in support of such operational requirements. There is quite a bit of leeway in what implementations can do, specifically in the IGMP Snooping arena and that's where there might be one or the other competitive differentiation which is maybe not best discussed on an open mailing list. Cheers Toerless _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Fri Jun 6 16:23: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 QAA11278 for ; Fri, 6 Jun 2003 16:23:09 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56KMgH26520 for ssm-archive@odin.ietf.org; Fri, 6 Jun 2003 16:22:42 -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 h56KMgB26517 for ; Fri, 6 Jun 2003 16:22:42 -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 QAA11269 for ; Fri, 6 Jun 2003 16:22:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ONhb-00069K-00 for ssm-web-archive@ietf.org; Fri, 06 Jun 2003 16:20:43 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ONhb-00069H-00 for ssm-web-archive@ietf.org; Fri, 06 Jun 2003 16:20:43 -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 h56KLeB26472; Fri, 6 Jun 2003 16:21:40 -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 h56KKBB26404 for ; Fri, 6 Jun 2003 16:20:11 -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 QAA11220 for ; Fri, 6 Jun 2003 16:20:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ONfB-00067q-00 for ssm@ietf.org; Fri, 06 Jun 2003 16:18:13 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by ietf-mx with esmtp (Exim 4.12) id 19ONfA-00067B-00 for ssm@ietf.org; Fri, 06 Jun 2003 16:18:12 -0400 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h56KJcjc014424; Fri, 6 Jun 2003 13:19:38 -0700 (PDT) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id NAA10460; Fri, 6 Jun 2003 13:19:36 -0700 (PDT) Date: Fri, 6 Jun 2003 13:19:36 -0700 From: Toerless Eckert To: Jon Zeeff Cc: Bill Fenner , ssm@ietf.org Subject: Re: [ssm] Document Action: An Overview of Source-Specific Multicast(SSM) Deployment to Informational Message-ID: <20030606201936.GI16697@cypher.cisco.com> References: <200306040550.h545oaD08547@windsor.research.att.com> <5.1.0.14.2.20030606144813.01d03370@mail.internet2.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20030606144813.01d03370@mail.internet2.edu> User-Agent: Mutt/1.4i 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 Fri, Jun 06, 2003 at 02:52:33PM -0400, Jon Zeeff wrote: > > Where is a good source of information on the details of migrating to SSM on > real-world LANs? You may have found a good place already. > I've seen switches that crash when they see a IGMPv3 packet. Apparently XP > doesn't send > IGMPv3 packets when it sees certain traffic on an existing LAN. Apparently > routers > stop using IGMPv3 when they see IGMPv2 traffic (sounds an easy inadvertent > DOS attack). >From my experience, windows XP does send IGMPv2 reports if it sees IGMPv2 queries. It MUST do this according to the IGMPv3 spec. Wether or not other hosts send IGMPv2 membership reports does not seem to change windows XP behaviors if i remember it correctly. It is allowed to do this according to the IGMPv3 spec, and this certainly is the best and luckily also the easiest option to implement on the host side. > Please tell me I'm wrong and that a gradual migration from ASM to SSM is > easy.... Unfortunately, this was never an argument in the design of IGMPv3. SSM itself was never an argument for the design of IGMPv3. IGMPv3 started out as being source filtering for ASM at a time when SSM was not even invented. Then it lingered around quite some time (years?) in the IETF, and then people started to see that one could do a cool thing called SSM by leveraging IGMPv3. That's when more work was put into pushing IGMPv3 through the IETF. Unfortunately is was only pushing, it was never really any redesign for the benefit of SSM. We already had a hard time to get certain protocol details out of IGMPv3 that were extremely detremental to SSM (hosts announcing EXCLUDE mode if the source list became too long and the like). So, as far as easy gradual migration to SSM with DoS attack prevention is concerned, this has almost completely been ignored by the IETF process. The best i can offer you is to recommend talking to your vendors of choice and ask them what their solution offers in support of such operational requirements. There is quite a bit of leeway in what implementations can do, specifically in the IGMP Snooping arena and that's where there might be one or the other competitive differentiation which is maybe not best discussed on an open mailing list. Cheers Toerless _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-admin@ietf.org Sat Jun 7 22:26:06 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 WAA29341 for ; Sat, 7 Jun 2003 22:26:06 -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 h582P7B12702; Sat, 7 Jun 2003 22:25:07 -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 h582NnB12644 for ; Sat, 7 Jun 2003 22:23:49 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29167 for ; Sat, 7 Jun 2003 22:23:43 -0400 (EDT) Message-Id: <200306080223.WAA29167@ietf.org> To: ssm@ietf.org From: The IESG Date: Sat, 07 Jun 2003 22:23:42 -0400 Subject: [ssm] Document Action: An Overview of Source-Specific Multicast(SSM) Deployment to Informational (Revised) 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: , The IESG has approved the Internet-Draft 'An Overview of Source-Specific Multicast(SSM) Deployment' as an Informational RFC. This document is the product of the Source-Specific Multicast Working Group. The IESG contact persons are Bill Fenner and Alex Zinin. RFC Editor Note: Replace the author list with: Supratik Bhattacharyya (Editor) Sprint Section 6.1, para 1, line 4: OLD: policies being proposed [20], which recommends ... ^^ NEW: policies being proposed [9], which recommends ... Section 6.4, para 1, line 6: OLD: provided by IGMP version 3 [3] and MLD version 2 [22]. These ^^ NEW: provided by IGMP version 3 [3] and MLD version 2 [20]. These Section 7, para 2, line 4: OLD: [20] states ... ^^ NEW: [9] states ... Section 9. Acknowledgments ADD right after the section name: Christophe Diot, Leonard Giuliano, Rob Rockell, John Meylor, David Meyer, Greg Shepherd, and Brian Haberman were the major contributors to the document. Section 10 Change section name to "Informative References" Section 12. Author information: Leave only info for Supratik. Put information about others in a new section called "13. Contributors" _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Sat Jun 7 22:26:40 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 WAA29362 for ; Sat, 7 Jun 2003 22:26:40 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h582QG812728 for ssm-archive@odin.ietf.org; Sat, 7 Jun 2003 22:26:16 -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 h582QGB12725 for ; Sat, 7 Jun 2003 22:26:16 -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 WAA29359 for ; Sat, 7 Jun 2003 22:26:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Opqv-0007nO-00 for ssm-web-archive@ietf.org; Sat, 07 Jun 2003 22:24:13 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Opqt-0007nK-00 for ssm-web-archive@ietf.org; Sat, 07 Jun 2003 22:24: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 h582P7B12702; Sat, 7 Jun 2003 22:25:07 -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 h582NnB12644 for ; Sat, 7 Jun 2003 22:23:49 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29167 for ; Sat, 7 Jun 2003 22:23:43 -0400 (EDT) Message-Id: <200306080223.WAA29167@ietf.org> To: ssm@ietf.org From: The IESG Date: Sat, 07 Jun 2003 22:23:42 -0400 Subject: [ssm] Document Action: An Overview of Source-Specific Multicast(SSM) Deployment to Informational (Revised) 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: , The IESG has approved the Internet-Draft 'An Overview of Source-Specific Multicast(SSM) Deployment' as an Informational RFC. This document is the product of the Source-Specific Multicast Working Group. The IESG contact persons are Bill Fenner and Alex Zinin. RFC Editor Note: Replace the author list with: Supratik Bhattacharyya (Editor) Sprint Section 6.1, para 1, line 4: OLD: policies being proposed [20], which recommends ... ^^ NEW: policies being proposed [9], which recommends ... Section 6.4, para 1, line 6: OLD: provided by IGMP version 3 [3] and MLD version 2 [22]. These ^^ NEW: provided by IGMP version 3 [3] and MLD version 2 [20]. These Section 7, para 2, line 4: OLD: [20] states ... ^^ NEW: [9] states ... Section 9. Acknowledgments ADD right after the section name: Christophe Diot, Leonard Giuliano, Rob Rockell, John Meylor, David Meyer, Greg Shepherd, and Brian Haberman were the major contributors to the document. Section 10 Change section name to "Informative References" Section 12. Author information: Leave only info for Supratik. Put information about others in a new section called "13. Contributors" _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-admin@ietf.org Tue Jun 10 09:09: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 JAA27464 for ; Tue, 10 Jun 2003 09:09:22 -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 h5AD7vB20042; Tue, 10 Jun 2003 09:07: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 h5AD55B19004 for ; Tue, 10 Jun 2003 09:05:05 -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 JAA27228 for ; Tue, 10 Jun 2003 09:05:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PimB-0005YH-00 for ssm@ietf.org; Tue, 10 Jun 2003 09:02:59 -0400 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx with esmtp (Exim 4.12) id 19PimA-0005YD-00 for ssm@ietf.org; Tue, 10 Jun 2003 09:02:58 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 209F47B4A0; Tue, 10 Jun 2003 09:05:00 -0400 (EDT) Received: from magic.internet2.edu (aa106.internet2.edu [207.75.164.106]) by basie.internet2.edu (Postfix) with ESMTP id 16F1D7B4B3; Tue, 10 Jun 2003 09:04:59 -0400 (EDT) Message-Id: <5.1.0.14.2.20030610085539.023c1740@mail.internet2.edu> X-Sender: jzeeff@mail.internet2.edu X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 10 Jun 2003 09:04:52 -0400 To: Toerless Eckert From: Jon Zeeff Subject: Re: [ssm] Document Action: An Overview of Source-Specific Multicast(SSM) Deployment to Informational Cc: Bill Fenner , ssm@ietf.org In-Reply-To: <20030606201936.GI16697@cypher.cisco.com> References: <5.1.0.14.2.20030606144813.01d03370@mail.internet2.edu> <200306040550.h545oaD08547@windsor.research.att.com> <5.1.0.14.2.20030606144813.01d03370@mail.internet2.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by AMaViS 0.3.12pre8 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: , > From my experience, windows XP does send IGMPv2 reports if it sees IGMPv2 > queries. >It MUST do this according to the IGMPv3 spec. So if I do manage to get my LAN completely IGMPv3 capable and thus allow the use of SSM, all it takes is one person plugging in a machine running IGMPv2 and SSM breaks. This probably means that SSM is unimplementable except in some special cases (example: one host per vlan). >So, as far as easy gradual migration to SSM with DoS attack prevention is >concerned, >this has almost completely been ignored by the IETF process. I see similar lack of concern about real world security in wireless routing protocols (and DHCP and IPv6 and PIM and ...). Thanks for the info. _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Tue Jun 10 09:09:58 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 JAA27556 for ; Tue, 10 Jun 2003 09:09:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5AD9Wn20123 for ssm-archive@odin.ietf.org; Tue, 10 Jun 2003 09:09:32 -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 h5AD9WB20120 for ; Tue, 10 Jun 2003 09:09:32 -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 JAA27482 for ; Tue, 10 Jun 2003 09:09:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PiqU-0005d0-00 for ssm-web-archive@ietf.org; Tue, 10 Jun 2003 09:07:26 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PiqT-0005cw-00 for ssm-web-archive@ietf.org; Tue, 10 Jun 2003 09:07:25 -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 h5AD7vB20042; Tue, 10 Jun 2003 09:07: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 h5AD55B19004 for ; Tue, 10 Jun 2003 09:05:05 -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 JAA27228 for ; Tue, 10 Jun 2003 09:05:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PimB-0005YH-00 for ssm@ietf.org; Tue, 10 Jun 2003 09:02:59 -0400 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx with esmtp (Exim 4.12) id 19PimA-0005YD-00 for ssm@ietf.org; Tue, 10 Jun 2003 09:02:58 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 209F47B4A0; Tue, 10 Jun 2003 09:05:00 -0400 (EDT) Received: from magic.internet2.edu (aa106.internet2.edu [207.75.164.106]) by basie.internet2.edu (Postfix) with ESMTP id 16F1D7B4B3; Tue, 10 Jun 2003 09:04:59 -0400 (EDT) Message-Id: <5.1.0.14.2.20030610085539.023c1740@mail.internet2.edu> X-Sender: jzeeff@mail.internet2.edu X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 10 Jun 2003 09:04:52 -0400 To: Toerless Eckert From: Jon Zeeff Subject: Re: [ssm] Document Action: An Overview of Source-Specific Multicast(SSM) Deployment to Informational Cc: Bill Fenner , ssm@ietf.org In-Reply-To: <20030606201936.GI16697@cypher.cisco.com> References: <5.1.0.14.2.20030606144813.01d03370@mail.internet2.edu> <200306040550.h545oaD08547@windsor.research.att.com> <5.1.0.14.2.20030606144813.01d03370@mail.internet2.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by AMaViS 0.3.12pre8 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: , > From my experience, windows XP does send IGMPv2 reports if it sees IGMPv2 > queries. >It MUST do this according to the IGMPv3 spec. So if I do manage to get my LAN completely IGMPv3 capable and thus allow the use of SSM, all it takes is one person plugging in a machine running IGMPv2 and SSM breaks. This probably means that SSM is unimplementable except in some special cases (example: one host per vlan). >So, as far as easy gradual migration to SSM with DoS attack prevention is >concerned, >this has almost completely been ignored by the IETF process. I see similar lack of concern about real world security in wireless routing protocols (and DHCP and IPv6 and PIM and ...). Thanks for the info. _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-admin@ietf.org Tue Jun 10 10:05:34 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 KAA00896 for ; Tue, 10 Jun 2003 10:05:34 -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 h5AE4TB24190; Tue, 10 Jun 2003 10:04: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 h5AE0IB24023 for ; Tue, 10 Jun 2003 10:00: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 KAA00448 for ; Tue, 10 Jun 2003 10:00:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pjdb-0006Vc-00 for ssm@ietf.org; Tue, 10 Jun 2003 09:58:11 -0400 Received: from sophia.inria.fr ([138.96.64.20]) by ietf-mx with esmtp (Exim 4.12) id 19PjdZ-0006VO-00 for ssm@ietf.org; Tue, 10 Jun 2003 09:58:10 -0400 Received: from localhost (odie.inria.fr [138.96.88.52]) by sophia.inria.fr (8.12.8/8.12.5) with ESMTP id h5ADxXvK026856; Tue, 10 Jun 2003 15:59:33 +0200 Date: Tue, 10 Jun 2003 15:59:31 +0200 (MEST) Message-Id: <20030610.155931.117536967.Hitoshi.Asaeda@sophia.inria.fr> To: jzeeff@internet2.edu Cc: eckert@cisco.com, fenner@research.att.com, ssm@ietf.org Subject: Re: [ssm] Document Action: An Overview of Source-Specific Multicast(SSM) Deployment to Informational From: Hitoshi Asaeda In-Reply-To: <5.1.0.14.2.20030610085539.023c1740@mail.internet2.edu> References: <5.1.0.14.2.20030606144813.01d03370@mail.internet2.edu> <20030606201936.GI16697@cypher.cisco.com> <5.1.0.14.2.20030610085539.023c1740@mail.internet2.edu> 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 > > From my experience, windows XP does send IGMPv2 reports if it sees IGMPv2 > > queries. > >It MUST do this according to the IGMPv3 spec. > > So if I do manage to get my LAN completely IGMPv3 capable and thus allow > the use of SSM, all it takes is one person > plugging in a machine running IGMPv2 and SSM breaks. This probably means > that SSM is unimplementable except > in some special cases (example: one host per vlan). In fact, and unfortunately, you are right. There was some lack of important statements in IGMPv3. One is a following sentence: "the Querier continues to send IGMPv3 queries, regardless of its Multicast Address Compatibility Mode." This should be included in the RFC. But it was too late. Actually, since we've found the problem before the MLDv2's last-call, it is included in Sect.8.3.2 of draft-vida-mld-v2-07.txt, though. Other is something related to "host compatibility mode" which I post the problem in MAGMA ML. But I heard this mail was also too late. Yes, it is also included in MLDv2's I-D (Sect.10.1) as follows: "A forged Version 1 Query message will put MLDv2 listeners on that link in MLDv1 Host Compatibility Mode. This scenario can be avoided by providing MLDv2 hosts with a configuration option to ignore Version 1 messages completely." FYI, my IGMPv3/MLDv2 implementations (incl. KAME) support them, anyway. -- Hitoshi Asaeda p.s. "IGMPv3 addendum" is the solution? _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Tue Jun 10 10:06:11 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 KAA00989 for ; Tue, 10 Jun 2003 10:06:10 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5AE5j624306 for ssm-archive@odin.ietf.org; Tue, 10 Jun 2003 10:05:45 -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 h5AE5jB24303 for ; Tue, 10 Jun 2003 10:05:45 -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 KAA00920 for ; Tue, 10 Jun 2003 10:05:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pjis-0006Yw-00 for ssm-web-archive@ietf.org; Tue, 10 Jun 2003 10:03:38 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Pjir-0006Yt-00 for ssm-web-archive@ietf.org; Tue, 10 Jun 2003 10:03:37 -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 h5AE4TB24190; Tue, 10 Jun 2003 10:04: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 h5AE0IB24023 for ; Tue, 10 Jun 2003 10:00: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 KAA00448 for ; Tue, 10 Jun 2003 10:00:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pjdb-0006Vc-00 for ssm@ietf.org; Tue, 10 Jun 2003 09:58:11 -0400 Received: from sophia.inria.fr ([138.96.64.20]) by ietf-mx with esmtp (Exim 4.12) id 19PjdZ-0006VO-00 for ssm@ietf.org; Tue, 10 Jun 2003 09:58:10 -0400 Received: from localhost (odie.inria.fr [138.96.88.52]) by sophia.inria.fr (8.12.8/8.12.5) with ESMTP id h5ADxXvK026856; Tue, 10 Jun 2003 15:59:33 +0200 Date: Tue, 10 Jun 2003 15:59:31 +0200 (MEST) Message-Id: <20030610.155931.117536967.Hitoshi.Asaeda@sophia.inria.fr> To: jzeeff@internet2.edu Cc: eckert@cisco.com, fenner@research.att.com, ssm@ietf.org Subject: Re: [ssm] Document Action: An Overview of Source-Specific Multicast(SSM) Deployment to Informational From: Hitoshi Asaeda In-Reply-To: <5.1.0.14.2.20030610085539.023c1740@mail.internet2.edu> References: <5.1.0.14.2.20030606144813.01d03370@mail.internet2.edu> <20030606201936.GI16697@cypher.cisco.com> <5.1.0.14.2.20030610085539.023c1740@mail.internet2.edu> 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 > > From my experience, windows XP does send IGMPv2 reports if it sees IGMPv2 > > queries. > >It MUST do this according to the IGMPv3 spec. > > So if I do manage to get my LAN completely IGMPv3 capable and thus allow > the use of SSM, all it takes is one person > plugging in a machine running IGMPv2 and SSM breaks. This probably means > that SSM is unimplementable except > in some special cases (example: one host per vlan). In fact, and unfortunately, you are right. There was some lack of important statements in IGMPv3. One is a following sentence: "the Querier continues to send IGMPv3 queries, regardless of its Multicast Address Compatibility Mode." This should be included in the RFC. But it was too late. Actually, since we've found the problem before the MLDv2's last-call, it is included in Sect.8.3.2 of draft-vida-mld-v2-07.txt, though. Other is something related to "host compatibility mode" which I post the problem in MAGMA ML. But I heard this mail was also too late. Yes, it is also included in MLDv2's I-D (Sect.10.1) as follows: "A forged Version 1 Query message will put MLDv2 listeners on that link in MLDv1 Host Compatibility Mode. This scenario can be avoided by providing MLDv2 hosts with a configuration option to ignore Version 1 messages completely." FYI, my IGMPv3/MLDv2 implementations (incl. KAME) support them, anyway. -- Hitoshi Asaeda p.s. "IGMPv3 addendum" is the solution? _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-admin@ietf.org Tue Jun 10 10:45:28 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 KAA03604 for ; Tue, 10 Jun 2003 10:45:28 -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 h5AEifB28473; Tue, 10 Jun 2003 10:44:41 -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 h5AEeXB28269 for ; Tue, 10 Jun 2003 10:40:33 -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 KAA03493 for ; Tue, 10 Jun 2003 10:40:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PkGX-0006zz-00 for ssm@ietf.org; Tue, 10 Jun 2003 10:38:25 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by ietf-mx with esmtp (Exim 4.12) id 19PkGW-0006zw-00 for ssm@ietf.org; Tue, 10 Jun 2003 10:38:25 -0400 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h5AEdtCL028271; Tue, 10 Jun 2003 07:39:55 -0700 (PDT) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id HAA07613; Tue, 10 Jun 2003 07:39:55 -0700 (PDT) Date: Tue, 10 Jun 2003 07:39:54 -0700 From: Toerless Eckert To: Jon Zeeff Cc: Toerless Eckert , Bill Fenner , ssm@ietf.org Subject: Re: [ssm] Document Action: An Overview of Source-Specific Multicast(SSM) Deployment to Informational Message-ID: <20030610143954.GK23388@cypher.cisco.com> References: <5.1.0.14.2.20030606144813.01d03370@mail.internet2.edu> <200306040550.h545oaD08547@windsor.research.att.com> <5.1.0.14.2.20030606144813.01d03370@mail.internet2.edu> <5.1.0.14.2.20030610085539.023c1740@mail.internet2.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20030610085539.023c1740@mail.internet2.edu> User-Agent: Mutt/1.4i 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, Jun 10, 2003 at 09:04:52AM -0400, Jon Zeeff wrote: > > > >From my experience, windows XP does send IGMPv2 reports if it sees IGMPv2 > >queries. > >It MUST do this according to the IGMPv3 spec. > > So if I do manage to get my LAN completely IGMPv3 capable and thus allow > the use of SSM, all it takes is one person > plugging in a machine running IGMPv2 and SSM breaks. This probably means > that SSM is unimplementable except > in some special cases (example: one host per vlan). While i completely agree that IGMPv3 sucks if all you want is SSM mainly because it's is some orders of magnitue unnecessarily too complex for that purpose. The actuall attack scenarios can all be solved: The real issue is in the presence of older routers sending IGMPv1 or IGMPv2 queries because they cause a host to (MUST) fall back to IGMPv1/v2 reports, whereas other hosts IGMPv1/v2 reports MAY just cause this (unlikely given that it makes a host implementation much more complex). So, there is definitely a conflict of interest between SSM and backward compatbility in IGMPv3: You do not want to have an older router on a network in which you wan to run SSM. Now, for all i care, everything RFC3376 says only applies to legally present entities in a network, eg: Just because RFC3376 demands properties from implementations does not imply uncontrolled deployment. RFC3376 itself will not ensure complete protection against DoS attacks by unwanted IGMPv1/IGMPv2 group queries, - rather the opposite -, but in most deployments you can quite well ensure such protection. The magic formula is quite simple: Put an intelligent layer2 switch into the network and connect only one host (or one set of hosts in a common trust domain) per switched L2 port and solve access control and DoS protection on the switch. That actually is the most common wired ethernet deployment today and IGMPv2 queries aren't the only DoS reason why such deployments are typically considered necessary to guarantee protection in an even moderately friendly environment. Heck, if you go into potentially hostile deployments, you even see stronger efforts of L2 protection, and those have been put into place for much more fundamental L2 issues than just what we're talking about here (see for example private VLANs on Cisco Catalyst switches - and likely similar technologies in other vendor products). Do all L2 switches provide for good protection against unwanted IGMPv2 queries - heck, no, but most of them could via simple software updates: Unless security is strongly being taken care of by the IETF protocol process, it is left up to vendors and actual customer demand. Talk to your vendor of choice ;-) Sure, it would have been nicer if the whole IGMPv3 spec process would have been revisited much harder in the face of IGMPv3 requirements - we tried, but we clearly reached a wall there given the long time in the process that was spend without thinking about SSM already. > >So, as far as easy gradual migration to SSM with DoS attack prevention is > >concerned, this has almost completely been ignored by the IETF process. > > I see similar lack of concern about real world security in wireless routing > protocols (and DHCP and IPv6 and PIM and ...). Well, it's as simple as this: IGMPv3 was NOT MADE for SSM, so it's a bit hart to shift the blame onto it completely. Once there is sufficient interest in SSM and people come to realize that SSM alone is sufficient in many cases on hosts, one could make much stronger statements about an SSM subset (and extensions) of IGMPv3 implementations in hosts: subset: - Ignore all IGMPv1/v2 queries - Don't implent any exclude mode reports extension: - trigger unsolicited IS_INCLUDE mode reports after 60 seconds without a query. Makes a really simple & safe SSM only implementation, and is completely compatible with IGMPv3 routers. But as long as the host needs to support both ASM _and_ SSM, it is really hard to strip down the complexity: Even that part of "which group is SSM, which is ASM" is contentuous. I for once am a strong proponent of using SSM also within 239/8 because of admin scoping, so how does a host determine wether a group is SSM or not ? MSNIP SSM range ? Well, that's another requirement for a host stack, and if i look at how long it takes for new requirements to be implemented into host stack *oh well*... Cheers Toerless _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Tue Jun 10 10:46: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 KAA03656 for ; Tue, 10 Jun 2003 10:46:02 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5AEjcD28613 for ssm-archive@odin.ietf.org; Tue, 10 Jun 2003 10:45:38 -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 h5AEjcB28610 for ; Tue, 10 Jun 2003 10:45:38 -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 KAA03629 for ; Tue, 10 Jun 2003 10:45:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PkLS-00072m-00 for ssm-web-archive@ietf.org; Tue, 10 Jun 2003 10:43:30 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PkLS-00072j-00 for ssm-web-archive@ietf.org; Tue, 10 Jun 2003 10:43:30 -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 h5AEifB28473; Tue, 10 Jun 2003 10:44:41 -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 h5AEeXB28269 for ; Tue, 10 Jun 2003 10:40:33 -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 KAA03493 for ; Tue, 10 Jun 2003 10:40:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PkGX-0006zz-00 for ssm@ietf.org; Tue, 10 Jun 2003 10:38:25 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by ietf-mx with esmtp (Exim 4.12) id 19PkGW-0006zw-00 for ssm@ietf.org; Tue, 10 Jun 2003 10:38:25 -0400 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h5AEdtCL028271; Tue, 10 Jun 2003 07:39:55 -0700 (PDT) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id HAA07613; Tue, 10 Jun 2003 07:39:55 -0700 (PDT) Date: Tue, 10 Jun 2003 07:39:54 -0700 From: Toerless Eckert To: Jon Zeeff Cc: Toerless Eckert , Bill Fenner , ssm@ietf.org Subject: Re: [ssm] Document Action: An Overview of Source-Specific Multicast(SSM) Deployment to Informational Message-ID: <20030610143954.GK23388@cypher.cisco.com> References: <5.1.0.14.2.20030606144813.01d03370@mail.internet2.edu> <200306040550.h545oaD08547@windsor.research.att.com> <5.1.0.14.2.20030606144813.01d03370@mail.internet2.edu> <5.1.0.14.2.20030610085539.023c1740@mail.internet2.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20030610085539.023c1740@mail.internet2.edu> User-Agent: Mutt/1.4i 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, Jun 10, 2003 at 09:04:52AM -0400, Jon Zeeff wrote: > > > >From my experience, windows XP does send IGMPv2 reports if it sees IGMPv2 > >queries. > >It MUST do this according to the IGMPv3 spec. > > So if I do manage to get my LAN completely IGMPv3 capable and thus allow > the use of SSM, all it takes is one person > plugging in a machine running IGMPv2 and SSM breaks. This probably means > that SSM is unimplementable except > in some special cases (example: one host per vlan). While i completely agree that IGMPv3 sucks if all you want is SSM mainly because it's is some orders of magnitue unnecessarily too complex for that purpose. The actuall attack scenarios can all be solved: The real issue is in the presence of older routers sending IGMPv1 or IGMPv2 queries because they cause a host to (MUST) fall back to IGMPv1/v2 reports, whereas other hosts IGMPv1/v2 reports MAY just cause this (unlikely given that it makes a host implementation much more complex). So, there is definitely a conflict of interest between SSM and backward compatbility in IGMPv3: You do not want to have an older router on a network in which you wan to run SSM. Now, for all i care, everything RFC3376 says only applies to legally present entities in a network, eg: Just because RFC3376 demands properties from implementations does not imply uncontrolled deployment. RFC3376 itself will not ensure complete protection against DoS attacks by unwanted IGMPv1/IGMPv2 group queries, - rather the opposite -, but in most deployments you can quite well ensure such protection. The magic formula is quite simple: Put an intelligent layer2 switch into the network and connect only one host (or one set of hosts in a common trust domain) per switched L2 port and solve access control and DoS protection on the switch. That actually is the most common wired ethernet deployment today and IGMPv2 queries aren't the only DoS reason why such deployments are typically considered necessary to guarantee protection in an even moderately friendly environment. Heck, if you go into potentially hostile deployments, you even see stronger efforts of L2 protection, and those have been put into place for much more fundamental L2 issues than just what we're talking about here (see for example private VLANs on Cisco Catalyst switches - and likely similar technologies in other vendor products). Do all L2 switches provide for good protection against unwanted IGMPv2 queries - heck, no, but most of them could via simple software updates: Unless security is strongly being taken care of by the IETF protocol process, it is left up to vendors and actual customer demand. Talk to your vendor of choice ;-) Sure, it would have been nicer if the whole IGMPv3 spec process would have been revisited much harder in the face of IGMPv3 requirements - we tried, but we clearly reached a wall there given the long time in the process that was spend without thinking about SSM already. > >So, as far as easy gradual migration to SSM with DoS attack prevention is > >concerned, this has almost completely been ignored by the IETF process. > > I see similar lack of concern about real world security in wireless routing > protocols (and DHCP and IPv6 and PIM and ...). Well, it's as simple as this: IGMPv3 was NOT MADE for SSM, so it's a bit hart to shift the blame onto it completely. Once there is sufficient interest in SSM and people come to realize that SSM alone is sufficient in many cases on hosts, one could make much stronger statements about an SSM subset (and extensions) of IGMPv3 implementations in hosts: subset: - Ignore all IGMPv1/v2 queries - Don't implent any exclude mode reports extension: - trigger unsolicited IS_INCLUDE mode reports after 60 seconds without a query. Makes a really simple & safe SSM only implementation, and is completely compatible with IGMPv3 routers. But as long as the host needs to support both ASM _and_ SSM, it is really hard to strip down the complexity: Even that part of "which group is SSM, which is ASM" is contentuous. I for once am a strong proponent of using SSM also within 239/8 because of admin scoping, so how does a host determine wether a group is SSM or not ? MSNIP SSM range ? Well, that's another requirement for a host stack, and if i look at how long it takes for new requirements to be implemented into host stack *oh well*... Cheers Toerless _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-admin@ietf.org Tue Jun 10 10:47:43 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 KAA03794 for ; Tue, 10 Jun 2003 10:47:42 -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 h5AEl4B28714; Tue, 10 Jun 2003 10:47:04 -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 h5AEkjB28691 for ; Tue, 10 Jun 2003 10:46:45 -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 KAA03740 for ; Tue, 10 Jun 2003 10:46:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PkMX-000745-00 for ssm@ietf.org; Tue, 10 Jun 2003 10:44:37 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by ietf-mx with esmtp (Exim 4.12) id 19PkMW-000736-00 for ssm@ietf.org; Tue, 10 Jun 2003 10:44:36 -0400 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h5AEjxjc021551; Tue, 10 Jun 2003 07:45:59 -0700 (PDT) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id HAA08477; Tue, 10 Jun 2003 07:45:58 -0700 (PDT) Date: Tue, 10 Jun 2003 07:45:58 -0700 From: Toerless Eckert To: Hitoshi Asaeda Cc: jzeeff@internet2.edu, eckert@cisco.com, fenner@research.att.com, ssm@ietf.org Subject: Re: [ssm] Document Action: An Overview of Source-Specific Multicast(SSM) Deployment to Informational Message-ID: <20030610144558.GL23388@cypher.cisco.com> References: <5.1.0.14.2.20030606144813.01d03370@mail.internet2.edu> <20030606201936.GI16697@cypher.cisco.com> <5.1.0.14.2.20030610085539.023c1740@mail.internet2.edu> <20030610.155931.117536967.Hitoshi.Asaeda@sophia.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030610.155931.117536967.Hitoshi.Asaeda@sophia.inria.fr> User-Agent: Mutt/1.4i 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, Jun 10, 2003 at 03:59:31PM +0200, Hitoshi Asaeda wrote: > In fact, and unfortunately, you are right. > There was some lack of important statements in IGMPv3. Well, yes, but that decision was intentional back then by proponents that wanted to ensuer maximum automatic backward compatibility. > One is a following sentence: > "the Querier continues to send IGMPv3 queries, regardless of > its Multicast Address Compatibility Mode." > This should be included in the RFC. But it was too late. Actually, > since we've found the problem before the MLDv2's last-call, it is > included in Sect.8.3.2 of draft-vida-mld-v2-07.txt, though. Ok, so in MLD i need not only start to send MLDv1 reports, i also have to have a smaller IP address to win and become the querier ? How much does this effectively buy me ? > Other is something related to "host compatibility mode" which I post > the problem in MAGMA ML. > > But I heard this mail was also too late. Yes, it is also included in > MLDv2's I-D (Sect.10.1) as follows: > "A forged Version 1 Query message will put MLDv2 listeners on > that link in MLDv1 Host Compatibility Mode. This scenario > can be avoided by providing MLDv2 hosts with a configuration > option to ignore Version 1 messages completely." Sure, such configuration options will be all over us and make deployment even more complex. You can pretty much figure that only the default behaviour will be what 90% of people will have installed. > FYI, my IGMPv3/MLDv2 implementations (incl. KAME) support them, anyway. Is it on by default ? Cheers Toerless _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Tue Jun 10 10:48: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 KAA03821 for ; Tue, 10 Jun 2003 10:48:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5AElqQ28778 for ssm-archive@odin.ietf.org; Tue, 10 Jun 2003 10:47:52 -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 h5AElqB28775 for ; Tue, 10 Jun 2003 10:47:52 -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 KAA03811 for ; Tue, 10 Jun 2003 10:47:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PkNc-00074g-00 for ssm-web-archive@ietf.org; Tue, 10 Jun 2003 10:45:44 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PkNb-00074d-00 for ssm-web-archive@ietf.org; Tue, 10 Jun 2003 10:45:43 -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 h5AEl4B28714; Tue, 10 Jun 2003 10:47:04 -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 h5AEkjB28691 for ; Tue, 10 Jun 2003 10:46:45 -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 KAA03740 for ; Tue, 10 Jun 2003 10:46:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PkMX-000745-00 for ssm@ietf.org; Tue, 10 Jun 2003 10:44:37 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by ietf-mx with esmtp (Exim 4.12) id 19PkMW-000736-00 for ssm@ietf.org; Tue, 10 Jun 2003 10:44:36 -0400 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h5AEjxjc021551; Tue, 10 Jun 2003 07:45:59 -0700 (PDT) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id HAA08477; Tue, 10 Jun 2003 07:45:58 -0700 (PDT) Date: Tue, 10 Jun 2003 07:45:58 -0700 From: Toerless Eckert To: Hitoshi Asaeda Cc: jzeeff@internet2.edu, eckert@cisco.com, fenner@research.att.com, ssm@ietf.org Subject: Re: [ssm] Document Action: An Overview of Source-Specific Multicast(SSM) Deployment to Informational Message-ID: <20030610144558.GL23388@cypher.cisco.com> References: <5.1.0.14.2.20030606144813.01d03370@mail.internet2.edu> <20030606201936.GI16697@cypher.cisco.com> <5.1.0.14.2.20030610085539.023c1740@mail.internet2.edu> <20030610.155931.117536967.Hitoshi.Asaeda@sophia.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030610.155931.117536967.Hitoshi.Asaeda@sophia.inria.fr> User-Agent: Mutt/1.4i 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, Jun 10, 2003 at 03:59:31PM +0200, Hitoshi Asaeda wrote: > In fact, and unfortunately, you are right. > There was some lack of important statements in IGMPv3. Well, yes, but that decision was intentional back then by proponents that wanted to ensuer maximum automatic backward compatibility. > One is a following sentence: > "the Querier continues to send IGMPv3 queries, regardless of > its Multicast Address Compatibility Mode." > This should be included in the RFC. But it was too late. Actually, > since we've found the problem before the MLDv2's last-call, it is > included in Sect.8.3.2 of draft-vida-mld-v2-07.txt, though. Ok, so in MLD i need not only start to send MLDv1 reports, i also have to have a smaller IP address to win and become the querier ? How much does this effectively buy me ? > Other is something related to "host compatibility mode" which I post > the problem in MAGMA ML. > > But I heard this mail was also too late. Yes, it is also included in > MLDv2's I-D (Sect.10.1) as follows: > "A forged Version 1 Query message will put MLDv2 listeners on > that link in MLDv1 Host Compatibility Mode. This scenario > can be avoided by providing MLDv2 hosts with a configuration > option to ignore Version 1 messages completely." Sure, such configuration options will be all over us and make deployment even more complex. You can pretty much figure that only the default behaviour will be what 90% of people will have installed. > FYI, my IGMPv3/MLDv2 implementations (incl. KAME) support them, anyway. Is it on by default ? Cheers Toerless _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-admin@ietf.org Tue Jun 10 11:32: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 LAA05631 for ; Tue, 10 Jun 2003 11:32:19 -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 h5AFVLB31723; Tue, 10 Jun 2003 11:31:21 -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 h5AFOGB31311 for ; Tue, 10 Jun 2003 11:24:16 -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 LAA05314 for ; Tue, 10 Jun 2003 11:24:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pkwu-0007Nh-00 for ssm@ietf.org; Tue, 10 Jun 2003 11:22:12 -0400 Received: from sophia.inria.fr ([138.96.64.20]) by ietf-mx with esmtp (Exim 4.12) id 19Pkwt-0007Nb-00 for ssm@ietf.org; Tue, 10 Jun 2003 11:22:11 -0400 Received: from localhost (odie.inria.fr [138.96.88.52]) by sophia.inria.fr (8.12.8/8.12.5) with ESMTP id h5AFNXvK003176; Tue, 10 Jun 2003 17:23:33 +0200 Date: Tue, 10 Jun 2003 17:23:32 +0200 (MEST) Message-Id: <20030610.172332.128597013.Hitoshi.Asaeda@sophia.inria.fr> To: eckert@cisco.com Cc: ssm@ietf.org Subject: Re: [ssm] Document Action: An Overview of Source-Specific Multicast(SSM) Deployment to Informational From: Hitoshi Asaeda In-Reply-To: <20030610144558.GL23388@cypher.cisco.com> References: <5.1.0.14.2.20030610085539.023c1740@mail.internet2.edu> <20030610.155931.117536967.Hitoshi.Asaeda@sophia.inria.fr> <20030610144558.GL23388@cypher.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 > Ok, so in MLD i need not only start to send MLDv1 reports, i also have to > have a smaller IP address to win and become the querier ? How much > does this effectively buy me ? Maybe I don't understand your question.. but, there is no change about querier selection. (What is the relation to my last comment?) > > "A forged Version 1 Query message will put MLDv2 listeners on > > that link in MLDv1 Host Compatibility Mode. This scenario > > can be avoided by providing MLDv2 hosts with a configuration > > option to ignore Version 1 messages completely." > > Sure, such configuration options will be all over us and make deployment > even more complex. You can pretty much figure that only the default > behaviour will be what 90% of people will have installed. I prefer to have an option to fix the problem rather than close my eyes, even though it may make some additional complexity. (But it's really complex?) Anyway, in a README file of IGMPv3 imple., I specify as follws: .... After this static configuration is done, any old IGMP Query message doesn't affect to change the compatibility mode. Remember this is useful only when correct upstream router(s) must be IGMPv3 capable and you want to filter out or ignore some bogus or unneeded old version's Report and Query messages transfered by irregular nodes. This configuration affects all interfaces of the box. Note that this configuration is not mentioned in a spec and turned off as the kernel's default value. I've never said host compat is *always* wrong. But we may need to bypass this automatic mode change *for some cases*. And at this moment, I don't have other good idea to bypass it. Or, do you have another solution to bypass the DoS Jon Zeeff mentioned? Or, ignoring the problem is good for the deployment? > > FYI, my IGMPv3/MLDv2 implementations (incl. KAME) support them, anyway. > > Is it on by default ? No. Thanks. -- Hitoshi Asaeda _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Tue Jun 10 11:32:54 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 LAA05662 for ; Tue, 10 Jun 2003 11:32:54 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5AFWQg31825 for ssm-archive@odin.ietf.org; Tue, 10 Jun 2003 11:32:26 -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 h5AFWQB31822 for ; Tue, 10 Jun 2003 11:32:26 -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 LAA05647 for ; Tue, 10 Jun 2003 11:32:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pl4o-0007RY-00 for ssm-web-archive@ietf.org; Tue, 10 Jun 2003 11:30:22 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Pl4n-0007RV-00 for ssm-web-archive@ietf.org; Tue, 10 Jun 2003 11:30:21 -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 h5AFVLB31723; Tue, 10 Jun 2003 11:31:21 -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 h5AFOGB31311 for ; Tue, 10 Jun 2003 11:24:16 -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 LAA05314 for ; Tue, 10 Jun 2003 11:24:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pkwu-0007Nh-00 for ssm@ietf.org; Tue, 10 Jun 2003 11:22:12 -0400 Received: from sophia.inria.fr ([138.96.64.20]) by ietf-mx with esmtp (Exim 4.12) id 19Pkwt-0007Nb-00 for ssm@ietf.org; Tue, 10 Jun 2003 11:22:11 -0400 Received: from localhost (odie.inria.fr [138.96.88.52]) by sophia.inria.fr (8.12.8/8.12.5) with ESMTP id h5AFNXvK003176; Tue, 10 Jun 2003 17:23:33 +0200 Date: Tue, 10 Jun 2003 17:23:32 +0200 (MEST) Message-Id: <20030610.172332.128597013.Hitoshi.Asaeda@sophia.inria.fr> To: eckert@cisco.com Cc: ssm@ietf.org Subject: Re: [ssm] Document Action: An Overview of Source-Specific Multicast(SSM) Deployment to Informational From: Hitoshi Asaeda In-Reply-To: <20030610144558.GL23388@cypher.cisco.com> References: <5.1.0.14.2.20030610085539.023c1740@mail.internet2.edu> <20030610.155931.117536967.Hitoshi.Asaeda@sophia.inria.fr> <20030610144558.GL23388@cypher.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 > Ok, so in MLD i need not only start to send MLDv1 reports, i also have to > have a smaller IP address to win and become the querier ? How much > does this effectively buy me ? Maybe I don't understand your question.. but, there is no change about querier selection. (What is the relation to my last comment?) > > "A forged Version 1 Query message will put MLDv2 listeners on > > that link in MLDv1 Host Compatibility Mode. This scenario > > can be avoided by providing MLDv2 hosts with a configuration > > option to ignore Version 1 messages completely." > > Sure, such configuration options will be all over us and make deployment > even more complex. You can pretty much figure that only the default > behaviour will be what 90% of people will have installed. I prefer to have an option to fix the problem rather than close my eyes, even though it may make some additional complexity. (But it's really complex?) Anyway, in a README file of IGMPv3 imple., I specify as follws: .... After this static configuration is done, any old IGMP Query message doesn't affect to change the compatibility mode. Remember this is useful only when correct upstream router(s) must be IGMPv3 capable and you want to filter out or ignore some bogus or unneeded old version's Report and Query messages transfered by irregular nodes. This configuration affects all interfaces of the box. Note that this configuration is not mentioned in a spec and turned off as the kernel's default value. I've never said host compat is *always* wrong. But we may need to bypass this automatic mode change *for some cases*. And at this moment, I don't have other good idea to bypass it. Or, do you have another solution to bypass the DoS Jon Zeeff mentioned? Or, ignoring the problem is good for the deployment? > > FYI, my IGMPv3/MLDv2 implementations (incl. KAME) support them, anyway. > > Is it on by default ? No. Thanks. -- Hitoshi Asaeda _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-admin@ietf.org Tue Jun 10 12:03: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 MAA06760 for ; Tue, 10 Jun 2003 12:03:20 -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 h5AG2YB02293; Tue, 10 Jun 2003 12:02:34 -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 h5AFxxB01944 for ; Tue, 10 Jun 2003 11:59:59 -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 LAA06674 for ; Tue, 10 Jun 2003 11:59:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PlVS-0007hR-00 for ssm@ietf.org; Tue, 10 Jun 2003 11:57:54 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by ietf-mx with esmtp (Exim 4.12) id 19PlVR-0007h1-00 for ssm@ietf.org; Tue, 10 Jun 2003 11:57:53 -0400 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h5AFxOI2020110; Tue, 10 Jun 2003 08:59:24 -0700 (PDT) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id IAA22954; Tue, 10 Jun 2003 08:59:24 -0700 (PDT) Date: Tue, 10 Jun 2003 08:59:24 -0700 From: Toerless Eckert To: Hitoshi Asaeda Cc: eckert@cisco.com, ssm@ietf.org Subject: Re: [ssm] Document Action: An Overview of Source-Specific Multicast(SSM) Deployment to Informational Message-ID: <20030610155923.GR23388@cypher.cisco.com> References: <5.1.0.14.2.20030610085539.023c1740@mail.internet2.edu> <20030610.155931.117536967.Hitoshi.Asaeda@sophia.inria.fr> <20030610144558.GL23388@cypher.cisco.com> <20030610.172332.128597013.Hitoshi.Asaeda@sophia.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030610.172332.128597013.Hitoshi.Asaeda@sophia.inria.fr> User-Agent: Mutt/1.4i 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, Jun 10, 2003 at 05:23:32PM +0200, Hitoshi Asaeda wrote: > Maybe I don't understand your question.. but, there is no change about > querier selection. (What is the relation to my last comment?) No, i just interpreted your statement incorrectly out of context. Never mind ;-) But: I am not sure how much more the stronger statement in MLDv2 buys. After all, it's the IGMPv3 for SSM spec that states you to ignore any non IGMPv3 (include type) reports within the SSM range, so i am not too much concerned about group mode behavior on the router, the only critical elements is host behaviour and illegal lower version queriers. > > Sure, such configuration options will be all over us and make deployment > > even more complex. You can pretty much figure that only the default > > behaviour will be what 90% of people will have installed. > > I prefer to have an option to fix the problem rather than close my > eyes, even though it may make some additional complexity. (But it's > really complex?) And i prefer to have what's needed be enabled by default so that the 90% population that doesn't want to waste understanding this mess still gets a save and working feature. > Anyway, in a README file of IGMPv3 imple., I specify as follws: > .... > After this static configuration is done, any old IGMP Query > message doesn't affect to change the compatibility mode. > Remember this is useful only when correct upstream router(s) > must be IGMPv3 capable and you want to filter out or ignore > some bogus or unneeded old version's Report and Query messages > transfered by irregular nodes. This configuration affects all > interfaces of the box. > Note that this configuration is not mentioned in a spec and > turned off as the kernel's default value. Very nice. Now how many pizzas does it take for you to enable this by default ? ;-)) (yeah, yeah, i know you can't do this today, see - that's the problem with config options, they are never enabled when you need them). Here's what i would recommend for this protection: Define another kernel flag (maybe force_v3_4_ssm) which you can enable by default. If it is enabled, then you will force yourself into that IGMPv3 mode (like with the flag you already have) only whenever there is at least one active INCLUDE mode membership application running (eg: a socket with an include source list). There's a higher than 90% chance that an application using INCLUDE mode memberships is written for SSM, so there you have your 90% correct by default situation. Sure, this wouldn't work all too well for servers running a lot of different multicast application simultaneously, but those are way below the 90% mark too. And this default could be changed wether or not this is supposed to be desktop or server installation. Even if you don't have this flag enabled by default, you can still have warnings by default: If you're not using IGMPv3 membership reports (eg: querier is older) but you start an application using INCLUDE mode reports, this might be worthy of a syslog to console or the like. There's a lot of things you can do to improve the perception of SSM application users i think. Cheers Toerless > I've never said host compat is *always* wrong. But we may need to > bypass this automatic mode change *for some cases*. And at this > moment, I don't have other good idea to bypass it. > Or, do you have another solution to bypass the DoS Jon Zeeff mentioned? > Or, ignoring the problem is good for the deployment? > > > > FYI, my IGMPv3/MLDv2 implementations (incl. KAME) support them, anyway. > > > > Is it on by default ? > > No. > > Thanks. > -- > Hitoshi Asaeda _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Tue Jun 10 12:03:54 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 MAA06819 for ; Tue, 10 Jun 2003 12:03:54 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5AG3RU02513 for ssm-archive@odin.ietf.org; Tue, 10 Jun 2003 12:03:27 -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 h5AG3RB02510 for ; Tue, 10 Jun 2003 12:03:27 -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 MAA06781 for ; Tue, 10 Jun 2003 12:03:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PlYo-0007j5-00 for ssm-web-archive@ietf.org; Tue, 10 Jun 2003 12:01:22 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PlYo-0007j2-00 for ssm-web-archive@ietf.org; Tue, 10 Jun 2003 12:01:22 -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 h5AG2YB02293; Tue, 10 Jun 2003 12:02:34 -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 h5AFxxB01944 for ; Tue, 10 Jun 2003 11:59:59 -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 LAA06674 for ; Tue, 10 Jun 2003 11:59:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PlVS-0007hR-00 for ssm@ietf.org; Tue, 10 Jun 2003 11:57:54 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by ietf-mx with esmtp (Exim 4.12) id 19PlVR-0007h1-00 for ssm@ietf.org; Tue, 10 Jun 2003 11:57:53 -0400 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h5AFxOI2020110; Tue, 10 Jun 2003 08:59:24 -0700 (PDT) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id IAA22954; Tue, 10 Jun 2003 08:59:24 -0700 (PDT) Date: Tue, 10 Jun 2003 08:59:24 -0700 From: Toerless Eckert To: Hitoshi Asaeda Cc: eckert@cisco.com, ssm@ietf.org Subject: Re: [ssm] Document Action: An Overview of Source-Specific Multicast(SSM) Deployment to Informational Message-ID: <20030610155923.GR23388@cypher.cisco.com> References: <5.1.0.14.2.20030610085539.023c1740@mail.internet2.edu> <20030610.155931.117536967.Hitoshi.Asaeda@sophia.inria.fr> <20030610144558.GL23388@cypher.cisco.com> <20030610.172332.128597013.Hitoshi.Asaeda@sophia.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030610.172332.128597013.Hitoshi.Asaeda@sophia.inria.fr> User-Agent: Mutt/1.4i 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, Jun 10, 2003 at 05:23:32PM +0200, Hitoshi Asaeda wrote: > Maybe I don't understand your question.. but, there is no change about > querier selection. (What is the relation to my last comment?) No, i just interpreted your statement incorrectly out of context. Never mind ;-) But: I am not sure how much more the stronger statement in MLDv2 buys. After all, it's the IGMPv3 for SSM spec that states you to ignore any non IGMPv3 (include type) reports within the SSM range, so i am not too much concerned about group mode behavior on the router, the only critical elements is host behaviour and illegal lower version queriers. > > Sure, such configuration options will be all over us and make deployment > > even more complex. You can pretty much figure that only the default > > behaviour will be what 90% of people will have installed. > > I prefer to have an option to fix the problem rather than close my > eyes, even though it may make some additional complexity. (But it's > really complex?) And i prefer to have what's needed be enabled by default so that the 90% population that doesn't want to waste understanding this mess still gets a save and working feature. > Anyway, in a README file of IGMPv3 imple., I specify as follws: > .... > After this static configuration is done, any old IGMP Query > message doesn't affect to change the compatibility mode. > Remember this is useful only when correct upstream router(s) > must be IGMPv3 capable and you want to filter out or ignore > some bogus or unneeded old version's Report and Query messages > transfered by irregular nodes. This configuration affects all > interfaces of the box. > Note that this configuration is not mentioned in a spec and > turned off as the kernel's default value. Very nice. Now how many pizzas does it take for you to enable this by default ? ;-)) (yeah, yeah, i know you can't do this today, see - that's the problem with config options, they are never enabled when you need them). Here's what i would recommend for this protection: Define another kernel flag (maybe force_v3_4_ssm) which you can enable by default. If it is enabled, then you will force yourself into that IGMPv3 mode (like with the flag you already have) only whenever there is at least one active INCLUDE mode membership application running (eg: a socket with an include source list). There's a higher than 90% chance that an application using INCLUDE mode memberships is written for SSM, so there you have your 90% correct by default situation. Sure, this wouldn't work all too well for servers running a lot of different multicast application simultaneously, but those are way below the 90% mark too. And this default could be changed wether or not this is supposed to be desktop or server installation. Even if you don't have this flag enabled by default, you can still have warnings by default: If you're not using IGMPv3 membership reports (eg: querier is older) but you start an application using INCLUDE mode reports, this might be worthy of a syslog to console or the like. There's a lot of things you can do to improve the perception of SSM application users i think. Cheers Toerless > I've never said host compat is *always* wrong. But we may need to > bypass this automatic mode change *for some cases*. And at this > moment, I don't have other good idea to bypass it. > Or, do you have another solution to bypass the DoS Jon Zeeff mentioned? > Or, ignoring the problem is good for the deployment? > > > > FYI, my IGMPv3/MLDv2 implementations (incl. KAME) support them, anyway. > > > > Is it on by default ? > > No. > > Thanks. > -- > Hitoshi Asaeda _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-admin@ietf.org Tue Jun 10 13:25:41 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 NAA09910 for ; Tue, 10 Jun 2003 13:25:41 -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 h5AHOfB10404; Tue, 10 Jun 2003 13:24:41 -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 h5AHMaB10322 for ; Tue, 10 Jun 2003 13:22:36 -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 NAA09834 for ; Tue, 10 Jun 2003 13:22:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PmnN-0000i9-00 for ssm@ietf.org; Tue, 10 Jun 2003 13:20:29 -0400 Received: from sophia.inria.fr ([138.96.64.20]) by ietf-mx with esmtp (Exim 4.12) id 19PmnM-0000i6-00 for ssm@ietf.org; Tue, 10 Jun 2003 13:20:28 -0400 Received: from localhost (odie.inria.fr [138.96.88.52]) by sophia.inria.fr (8.12.8/8.12.5) with ESMTP id h5AHLgvK017781; Tue, 10 Jun 2003 19:21:42 +0200 Date: Tue, 10 Jun 2003 19:21:41 +0200 (MEST) Message-Id: <20030610.192141.129511487.Hitoshi.Asaeda@sophia.inria.fr> To: eckert@cisco.com Cc: ssm@ietf.org Subject: Re: [ssm] Document Action: An Overview of Source-Specific Multicast(SSM) Deployment to Informational From: Hitoshi Asaeda In-Reply-To: <20030610155923.GR23388@cypher.cisco.com> References: <20030610144558.GL23388@cypher.cisco.com> <20030610.172332.128597013.Hitoshi.Asaeda@sophia.inria.fr> <20030610155923.GR23388@cypher.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 Toerless, > No, i just interpreted your statement incorrectly out of context. Never mind ;-) Okay. :) > But: I am not sure how much more the stronger statement in MLDv2 > buys. After all, it's the IGMPv3 for SSM spec that states you to ignore > any non IGMPv3 (include type) reports within the SSM range, so i am > not too much concerned about group mode behavior on the router, the > only critical elements is host behaviour and illegal lower version queriers. No. I mean, whether the multicast address is within the SSM range or not, and whether the multicast routers compatibility mode is v3 or not, IGMPv3 capable router SHOULD always send IGMPv3 General query. It SHOULD NOT send IGMPv1/v2 query in order to avoid that the host compatibility mode of IGMPv3 capable node is switched to v1/v2 by such downgraded General query. Due to this rule, the v3 capable node switches its compat mode only when v1/v2 router, which means "non-upgraded router", appears on the link (with sending v1/v2 General query). It is in fact no problem for non-upgraded *legal* end-nodes since they can only look 8 bytes from the top of the query message. So, we would be able to guarantee the interoperability as well. Further if you want to avoid the mode switch by the v1/v2 router, then you can configure the compat mode disable by "statically". But as we agreed, this should not be the default. These situations are same of MLDv2. This is my thought. ...snip... > Even if you don't have this flag enabled by default, you can still have > warnings by default: If you're not using IGMPv3 membership reports > (eg: querier is older) but you start an application using INCLUDE mode > reports, this might be worthy of a syslog to console or the like. > > There's a lot of things you can do to improve the perception of SSM > application users i think. Sounds interesting. I would think it. Thanks. -- Hitoshi Asaeda _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Tue Jun 10 13:26: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 NAA09954 for ; Tue, 10 Jun 2003 13:26:17 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5AHPrG10451 for ssm-archive@odin.ietf.org; Tue, 10 Jun 2003 13:25:53 -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 h5AHPrB10448 for ; Tue, 10 Jun 2003 13:25:53 -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 NAA09949 for ; Tue, 10 Jun 2003 13:25:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PmqY-0000jk-00 for ssm-web-archive@ietf.org; Tue, 10 Jun 2003 13:23:46 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PmqX-0000jh-00 for ssm-web-archive@ietf.org; Tue, 10 Jun 2003 13:23:45 -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 h5AHOfB10404; Tue, 10 Jun 2003 13:24:41 -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 h5AHMaB10322 for ; Tue, 10 Jun 2003 13:22:36 -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 NAA09834 for ; Tue, 10 Jun 2003 13:22:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PmnN-0000i9-00 for ssm@ietf.org; Tue, 10 Jun 2003 13:20:29 -0400 Received: from sophia.inria.fr ([138.96.64.20]) by ietf-mx with esmtp (Exim 4.12) id 19PmnM-0000i6-00 for ssm@ietf.org; Tue, 10 Jun 2003 13:20:28 -0400 Received: from localhost (odie.inria.fr [138.96.88.52]) by sophia.inria.fr (8.12.8/8.12.5) with ESMTP id h5AHLgvK017781; Tue, 10 Jun 2003 19:21:42 +0200 Date: Tue, 10 Jun 2003 19:21:41 +0200 (MEST) Message-Id: <20030610.192141.129511487.Hitoshi.Asaeda@sophia.inria.fr> To: eckert@cisco.com Cc: ssm@ietf.org Subject: Re: [ssm] Document Action: An Overview of Source-Specific Multicast(SSM) Deployment to Informational From: Hitoshi Asaeda In-Reply-To: <20030610155923.GR23388@cypher.cisco.com> References: <20030610144558.GL23388@cypher.cisco.com> <20030610.172332.128597013.Hitoshi.Asaeda@sophia.inria.fr> <20030610155923.GR23388@cypher.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 Toerless, > No, i just interpreted your statement incorrectly out of context. Never mind ;-) Okay. :) > But: I am not sure how much more the stronger statement in MLDv2 > buys. After all, it's the IGMPv3 for SSM spec that states you to ignore > any non IGMPv3 (include type) reports within the SSM range, so i am > not too much concerned about group mode behavior on the router, the > only critical elements is host behaviour and illegal lower version queriers. No. I mean, whether the multicast address is within the SSM range or not, and whether the multicast routers compatibility mode is v3 or not, IGMPv3 capable router SHOULD always send IGMPv3 General query. It SHOULD NOT send IGMPv1/v2 query in order to avoid that the host compatibility mode of IGMPv3 capable node is switched to v1/v2 by such downgraded General query. Due to this rule, the v3 capable node switches its compat mode only when v1/v2 router, which means "non-upgraded router", appears on the link (with sending v1/v2 General query). It is in fact no problem for non-upgraded *legal* end-nodes since they can only look 8 bytes from the top of the query message. So, we would be able to guarantee the interoperability as well. Further if you want to avoid the mode switch by the v1/v2 router, then you can configure the compat mode disable by "statically". But as we agreed, this should not be the default. These situations are same of MLDv2. This is my thought. ...snip... > Even if you don't have this flag enabled by default, you can still have > warnings by default: If you're not using IGMPv3 membership reports > (eg: querier is older) but you start an application using INCLUDE mode > reports, this might be worthy of a syslog to console or the like. > > There's a lot of things you can do to improve the perception of SSM > application users i think. Sounds interesting. I would think it. Thanks. -- Hitoshi Asaeda _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-admin@ietf.org Tue Jun 10 13:39:58 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 NAA10350 for ; Tue, 10 Jun 2003 13:39:58 -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 h5AHd9B11881; Tue, 10 Jun 2003 13:39:09 -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 h5AHc0B11840 for ; Tue, 10 Jun 2003 13:38:00 -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 NAA10324 for ; Tue, 10 Jun 2003 13:37:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pn2H-0000qH-00 for ssm@ietf.org; Tue, 10 Jun 2003 13:35:53 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by ietf-mx with esmtp (Exim 4.12) id 19Pn2G-0000q0-00 for ssm@ietf.org; Tue, 10 Jun 2003 13:35:52 -0400 Received: from holbrook-laptop.cisco.com (sjc-vpn3-792.cisco.com [10.21.67.24]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h5AHb4jc025963; Tue, 10 Jun 2003 10:37:15 -0700 (PDT) Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id 61C9910B7A7; Tue, 10 Jun 2003 10:36:50 -0700 (PDT) From: Hugh Holbrook To: Toerless Eckert Cc: Jon Zeeff , Toerless Eckert , Bill Fenner , ssm@ietf.org In-reply-to: <20030610143954.GK23388@cypher.cisco.com> Subject: Re: Re: [ssm] Document Action: An Overview of Source-Specific Multicast(SSM) Deployment to Informational Reply-To: holbrook@cisco.com Message-Id: <20030610173650.61C9910B7A7@holbrook-laptop.cisco.com> Date: Tue, 10 Jun 2003 10:36:50 -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: , Jon, Toerless: This problem has not been ignored by the IETF; see draft-holbrook-idmr-igmpv3-ssm-04.txt. Section 3.5 states that a router should not revert to IGMPv2 (or MLDv1) compatibility mode in the SSM range in response to IGMPv1/v2 or MLDv1 reports. So this protects against v1 and v2 reports in the SSM range. That is if a v2-only host sends a v2 report for some SSM address, it won't deny ssm service to everyone else. To deny SSM service, you have to either plug in a v2 *router*, or you have to have a malicious attacker that is sending v2 queries. I think the current rules (MUST log an error on the v3-capable router) are good enough to detect benign misconfigurations when you have a v2 router on the LAN. You see the log, go find the bad router, and fix it. For *malicious* attacks, we considered a requirement on hosts to ignore v2 queries in the SSM range. The -03 revision of the draft, in fact, included text specifically nothing this as a MAY. But this (a) contradicts RFC3376, it is only is useful if the *routers* also refuse to revert to v2 compatibility mode (for the SSM range) in the presence of a v2 querier, and it results in a situation that is not addressed at all in RFC3376. Our assessment was that there were too many complicated scenarios to get this right, and so we did not call this out as an option. If you want to suggest something else, pleaes bring your concerns forward now. Hitoshi, if you have implementation experience that indicates that this works, that would also be useful to know. The ssm-with-igmpv3/mld document has just gone through a magma wg last call, and mostly passed -- we're pretty close to shipping it to the IESG. An alternative solution to address the problem is to filter v2 queries at the ingress physical port -- basically implement a layer 2 security policy that prevents queries from unauthorized hosts. A number of vendors make products that are capable of this, at least in the wired world. The right way for hosts to learn the SSM range is to use the MRD SSM Range option, IMO. -Hugh > > I see similar lack of concern about real world security in > > wireless routing protocols (and DHCP and IPv6 and PIM and ...). > > Well, it's as simple as this: IGMPv3 was NOT MADE for SSM, so it's a > bit hart to shift the blame onto it completely. Once there is sufficient > interest in SSM and people come to realize that SSM alone is sufficient > in many cases on hosts, one could make much stronger statements about an SSM > subset (and extensions) of IGMPv3 implementations in hosts: > > subset: - Ignore all IGMPv1/v2 queries > - Don't implent any exclude mode reports > extension: - trigger unsolicited IS_INCLUDE mode reports after > 60 seconds without a query. > > Makes a really simple & safe SSM only implementation, and is completely > compatible with IGMPv3 routers. But as long as the host needs to support > both ASM _and_ SSM, it is really hard to strip down the complexity: Even > that part of "which group is SSM, which is ASM" is contentuous. I for > once am a strong proponent of using SSM also within 239/8 because of admin > scoping, so how does a host determine wether a group is SSM or not ? > MSNIP SSM range ? Well, that's another requirement for a host stack, > and if i look at how long it takes for new requirements to be implemented > into host stack *oh well*... > > Cheers > Toerless _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Tue Jun 10 13:40:32 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 NAA10375 for ; Tue, 10 Jun 2003 13:40:32 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5AHe5211967 for ssm-archive@odin.ietf.org; Tue, 10 Jun 2003 13:40:05 -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 h5AHe5B11964 for ; Tue, 10 Jun 2003 13:40:05 -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 NAA10366 for ; Tue, 10 Jun 2003 13:40:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pn4I-0000qu-00 for ssm-web-archive@ietf.org; Tue, 10 Jun 2003 13:37:58 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Pn4I-0000qr-00 for ssm-web-archive@ietf.org; Tue, 10 Jun 2003 13:37:58 -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 h5AHd9B11881; Tue, 10 Jun 2003 13:39:09 -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 h5AHc0B11840 for ; Tue, 10 Jun 2003 13:38:00 -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 NAA10324 for ; Tue, 10 Jun 2003 13:37:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pn2H-0000qH-00 for ssm@ietf.org; Tue, 10 Jun 2003 13:35:53 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by ietf-mx with esmtp (Exim 4.12) id 19Pn2G-0000q0-00 for ssm@ietf.org; Tue, 10 Jun 2003 13:35:52 -0400 Received: from holbrook-laptop.cisco.com (sjc-vpn3-792.cisco.com [10.21.67.24]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h5AHb4jc025963; Tue, 10 Jun 2003 10:37:15 -0700 (PDT) Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id 61C9910B7A7; Tue, 10 Jun 2003 10:36:50 -0700 (PDT) From: Hugh Holbrook To: Toerless Eckert Cc: Jon Zeeff , Toerless Eckert , Bill Fenner , ssm@ietf.org In-reply-to: <20030610143954.GK23388@cypher.cisco.com> Subject: Re: Re: [ssm] Document Action: An Overview of Source-Specific Multicast(SSM) Deployment to Informational Reply-To: holbrook@cisco.com Message-Id: <20030610173650.61C9910B7A7@holbrook-laptop.cisco.com> Date: Tue, 10 Jun 2003 10:36:50 -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: , Jon, Toerless: This problem has not been ignored by the IETF; see draft-holbrook-idmr-igmpv3-ssm-04.txt. Section 3.5 states that a router should not revert to IGMPv2 (or MLDv1) compatibility mode in the SSM range in response to IGMPv1/v2 or MLDv1 reports. So this protects against v1 and v2 reports in the SSM range. That is if a v2-only host sends a v2 report for some SSM address, it won't deny ssm service to everyone else. To deny SSM service, you have to either plug in a v2 *router*, or you have to have a malicious attacker that is sending v2 queries. I think the current rules (MUST log an error on the v3-capable router) are good enough to detect benign misconfigurations when you have a v2 router on the LAN. You see the log, go find the bad router, and fix it. For *malicious* attacks, we considered a requirement on hosts to ignore v2 queries in the SSM range. The -03 revision of the draft, in fact, included text specifically nothing this as a MAY. But this (a) contradicts RFC3376, it is only is useful if the *routers* also refuse to revert to v2 compatibility mode (for the SSM range) in the presence of a v2 querier, and it results in a situation that is not addressed at all in RFC3376. Our assessment was that there were too many complicated scenarios to get this right, and so we did not call this out as an option. If you want to suggest something else, pleaes bring your concerns forward now. Hitoshi, if you have implementation experience that indicates that this works, that would also be useful to know. The ssm-with-igmpv3/mld document has just gone through a magma wg last call, and mostly passed -- we're pretty close to shipping it to the IESG. An alternative solution to address the problem is to filter v2 queries at the ingress physical port -- basically implement a layer 2 security policy that prevents queries from unauthorized hosts. A number of vendors make products that are capable of this, at least in the wired world. The right way for hosts to learn the SSM range is to use the MRD SSM Range option, IMO. -Hugh > > I see similar lack of concern about real world security in > > wireless routing protocols (and DHCP and IPv6 and PIM and ...). > > Well, it's as simple as this: IGMPv3 was NOT MADE for SSM, so it's a > bit hart to shift the blame onto it completely. Once there is sufficient > interest in SSM and people come to realize that SSM alone is sufficient > in many cases on hosts, one could make much stronger statements about an SSM > subset (and extensions) of IGMPv3 implementations in hosts: > > subset: - Ignore all IGMPv1/v2 queries > - Don't implent any exclude mode reports > extension: - trigger unsolicited IS_INCLUDE mode reports after > 60 seconds without a query. > > Makes a really simple & safe SSM only implementation, and is completely > compatible with IGMPv3 routers. But as long as the host needs to support > both ASM _and_ SSM, it is really hard to strip down the complexity: Even > that part of "which group is SSM, which is ASM" is contentuous. I for > once am a strong proponent of using SSM also within 239/8 because of admin > scoping, so how does a host determine wether a group is SSM or not ? > MSNIP SSM range ? Well, that's another requirement for a host stack, > and if i look at how long it takes for new requirements to be implemented > into host stack *oh well*... > > Cheers > Toerless _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-admin@ietf.org Tue Jun 10 14:11: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 OAA11328 for ; Tue, 10 Jun 2003 14:11:01 -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 h5AIAEB14223; Tue, 10 Jun 2003 14:10:14 -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 h5AI9dB14179 for ; Tue, 10 Jun 2003 14:09:39 -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 OAA11300 for ; Tue, 10 Jun 2003 14:09:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PnWt-00013z-00 for ssm@ietf.org; Tue, 10 Jun 2003 14:07:31 -0400 Received: from sophia.inria.fr ([138.96.64.20]) by ietf-mx with esmtp (Exim 4.12) id 19PnWs-00013f-00 for ssm@ietf.org; Tue, 10 Jun 2003 14:07:30 -0400 Received: from localhost (odie.inria.fr [138.96.88.52]) by sophia.inria.fr (8.12.8/8.12.5) with ESMTP id h5AI93vK022637 for ; Tue, 10 Jun 2003 20:09:03 +0200 Date: Tue, 10 Jun 2003 20:09:02 +0200 (MEST) Message-Id: <20030610.200902.89673002.Hitoshi.Asaeda@sophia.inria.fr> To: ssm@ietf.org Subject: Re: [ssm] Document Action: An Overview of Source-Specific Multicast(SSM) Deployment to Informational From: Hitoshi Asaeda In-Reply-To: <20030610.192141.129511487.Hitoshi.Asaeda@sophia.inria.fr> References: <20030610.172332.128597013.Hitoshi.Asaeda@sophia.inria.fr> <20030610155923.GR23388@cypher.cisco.com> <20030610.192141.129511487.Hitoshi.Asaeda@sophia.inria.fr> 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 Sorry for one typo. > No. I mean, whether the multicast address is within the SSM range or > not, and whether the multicast routers compatibility mode is v3 or > not, IGMPv3 capable router SHOULD always send IGMPv3 General query. It > SHOULD NOT send IGMPv1/v2 query in order to avoid that the host ^^^^^^^^^^^^^^^IGMPv1/v2 General query -- Hitoshi Asaeda _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Tue Jun 10 14:11:36 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 OAA11361 for ; Tue, 10 Jun 2003 14:11:36 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5AIBBs14287 for ssm-archive@odin.ietf.org; Tue, 10 Jun 2003 14:11:11 -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 h5AIBBB14284 for ; Tue, 10 Jun 2003 14:11:11 -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 OAA11349 for ; Tue, 10 Jun 2003 14:11:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PnYN-000153-00 for ssm-web-archive@ietf.org; Tue, 10 Jun 2003 14:09:03 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PnYM-000150-00 for ssm-web-archive@ietf.org; Tue, 10 Jun 2003 14:09:02 -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 h5AIAEB14223; Tue, 10 Jun 2003 14:10:14 -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 h5AI9dB14179 for ; Tue, 10 Jun 2003 14:09:39 -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 OAA11300 for ; Tue, 10 Jun 2003 14:09:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PnWt-00013z-00 for ssm@ietf.org; Tue, 10 Jun 2003 14:07:31 -0400 Received: from sophia.inria.fr ([138.96.64.20]) by ietf-mx with esmtp (Exim 4.12) id 19PnWs-00013f-00 for ssm@ietf.org; Tue, 10 Jun 2003 14:07:30 -0400 Received: from localhost (odie.inria.fr [138.96.88.52]) by sophia.inria.fr (8.12.8/8.12.5) with ESMTP id h5AI93vK022637 for ; Tue, 10 Jun 2003 20:09:03 +0200 Date: Tue, 10 Jun 2003 20:09:02 +0200 (MEST) Message-Id: <20030610.200902.89673002.Hitoshi.Asaeda@sophia.inria.fr> To: ssm@ietf.org Subject: Re: [ssm] Document Action: An Overview of Source-Specific Multicast(SSM) Deployment to Informational From: Hitoshi Asaeda In-Reply-To: <20030610.192141.129511487.Hitoshi.Asaeda@sophia.inria.fr> References: <20030610.172332.128597013.Hitoshi.Asaeda@sophia.inria.fr> <20030610155923.GR23388@cypher.cisco.com> <20030610.192141.129511487.Hitoshi.Asaeda@sophia.inria.fr> 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 Sorry for one typo. > No. I mean, whether the multicast address is within the SSM range or > not, and whether the multicast routers compatibility mode is v3 or > not, IGMPv3 capable router SHOULD always send IGMPv3 General query. It > SHOULD NOT send IGMPv1/v2 query in order to avoid that the host ^^^^^^^^^^^^^^^IGMPv1/v2 General query -- Hitoshi Asaeda _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-admin@ietf.org Wed Jun 11 09:39:59 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 JAA08467 for ; Wed, 11 Jun 2003 09:39:59 -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 h5BDdDB08277; Wed, 11 Jun 2003 09:39:13 -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 h5BDbHB07744 for ; Wed, 11 Jun 2003 09:37:17 -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 JAA08399 for ; Wed, 11 Jun 2003 09:37:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Q5kq-0000GX-00 for ssm@ietf.org; Wed, 11 Jun 2003 09:35:08 -0400 Received: from lmout02.st1.spray.net ([212.78.202.121]) by ietf-mx with esmtp (Exim 4.12) id 19Q5kp-0000GG-00 for ssm@ietf.org; Wed, 11 Jun 2003 09:35:07 -0400 Received: from lmfilto02.st1.spray.net (lmfilto02.st1.spray.net [212.78.202.66]) by lmout02.st1.spray.net (Postfix) with ESMTP id 46D68100CD; Wed, 11 Jun 2003 15:36:41 +0200 (MEST) Received: from localhost (localhost [127.0.0.1]) by lmfilto02.st1.spray.net (Postfix) with ESMTP id 28D6324EE; Wed, 11 Jun 2003 15:36:41 +0200 (CEST) Received: from lmout02.st1.spray.net ([212.78.202.121]) by localhost (lmfilto02.st1.spray.net [212.78.202.66]) (amavisd-new, port 10024) with ESMTP id 14964-08; Wed, 11 Jun 2003 15:36:40 +0200 (CEST) Received: from spray.se (lmcodec02.st1.spray.net [212.78.202.56]) by lmout02.st1.spray.net (Postfix) with SMTP id B4444100CD; Wed, 11 Jun 2003 15:36:40 +0200 (MEST) From: p v To: msdp@network-services.uoregon.edu, ssm@ietf.org, msdp@ietf.org Message-ID: <1055338600004511@lycos-europe.com> X-Mailer: LycosMail X-Originating-IP: [213.116.225.84] Mime-Version: 1.0 Date: Wed, 11 Jun 2003 15:36:40 +0100 Content-Type: multipart/mixed; boundary="=_NextPart_Lycos_0045111055338600_ID" X-Virus-Scanned: by amavisd-new at spray.net 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: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --=_NextPart_Lycos_0045111055338600_ID Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable unsubscribe ____________________________________________________________ Nu =E4r det l=E4ttare att umg=E5s p=E5 Spray. V=E4lkommen! - http://www.spray.se/ --=_NextPart_Lycos_0045111055338600_ID-- _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Wed Jun 11 09:40:32 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 JAA08494 for ; Wed, 11 Jun 2003 09:40:32 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5BDe7008358 for ssm-archive@odin.ietf.org; Wed, 11 Jun 2003 09:40:07 -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 h5BDe7B08355 for ; Wed, 11 Jun 2003 09:40:07 -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 JAA08485 for ; Wed, 11 Jun 2003 09:40:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Q5na-0000Ha-00 for ssm-web-archive@ietf.org; Wed, 11 Jun 2003 09:37:58 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Q5nZ-0000HW-00 for ssm-web-archive@ietf.org; Wed, 11 Jun 2003 09:37: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 h5BDdDB08277; Wed, 11 Jun 2003 09:39:13 -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 h5BDbHB07744 for ; Wed, 11 Jun 2003 09:37:17 -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 JAA08399 for ; Wed, 11 Jun 2003 09:37:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Q5kq-0000GX-00 for ssm@ietf.org; Wed, 11 Jun 2003 09:35:08 -0400 Received: from lmout02.st1.spray.net ([212.78.202.121]) by ietf-mx with esmtp (Exim 4.12) id 19Q5kp-0000GG-00 for ssm@ietf.org; Wed, 11 Jun 2003 09:35:07 -0400 Received: from lmfilto02.st1.spray.net (lmfilto02.st1.spray.net [212.78.202.66]) by lmout02.st1.spray.net (Postfix) with ESMTP id 46D68100CD; Wed, 11 Jun 2003 15:36:41 +0200 (MEST) Received: from localhost (localhost [127.0.0.1]) by lmfilto02.st1.spray.net (Postfix) with ESMTP id 28D6324EE; Wed, 11 Jun 2003 15:36:41 +0200 (CEST) Received: from lmout02.st1.spray.net ([212.78.202.121]) by localhost (lmfilto02.st1.spray.net [212.78.202.66]) (amavisd-new, port 10024) with ESMTP id 14964-08; Wed, 11 Jun 2003 15:36:40 +0200 (CEST) Received: from spray.se (lmcodec02.st1.spray.net [212.78.202.56]) by lmout02.st1.spray.net (Postfix) with SMTP id B4444100CD; Wed, 11 Jun 2003 15:36:40 +0200 (MEST) From: p v To: msdp@network-services.uoregon.edu, ssm@ietf.org, msdp@ietf.org Message-ID: <1055338600004511@lycos-europe.com> X-Mailer: LycosMail X-Originating-IP: [213.116.225.84] Mime-Version: 1.0 Date: Wed, 11 Jun 2003 15:36:40 +0100 Content-Type: multipart/mixed; boundary="=_NextPart_Lycos_0045111055338600_ID" X-Virus-Scanned: by amavisd-new at spray.net 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: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --=_NextPart_Lycos_0045111055338600_ID Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable unsubscribe ____________________________________________________________ Nu =E4r det l=E4ttare att umg=E5s p=E5 Spray. V=E4lkommen! - http://www.spray.se/ --=_NextPart_Lycos_0045111055338600_ID-- _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-admin@ietf.org Fri Jun 13 04:14:45 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 EAA24783 for ; Fri, 13 Jun 2003 04:14:45 -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 h5CHmWa11759; Thu, 12 Jun 2003 13:48:32 -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 h5ADoVB23279 for ; Tue, 10 Jun 2003 09:50:31 -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 JAA00009 for ; Tue, 10 Jun 2003 09:50:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PjU8-0006Or-00 for ssm@ietf.org; Tue, 10 Jun 2003 09:48:24 -0400 Received: from ns1.u-strasbg.fr ([130.79.200.1]) by ietf-mx with esmtp (Exim 4.12) id 19PjU7-0006Ok-00 for ssm@ietf.org; Tue, 10 Jun 2003 09:48:24 -0400 Received: from crc.u-strasbg.fr (crc.u-strasbg.fr [130.79.201.129]) by ns1.u-strasbg.fr (8.12.6p2/jtpda-5.4) with ESMTP id h5ADoGHT026714 ; Tue, 10 Jun 2003 15:50:16 +0200 (CEST) Received: from crc.u-strasbg.fr (sixnet.u-strasbg.fr [130.79.90.153]) by crc.u-strasbg.fr (8.12.9/jtpda-5.4) with ESMTP id h5ADoGXc090189 ; Tue, 10 Jun 2003 15:50:16 +0200 (CEST) Message-ID: <3EE5E218.9020108@crc.u-strasbg.fr> Date: Tue, 10 Jun 2003 15:50:16 +0200 From: Jean-Jacques Pansiot Organization: ULP LSIIT & Departement d'Informatique User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020811 X-Accept-Language: fr, en-us MIME-Version: 1.0 To: Jon Zeeff CC: Toerless Eckert , Bill Fenner , ssm@ietf.org Subject: Re: [ssm] Document Action: An Overview of Source-Specific Multicast(SSM) Deployment to Informational References: <5.1.0.14.2.20030606144813.01d03370@mail.internet2.edu> <200306040550.h545oaD08547@windsor.research.att.com> <5.1.0.14.2.20030606144813.01d03370@mail.internet2.edu> <5.1.0.14.2.20030610085539.023c1740@mail.internet2.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: scanned by sophos at u-strasbg.fr 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 Jon Zeeff wrote: > > >> From my experience, windows XP does send IGMPv2 reports if it sees >> IGMPv2 queries. >> It MUST do this according to the IGMPv3 spec. > > > So if I do manage to get my LAN completely IGMPv3 capable and thus allow > the use of SSM, all it takes is one person > plugging in a machine running IGMPv2 and SSM breaks. This probably > means that SSM is unimplementable except > in some special cases (example: one host per vlan). Hi this is not my understanding of IGMPv3 (and MLDv2). The problem you describe occurs only if a router runs IGMPv2, which should not be the case in a well managed network. If all routers are running IGMPv3 (or MLDv2) then the compatibility "downgrade" is per group (ie per multicast address) : that is a group may use IGMPv2 if one member host is IGMPv2 only, and another group on the same LAN may use IGMPv3 if all member hosts use IGMPv3. Moreover, although it is not completely clear to me, I think IGMPv3 capable hosts and routers should not downgrade to IGMPv2 for a multicast address in the SSM range. I suppose that the main problem arises when a malicious user runs a fake IGMPv2 router. Jean-Jacques > >> So, as far as easy gradual migration to SSM with DoS attack prevention >> is concerned, >> this has almost completely been ignored by the IETF process. > > > I see similar lack of concern about real world security in wireless > routing protocols (and DHCP and IPv6 and PIM and ...). > > Thanks for the info. > > _______________________________________________ > 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 Jun 13 04:15: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 EAA24808 for ; Fri, 13 Jun 2003 04:15:19 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5D8Eod18030 for ssm-archive@odin.ietf.org; Fri, 13 Jun 2003 04:14:50 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D8Eom18027 for ; Fri, 13 Jun 2003 04:14:50 -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 EAA24801 for ; Fri, 13 Jun 2003 04:14:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qjfs-0002fC-00 for ssm-web-archive@ietf.org; Fri, 13 Jun 2003 04:12:40 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Qjfr-0002f8-00 for ssm-web-archive@ietf.org; Fri, 13 Jun 2003 04:12:39 -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 h5CHmWa11759; Thu, 12 Jun 2003 13:48:32 -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 h5ADoVB23279 for ; Tue, 10 Jun 2003 09:50:31 -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 JAA00009 for ; Tue, 10 Jun 2003 09:50:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PjU8-0006Or-00 for ssm@ietf.org; Tue, 10 Jun 2003 09:48:24 -0400 Received: from ns1.u-strasbg.fr ([130.79.200.1]) by ietf-mx with esmtp (Exim 4.12) id 19PjU7-0006Ok-00 for ssm@ietf.org; Tue, 10 Jun 2003 09:48:24 -0400 Received: from crc.u-strasbg.fr (crc.u-strasbg.fr [130.79.201.129]) by ns1.u-strasbg.fr (8.12.6p2/jtpda-5.4) with ESMTP id h5ADoGHT026714 ; Tue, 10 Jun 2003 15:50:16 +0200 (CEST) Received: from crc.u-strasbg.fr (sixnet.u-strasbg.fr [130.79.90.153]) by crc.u-strasbg.fr (8.12.9/jtpda-5.4) with ESMTP id h5ADoGXc090189 ; Tue, 10 Jun 2003 15:50:16 +0200 (CEST) Message-ID: <3EE5E218.9020108@crc.u-strasbg.fr> Date: Tue, 10 Jun 2003 15:50:16 +0200 From: Jean-Jacques Pansiot Organization: ULP LSIIT & Departement d'Informatique User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020811 X-Accept-Language: fr, en-us MIME-Version: 1.0 To: Jon Zeeff CC: Toerless Eckert , Bill Fenner , ssm@ietf.org Subject: Re: [ssm] Document Action: An Overview of Source-Specific Multicast(SSM) Deployment to Informational References: <5.1.0.14.2.20030606144813.01d03370@mail.internet2.edu> <200306040550.h545oaD08547@windsor.research.att.com> <5.1.0.14.2.20030606144813.01d03370@mail.internet2.edu> <5.1.0.14.2.20030610085539.023c1740@mail.internet2.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: scanned by sophos at u-strasbg.fr 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 Jon Zeeff wrote: > > >> From my experience, windows XP does send IGMPv2 reports if it sees >> IGMPv2 queries. >> It MUST do this according to the IGMPv3 spec. > > > So if I do manage to get my LAN completely IGMPv3 capable and thus allow > the use of SSM, all it takes is one person > plugging in a machine running IGMPv2 and SSM breaks. This probably > means that SSM is unimplementable except > in some special cases (example: one host per vlan). Hi this is not my understanding of IGMPv3 (and MLDv2). The problem you describe occurs only if a router runs IGMPv2, which should not be the case in a well managed network. If all routers are running IGMPv3 (or MLDv2) then the compatibility "downgrade" is per group (ie per multicast address) : that is a group may use IGMPv2 if one member host is IGMPv2 only, and another group on the same LAN may use IGMPv3 if all member hosts use IGMPv3. Moreover, although it is not completely clear to me, I think IGMPv3 capable hosts and routers should not downgrade to IGMPv2 for a multicast address in the SSM range. I suppose that the main problem arises when a malicious user runs a fake IGMPv2 router. Jean-Jacques > >> So, as far as easy gradual migration to SSM with DoS attack prevention >> is concerned, >> this has almost completely been ignored by the IETF process. > > > I see similar lack of concern about real world security in wireless > routing protocols (and DHCP and IPv6 and PIM and ...). > > Thanks for the info. > > _______________________________________________ > 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