From ssm-interest-owner@cisco.com Mon Jan 13 17:37:05 2003 Received: from domohead.cisco.com (domohead.cisco.com [161.44.11.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26619 for ; Mon, 13 Jan 2003 17:37:04 -0500 (EST) Received: (from daemon@localhost) by domohead.cisco.com (8.12.2/8.12.2) id h0DKZIIv013292; Mon, 13 Jan 2003 15:35:18 -0500 (EST) Date: Mon, 13 Jan 2003 15:35:18 -0500 (EST) Message-Id: <200301132035.h0DKZIIv013292@domohead.cisco.com> To: ssm-interest@cisco.com From: holbrook@cisco.com Subject: ssm wg mailing list moving to ietf.org Hello, SSM wg members. The SSM working group mailing list (and archives) will soon be migrating to ietf.org. The new mailing list will be called ssm@ietf.org We are planning to preserve all current subscribers to the new list, so you won't have to do anything to keep your existing subscription. The only thing you'll have to remember is to send to the new alias. Once the list is fully set up (probably today or tomorrow) you will be receiving a confirmation and welcome mail with subscription and unsubscription instructions. Once the new list is up, I'll send out a notification, and messages posted to the old list will probably start to bounce within a few days. If you have any issues with this, please let me know. -Hugh From mailnull@www1.ietf.org Tue Jan 14 15:15:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10106 for ; Tue, 14 Jan 2003 15:15:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EKTMb28837 for ssm-archive@odin.ietf.org; Tue, 14 Jan 2003 15:29:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EKTMJ28834 for ; Tue, 14 Jan 2003 15:29:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10095 for ; Tue, 14 Jan 2003 15:14:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EKTLJ28830 for ; Tue, 14 Jan 2003 15:29:21 -0500 Date: Tue, 14 Jan 2003 15:29:21 -0500 Message-ID: <20030114202921.28828.22638.Mailman@www1.ietf.org> Subject: Welcome to the "Ssm" mailing list From: ssm-request@ietf.org To: ssm-web-archive@ietf.org X-No-Archive: yes X-Ack: no 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: , Welcome to the Ssm@ietf.org mailing list! To post to this list, send your email to: ssm@ietf.org General information about the mailing list is at: https://www1.ietf.org/mailman/listinfo/ssm ************************************************************************** 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 ever want to unsubscribe or change your options (eg, switch to or from digest mode, change your password, etc.), visit your subscription page at: https://www1.ietf.org/mailman/options/ssm/ssm-web-archive%40ietf.org You can also make such adjustments via email by sending a message to: Ssm-request@ietf.org with the word `help' in the subject or body (don't include the quotes), and you will get back a message with instructions. You must know your password to change your options (including changing the password, itself) or to unsubscribe. It is: daemut If you forget your password, don't worry, you will receive a monthly reminder telling you what all your ietf.org mailing list passwords are, and how to unsubscribe or change your options. There is also a button on your options page that will email your current password to you. You may also have your password mailed to you automatically off of the Web page noted above. From mailnull@www1.ietf.org Tue Jan 14 15:16:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10143 for ; Tue, 14 Jan 2003 15:16:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EKV1828959 for ssm-archive@odin.ietf.org; Tue, 14 Jan 2003 15:31:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EKV1J28956 for ; Tue, 14 Jan 2003 15:31:01 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10134 for ; Tue, 14 Jan 2003 15:16:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EKV0J28939 for ; Tue, 14 Jan 2003 15:31:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EKUYJ28896 for ; Tue, 14 Jan 2003 15:30:34 -0500 Received: from cnri.reston.va.us (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10121 for ; Tue, 14 Jan 2003 15:15:46 -0500 (EST) Received: from hubris.cnri.reston.va.us (cnri-7-65.cnri.reston.va.us [132.151.7.65]) by cnri.reston.va.us (8.11.6+Sun/8.11.3) with ESMTP id h0EKJ7824666 for ; Tue, 14 Jan 2003 15:19:07 -0500 (EST) Message-Id: <5.0.0.25.2.20030114151655.00acde00@mailbox.cnri.reston.va.us> X-Sender: gcunning@mailbox.cnri.reston.va.us X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 14 Jan 2003 15:17:55 -0500 To: ssm@ietf.org From: Greg Cunningham Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Ssm] Test message #1 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 SSM WG mailing list is being moved to the ietf. This is a test message to check the archives. _______________________________________________ Ssm mailing list Ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-admin@ietf.org Tue Jan 14 15:42: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 PAA10897 for ; Tue, 14 Jan 2003 15:42:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EKvGJ31634 for ; Tue, 14 Jan 2003 15:57:16 -0500 Date: Tue, 14 Jan 2003 15:57:16 -0500 Message-ID: <20030114205716.31525.21309.Mailman@www1.ietf.org> Subject: Welcome to the "Ssm" mailing list From: ssm-request@ietf.org To: ssm-archive@ietf.org X-No-Archive: yes X-Ack: no 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: , Welcome to the Ssm@ietf.org mailing list! To post to this list, send your email to: ssm@ietf.org General information about the mailing list is at: https://www1.ietf.org/mailman/listinfo/ssm ************************************************************************** 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 ever want to unsubscribe or change your options (eg, switch to or from digest mode, change your password, etc.), visit your subscription page at: https://www1.ietf.org/mailman/options/ssm/ssm-archive%40lists.ietf.org You can also make such adjustments via email by sending a message to: Ssm-request@ietf.org with the word `help' in the subject or body (don't include the quotes), and you will get back a message with instructions. You must know your password to change your options (including changing the password, itself) or to unsubscribe. It is: mifemu If you forget your password, don't worry, you will receive a monthly reminder telling you what all your ietf.org mailing list passwords are, and how to unsubscribe or change your options. There is also a button on your options page that will email your current password to you. You may also have your password mailed to you automatically off of the Web page noted above. From ssm-admin@ietf.org Wed Jan 15 01:32:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23766 for ; Wed, 15 Jan 2003 01:32:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F6kxJ04847; Wed, 15 Jan 2003 01:46:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F6dUJ04583 for ; Wed, 15 Jan 2003 01:39:30 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23704 for ; Wed, 15 Jan 2003 01:24:30 -0500 (EST) Received: from holbrook-laptop.cisco.com (sjc-vpn1-676.cisco.com [10.21.98.164]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id h0F6RDjS025665; Tue, 14 Jan 2003 22:27:14 -0800 (PST) Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id 076C910B869; Wed, 15 Jan 2003 01:25:34 -0500 (EST) From: Hugh Holbrook To: ssm@ietf.org Cc: mbaugher@cisco.com, bew@cisco.com Reply-To: holbrook@cisco.com Message-Id: <20030115062534.076C910B869@holbrook-laptop.cisco.com> Date: Wed, 15 Jan 2003 01:25:34 -0500 (EST) Subject: [ssm] SSM with IPSec 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: , Hello, SSM working group. [ Welcome to the brand spanking new ssm@ietf.org mailing list. Please tell me if you notice any problems with the list. You should have received a mail from the mailman program running the list. The SSM page at ietf.org still lists the [un]subscription info for the old list, but it will be updated shortly. ] Last week, I was talking to some security folks here (Brian Weis and Mark Baugher) who pointed out that IPSec as specified in RFC2401 has some issues when securing SSM traffic. In short, the problem is that including the source in the SA lookup isn't really accounted for in IPSec, but it really should be. Details below. I don't think this is a really urgent problem, but I think the WG should be aware of the problem, so I'll spell it out. Comments solicited. Some IPSec background: [Apologies for the tutorial, but I know that not everyone in the wg is fluent in IPSec details.] IPSec, in RFC2401, specifies that an incoming IPSec packet is looked up on arrival in a local Security Association Database (SAD) to decide which Security Association (SA) should be applied to the packet [see section 4.4.3 of RFC2401.] The resulting SA determines the decryption/authentication key, and the anti-replay window (if one is used). RFC2401 specifies that the key for the SAD lookup is a 3-tuple of: - the packet's destination IP address - the IPSec protocol (ESP or AH) - the Security Parameters Index (SPI) The problem (for SSM) is that the source address is *not* included in the SAD lookup. The problem: You would to be sure that two unrelated SSM channels, if secured by IPSec, can be guaranteed to have unique Security Associations at all receivers. This should be true even if the senders accidentally happen to choose the same SSM destination address. There is, however, no entity that "owns" an SSM destination address and can reasonably ensure that every sender to an SSM address uses a unique SPI One could envision a similar problem for ASM, but I believe in the ASM case, the assumption of the IPSec design is that there exists a "group controller" that logically "owns" the group and can hand out a unique SPI to each source that needs one. But this doesn't apply to SSM. The mere existence of such an entity for an SSM address would defeat one of SSM's big benefits -- that external coordination with other senders is not needed before choosing and using an SSM address. In practice, I don't think this problem is very severe. It only arises if a receiver subscribes simultaneously to two unrelated IPSec'ed channels whose sources happen to have chosen the same IPDA and the same IPSec SPI. Given that the tuple contains 56 bits of generally randomly-picked data, it is very unlikely to occur in practice. However, I don't think the architecture should rely on coincidence to work properly. What to do: The solution that I most like is fairly easy to state: require the source address to be part of the SA lookup when the destination address is an SSM address. Mark and Brian inform me that the msec working group is looking at solving the problem this way. The required action from the SSM working group is, I think, to simply point out the problem in the -arch draft, more or less as I've done above, and note that work is currently underway to address the problem. I don't believe we need to or want to hold up the SSM draft until msec (or ipsec) solves the problem, but I'd like to hear WG comments on this topic. I'll probably be sending out some proposed modifications to the architecture draft shortly. Thanks to Mark and Brian for pointing out this problem. Cheers, -Hugh _______________________________________________ Ssm mailing list Ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Wed Jan 15 01:36:35 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 BAA23816 for ; Wed, 15 Jan 2003 01:36:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0F6p4o05012 for ssm-archive@odin.ietf.org; Wed, 15 Jan 2003 01:51:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F6p4J05009 for ; Wed, 15 Jan 2003 01:51:04 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23813 for ; Wed, 15 Jan 2003 01:36:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F6kxJ04847; Wed, 15 Jan 2003 01:46:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F6dUJ04583 for ; Wed, 15 Jan 2003 01:39:30 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23704 for ; Wed, 15 Jan 2003 01:24:30 -0500 (EST) Received: from holbrook-laptop.cisco.com (sjc-vpn1-676.cisco.com [10.21.98.164]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id h0F6RDjS025665; Tue, 14 Jan 2003 22:27:14 -0800 (PST) Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id 076C910B869; Wed, 15 Jan 2003 01:25:34 -0500 (EST) From: Hugh Holbrook To: ssm@ietf.org Cc: mbaugher@cisco.com, bew@cisco.com Reply-To: holbrook@cisco.com Message-Id: <20030115062534.076C910B869@holbrook-laptop.cisco.com> Date: Wed, 15 Jan 2003 01:25:34 -0500 (EST) Subject: [ssm] SSM with IPSec 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: , Hello, SSM working group. [ Welcome to the brand spanking new ssm@ietf.org mailing list. Please tell me if you notice any problems with the list. You should have received a mail from the mailman program running the list. The SSM page at ietf.org still lists the [un]subscription info for the old list, but it will be updated shortly. ] Last week, I was talking to some security folks here (Brian Weis and Mark Baugher) who pointed out that IPSec as specified in RFC2401 has some issues when securing SSM traffic. In short, the problem is that including the source in the SA lookup isn't really accounted for in IPSec, but it really should be. Details below. I don't think this is a really urgent problem, but I think the WG should be aware of the problem, so I'll spell it out. Comments solicited. Some IPSec background: [Apologies for the tutorial, but I know that not everyone in the wg is fluent in IPSec details.] IPSec, in RFC2401, specifies that an incoming IPSec packet is looked up on arrival in a local Security Association Database (SAD) to decide which Security Association (SA) should be applied to the packet [see section 4.4.3 of RFC2401.] The resulting SA determines the decryption/authentication key, and the anti-replay window (if one is used). RFC2401 specifies that the key for the SAD lookup is a 3-tuple of: - the packet's destination IP address - the IPSec protocol (ESP or AH) - the Security Parameters Index (SPI) The problem (for SSM) is that the source address is *not* included in the SAD lookup. The problem: You would to be sure that two unrelated SSM channels, if secured by IPSec, can be guaranteed to have unique Security Associations at all receivers. This should be true even if the senders accidentally happen to choose the same SSM destination address. There is, however, no entity that "owns" an SSM destination address and can reasonably ensure that every sender to an SSM address uses a unique SPI One could envision a similar problem for ASM, but I believe in the ASM case, the assumption of the IPSec design is that there exists a "group controller" that logically "owns" the group and can hand out a unique SPI to each source that needs one. But this doesn't apply to SSM. The mere existence of such an entity for an SSM address would defeat one of SSM's big benefits -- that external coordination with other senders is not needed before choosing and using an SSM address. In practice, I don't think this problem is very severe. It only arises if a receiver subscribes simultaneously to two unrelated IPSec'ed channels whose sources happen to have chosen the same IPDA and the same IPSec SPI. Given that the tuple contains 56 bits of generally randomly-picked data, it is very unlikely to occur in practice. However, I don't think the architecture should rely on coincidence to work properly. What to do: The solution that I most like is fairly easy to state: require the source address to be part of the SA lookup when the destination address is an SSM address. Mark and Brian inform me that the msec working group is looking at solving the problem this way. The required action from the SSM working group is, I think, to simply point out the problem in the -arch draft, more or less as I've done above, and note that work is currently underway to address the problem. I don't believe we need to or want to hold up the SSM draft until msec (or ipsec) solves the problem, but I'd like to hear WG comments on this topic. I'll probably be sending out some proposed modifications to the architecture draft shortly. Thanks to Mark and Brian for pointing out this problem. Cheers, -Hugh _______________________________________________ Ssm mailing list Ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-admin@ietf.org Wed Jan 15 03:12: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 DAA19446 for ; Wed, 15 Jan 2003 03:12:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F8QSJ21165; Wed, 15 Jan 2003 03:26:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F8HBJ20820 for ; Wed, 15 Jan 2003 03:17:11 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19212 for ; Wed, 15 Jan 2003 03:02:07 -0500 (EST) Received: from holbrook-laptop.cisco.com (sjc-vpn1-676.cisco.com [10.21.98.164]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h0F85N0E012220 for ; Wed, 15 Jan 2003 00:05:28 -0800 (PST) Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id 21E0810B869; Wed, 15 Jan 2003 03:03:09 -0500 (EST) From: Hugh Holbrook To: ssm@ietf.org Reply-To: holbrook@cisco.com Message-Id: <20030115080309.21E0810B869@holbrook-laptop.cisco.com> Date: Wed, 15 Jan 2003 03:03:09 -0500 (EST) Subject: [ssm] Fwd: Re: Fwd: Re: Fwd: Re: draft-ietf-ssm-arch-01, wg last call deadline 12/9/2002 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: , Pavlin asked me to relay this message to the list for the record. This message originally bounced. -Hugh ------- Forwarded Message ------- Message-Id: <200212181828.gBIISE2U090143@possum.icir.org> To: holbrook@cisco.com Cc: ssm-interest@external.cisco.com, pavlin@icir.org Subject: Re: Fwd: Re: Fwd: Re: draft-ietf-ssm-arch-01, wg last call deadline 12/9/2002 Date: Wed, 18 Dec 2002 10:28:14 -0800 From: Pavlin Radoslavov > Yikes. I made a typo in the destination address when I responded to > Pavlin's mail, so this never went out to the list. I think I already received this email through the list, but I am not sure. In any case, I am happy with the changes, so I don't have any other comments. Thanks, Pavlin > > -Hugh > > ------- Forwarded Message ------- > From: Hugh Holbrook > To: holbrook@cisco.com > Cc: ssm-interest@external.cicso.com, pavlin@icir.org, > holbrook@cisco.com, dthaler@microsoft.com > Subject: Re: Fwd: Re: draft-ietf-ssm-arch-01, wg last call deadline 12/9/2002 > Reply-To: holbrook@cisco.com > Message-Id: <20021213202557.677B710B7A7@holbrook-laptop.cisco.com> > Date: Fri, 13 Dec 2002 15:25:57 -0500 (EST) > > Thanks for the detailed comments, Pavlin. > > Responses to your non-IPv6 related comments are inline. I'll follow > up separately with responses to your IPv6 comments. > > -Hugh > > > ------- Forwarded Message ------- > > Message-Id: <200211210052.gAL0qDoo082003@possum.icir.org> > > To: holbrook@cisco.com > > Cc: ssm-interest@cisco.com > > Subject: Re: draft-ietf-ssm-arch-01, wg last call deadline 12/9/2002 > > Date: Wed, 20 Nov 2002 16:52:13 -0800 > > From: Pavlin Radoslavov > > > > > There is a new revision of the SSM architecture draft in the ID > > > archives: > > > > > > draft-ietf-ssm-arch-01.txt > > > > > > Please consider this email as notice of an SSM working group last call > > > for comments on this document. Send comments by 12/9/2002. > > > > Several comments (in no particular order): > > > > * You may want to check the I-D against the nits in > > http://www.ietf.org/ID-nits.html > > E.g, don't use citations in the Abstract. > > Thanks. I did that. In addition to the citations that you pointed > out, I added Copyright and IPR sections and changed the example IPv4 > addresses to conform to rfc3330 (use 192.0.2.*) > > > * Should the draft include a recommendation that if a host is > > updated to support SSM, then ASM (*,G) join request by an > > application for a multicast group that fails within the SSM range > > should return an error? > > I think this is a good suggestion. Brian and I also discussed > something like this in the context of the IGMPv3/MLDv2 draft. When we > originally wrote the -arch draft, it was not clear how a host would > really know the SSM address range (other than by configuration). Now, > there is the (proposed) MRD option for the SSM range advertisement, > and we've put in text about possible manual configuration also. So I > think it would make sense to specify this. > > How about adding the following text to the second to last paragraph of > 4.1 (the one that mentions the MSFAPI) as follows: > > When a host has been configured to know the SSM address range, either > manually or using a protocol, then the host's operating system SHOULD > return an error to an application that makes a non-source-specific > request to receive data sent to an SSM destination address. > > I'm interested in hearing opinions on this from the list. > > > * After enumerating the benefits of the SSM model in Section 1, > > what about enumerating its limitations/drawbacks? :) > > Fair enough. I'll come up with something. > > > * Reference [IANA-ALLOCATION] should point to > > http://www.iana.org/assignments/multicast-addresses > > Done. > > > * Use consistent notation for the IPv6 hex addresses. E.g., the > > draft has addresses like FF3x::7fff:ffff which mixes capital with > > small letters. > > Done > > > Thanks, > > Pavlin > > > _______________________________________________ Ssm mailing list Ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Wed Jan 15 03:16:00 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 DAA19546 for ; Wed, 15 Jan 2003 03:16:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0F8UWG21385 for ssm-archive@odin.ietf.org; Wed, 15 Jan 2003 03:30:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F8UVJ21382 for ; Wed, 15 Jan 2003 03:30:31 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19538 for ; Wed, 15 Jan 2003 03:15:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F8QSJ21165; Wed, 15 Jan 2003 03:26:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F8HBJ20820 for ; Wed, 15 Jan 2003 03:17:11 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19212 for ; Wed, 15 Jan 2003 03:02:07 -0500 (EST) Received: from holbrook-laptop.cisco.com (sjc-vpn1-676.cisco.com [10.21.98.164]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h0F85N0E012220 for ; Wed, 15 Jan 2003 00:05:28 -0800 (PST) Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id 21E0810B869; Wed, 15 Jan 2003 03:03:09 -0500 (EST) From: Hugh Holbrook To: ssm@ietf.org Reply-To: holbrook@cisco.com Message-Id: <20030115080309.21E0810B869@holbrook-laptop.cisco.com> Date: Wed, 15 Jan 2003 03:03:09 -0500 (EST) Subject: [ssm] Fwd: Re: Fwd: Re: Fwd: Re: draft-ietf-ssm-arch-01, wg last call deadline 12/9/2002 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: , Pavlin asked me to relay this message to the list for the record. This message originally bounced. -Hugh ------- Forwarded Message ------- Message-Id: <200212181828.gBIISE2U090143@possum.icir.org> To: holbrook@cisco.com Cc: ssm-interest@external.cisco.com, pavlin@icir.org Subject: Re: Fwd: Re: Fwd: Re: draft-ietf-ssm-arch-01, wg last call deadline 12/9/2002 Date: Wed, 18 Dec 2002 10:28:14 -0800 From: Pavlin Radoslavov > Yikes. I made a typo in the destination address when I responded to > Pavlin's mail, so this never went out to the list. I think I already received this email through the list, but I am not sure. In any case, I am happy with the changes, so I don't have any other comments. Thanks, Pavlin > > -Hugh > > ------- Forwarded Message ------- > From: Hugh Holbrook > To: holbrook@cisco.com > Cc: ssm-interest@external.cicso.com, pavlin@icir.org, > holbrook@cisco.com, dthaler@microsoft.com > Subject: Re: Fwd: Re: draft-ietf-ssm-arch-01, wg last call deadline 12/9/2002 > Reply-To: holbrook@cisco.com > Message-Id: <20021213202557.677B710B7A7@holbrook-laptop.cisco.com> > Date: Fri, 13 Dec 2002 15:25:57 -0500 (EST) > > Thanks for the detailed comments, Pavlin. > > Responses to your non-IPv6 related comments are inline. I'll follow > up separately with responses to your IPv6 comments. > > -Hugh > > > ------- Forwarded Message ------- > > Message-Id: <200211210052.gAL0qDoo082003@possum.icir.org> > > To: holbrook@cisco.com > > Cc: ssm-interest@cisco.com > > Subject: Re: draft-ietf-ssm-arch-01, wg last call deadline 12/9/2002 > > Date: Wed, 20 Nov 2002 16:52:13 -0800 > > From: Pavlin Radoslavov > > > > > There is a new revision of the SSM architecture draft in the ID > > > archives: > > > > > > draft-ietf-ssm-arch-01.txt > > > > > > Please consider this email as notice of an SSM working group last call > > > for comments on this document. Send comments by 12/9/2002. > > > > Several comments (in no particular order): > > > > * You may want to check the I-D against the nits in > > http://www.ietf.org/ID-nits.html > > E.g, don't use citations in the Abstract. > > Thanks. I did that. In addition to the citations that you pointed > out, I added Copyright and IPR sections and changed the example IPv4 > addresses to conform to rfc3330 (use 192.0.2.*) > > > * Should the draft include a recommendation that if a host is > > updated to support SSM, then ASM (*,G) join request by an > > application for a multicast group that fails within the SSM range > > should return an error? > > I think this is a good suggestion. Brian and I also discussed > something like this in the context of the IGMPv3/MLDv2 draft. When we > originally wrote the -arch draft, it was not clear how a host would > really know the SSM address range (other than by configuration). Now, > there is the (proposed) MRD option for the SSM range advertisement, > and we've put in text about possible manual configuration also. So I > think it would make sense to specify this. > > How about adding the following text to the second to last paragraph of > 4.1 (the one that mentions the MSFAPI) as follows: > > When a host has been configured to know the SSM address range, either > manually or using a protocol, then the host's operating system SHOULD > return an error to an application that makes a non-source-specific > request to receive data sent to an SSM destination address. > > I'm interested in hearing opinions on this from the list. > > > * After enumerating the benefits of the SSM model in Section 1, > > what about enumerating its limitations/drawbacks? :) > > Fair enough. I'll come up with something. > > > * Reference [IANA-ALLOCATION] should point to > > http://www.iana.org/assignments/multicast-addresses > > Done. > > > * Use consistent notation for the IPv6 hex addresses. E.g., the > > draft has addresses like FF3x::7fff:ffff which mixes capital with > > small letters. > > Done > > > Thanks, > > Pavlin > > > _______________________________________________ Ssm mailing list Ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-admin@ietf.org Wed Jan 15 04:40: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 EAA21014 for ; Wed, 15 Jan 2003 04:40:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F9sKJ27336; Wed, 15 Jan 2003 04:54:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F9lDJ27092 for ; Wed, 15 Jan 2003 04:47:13 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20939 for ; Wed, 15 Jan 2003 04:32:08 -0500 (EST) Received: from holbrook-laptop.cisco.com (sjc-vpn1-676.cisco.com [10.21.98.164]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h0F9ZO0E017146; Wed, 15 Jan 2003 01:35:24 -0800 (PST) Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id E7BE610B7A7; Wed, 15 Jan 2003 04:33:05 -0500 (EST) From: Hugh Holbrook To: holbrook@cisco.com Cc: ssm@ietf.org, pavlin@icir.org In-reply-to: <20021213202557.677B710B7A7@holbrook-laptop.cisco.com> Reply-To: holbrook@cisco.com Message-Id: <20030115093305.E7BE610B7A7@holbrook-laptop.cisco.com> Date: Wed, 15 Jan 2003 04:33:05 -0500 (EST) Subject: [ssm] Re: last call comments on ssm-arch doc Sender: ssm-admin@ietf.org Errors-To: ssm-admin@ietf.org X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , I wrote: > Pavlin wrote: > > * After enumerating the benefits of the SSM model in Section 1, > > what about enumerating its limitations/drawbacks? :) > > Fair enough. I'll come up with something. I promised to come up with some text. How about this: SSM is particularly well-suited to dissemination-style applications with a single sender. It can be used in multi-source applications, but the multi-source "rendezvous" functionality must be implemented by the application or by an application-layer library. For instance, an application that desires to provide a secondary data source in case the primary source fails must implement the failover mechanism in the application itself, presumably by using two channels, as two hosts cannot both send to a single SSM channel. SSM does not support network- layer multicast resource discovery. -Hugh _______________________________________________ Ssm mailing list Ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Wed Jan 15 04:43:52 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 EAA21156 for ; Wed, 15 Jan 2003 04:43:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0F9wOM27544 for ssm-archive@odin.ietf.org; Wed, 15 Jan 2003 04:58:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F9wOJ27541 for ; Wed, 15 Jan 2003 04:58:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21140 for ; Wed, 15 Jan 2003 04:43:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F9sKJ27336; Wed, 15 Jan 2003 04:54:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F9lDJ27092 for ; Wed, 15 Jan 2003 04:47:13 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20939 for ; Wed, 15 Jan 2003 04:32:08 -0500 (EST) Received: from holbrook-laptop.cisco.com (sjc-vpn1-676.cisco.com [10.21.98.164]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h0F9ZO0E017146; Wed, 15 Jan 2003 01:35:24 -0800 (PST) Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id E7BE610B7A7; Wed, 15 Jan 2003 04:33:05 -0500 (EST) From: Hugh Holbrook To: holbrook@cisco.com Cc: ssm@ietf.org, pavlin@icir.org In-reply-to: <20021213202557.677B710B7A7@holbrook-laptop.cisco.com> Reply-To: holbrook@cisco.com Message-Id: <20030115093305.E7BE610B7A7@holbrook-laptop.cisco.com> Date: Wed, 15 Jan 2003 04:33:05 -0500 (EST) Subject: [ssm] Re: last call comments on ssm-arch doc Sender: ssm-admin@ietf.org Errors-To: ssm-admin@ietf.org X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , I wrote: > Pavlin wrote: > > * After enumerating the benefits of the SSM model in Section 1, > > what about enumerating its limitations/drawbacks? :) > > Fair enough. I'll come up with something. I promised to come up with some text. How about this: SSM is particularly well-suited to dissemination-style applications with a single sender. It can be used in multi-source applications, but the multi-source "rendezvous" functionality must be implemented by the application or by an application-layer library. For instance, an application that desires to provide a secondary data source in case the primary source fails must implement the failover mechanism in the application itself, presumably by using two channels, as two hosts cannot both send to a single SSM channel. SSM does not support network- layer multicast resource discovery. -Hugh _______________________________________________ Ssm mailing list Ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-admin@ietf.org Wed Jan 15 05:16: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 FAA21701 for ; Wed, 15 Jan 2003 05:16:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FAVPJ29700; Wed, 15 Jan 2003 05:31:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FAOXJ29515 for ; Wed, 15 Jan 2003 05:24:33 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21621 for ; Wed, 15 Jan 2003 05:09:29 -0500 (EST) Received: from holbrook-laptop.cisco.com (sjc-vpn1-676.cisco.com [10.21.98.164]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h0FACm0E001805 for ; Wed, 15 Jan 2003 02:12:49 -0800 (PST) Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id 79A8510B7A7; Wed, 15 Jan 2003 05:10:35 -0500 (EST) From: Hugh Holbrook To: ssm@ietf.org Reply-To: holbrook@cisco.com Message-Id: <20030115101035.79A8510B7A7@holbrook-laptop.cisco.com> Date: Wed, 15 Jan 2003 05:10:35 -0500 (EST) Subject: [ssm] draft-ietf-ssm-arch last call changes summary Sender: ssm-admin@ietf.org Errors-To: ssm-admin@ietf.org X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , I am about to submit a new version of draft-ietf-ssm-arch to the I-D archives. I've attached a list of the changes in the upcoming version, with the source of the request. I believe this new revision addresses all of the comments that came up during the wg last call. If you have any comments that you haven't yet sent or that I've missed and aren't addressed below, please (re)send them ASAP. Thanks! -Hugh ---------------------------------------------------------------- - [pavlin] Added text: OS API should return an error for a (*,G) request on an SSM address. - [pavlin] Added a note about limitations of SSM. (1) Any multi-source aspect apps must be implemented in the application layer. (2) SSM does not support network-layer resource discovery. - [pekka/brian] Added clarification about the SSM address range FF3x::/32 is reserved for SSM P=1 and T=1 and plen=0 is required. Thus, FF3x::/96 is the actual range today because network prefix field must be zero But we leave open the possibility of putting something else in the network prefix field. - [pavlin] Changed erroneous FF2x:: to FF3x:: - [pekka] New text on administrative scoping to describe admin-scoping in v6 and to clarify that there is none for IPv4. - [pekka] New text on source routing: A router SHOULD NOT allow source-routing to an SSM addr; MAY have a config option to allow it - [me/bweis/mbaugher] Add security considerations text describing the IPSec/SSM issue. - Minor things: - [pavlin] Use consistent capitalization on v6 addresses - [me] Use consistent capitalization of Source-Specific - [pavlin] id-nits - Removed references from abstract and shortened it - Modified address ranges - Added IPR notice and Copyright Statement. - [brad] Changed author mailing address _______________________________________________ Ssm mailing list Ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Wed Jan 15 05:20:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21730 for ; Wed, 15 Jan 2003 05:20:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FAZHs29828 for ssm-archive@odin.ietf.org; Wed, 15 Jan 2003 05:35:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FAZHJ29825 for ; Wed, 15 Jan 2003 05:35:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21720 for ; Wed, 15 Jan 2003 05:20:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FAVPJ29700; Wed, 15 Jan 2003 05:31:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FAOXJ29515 for ; Wed, 15 Jan 2003 05:24:33 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21621 for ; Wed, 15 Jan 2003 05:09:29 -0500 (EST) Received: from holbrook-laptop.cisco.com (sjc-vpn1-676.cisco.com [10.21.98.164]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h0FACm0E001805 for ; Wed, 15 Jan 2003 02:12:49 -0800 (PST) Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id 79A8510B7A7; Wed, 15 Jan 2003 05:10:35 -0500 (EST) From: Hugh Holbrook To: ssm@ietf.org Reply-To: holbrook@cisco.com Message-Id: <20030115101035.79A8510B7A7@holbrook-laptop.cisco.com> Date: Wed, 15 Jan 2003 05:10:35 -0500 (EST) Subject: [ssm] draft-ietf-ssm-arch last call changes summary Sender: ssm-admin@ietf.org Errors-To: ssm-admin@ietf.org X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , I am about to submit a new version of draft-ietf-ssm-arch to the I-D archives. I've attached a list of the changes in the upcoming version, with the source of the request. I believe this new revision addresses all of the comments that came up during the wg last call. If you have any comments that you haven't yet sent or that I've missed and aren't addressed below, please (re)send them ASAP. Thanks! -Hugh ---------------------------------------------------------------- - [pavlin] Added text: OS API should return an error for a (*,G) request on an SSM address. - [pavlin] Added a note about limitations of SSM. (1) Any multi-source aspect apps must be implemented in the application layer. (2) SSM does not support network-layer resource discovery. - [pekka/brian] Added clarification about the SSM address range FF3x::/32 is reserved for SSM P=1 and T=1 and plen=0 is required. Thus, FF3x::/96 is the actual range today because network prefix field must be zero But we leave open the possibility of putting something else in the network prefix field. - [pavlin] Changed erroneous FF2x:: to FF3x:: - [pekka] New text on administrative scoping to describe admin-scoping in v6 and to clarify that there is none for IPv4. - [pekka] New text on source routing: A router SHOULD NOT allow source-routing to an SSM addr; MAY have a config option to allow it - [me/bweis/mbaugher] Add security considerations text describing the IPSec/SSM issue. - Minor things: - [pavlin] Use consistent capitalization on v6 addresses - [me] Use consistent capitalization of Source-Specific - [pavlin] id-nits - Removed references from abstract and shortened it - Modified address ranges - Added IPR notice and Copyright Statement. - [brad] Changed author mailing address _______________________________________________ Ssm mailing list Ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-admin@ietf.org Wed Jan 15 06:30:55 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 GAA22633 for ; Wed, 15 Jan 2003 06:30:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FBjLJ02338; Wed, 15 Jan 2003 06:45:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FBcpJ02077 for ; Wed, 15 Jan 2003 06:38:51 -0500 Received: from sophia.inria.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22563 for ; Wed, 15 Jan 2003 06:23:45 -0500 (EST) Received: from localhost (odie.inria.fr [138.96.88.52]) by sophia.inria.fr (8.12.5/8.12.5) with ESMTP id h0FBQu5d005200; Wed, 15 Jan 2003 12:26:56 +0100 X-Authentication-Warning: sophia.inria.fr: Host odie.inria.fr [138.96.88.52] claimed to be localhost Date: Wed, 15 Jan 2003 12:26:55 +0100 (MET) Message-Id: <20030115.122655.70199744.Hitoshi.Asaeda@sophia.inria.fr> To: holbrook@cisco.com Cc: ssm@ietf.org Subject: Re: [ssm] Re: last call comments on ssm-arch doc From: Hitoshi Asaeda In-Reply-To: <20030115093305.E7BE610B7A7@holbrook-laptop.cisco.com> References: <20021213202557.677B710B7A7@holbrook-laptop.cisco.com> <20030115093305.E7BE610B7A7@holbrook-laptop.cisco.com> X-Mailer: Mew version 2.2rc1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ssm-admin@ietf.org Errors-To: ssm-admin@ietf.org X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hugh, > SSM is particularly well-suited to dissemination-style applications with > a single sender. It can be used in multi-source applications, but the > multi-source "rendezvous" functionality must be implemented by the > application or by an application-layer library. For instance, an > application that desires to provide a secondary data source in case the > primary source fails must implement the failover mechanism in the > application itself, presumably by using two channels, as two hosts > cannot both send to a single SSM channel. SSM does not support network- > layer multicast resource discovery. I'm confusing the terminology (or definition) of "channel" now. Let's imagine something like an application of a panel discussion. E.g., now, there are two senders (S1 and S2) as the speakers, and then we do ((S1,S2),G) join. In this case, does this panel discussion works as "a single channel" application or "two channels" application? This example can be similar case of using a whiteboard application. S1 and S2 write some words on a same whiteboard, and many receivers watch it. In this application, do we say the receivers join "a single channel" or "two channels"? I've thought these answers would be "a single channel" since both S1 and S2 work for a same application, but your statements would make me reform... So, if each answer is "two channels", is it correct that a channel MUST consist of a single source except such failover mechanism? Or, are there any other applications that would prompt ((multiple Ss),G) join for a single channel? If the answer is "a single channel", then above statements might not be fair enough for me. Especially, "but the multi-source "rendezvous" functionality must be implemented by the application or by an application-layer library." seems to be strange. Thanks. -- Hitoshi Asaeda _______________________________________________ Ssm mailing list Ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Wed Jan 15 06:34:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22730 for ; Wed, 15 Jan 2003 06:34:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FBnCw02473 for ssm-archive@odin.ietf.org; Wed, 15 Jan 2003 06:49:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FBnBJ02470 for ; Wed, 15 Jan 2003 06:49:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22704 for ; Wed, 15 Jan 2003 06:34:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FBjLJ02338; Wed, 15 Jan 2003 06:45:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FBcpJ02077 for ; Wed, 15 Jan 2003 06:38:51 -0500 Received: from sophia.inria.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22563 for ; Wed, 15 Jan 2003 06:23:45 -0500 (EST) Received: from localhost (odie.inria.fr [138.96.88.52]) by sophia.inria.fr (8.12.5/8.12.5) with ESMTP id h0FBQu5d005200; Wed, 15 Jan 2003 12:26:56 +0100 X-Authentication-Warning: sophia.inria.fr: Host odie.inria.fr [138.96.88.52] claimed to be localhost Date: Wed, 15 Jan 2003 12:26:55 +0100 (MET) Message-Id: <20030115.122655.70199744.Hitoshi.Asaeda@sophia.inria.fr> To: holbrook@cisco.com Cc: ssm@ietf.org Subject: Re: [ssm] Re: last call comments on ssm-arch doc From: Hitoshi Asaeda In-Reply-To: <20030115093305.E7BE610B7A7@holbrook-laptop.cisco.com> References: <20021213202557.677B710B7A7@holbrook-laptop.cisco.com> <20030115093305.E7BE610B7A7@holbrook-laptop.cisco.com> X-Mailer: Mew version 2.2rc1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ssm-admin@ietf.org Errors-To: ssm-admin@ietf.org X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hugh, > SSM is particularly well-suited to dissemination-style applications with > a single sender. It can be used in multi-source applications, but the > multi-source "rendezvous" functionality must be implemented by the > application or by an application-layer library. For instance, an > application that desires to provide a secondary data source in case the > primary source fails must implement the failover mechanism in the > application itself, presumably by using two channels, as two hosts > cannot both send to a single SSM channel. SSM does not support network- > layer multicast resource discovery. I'm confusing the terminology (or definition) of "channel" now. Let's imagine something like an application of a panel discussion. E.g., now, there are two senders (S1 and S2) as the speakers, and then we do ((S1,S2),G) join. In this case, does this panel discussion works as "a single channel" application or "two channels" application? This example can be similar case of using a whiteboard application. S1 and S2 write some words on a same whiteboard, and many receivers watch it. In this application, do we say the receivers join "a single channel" or "two channels"? I've thought these answers would be "a single channel" since both S1 and S2 work for a same application, but your statements would make me reform... So, if each answer is "two channels", is it correct that a channel MUST consist of a single source except such failover mechanism? Or, are there any other applications that would prompt ((multiple Ss),G) join for a single channel? If the answer is "a single channel", then above statements might not be fair enough for me. Especially, "but the multi-source "rendezvous" functionality must be implemented by the application or by an application-layer library." seems to be strange. Thanks. -- Hitoshi Asaeda _______________________________________________ Ssm mailing list Ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-admin@ietf.org Wed Jan 15 08:07:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24863 for ; Wed, 15 Jan 2003 08:07:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FDMDJ08523; Wed, 15 Jan 2003 08:22:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FDDnJ08040 for ; Wed, 15 Jan 2003 08:13:49 -0500 Received: from ncsmtp03.ogw.rr.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24439 for ; Wed, 15 Jan 2003 07:58:41 -0500 (EST) Received: from mail4.nc.rr.com (fe4 [24.93.67.51]) by ncsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id h0FD1DiZ014186; Wed, 15 Jan 2003 08:01:13 -0500 (EST) Received: from nc.rr.com ([63.109.132.2]) by mail4.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Wed, 15 Jan 2003 08:02:53 -0500 Message-ID: <3E255C25.2050408@nc.rr.com> Date: Wed, 15 Jan 2003 08:03:33 -0500 From: Brian Haberman Organization: No Organization Here User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: holbrook@cisco.com CC: ssm@ietf.org, mbaugher@cisco.com, bew@cisco.com Subject: Re: [ssm] SSM with IPSec References: <20030115062534.076C910B869@holbrook-laptop.cisco.com> In-Reply-To: <20030115062534.076C910B869@holbrook-laptop.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ssm-admin@ietf.org Errors-To: ssm-admin@ietf.org X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hugh, I had a similar discussion with Thomas Hardjono on the subject. I feel comfortable with adding text the the arch doc and allowing MSEC to work through the details. I would suggest that some of us volunteer to assist the MSEC guys with the details of SSM if needed. I am willing to help them out if the need arises. Brian Hugh Holbrook wrote: > Hello, SSM working group. > > [ Welcome to the brand spanking new ssm@ietf.org mailing list. Please > tell me if you notice any problems with the list. You should have > received a mail from the mailman program running the list. The SSM > page at ietf.org still lists the [un]subscription info for the old > list, but it will be updated shortly. ] > > Last week, I was talking to some security folks here (Brian Weis and > Mark Baugher) who pointed out that IPSec as specified in RFC2401 has > some issues when securing SSM traffic. In short, the problem is that > including the source in the SA lookup isn't really accounted for in > IPSec, but it really should be. Details below. > > I don't think this is a really urgent problem, but I think the WG > should be aware of the problem, so I'll spell it out. Comments > solicited. > > Some IPSec background: > > [Apologies for the tutorial, but I know that not everyone in the wg is > fluent in IPSec details.] > > IPSec, in RFC2401, specifies that an incoming IPSec packet is looked > up on arrival in a local Security Association Database (SAD) to decide > which Security Association (SA) should be applied to the packet [see > section 4.4.3 of RFC2401.] The resulting SA determines the > decryption/authentication key, and the anti-replay window (if one is > used). > > RFC2401 specifies that the key for the SAD lookup is a 3-tuple of: > > - the packet's destination IP address > - the IPSec protocol (ESP or AH) > - the Security Parameters Index (SPI) > > The problem (for SSM) is that the source address is *not* included in > the SAD lookup. > > The problem: > > You would to be sure that two unrelated SSM channels, if secured by > IPSec, can be guaranteed to have unique Security Associations at all > receivers. This should be true even if the senders accidentally > happen to choose the same SSM destination address. There is, however, > no entity that "owns" an SSM destination address and can reasonably > ensure that every sender to an SSM address uses a unique SPI > > One could envision a similar problem for ASM, but I believe in the ASM > case, the assumption of the IPSec design is that there exists a "group > controller" that logically "owns" the group and can hand out a unique > SPI to each source that needs one. But this doesn't apply to SSM. > The mere existence of such an entity for an SSM address would defeat > one of SSM's big benefits -- that external coordination with other > senders is not needed before choosing and using an SSM address. > > In practice, I don't think this problem is very severe. It only > arises if a receiver subscribes simultaneously to two unrelated > IPSec'ed channels whose sources happen to have chosen the same IPDA > and the same IPSec SPI. Given that the tuple contains 56 > bits of generally randomly-picked data, it is very unlikely to occur > in practice. However, I don't think the architecture should rely on > coincidence to work properly. > > What to do: > > The solution that I most like is fairly easy to state: require the > source address to be part of the SA lookup when the destination > address is an SSM address. Mark and Brian inform me that the msec > working group is looking at solving the problem this way. > > The required action from the SSM working group is, I think, to simply > point out the problem in the -arch draft, more or less as I've done > above, and note that work is currently underway to address the > problem. I don't believe we need to or want to hold up the SSM draft > until msec (or ipsec) solves the problem, but I'd like to hear WG > comments on this topic. > > I'll probably be sending out some proposed modifications to the > architecture draft shortly. > > Thanks to Mark and Brian for pointing out this problem. _______________________________________________ Ssm mailing list Ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Wed Jan 15 08:11:27 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 IAA24976 for ; Wed, 15 Jan 2003 08:11:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FDQ4d08814 for ssm-archive@odin.ietf.org; Wed, 15 Jan 2003 08:26:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FDQ4J08811 for ; Wed, 15 Jan 2003 08:26:04 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24965 for ; Wed, 15 Jan 2003 08:10:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FDMDJ08523; Wed, 15 Jan 2003 08:22:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FDDnJ08040 for ; Wed, 15 Jan 2003 08:13:49 -0500 Received: from ncsmtp03.ogw.rr.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24439 for ; Wed, 15 Jan 2003 07:58:41 -0500 (EST) Received: from mail4.nc.rr.com (fe4 [24.93.67.51]) by ncsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id h0FD1DiZ014186; Wed, 15 Jan 2003 08:01:13 -0500 (EST) Received: from nc.rr.com ([63.109.132.2]) by mail4.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Wed, 15 Jan 2003 08:02:53 -0500 Message-ID: <3E255C25.2050408@nc.rr.com> Date: Wed, 15 Jan 2003 08:03:33 -0500 From: Brian Haberman Organization: No Organization Here User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: holbrook@cisco.com CC: ssm@ietf.org, mbaugher@cisco.com, bew@cisco.com Subject: Re: [ssm] SSM with IPSec References: <20030115062534.076C910B869@holbrook-laptop.cisco.com> In-Reply-To: <20030115062534.076C910B869@holbrook-laptop.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ssm-admin@ietf.org Errors-To: ssm-admin@ietf.org X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hugh, I had a similar discussion with Thomas Hardjono on the subject. I feel comfortable with adding text the the arch doc and allowing MSEC to work through the details. I would suggest that some of us volunteer to assist the MSEC guys with the details of SSM if needed. I am willing to help them out if the need arises. Brian Hugh Holbrook wrote: > Hello, SSM working group. > > [ Welcome to the brand spanking new ssm@ietf.org mailing list. Please > tell me if you notice any problems with the list. You should have > received a mail from the mailman program running the list. The SSM > page at ietf.org still lists the [un]subscription info for the old > list, but it will be updated shortly. ] > > Last week, I was talking to some security folks here (Brian Weis and > Mark Baugher) who pointed out that IPSec as specified in RFC2401 has > some issues when securing SSM traffic. In short, the problem is that > including the source in the SA lookup isn't really accounted for in > IPSec, but it really should be. Details below. > > I don't think this is a really urgent problem, but I think the WG > should be aware of the problem, so I'll spell it out. Comments > solicited. > > Some IPSec background: > > [Apologies for the tutorial, but I know that not everyone in the wg is > fluent in IPSec details.] > > IPSec, in RFC2401, specifies that an incoming IPSec packet is looked > up on arrival in a local Security Association Database (SAD) to decide > which Security Association (SA) should be applied to the packet [see > section 4.4.3 of RFC2401.] The resulting SA determines the > decryption/authentication key, and the anti-replay window (if one is > used). > > RFC2401 specifies that the key for the SAD lookup is a 3-tuple of: > > - the packet's destination IP address > - the IPSec protocol (ESP or AH) > - the Security Parameters Index (SPI) > > The problem (for SSM) is that the source address is *not* included in > the SAD lookup. > > The problem: > > You would to be sure that two unrelated SSM channels, if secured by > IPSec, can be guaranteed to have unique Security Associations at all > receivers. This should be true even if the senders accidentally > happen to choose the same SSM destination address. There is, however, > no entity that "owns" an SSM destination address and can reasonably > ensure that every sender to an SSM address uses a unique SPI > > One could envision a similar problem for ASM, but I believe in the ASM > case, the assumption of the IPSec design is that there exists a "group > controller" that logically "owns" the group and can hand out a unique > SPI to each source that needs one. But this doesn't apply to SSM. > The mere existence of such an entity for an SSM address would defeat > one of SSM's big benefits -- that external coordination with other > senders is not needed before choosing and using an SSM address. > > In practice, I don't think this problem is very severe. It only > arises if a receiver subscribes simultaneously to two unrelated > IPSec'ed channels whose sources happen to have chosen the same IPDA > and the same IPSec SPI. Given that the tuple contains 56 > bits of generally randomly-picked data, it is very unlikely to occur > in practice. However, I don't think the architecture should rely on > coincidence to work properly. > > What to do: > > The solution that I most like is fairly easy to state: require the > source address to be part of the SA lookup when the destination > address is an SSM address. Mark and Brian inform me that the msec > working group is looking at solving the problem this way. > > The required action from the SSM working group is, I think, to simply > point out the problem in the -arch draft, more or less as I've done > above, and note that work is currently underway to address the > problem. I don't believe we need to or want to hold up the SSM draft > until msec (or ipsec) solves the problem, but I'd like to hear WG > comments on this topic. > > I'll probably be sending out some proposed modifications to the > architecture draft shortly. > > Thanks to Mark and Brian for pointing out this problem. _______________________________________________ Ssm mailing list Ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-admin@ietf.org Wed Jan 15 08:24:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26014 for ; Wed, 15 Jan 2003 08:24:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FDcTJ10195; Wed, 15 Jan 2003 08:38:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FDV7J09036 for ; Wed, 15 Jan 2003 08:31:07 -0500 Received: from isis.lip6.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25131 for ; Wed, 15 Jan 2003 08:15:58 -0500 (EST) Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2]) by isis.lip6.fr (8.12.4/jtpda-5.4+victor) with ESMTP id h0FDJ5mT029804 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) ; Wed, 15 Jan 2003 14:19:05 +0100 X-pt: isis.lip6.fr Received: from otos (otos [132.227.61.47]) by tibre.lip6.fr (8.11.6/8.11.3) with SMTP id h0FDJ5312918; Wed, 15 Jan 2003 14:19:05 +0100 (MET) From: "Rolland Vida" To: "Hitoshi Asaeda" , Cc: Subject: RE: [ssm] Re: last call comments on ssm-arch doc Date: Wed, 15 Jan 2003 14:19:05 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <20030115.122655.70199744.Hitoshi.Asaeda@sophia.inria.fr> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Scanned-By: isis.lip6.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 Hitoshi, > Let's imagine something like an application of a panel discussion. > E.g., now, there are two senders (S1 and S2) as the speakers, and then > we do ((S1,S2),G) join. In this case, does this panel discussion works > as "a single channel" application or "two channels" application? We obviously have two channels: (S1, G) and (S2,G). The fact that a receiver sends an IGMPv3 join containing (INCLUDE(S1,S2),G) does not mean that there is a unified channel, but that he wants to join two channels in the same time. You might have another receiver that sends INCLUDE(S1,G) only, so the channels have to be separated. > I've thought these answers would be "a single channel" since both S1 > and S2 work for a same application, The fact that it is the same application or not has nothing to do with it. Each source has its own channel. > So, if each answer is "two channels", is it correct that a channel > MUST consist of a single source except such failover mechanism? As Hugh said, the channel ALWAYS corresponds to a single source. If we want a secondary source to assure a failover mechanism for example, it should have its own channel. But to assure the transparency of the mechanism for the end-user, the binding between these two channels should be built in the application itself, and not at the network layer. At least this is what I understood from Hugh's message, and this is what seems to be correct for me too. Regards, Rolland Vida _______________________________________________ Ssm mailing list Ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Wed Jan 15 08:27:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26474 for ; Wed, 15 Jan 2003 08:27:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FDgZI10514 for ssm-archive@odin.ietf.org; Wed, 15 Jan 2003 08:42:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FDgYJ10511 for ; Wed, 15 Jan 2003 08:42:34 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26438 for ; Wed, 15 Jan 2003 08:27:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FDcTJ10195; Wed, 15 Jan 2003 08:38:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FDV7J09036 for ; Wed, 15 Jan 2003 08:31:07 -0500 Received: from isis.lip6.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25131 for ; Wed, 15 Jan 2003 08:15:58 -0500 (EST) Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2]) by isis.lip6.fr (8.12.4/jtpda-5.4+victor) with ESMTP id h0FDJ5mT029804 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) ; Wed, 15 Jan 2003 14:19:05 +0100 X-pt: isis.lip6.fr Received: from otos (otos [132.227.61.47]) by tibre.lip6.fr (8.11.6/8.11.3) with SMTP id h0FDJ5312918; Wed, 15 Jan 2003 14:19:05 +0100 (MET) From: "Rolland Vida" To: "Hitoshi Asaeda" , Cc: Subject: RE: [ssm] Re: last call comments on ssm-arch doc Date: Wed, 15 Jan 2003 14:19:05 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <20030115.122655.70199744.Hitoshi.Asaeda@sophia.inria.fr> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Scanned-By: isis.lip6.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 Hitoshi, > Let's imagine something like an application of a panel discussion. > E.g., now, there are two senders (S1 and S2) as the speakers, and then > we do ((S1,S2),G) join. In this case, does this panel discussion works > as "a single channel" application or "two channels" application? We obviously have two channels: (S1, G) and (S2,G). The fact that a receiver sends an IGMPv3 join containing (INCLUDE(S1,S2),G) does not mean that there is a unified channel, but that he wants to join two channels in the same time. You might have another receiver that sends INCLUDE(S1,G) only, so the channels have to be separated. > I've thought these answers would be "a single channel" since both S1 > and S2 work for a same application, The fact that it is the same application or not has nothing to do with it. Each source has its own channel. > So, if each answer is "two channels", is it correct that a channel > MUST consist of a single source except such failover mechanism? As Hugh said, the channel ALWAYS corresponds to a single source. If we want a secondary source to assure a failover mechanism for example, it should have its own channel. But to assure the transparency of the mechanism for the end-user, the binding between these two channels should be built in the application itself, and not at the network layer. At least this is what I understood from Hugh's message, and this is what seems to be correct for me too. Regards, Rolland Vida _______________________________________________ Ssm mailing list Ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-admin@ietf.org Wed Jan 15 09:16: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 JAA27957 for ; Wed, 15 Jan 2003 09:16:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FEUUJ13063; Wed, 15 Jan 2003 09:30:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FENAJ12830 for ; Wed, 15 Jan 2003 09:23:10 -0500 Received: from sophia.inria.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27779 for ; Wed, 15 Jan 2003 09:08:00 -0500 (EST) Received: from localhost (odie.inria.fr [138.96.88.52]) by sophia.inria.fr (8.12.5/8.12.5) with ESMTP id h0FEB95d016663; Wed, 15 Jan 2003 15:11:10 +0100 X-Authentication-Warning: sophia.inria.fr: Host odie.inria.fr [138.96.88.52] claimed to be localhost Date: Wed, 15 Jan 2003 15:11:09 +0100 (MET) Message-Id: <20030115.151109.102792220.Hitoshi.Asaeda@sophia.inria.fr> To: Rolland.Vida@lip6.fr, holbrook@cisco.com Cc: ssm@ietf.org Subject: Re: [ssm] Re: last call comments on ssm-arch doc From: Hitoshi Asaeda In-Reply-To: References: <20030115.122655.70199744.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 > As Hugh said, the channel ALWAYS corresponds to a single source. If we want > a secondary source to assure a failover mechanism for example, it should > have its own channel. Okay, I understand. -- Hitoshi Asaeda _______________________________________________ Ssm mailing list Ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Wed Jan 15 09:20:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28130 for ; Wed, 15 Jan 2003 09:20:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FEYie13431 for ssm-archive@odin.ietf.org; Wed, 15 Jan 2003 09:34:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FEYiJ13428 for ; Wed, 15 Jan 2003 09:34:44 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28116 for ; Wed, 15 Jan 2003 09:19:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FEUUJ13063; Wed, 15 Jan 2003 09:30:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FENAJ12830 for ; Wed, 15 Jan 2003 09:23:10 -0500 Received: from sophia.inria.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27779 for ; Wed, 15 Jan 2003 09:08:00 -0500 (EST) Received: from localhost (odie.inria.fr [138.96.88.52]) by sophia.inria.fr (8.12.5/8.12.5) with ESMTP id h0FEB95d016663; Wed, 15 Jan 2003 15:11:10 +0100 X-Authentication-Warning: sophia.inria.fr: Host odie.inria.fr [138.96.88.52] claimed to be localhost Date: Wed, 15 Jan 2003 15:11:09 +0100 (MET) Message-Id: <20030115.151109.102792220.Hitoshi.Asaeda@sophia.inria.fr> To: Rolland.Vida@lip6.fr, holbrook@cisco.com Cc: ssm@ietf.org Subject: Re: [ssm] Re: last call comments on ssm-arch doc From: Hitoshi Asaeda In-Reply-To: References: <20030115.122655.70199744.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 > As Hugh said, the channel ALWAYS corresponds to a single source. If we want > a secondary source to assure a failover mechanism for example, it should > have its own channel. Okay, I understand. -- Hitoshi Asaeda _______________________________________________ Ssm mailing list Ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-admin@ietf.org Wed Jan 15 10:10: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 KAA29285 for ; Wed, 15 Jan 2003 10:10:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FFOSJ17017; Wed, 15 Jan 2003 10:24:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FFHsJ16735 for ; Wed, 15 Jan 2003 10:17:54 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29193 for ; Wed, 15 Jan 2003 10:02:37 -0500 (EST) Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h0FF5x0E023007; Wed, 15 Jan 2003 07:05:59 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id HAA25436; Wed, 15 Jan 2003 07:05:59 -0800 (PST) Date: Wed, 15 Jan 2003 07:05:59 -0800 From: Toerless Eckert To: Hitoshi Asaeda Cc: Rolland.Vida@lip6.fr, holbrook@cisco.com, ssm@ietf.org Subject: Re: [ssm] Re: last call comments on ssm-arch doc Message-ID: <20030115150558.GD2103@cypher.cisco.com> References: <20030115.122655.70199744.Hitoshi.Asaeda@sophia.inria.fr> <20030115.151109.102792220.Hitoshi.Asaeda@sophia.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030115.151109.102792220.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: , One note on the discussed application requirement: If you're building a pure ad-hoc multi-peer application then what was said in before on this thread is correct. One could argue though that in face of overwhelmingly web based or bound applications client/server models for application architectures have become more ubiquitous because they provide easier architectural solution to some typical problems, and if such a client/server architecture is used, then the use of IPmulticast or SSM specifically can easily be designed to be really "single source". Eg: If you're building the white board application as pure peer to peer, each peer has to become a SSM channel source. If you implement the application as a client/server system, the clients could unicast to the server, and the server would have one SSM channel to all clients. Advantages: Easier model for access control, session management and ressource allocation then in a full peer to peer model. Given that today most networked applications are somehow started via the web, makes it quite easy to imagine the typical solution to be one involving some web server applet or the like. So, architecturally, i think one can make three classes of SSM peer-to-peer applications: a) client/server control and data: clients send unicast to server, server multicasts on one or multiple SSM channels back to clients. b) client/server control, peer-to-peer data: clients have control connection with server to learn about peers multicasting. Data itself is multicasted on SSM channels from each client to other interested clients. c) peer-to-peer control and data: There is no central server. Instead new peers have to somehow discover at least one existing peer, who can then signal to all other peers the existance of this new peer. This peer-to-peer control connections can be unicast with some topology between peers or can be SSM. From the applications i know, it seems to me that c) is today only predominant in application that have lots of good reasons to avoid servers. The typical examples of course are those in which the server(s) would be in danger of being sued or bombed away anyhow (eg: typical file-sharing software or military applications). For typical commercial applications you almost always resort to a) or b), and then b) typically has a lot of advantages on access control, synchronization, etc., and a) is mostly used in cases where the added efficiency of avoiding passind data through a server becomes important. So from that perspective i think that SSM quite well, if not better fits the typical application retuirements than compared to ASM. Cheers Toerless _______________________________________________ Ssm mailing list Ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Wed Jan 15 10:13:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29390 for ; Wed, 15 Jan 2003 10:13:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FFSTc17311 for ssm-archive@odin.ietf.org; Wed, 15 Jan 2003 10:28:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FFSTJ17308 for ; Wed, 15 Jan 2003 10:28:29 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29382 for ; Wed, 15 Jan 2003 10:13:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FFOSJ17017; Wed, 15 Jan 2003 10:24:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FFHsJ16735 for ; Wed, 15 Jan 2003 10:17:54 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29193 for ; Wed, 15 Jan 2003 10:02:37 -0500 (EST) Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h0FF5x0E023007; Wed, 15 Jan 2003 07:05:59 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id HAA25436; Wed, 15 Jan 2003 07:05:59 -0800 (PST) Date: Wed, 15 Jan 2003 07:05:59 -0800 From: Toerless Eckert To: Hitoshi Asaeda Cc: Rolland.Vida@lip6.fr, holbrook@cisco.com, ssm@ietf.org Subject: Re: [ssm] Re: last call comments on ssm-arch doc Message-ID: <20030115150558.GD2103@cypher.cisco.com> References: <20030115.122655.70199744.Hitoshi.Asaeda@sophia.inria.fr> <20030115.151109.102792220.Hitoshi.Asaeda@sophia.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030115.151109.102792220.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: , One note on the discussed application requirement: If you're building a pure ad-hoc multi-peer application then what was said in before on this thread is correct. One could argue though that in face of overwhelmingly web based or bound applications client/server models for application architectures have become more ubiquitous because they provide easier architectural solution to some typical problems, and if such a client/server architecture is used, then the use of IPmulticast or SSM specifically can easily be designed to be really "single source". Eg: If you're building the white board application as pure peer to peer, each peer has to become a SSM channel source. If you implement the application as a client/server system, the clients could unicast to the server, and the server would have one SSM channel to all clients. Advantages: Easier model for access control, session management and ressource allocation then in a full peer to peer model. Given that today most networked applications are somehow started via the web, makes it quite easy to imagine the typical solution to be one involving some web server applet or the like. So, architecturally, i think one can make three classes of SSM peer-to-peer applications: a) client/server control and data: clients send unicast to server, server multicasts on one or multiple SSM channels back to clients. b) client/server control, peer-to-peer data: clients have control connection with server to learn about peers multicasting. Data itself is multicasted on SSM channels from each client to other interested clients. c) peer-to-peer control and data: There is no central server. Instead new peers have to somehow discover at least one existing peer, who can then signal to all other peers the existance of this new peer. This peer-to-peer control connections can be unicast with some topology between peers or can be SSM. From the applications i know, it seems to me that c) is today only predominant in application that have lots of good reasons to avoid servers. The typical examples of course are those in which the server(s) would be in danger of being sued or bombed away anyhow (eg: typical file-sharing software or military applications). For typical commercial applications you almost always resort to a) or b), and then b) typically has a lot of advantages on access control, synchronization, etc., and a) is mostly used in cases where the added efficiency of avoiding passind data through a server becomes important. So from that perspective i think that SSM quite well, if not better fits the typical application retuirements than compared to ASM. Cheers Toerless _______________________________________________ Ssm mailing list Ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-admin@ietf.org Wed Jan 15 10:43:24 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 KAA00487 for ; Wed, 15 Jan 2003 10:43:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FFvkJ19661; Wed, 15 Jan 2003 10:57:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FFo5J19266 for ; Wed, 15 Jan 2003 10:50:05 -0500 Received: from isis.lip6.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00167 for ; Wed, 15 Jan 2003 10:34:48 -0500 (EST) Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2]) by isis.lip6.fr (8.12.4/jtpda-5.4+victor) with ESMTP id h0FFc1mT009626 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) ; Wed, 15 Jan 2003 16:38:01 +0100 X-pt: isis.lip6.fr Received: from otos (otos [132.227.61.47]) by tibre.lip6.fr (8.11.6/8.11.3) with SMTP id h0FFc1318894; Wed, 15 Jan 2003 16:38:01 +0100 (MET) From: "Rolland Vida" To: "Toerless Eckert" Cc: Subject: RE: [ssm] Re: last call comments on ssm-arch doc Date: Wed, 15 Jan 2003 16:38:01 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <20030115150558.GD2103@cypher.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Scanned-By: isis.lip6.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 Toerless, > If you're building the white board application as pure peer to peer, > each peer has to become a SSM channel source. If you implement the > application as a client/server system, the clients could unicast to > the server, and the server would have one SSM channel to all clients. > Advantages: Easier model for access control, session management > and ressource allocation then in a full peer to peer model. This is a nice trick to provide a multi-source service through SSM. However, there are also some drawbacks: no source filtering, no shortest path delivery. It is basicly like standard PIM-SM: everybody sends to the RP (server), which forwards then on the shared tree (here the SSM channel). And as in PIM-SM already the shared tree is switched for a source-specific tree (to optimize delivery), why should it be now acceptable to use such a shared tree just to enable multi-source SSM? > b) client/server control, peer-to-peer data: > clients have control connection with server to learn > about peers multicasting. Data itself is multicasted > on SSM channels from each client to other interested > clients. > > c) peer-to-peer control and data: > There is no central server. Instead new peers have to > somehow discover at least one existing peer, who can then > signal to all other peers the existance of this new peer. > This peer-to-peer control connections can be unicast > with some topology between peers or can be SSM. The difference between b) and c) seems to be only the way how the receivers learn the address of the SSM source. But, as far as I know, it was always said that this is out of scope of the SSM specs. Hugh said in its last sentence: "SSM does not support network-layer multicast resource discovery". In my understanding, this is related exactly to our discussion. Regards, Rolland _______________________________________________ Ssm mailing list Ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Wed Jan 15 10:47:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00602 for ; Wed, 15 Jan 2003 10:47:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FG1nY20044 for ssm-archive@odin.ietf.org; Wed, 15 Jan 2003 11:01:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FG1nJ20041 for ; Wed, 15 Jan 2003 11:01:49 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00582 for ; Wed, 15 Jan 2003 10:46:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FFvkJ19661; Wed, 15 Jan 2003 10:57:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FFo5J19266 for ; Wed, 15 Jan 2003 10:50:05 -0500 Received: from isis.lip6.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00167 for ; Wed, 15 Jan 2003 10:34:48 -0500 (EST) Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2]) by isis.lip6.fr (8.12.4/jtpda-5.4+victor) with ESMTP id h0FFc1mT009626 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) ; Wed, 15 Jan 2003 16:38:01 +0100 X-pt: isis.lip6.fr Received: from otos (otos [132.227.61.47]) by tibre.lip6.fr (8.11.6/8.11.3) with SMTP id h0FFc1318894; Wed, 15 Jan 2003 16:38:01 +0100 (MET) From: "Rolland Vida" To: "Toerless Eckert" Cc: Subject: RE: [ssm] Re: last call comments on ssm-arch doc Date: Wed, 15 Jan 2003 16:38:01 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <20030115150558.GD2103@cypher.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Scanned-By: isis.lip6.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 Toerless, > If you're building the white board application as pure peer to peer, > each peer has to become a SSM channel source. If you implement the > application as a client/server system, the clients could unicast to > the server, and the server would have one SSM channel to all clients. > Advantages: Easier model for access control, session management > and ressource allocation then in a full peer to peer model. This is a nice trick to provide a multi-source service through SSM. However, there are also some drawbacks: no source filtering, no shortest path delivery. It is basicly like standard PIM-SM: everybody sends to the RP (server), which forwards then on the shared tree (here the SSM channel). And as in PIM-SM already the shared tree is switched for a source-specific tree (to optimize delivery), why should it be now acceptable to use such a shared tree just to enable multi-source SSM? > b) client/server control, peer-to-peer data: > clients have control connection with server to learn > about peers multicasting. Data itself is multicasted > on SSM channels from each client to other interested > clients. > > c) peer-to-peer control and data: > There is no central server. Instead new peers have to > somehow discover at least one existing peer, who can then > signal to all other peers the existance of this new peer. > This peer-to-peer control connections can be unicast > with some topology between peers or can be SSM. The difference between b) and c) seems to be only the way how the receivers learn the address of the SSM source. But, as far as I know, it was always said that this is out of scope of the SSM specs. Hugh said in its last sentence: "SSM does not support network-layer multicast resource discovery". In my understanding, this is related exactly to our discussion. Regards, Rolland _______________________________________________ Ssm mailing list Ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-admin@ietf.org Wed Jan 15 10:54:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00787 for ; Wed, 15 Jan 2003 10:54:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FG9AJ20972; Wed, 15 Jan 2003 11:09:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FG2WJ20078 for ; Wed, 15 Jan 2003 11:02:32 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00619 for ; Wed, 15 Jan 2003 10:47:19 -0500 (EST) Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h0FFof0E022051; Wed, 15 Jan 2003 07:50:41 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id HAA02537; Wed, 15 Jan 2003 07:50:41 -0800 (PST) Date: Wed, 15 Jan 2003 07:50:41 -0800 From: Toerless Eckert To: Rolland Vida Cc: Toerless Eckert , ssm@ietf.org Subject: Re: [ssm] Re: last call comments on ssm-arch doc Message-ID: <20030115155041.GF2103@cypher.cisco.com> References: <20030115150558.GD2103@cypher.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Wed, Jan 15, 2003 at 04:38:01PM +0100, Rolland Vida wrote: > Toerless, > > > If you're building the white board application as pure peer to peer, > > each peer has to become a SSM channel source. If you implement the > > application as a client/server system, the clients could unicast to > > the server, and the server would have one SSM channel to all clients. > > Advantages: Easier model for access control, session management > > and ressource allocation then in a full peer to peer model. > > This is a nice trick to provide a multi-source service through SSM. However, > there are also some drawbacks: no source filtering, no shortest path > delivery. It is basicly like standard PIM-SM: everybody sends to the RP > (server), which forwards then on the shared tree (here the SSM channel). And > as in PIM-SM already the shared tree is switched for a source-specific tree > (to optimize delivery), why should it be now acceptable to use such a shared > tree just to enable multi-source SSM? Because in SSM the reflection is done at application level, so the reflecting server can do a lot of useful stuff like source filtering (access control), (re-)encoding/fec, (re-)encryption, filtering, synchronization, buffering, shaping, adding coffee. And security of the applications data flow is now completely under the control of the application. Reflection at the PIM-SM RP is not under application control, and source filtering on the RP doesn't really work except for well controlled and architected intradomain applications. Also, it's static only. Besides, there are so many shortcut possiblities in PIM-SM that it's almost not possible to really guarantee in all situations that traffic has to go through the RP for means of filtering. > > b) client/server control, peer-to-peer data: > > clients have control connection with server to learn > > about peers multicasting. Data itself is multicasted > > on SSM channels from each client to other interested > > clients. > > > > c) peer-to-peer control and data: > > There is no central server. Instead new peers have to > > somehow discover at least one existing peer, who can then > > signal to all other peers the existance of this new peer. > > This peer-to-peer control connections can be unicast > > with some topology between peers or can be SSM. > > The difference between b) and c) seems to be only the way how the receivers > learn the address of the SSM source. But, as far as I know, it was always > said that this is out of scope of the SSM specs. Hugh said in its last > sentence: "SSM does not support network-layer multicast resource discovery". > In my understanding, this is related exactly to our discussion. I was talking about the application architecture on layers above SSM, and the difference between b) and c) is mostly complexity: b) is simple and well understood. c) is highly complex, like a self learning topology. You can try to approach c) very simple, but that means full mesh and that means wasted ressources. Cheers Toerless _______________________________________________ Ssm mailing list Ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Wed Jan 15 10:58:29 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 KAA00973 for ; Wed, 15 Jan 2003 10:58:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FGD9F21283 for ssm-archive@odin.ietf.org; Wed, 15 Jan 2003 11:13:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGD9J21280 for ; Wed, 15 Jan 2003 11:13:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00959 for ; Wed, 15 Jan 2003 10:57:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FG9AJ20972; Wed, 15 Jan 2003 11:09:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FG2WJ20078 for ; Wed, 15 Jan 2003 11:02:32 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00619 for ; Wed, 15 Jan 2003 10:47:19 -0500 (EST) Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h0FFof0E022051; Wed, 15 Jan 2003 07:50:41 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id HAA02537; Wed, 15 Jan 2003 07:50:41 -0800 (PST) Date: Wed, 15 Jan 2003 07:50:41 -0800 From: Toerless Eckert To: Rolland Vida Cc: Toerless Eckert , ssm@ietf.org Subject: Re: [ssm] Re: last call comments on ssm-arch doc Message-ID: <20030115155041.GF2103@cypher.cisco.com> References: <20030115150558.GD2103@cypher.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Wed, Jan 15, 2003 at 04:38:01PM +0100, Rolland Vida wrote: > Toerless, > > > If you're building the white board application as pure peer to peer, > > each peer has to become a SSM channel source. If you implement the > > application as a client/server system, the clients could unicast to > > the server, and the server would have one SSM channel to all clients. > > Advantages: Easier model for access control, session management > > and ressource allocation then in a full peer to peer model. > > This is a nice trick to provide a multi-source service through SSM. However, > there are also some drawbacks: no source filtering, no shortest path > delivery. It is basicly like standard PIM-SM: everybody sends to the RP > (server), which forwards then on the shared tree (here the SSM channel). And > as in PIM-SM already the shared tree is switched for a source-specific tree > (to optimize delivery), why should it be now acceptable to use such a shared > tree just to enable multi-source SSM? Because in SSM the reflection is done at application level, so the reflecting server can do a lot of useful stuff like source filtering (access control), (re-)encoding/fec, (re-)encryption, filtering, synchronization, buffering, shaping, adding coffee. And security of the applications data flow is now completely under the control of the application. Reflection at the PIM-SM RP is not under application control, and source filtering on the RP doesn't really work except for well controlled and architected intradomain applications. Also, it's static only. Besides, there are so many shortcut possiblities in PIM-SM that it's almost not possible to really guarantee in all situations that traffic has to go through the RP for means of filtering. > > b) client/server control, peer-to-peer data: > > clients have control connection with server to learn > > about peers multicasting. Data itself is multicasted > > on SSM channels from each client to other interested > > clients. > > > > c) peer-to-peer control and data: > > There is no central server. Instead new peers have to > > somehow discover at least one existing peer, who can then > > signal to all other peers the existance of this new peer. > > This peer-to-peer control connections can be unicast > > with some topology between peers or can be SSM. > > The difference between b) and c) seems to be only the way how the receivers > learn the address of the SSM source. But, as far as I know, it was always > said that this is out of scope of the SSM specs. Hugh said in its last > sentence: "SSM does not support network-layer multicast resource discovery". > In my understanding, this is related exactly to our discussion. I was talking about the application architecture on layers above SSM, and the difference between b) and c) is mostly complexity: b) is simple and well understood. c) is highly complex, like a self learning topology. You can try to approach c) very simple, but that means full mesh and that means wasted ressources. Cheers Toerless _______________________________________________ Ssm mailing list Ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-admin@ietf.org Wed Jan 15 11:03:04 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 LAA01093 for ; Wed, 15 Jan 2003 11:03:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGHMJ21482; Wed, 15 Jan 2003 11:17:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FG9AJ20974 for ; Wed, 15 Jan 2003 11:09:10 -0500 Received: from hunkular.glarp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00758 for ; Wed, 15 Jan 2003 10:53:58 -0500 (EST) Received: from hunkular.glarp.com (localhost [127.0.0.1]) by hunkular.glarp.com (8.12.6/8.12.6) with ESMTP id h0FFv5Lq041831; Wed, 15 Jan 2003 08:57:05 -0700 (MST) (envelope-from huntting@hunkular.glarp.com) Message-Id: <200301151557.h0FFv5Lq041831@hunkular.glarp.com> To: holbrook@cisco.com cc: ssm@ietf.org, mbaugher@cisco.com, bew@cisco.com Subject: Re: [ssm] SSM with IPSec In-Reply-To: Your message of "Wed, 15 Jan 2003 01:25:34 EST." <20030115062534.076C910B869@holbrook-laptop.cisco.com> Date: Wed, 15 Jan 2003 08:57:05 -0700 From: Brad Huntting 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 solution that I most like is fairly easy to state: require the > source address to be part of the SA lookup when the destination > address is an SSM address. Mark and Brian inform me that the msec > working group is looking at solving the problem this way. What if the destination address is not in the SSM range? For example: A host wishes to receive NTP (network time protocol) multicast traffic (destination address 224.0.1.1) from three specific hosts that it trusts (whether PIM-SSM can honor this request efficiently is, I think, a separate issue). I assume there is no global group `owner' for this well known address 224.0.1.1, so the SA for this traffic would, I suspect, need to be indexed by source and destination just like SSM. One could easily imagine similar situations for other group addresses. However, as you pointed out, it's probably not necessary that the SSM group solve this problem; at least not right away. brad _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Wed Jan 15 11:06:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01245 for ; Wed, 15 Jan 2003 11:06:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FGLRe21729 for ssm-archive@odin.ietf.org; Wed, 15 Jan 2003 11:21:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGLRJ21726 for ; Wed, 15 Jan 2003 11:21:27 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01228 for ; Wed, 15 Jan 2003 11:06:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGHMJ21482; Wed, 15 Jan 2003 11:17:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FG9AJ20974 for ; Wed, 15 Jan 2003 11:09:10 -0500 Received: from hunkular.glarp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00758 for ; Wed, 15 Jan 2003 10:53:58 -0500 (EST) Received: from hunkular.glarp.com (localhost [127.0.0.1]) by hunkular.glarp.com (8.12.6/8.12.6) with ESMTP id h0FFv5Lq041831; Wed, 15 Jan 2003 08:57:05 -0700 (MST) (envelope-from huntting@hunkular.glarp.com) Message-Id: <200301151557.h0FFv5Lq041831@hunkular.glarp.com> To: holbrook@cisco.com cc: ssm@ietf.org, mbaugher@cisco.com, bew@cisco.com Subject: Re: [ssm] SSM with IPSec In-Reply-To: Your message of "Wed, 15 Jan 2003 01:25:34 EST." <20030115062534.076C910B869@holbrook-laptop.cisco.com> Date: Wed, 15 Jan 2003 08:57:05 -0700 From: Brad Huntting 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 solution that I most like is fairly easy to state: require the > source address to be part of the SA lookup when the destination > address is an SSM address. Mark and Brian inform me that the msec > working group is looking at solving the problem this way. What if the destination address is not in the SSM range? For example: A host wishes to receive NTP (network time protocol) multicast traffic (destination address 224.0.1.1) from three specific hosts that it trusts (whether PIM-SSM can honor this request efficiently is, I think, a separate issue). I assume there is no global group `owner' for this well known address 224.0.1.1, so the SA for this traffic would, I suspect, need to be indexed by source and destination just like SSM. One could easily imagine similar situations for other group addresses. However, as you pointed out, it's probably not necessary that the SSM group solve this problem; at least not right away. brad _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-admin@ietf.org Wed Jan 15 11:13:56 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 LAA01546 for ; Wed, 15 Jan 2003 11:13:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGSIJ22115; Wed, 15 Jan 2003 11:28:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGLgJ21810 for ; Wed, 15 Jan 2003 11:21:42 -0500 Received: from isis.lip6.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01238 for ; Wed, 15 Jan 2003 11:06:30 -0500 (EST) Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2]) by isis.lip6.fr (8.12.4/jtpda-5.4+victor) with ESMTP id h0FG8kmT012506 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) ; Wed, 15 Jan 2003 17:08:46 +0100 X-pt: isis.lip6.fr Received: from otos (otos [132.227.61.47]) by tibre.lip6.fr (8.11.6/8.11.3) with SMTP id h0FG8k320015; Wed, 15 Jan 2003 17:08:46 +0100 (MET) From: "Rolland Vida" To: "Toerless Eckert" Cc: Subject: RE: [ssm] Re: last call comments on ssm-arch doc Date: Wed, 15 Jan 2003 17:08:46 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <20030115155041.GF2103@cypher.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Scanned-By: isis.lip6.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 > Because in SSM the reflection is done at application level, so the > reflecting server can do a lot of useful stuff like source filtering > (access control), (re-)encoding/fec, (re-)encryption, filtering, > synchronization, buffering, shaping, adding coffee. It depends on the application. For some, I agree that this model can be useful. for a small size videoconference for example, you could mix all the voice flows together at the server, and send out only one voice stream on the SSM channel (for the video it's more complicated...) But in any case, I see it as a way to use SSM for doing something that is quite different from what SSM was originaly meant for. One basic feature of SSM is source filtering. In your model the server can only filter out malicious sources for example. But if two different receivers want to listen to two different "legal" sources, and do not want to listen to nobody else, your server can never support that on the same SSM channel. Regards, Rolland _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Wed Jan 15 11:17: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 LAA01697 for ; Wed, 15 Jan 2003 11:17:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FGWKS22419 for ssm-archive@odin.ietf.org; Wed, 15 Jan 2003 11:32:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGWKJ22416 for ; Wed, 15 Jan 2003 11:32:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01671 for ; Wed, 15 Jan 2003 11:17:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGSIJ22115; Wed, 15 Jan 2003 11:28:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGLgJ21810 for ; Wed, 15 Jan 2003 11:21:42 -0500 Received: from isis.lip6.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01238 for ; Wed, 15 Jan 2003 11:06:30 -0500 (EST) Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2]) by isis.lip6.fr (8.12.4/jtpda-5.4+victor) with ESMTP id h0FG8kmT012506 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) ; Wed, 15 Jan 2003 17:08:46 +0100 X-pt: isis.lip6.fr Received: from otos (otos [132.227.61.47]) by tibre.lip6.fr (8.11.6/8.11.3) with SMTP id h0FG8k320015; Wed, 15 Jan 2003 17:08:46 +0100 (MET) From: "Rolland Vida" To: "Toerless Eckert" Cc: Subject: RE: [ssm] Re: last call comments on ssm-arch doc Date: Wed, 15 Jan 2003 17:08:46 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <20030115155041.GF2103@cypher.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Scanned-By: isis.lip6.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 > Because in SSM the reflection is done at application level, so the > reflecting server can do a lot of useful stuff like source filtering > (access control), (re-)encoding/fec, (re-)encryption, filtering, > synchronization, buffering, shaping, adding coffee. It depends on the application. For some, I agree that this model can be useful. for a small size videoconference for example, you could mix all the voice flows together at the server, and send out only one voice stream on the SSM channel (for the video it's more complicated...) But in any case, I see it as a way to use SSM for doing something that is quite different from what SSM was originaly meant for. One basic feature of SSM is source filtering. In your model the server can only filter out malicious sources for example. But if two different receivers want to listen to two different "legal" sources, and do not want to listen to nobody else, your server can never support that on the same SSM channel. Regards, Rolland _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-admin@ietf.org Wed Jan 15 11:58: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 LAA03204 for ; Wed, 15 Jan 2003 11:58:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FHCVJ26470; Wed, 15 Jan 2003 12:12:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FH2eJ25174 for ; Wed, 15 Jan 2003 12:02:40 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03040 for ; Wed, 15 Jan 2003 11:47:28 -0500 (EST) Received: from holbrook-laptop.cisco.com (sjc-vpn1-676.cisco.com [10.21.98.164]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id h0FGo6jS007231; Wed, 15 Jan 2003 08:50:06 -0800 (PST) Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id 6B2EF10B7A7; Wed, 15 Jan 2003 11:48:22 -0500 (EST) From: Hugh Holbrook To: Brad Huntting Cc: holbrook@cisco.com, ssm@ietf.org, mbaugher@cisco.com, bew@cisco.com In-reply-to: <200301151557.h0FFv5Lq041831@hunkular.glarp.com> Subject: Re: Re: [ssm] SSM with IPSec Reply-To: holbrook@cisco.com Message-Id: <20030115164822.6B2EF10B7A7@holbrook-laptop.cisco.com> Date: Wed, 15 Jan 2003 11:48:22 -0500 (EST) Sender: ssm-admin@ietf.org Errors-To: ssm-admin@ietf.org X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , I agree with you, and I didn't mean to imply that this was an SSM-only problem. NTP is a good example of an ASM app that has the same problem. The fact that this problem occurs with ASM is a complicating factor in determining the right solution (which is a major reason that I don't want to tackle it in SSM). I think it would be relatively easy to specify IPSec modifications to fix the SSM problem. But to solve the ASM problem you have to do source-based SAD lookups in some cases for ASM addresses. There are some design choices to consider in how to specify the SAD lookups and some and backwards compatibility issues that need to be worked out to solve the ASM problem, or so I am told. Given that the tricky issues arise mostly from ASM and that msec has the ipsec expertise and the charter, I think it makes sense to solve this in msec rather than in ssm. Sounds like you agree with that anyway.. I'll find out where msec is at in terms of solving this problem and report back. -Hugh > Cc: ssm@ietf.org, mbaugher@cisco.com, bew@cisco.com > Date: Wed, 15 Jan 2003 08:57:05 -0700 > From: Brad Huntting > > > > The solution that I most like is fairly easy to state: require the > > source address to be part of the SA lookup when the destination > > address is an SSM address. Mark and Brian inform me that the msec > > working group is looking at solving the problem this way. > > What if the destination address is not in the SSM range? For > example: A host wishes to receive NTP (network time protocol) > multicast traffic (destination address 224.0.1.1) from three specific > hosts that it trusts (whether PIM-SSM can honor this request > efficiently is, I think, a separate issue). I assume there is no > global group `owner' for this well known address 224.0.1.1, so the > SA for this traffic would, I suspect, need to be indexed by source > and destination just like SSM. > > One could easily imagine similar situations for other group addresses. > However, as you pointed out, it's probably not necessary that the > SSM group solve this problem; at least not right away. > > > brad > _______________________________________________ > ssm mailing list > ssm@ietf.org > https://www1.ietf.org/mailman/listinfo/ssm _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Wed Jan 15 12:02:04 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 MAA03292 for ; Wed, 15 Jan 2003 12:02:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FHGkC26626 for ssm-archive@odin.ietf.org; Wed, 15 Jan 2003 12:16:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FHGjJ26623 for ; Wed, 15 Jan 2003 12:16:45 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03281 for ; Wed, 15 Jan 2003 12:01:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FHCVJ26470; Wed, 15 Jan 2003 12:12:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FH2eJ25174 for ; Wed, 15 Jan 2003 12:02:40 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03040 for ; Wed, 15 Jan 2003 11:47:28 -0500 (EST) Received: from holbrook-laptop.cisco.com (sjc-vpn1-676.cisco.com [10.21.98.164]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id h0FGo6jS007231; Wed, 15 Jan 2003 08:50:06 -0800 (PST) Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id 6B2EF10B7A7; Wed, 15 Jan 2003 11:48:22 -0500 (EST) From: Hugh Holbrook To: Brad Huntting Cc: holbrook@cisco.com, ssm@ietf.org, mbaugher@cisco.com, bew@cisco.com In-reply-to: <200301151557.h0FFv5Lq041831@hunkular.glarp.com> Subject: Re: Re: [ssm] SSM with IPSec Reply-To: holbrook@cisco.com Message-Id: <20030115164822.6B2EF10B7A7@holbrook-laptop.cisco.com> Date: Wed, 15 Jan 2003 11:48:22 -0500 (EST) Sender: ssm-admin@ietf.org Errors-To: ssm-admin@ietf.org X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , I agree with you, and I didn't mean to imply that this was an SSM-only problem. NTP is a good example of an ASM app that has the same problem. The fact that this problem occurs with ASM is a complicating factor in determining the right solution (which is a major reason that I don't want to tackle it in SSM). I think it would be relatively easy to specify IPSec modifications to fix the SSM problem. But to solve the ASM problem you have to do source-based SAD lookups in some cases for ASM addresses. There are some design choices to consider in how to specify the SAD lookups and some and backwards compatibility issues that need to be worked out to solve the ASM problem, or so I am told. Given that the tricky issues arise mostly from ASM and that msec has the ipsec expertise and the charter, I think it makes sense to solve this in msec rather than in ssm. Sounds like you agree with that anyway.. I'll find out where msec is at in terms of solving this problem and report back. -Hugh > Cc: ssm@ietf.org, mbaugher@cisco.com, bew@cisco.com > Date: Wed, 15 Jan 2003 08:57:05 -0700 > From: Brad Huntting > > > > The solution that I most like is fairly easy to state: require the > > source address to be part of the SA lookup when the destination > > address is an SSM address. Mark and Brian inform me that the msec > > working group is looking at solving the problem this way. > > What if the destination address is not in the SSM range? For > example: A host wishes to receive NTP (network time protocol) > multicast traffic (destination address 224.0.1.1) from three specific > hosts that it trusts (whether PIM-SSM can honor this request > efficiently is, I think, a separate issue). I assume there is no > global group `owner' for this well known address 224.0.1.1, so the > SA for this traffic would, I suspect, need to be indexed by source > and destination just like SSM. > > One could easily imagine similar situations for other group addresses. > However, as you pointed out, it's probably not necessary that the > SSM group solve this problem; at least not right away. > > > brad > _______________________________________________ > 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 ssm-admin@ietf.org Wed Jan 15 12:04: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 MAA03331 for ; Wed, 15 Jan 2003 12:04:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FHIWJ26693; Wed, 15 Jan 2003 12:18:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGjTJ24030 for ; Wed, 15 Jan 2003 11:45:29 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02368 for ; Wed, 15 Jan 2003 11:30:17 -0500 (EST) Received: from cscoamera13263.cisco.com ([10.21.83.87]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id h0FGX0jT014708; Wed, 15 Jan 2003 08:33:00 -0800 (PST) Message-Id: <5.1.1.5.2.20030115083207.05fa7210@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 15 Jan 2003 08:33:35 -0800 To: Brian Haberman From: Mark Baugher Subject: Re: [ssm] SSM with IPSec Cc: holbrook@cisco.com, ssm@ietf.org, Brian Weis In-Reply-To: <3E255C25.2050408@nc.rr.com> References: <20030115062534.076C910B869@holbrook-laptop.cisco.com> <20030115062534.076C910B869@holbrook-laptop.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , At 08:03 AM 1/15/2003 -0500, Brian Haberman wrote: >Hugh, > I had a similar discussion with Thomas Hardjono on the >subject. I feel comfortable with adding text the the arch >doc and allowing MSEC to work through the details. I would >suggest that some of us volunteer to assist the MSEC guys >with the details of SSM if needed. I am willing to help them >out if the need arises. I mentioned this to Thomas, Brian and Ran. We would like to review our proposal with a small group who are knowledgeable about SSM and current IP multicast requirements. Mark >Brian > >Hugh Holbrook wrote: >>Hello, SSM working group. >>[ Welcome to the brand spanking new ssm@ietf.org mailing list. Please >> tell me if you notice any problems with the list. You should have >> received a mail from the mailman program running the list. The SSM >> page at ietf.org still lists the [un]subscription info for the old >> list, but it will be updated shortly. ] >>Last week, I was talking to some security folks here (Brian Weis and >>Mark Baugher) who pointed out that IPSec as specified in RFC2401 has >>some issues when securing SSM traffic. In short, the problem is that >>including the source in the SA lookup isn't really accounted for in >>IPSec, but it really should be. Details below. >>I don't think this is a really urgent problem, but I think the WG >>should be aware of the problem, so I'll spell it out. Comments >>solicited. >>Some IPSec background: >>[Apologies for the tutorial, but I know that not everyone in the wg is >> fluent in IPSec details.] >>IPSec, in RFC2401, specifies that an incoming IPSec packet is looked >>up on arrival in a local Security Association Database (SAD) to decide >>which Security Association (SA) should be applied to the packet [see >>section 4.4.3 of RFC2401.] The resulting SA determines the >>decryption/authentication key, and the anti-replay window (if one is >>used). >>RFC2401 specifies that the key for the SAD lookup is a 3-tuple of: >> - the packet's destination IP address >> - the IPSec protocol (ESP or AH) >> - the Security Parameters Index (SPI) >>The problem (for SSM) is that the source address is *not* included in >>the SAD lookup. >>The problem: >>You would to be sure that two unrelated SSM channels, if secured by >>IPSec, can be guaranteed to have unique Security Associations at all >>receivers. This should be true even if the senders accidentally >>happen to choose the same SSM destination address. There is, however, >>no entity that "owns" an SSM destination address and can reasonably >>ensure that every sender to an SSM address uses a unique SPI >>One could envision a similar problem for ASM, but I believe in the ASM >>case, the assumption of the IPSec design is that there exists a "group >>controller" that logically "owns" the group and can hand out a unique >>SPI to each source that needs one. But this doesn't apply to SSM. >>The mere existence of such an entity for an SSM address would defeat >>one of SSM's big benefits -- that external coordination with other >>senders is not needed before choosing and using an SSM address. >>In practice, I don't think this problem is very severe. It only >>arises if a receiver subscribes simultaneously to two unrelated >>IPSec'ed channels whose sources happen to have chosen the same IPDA >>and the same IPSec SPI. Given that the tuple contains 56 >>bits of generally randomly-picked data, it is very unlikely to occur >>in practice. However, I don't think the architecture should rely on >>coincidence to work properly. >>What to do: >>The solution that I most like is fairly easy to state: require the >>source address to be part of the SA lookup when the destination >>address is an SSM address. Mark and Brian inform me that the msec >>working group is looking at solving the problem this way. >>The required action from the SSM working group is, I think, to simply >>point out the problem in the -arch draft, more or less as I've done >>above, and note that work is currently underway to address the >>problem. I don't believe we need to or want to hold up the SSM draft >>until msec (or ipsec) solves the problem, but I'd like to hear WG >>comments on this topic. >>I'll probably be sending out some proposed modifications to the >>architecture draft shortly. >>Thanks to Mark and Brian for pointing out this problem. _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Wed Jan 15 12:07:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03485 for ; Wed, 15 Jan 2003 12:07:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FHMYg26951 for ssm-archive@odin.ietf.org; Wed, 15 Jan 2003 12:22:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FHMYJ26948 for ; Wed, 15 Jan 2003 12:22:34 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03435 for ; Wed, 15 Jan 2003 12:07:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FHIWJ26693; Wed, 15 Jan 2003 12:18:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGjTJ24030 for ; Wed, 15 Jan 2003 11:45:29 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02368 for ; Wed, 15 Jan 2003 11:30:17 -0500 (EST) Received: from cscoamera13263.cisco.com ([10.21.83.87]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id h0FGX0jT014708; Wed, 15 Jan 2003 08:33:00 -0800 (PST) Message-Id: <5.1.1.5.2.20030115083207.05fa7210@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 15 Jan 2003 08:33:35 -0800 To: Brian Haberman From: Mark Baugher Subject: Re: [ssm] SSM with IPSec Cc: holbrook@cisco.com, ssm@ietf.org, Brian Weis In-Reply-To: <3E255C25.2050408@nc.rr.com> References: <20030115062534.076C910B869@holbrook-laptop.cisco.com> <20030115062534.076C910B869@holbrook-laptop.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , At 08:03 AM 1/15/2003 -0500, Brian Haberman wrote: >Hugh, > I had a similar discussion with Thomas Hardjono on the >subject. I feel comfortable with adding text the the arch >doc and allowing MSEC to work through the details. I would >suggest that some of us volunteer to assist the MSEC guys >with the details of SSM if needed. I am willing to help them >out if the need arises. I mentioned this to Thomas, Brian and Ran. We would like to review our proposal with a small group who are knowledgeable about SSM and current IP multicast requirements. Mark >Brian > >Hugh Holbrook wrote: >>Hello, SSM working group. >>[ Welcome to the brand spanking new ssm@ietf.org mailing list. Please >> tell me if you notice any problems with the list. You should have >> received a mail from the mailman program running the list. The SSM >> page at ietf.org still lists the [un]subscription info for the old >> list, but it will be updated shortly. ] >>Last week, I was talking to some security folks here (Brian Weis and >>Mark Baugher) who pointed out that IPSec as specified in RFC2401 has >>some issues when securing SSM traffic. In short, the problem is that >>including the source in the SA lookup isn't really accounted for in >>IPSec, but it really should be. Details below. >>I don't think this is a really urgent problem, but I think the WG >>should be aware of the problem, so I'll spell it out. Comments >>solicited. >>Some IPSec background: >>[Apologies for the tutorial, but I know that not everyone in the wg is >> fluent in IPSec details.] >>IPSec, in RFC2401, specifies that an incoming IPSec packet is looked >>up on arrival in a local Security Association Database (SAD) to decide >>which Security Association (SA) should be applied to the packet [see >>section 4.4.3 of RFC2401.] The resulting SA determines the >>decryption/authentication key, and the anti-replay window (if one is >>used). >>RFC2401 specifies that the key for the SAD lookup is a 3-tuple of: >> - the packet's destination IP address >> - the IPSec protocol (ESP or AH) >> - the Security Parameters Index (SPI) >>The problem (for SSM) is that the source address is *not* included in >>the SAD lookup. >>The problem: >>You would to be sure that two unrelated SSM channels, if secured by >>IPSec, can be guaranteed to have unique Security Associations at all >>receivers. This should be true even if the senders accidentally >>happen to choose the same SSM destination address. There is, however, >>no entity that "owns" an SSM destination address and can reasonably >>ensure that every sender to an SSM address uses a unique SPI >>One could envision a similar problem for ASM, but I believe in the ASM >>case, the assumption of the IPSec design is that there exists a "group >>controller" that logically "owns" the group and can hand out a unique >>SPI to each source that needs one. But this doesn't apply to SSM. >>The mere existence of such an entity for an SSM address would defeat >>one of SSM's big benefits -- that external coordination with other >>senders is not needed before choosing and using an SSM address. >>In practice, I don't think this problem is very severe. It only >>arises if a receiver subscribes simultaneously to two unrelated >>IPSec'ed channels whose sources happen to have chosen the same IPDA >>and the same IPSec SPI. Given that the tuple contains 56 >>bits of generally randomly-picked data, it is very unlikely to occur >>in practice. However, I don't think the architecture should rely on >>coincidence to work properly. >>What to do: >>The solution that I most like is fairly easy to state: require the >>source address to be part of the SA lookup when the destination >>address is an SSM address. Mark and Brian inform me that the msec >>working group is looking at solving the problem this way. >>The required action from the SSM working group is, I think, to simply >>point out the problem in the -arch draft, more or less as I've done >>above, and note that work is currently underway to address the >>problem. I don't believe we need to or want to hold up the SSM draft >>until msec (or ipsec) solves the problem, but I'd like to hear WG >>comments on this topic. >>I'll probably be sending out some proposed modifications to the >>architecture draft shortly. >>Thanks to Mark and Brian for pointing out this problem. _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-admin@ietf.org Wed Jan 15 12:11: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 MAA03686 for ; Wed, 15 Jan 2003 12:11:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FHQGJ27125; Wed, 15 Jan 2003 12:26:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FHCoJ26499 for ; Wed, 15 Jan 2003 12:12:50 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03175 for ; Wed, 15 Jan 2003 11:57:37 -0500 (EST) Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h0FH0v0E017137; Wed, 15 Jan 2003 09:00:57 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id JAA18658; Wed, 15 Jan 2003 09:00:56 -0800 (PST) Date: Wed, 15 Jan 2003 09:00:56 -0800 From: Toerless Eckert To: Rolland Vida Cc: Toerless Eckert , ssm@ietf.org Subject: Re: [ssm] Re: last call comments on ssm-arch doc Message-ID: <20030115170056.GJ2103@cypher.cisco.com> References: <20030115155041.GF2103@cypher.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Wed, Jan 15, 2003 at 05:08:46PM +0100, Rolland Vida wrote: > > Because in SSM the reflection is done at application level, so the > > reflecting server can do a lot of useful stuff like source filtering > > (access control), (re-)encoding/fec, (re-)encryption, filtering, > > synchronization, buffering, shaping, adding coffee. > > It depends on the application. For some, I agree that this model can be > useful. for a small size videoconference for example, you could mix all the > voice flows together at the server, and send out only one voice stream on > the SSM channel (for the video it's more complicated...) > > But in any case, I see it as a way to use SSM for doing something that is > quite different from what SSM was originaly meant for. I think that that opinion requires a narrow minded expectation on what SSM was meant for ;-)) > One basic feature of > SSM is source filtering. In your model the server can only filter out > malicious sources for example. But if two different receivers want to listen > to two different "legal" sources, and do not want to listen to nobody else, > your server can never support that on the same SSM channel. Not true. If you ONLY want to have a server for reasons of securities et. al., then you can still have this server reflect each sources traffic on an individual channel. You don't save SSM channels, but this can help you hide the IP addresses of the sources for example for scurity reasons. Cheers Toerless _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Wed Jan 15 12:15:29 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 MAA03848 for ; Wed, 15 Jan 2003 12:15:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FHUAF27438 for ssm-archive@odin.ietf.org; Wed, 15 Jan 2003 12:30:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FHUAJ27435 for ; Wed, 15 Jan 2003 12:30:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03835 for ; Wed, 15 Jan 2003 12:14:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FHQGJ27125; Wed, 15 Jan 2003 12:26:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FHCoJ26499 for ; Wed, 15 Jan 2003 12:12:50 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03175 for ; Wed, 15 Jan 2003 11:57:37 -0500 (EST) Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h0FH0v0E017137; Wed, 15 Jan 2003 09:00:57 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id JAA18658; Wed, 15 Jan 2003 09:00:56 -0800 (PST) Date: Wed, 15 Jan 2003 09:00:56 -0800 From: Toerless Eckert To: Rolland Vida Cc: Toerless Eckert , ssm@ietf.org Subject: Re: [ssm] Re: last call comments on ssm-arch doc Message-ID: <20030115170056.GJ2103@cypher.cisco.com> References: <20030115155041.GF2103@cypher.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Wed, Jan 15, 2003 at 05:08:46PM +0100, Rolland Vida wrote: > > Because in SSM the reflection is done at application level, so the > > reflecting server can do a lot of useful stuff like source filtering > > (access control), (re-)encoding/fec, (re-)encryption, filtering, > > synchronization, buffering, shaping, adding coffee. > > It depends on the application. For some, I agree that this model can be > useful. for a small size videoconference for example, you could mix all the > voice flows together at the server, and send out only one voice stream on > the SSM channel (for the video it's more complicated...) > > But in any case, I see it as a way to use SSM for doing something that is > quite different from what SSM was originaly meant for. I think that that opinion requires a narrow minded expectation on what SSM was meant for ;-)) > One basic feature of > SSM is source filtering. In your model the server can only filter out > malicious sources for example. But if two different receivers want to listen > to two different "legal" sources, and do not want to listen to nobody else, > your server can never support that on the same SSM channel. Not true. If you ONLY want to have a server for reasons of securities et. al., then you can still have this server reflect each sources traffic on an individual channel. You don't save SSM channels, but this can help you hide the IP addresses of the sources for example for scurity reasons. Cheers Toerless _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-admin@ietf.org Wed Jan 15 12:19:35 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 MAA04029 for ; Wed, 15 Jan 2003 12:19:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FHY2J27637; Wed, 15 Jan 2003 12:34:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FHNbJ27016 for ; Wed, 15 Jan 2003 12:23:37 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03511 for ; Wed, 15 Jan 2003 12:08:24 -0500 (EST) Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id h0FHB2jS006270; Wed, 15 Jan 2003 09:11:02 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id JAA21423; Wed, 15 Jan 2003 09:11:37 -0800 (PST) Date: Wed, 15 Jan 2003 09:11:37 -0800 From: Toerless Eckert To: Hugh Holbrook Cc: Brad Huntting , ssm@ietf.org, mbaugher@cisco.com, bew@cisco.com Subject: Re: Re: [ssm] SSM with IPSec Message-ID: <20030115171137.GK2103@cypher.cisco.com> References: <200301151557.h0FFv5Lq041831@hunkular.glarp.com> <20030115164822.6B2EF10B7A7@holbrook-laptop.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030115164822.6B2EF10B7A7@holbrook-laptop.cisco.com> 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 Wed, Jan 15, 2003 at 11:48:22AM -0500, Hugh Holbrook wrote: > > I agree with you, and I didn't mean to imply that this was an SSM-only > problem. NTP is a good example of an ASM app that has the same > problem. The fact that this problem occurs with ASM is a complicating > factor in determining the right solution (which is a major reason that > I don't want to tackle it in SSM). I don't yet understand the details of the key management yet, but correct me if i'm wrong: Wouldn't a solution with channel-only support (eg: SSM only) be able to be much easier than one that needs to support a multi-source group concept ? Given that simplicity is one key argument for SSM, it would be good if the security solution in support of SSM was not necessarily encumbered by additional complexity only required for ASM. Eg: probably have two approaches, one that will only work with SSM and one which will work for ASM but of course also SSM. Wrong line of thought ? _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Wed Jan 15 12:23: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 MAA04131 for ; Wed, 15 Jan 2003 12:23:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FHc3m28529 for ssm-archive@odin.ietf.org; Wed, 15 Jan 2003 12:38:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FHc3J28526 for ; Wed, 15 Jan 2003 12:38:03 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04115 for ; Wed, 15 Jan 2003 12:22:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FHY2J27637; Wed, 15 Jan 2003 12:34:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FHNbJ27016 for ; Wed, 15 Jan 2003 12:23:37 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03511 for ; Wed, 15 Jan 2003 12:08:24 -0500 (EST) Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id h0FHB2jS006270; Wed, 15 Jan 2003 09:11:02 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id JAA21423; Wed, 15 Jan 2003 09:11:37 -0800 (PST) Date: Wed, 15 Jan 2003 09:11:37 -0800 From: Toerless Eckert To: Hugh Holbrook Cc: Brad Huntting , ssm@ietf.org, mbaugher@cisco.com, bew@cisco.com Subject: Re: Re: [ssm] SSM with IPSec Message-ID: <20030115171137.GK2103@cypher.cisco.com> References: <200301151557.h0FFv5Lq041831@hunkular.glarp.com> <20030115164822.6B2EF10B7A7@holbrook-laptop.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030115164822.6B2EF10B7A7@holbrook-laptop.cisco.com> 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 Wed, Jan 15, 2003 at 11:48:22AM -0500, Hugh Holbrook wrote: > > I agree with you, and I didn't mean to imply that this was an SSM-only > problem. NTP is a good example of an ASM app that has the same > problem. The fact that this problem occurs with ASM is a complicating > factor in determining the right solution (which is a major reason that > I don't want to tackle it in SSM). I don't yet understand the details of the key management yet, but correct me if i'm wrong: Wouldn't a solution with channel-only support (eg: SSM only) be able to be much easier than one that needs to support a multi-source group concept ? Given that simplicity is one key argument for SSM, it would be good if the security solution in support of SSM was not necessarily encumbered by additional complexity only required for ASM. Eg: probably have two approaches, one that will only work with SSM and one which will work for ASM but of course also SSM. Wrong line of thought ? _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-admin@ietf.org Wed Jan 15 12:49:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04925 for ; Wed, 15 Jan 2003 12:49:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FI4LJ29830; Wed, 15 Jan 2003 13:04:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FHvcJ29516 for ; Wed, 15 Jan 2003 12:57:38 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04722 for ; Wed, 15 Jan 2003 12:42:24 -0500 (EST) Received: from holbrook-laptop.cisco.com (sjc-vpn1-676.cisco.com [10.21.98.164]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0FHjbFp026386; Wed, 15 Jan 2003 09:45:37 -0800 (PST) Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id 9E3FD10B7A7; Wed, 15 Jan 2003 12:43:22 -0500 (EST) From: Hugh Holbrook To: Toerless Eckert Cc: Hugh Holbrook , Brad Huntting , ssm@ietf.org, mbaugher@cisco.com, bew@cisco.com In-reply-to: <20030115171137.GK2103@cypher.cisco.com> Subject: Re: Re: Re: [ssm] SSM with IPSec Reply-To: holbrook@cisco.com Message-Id: <20030115174322.9E3FD10B7A7@holbrook-laptop.cisco.com> Date: Wed, 15 Jan 2003 12:43:22 -0500 (EST) Sender: ssm-admin@ietf.org Errors-To: ssm-admin@ietf.org X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , I'm not sure. I think it will be somewhat easier but I suspect not "much easier" to do an SSM-only solution. But I don't know and I'm waiting to see the msec proposal. I do think it would be prudent to take your points under consideration when looking at the msec proposal, though. -Hugh > Date: Wed, 15 Jan 2003 09:11:37 -0800 > From: Toerless Eckert > Cc: Brad Huntting , ssm@ietf.org, > mbaugher@cisco.com, bew@cisco.com > > On Wed, Jan 15, 2003 at 11:48:22AM -0500, Hugh Holbrook wrote: > > > > I agree with you, and I didn't mean to imply that this was an SSM-only > > problem. NTP is a good example of an ASM app that has the same > > problem. The fact that this problem occurs with ASM is a complicating > > factor in determining the right solution (which is a major reason that > > I don't want to tackle it in SSM). > > I don't yet understand the details of the key management yet, but > correct me if i'm wrong: Wouldn't a solution with channel-only > support (eg: SSM only) be able to be much easier than one that > needs to support a multi-source group concept ? Given that simplicity > is one key argument for SSM, it would be good if the security solution > in support of SSM was not necessarily encumbered by additional > complexity only required for ASM. Eg: probably have two approaches, > one that will only work with SSM and one which will work for ASM > but of course also SSM. > > Wrong line of thought ? _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Wed Jan 15 12:53:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05059 for ; Wed, 15 Jan 2003 12:53:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FI8Jt30660 for ssm-archive@odin.ietf.org; Wed, 15 Jan 2003 13:08:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FI8JJ30657 for ; Wed, 15 Jan 2003 13:08:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05045 for ; Wed, 15 Jan 2003 12:53:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FI4LJ29830; Wed, 15 Jan 2003 13:04:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FHvcJ29516 for ; Wed, 15 Jan 2003 12:57:38 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04722 for ; Wed, 15 Jan 2003 12:42:24 -0500 (EST) Received: from holbrook-laptop.cisco.com (sjc-vpn1-676.cisco.com [10.21.98.164]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0FHjbFp026386; Wed, 15 Jan 2003 09:45:37 -0800 (PST) Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id 9E3FD10B7A7; Wed, 15 Jan 2003 12:43:22 -0500 (EST) From: Hugh Holbrook To: Toerless Eckert Cc: Hugh Holbrook , Brad Huntting , ssm@ietf.org, mbaugher@cisco.com, bew@cisco.com In-reply-to: <20030115171137.GK2103@cypher.cisco.com> Subject: Re: Re: Re: [ssm] SSM with IPSec Reply-To: holbrook@cisco.com Message-Id: <20030115174322.9E3FD10B7A7@holbrook-laptop.cisco.com> Date: Wed, 15 Jan 2003 12:43:22 -0500 (EST) Sender: ssm-admin@ietf.org Errors-To: ssm-admin@ietf.org X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , I'm not sure. I think it will be somewhat easier but I suspect not "much easier" to do an SSM-only solution. But I don't know and I'm waiting to see the msec proposal. I do think it would be prudent to take your points under consideration when looking at the msec proposal, though. -Hugh > Date: Wed, 15 Jan 2003 09:11:37 -0800 > From: Toerless Eckert > Cc: Brad Huntting , ssm@ietf.org, > mbaugher@cisco.com, bew@cisco.com > > On Wed, Jan 15, 2003 at 11:48:22AM -0500, Hugh Holbrook wrote: > > > > I agree with you, and I didn't mean to imply that this was an SSM-only > > problem. NTP is a good example of an ASM app that has the same > > problem. The fact that this problem occurs with ASM is a complicating > > factor in determining the right solution (which is a major reason that > > I don't want to tackle it in SSM). > > I don't yet understand the details of the key management yet, but > correct me if i'm wrong: Wouldn't a solution with channel-only > support (eg: SSM only) be able to be much easier than one that > needs to support a multi-source group concept ? Given that simplicity > is one key argument for SSM, it would be good if the security solution > in support of SSM was not necessarily encumbered by additional > complexity only required for ASM. Eg: probably have two approaches, > one that will only work with SSM and one which will work for ASM > but of course also SSM. > > Wrong line of thought ? _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-admin@ietf.org Wed Jan 15 16:02:31 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 QAA09922 for ; Wed, 15 Jan 2003 16:02:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FLGqJ09685; Wed, 15 Jan 2003 16:16:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FL9UJ09440 for ; Wed, 15 Jan 2003 16:09:30 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09716 for ; Wed, 15 Jan 2003 15:54:11 -0500 (EST) Received: from cscoamera13263.cisco.com ([10.21.83.87]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id h0FKumjT014654; Wed, 15 Jan 2003 12:56:49 -0800 (PST) Message-Id: <5.1.1.5.2.20030115123146.021e95a8@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 15 Jan 2003 12:57:24 -0800 To: holbrook@cisco.com From: Mark Baugher Subject: Re: Re: Re: [ssm] SSM with IPSec Cc: Toerless Eckert , Hugh Holbrook , Brad Huntting , ssm@ietf.org, Brian Weis In-Reply-To: <20030115174322.9E3FD10B7A7@holbrook-laptop.cisco.com> References: <20030115171137.GK2103@cypher.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ssm-admin@ietf.org Errors-To: ssm-admin@ietf.org X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , I started from Toerless' position and wanted to focus only on SSM for using the source address for looking up a security association. But how does an IPsec implementation identify that an incoming packet is SSM? I thought we could rely on a 232/8 address and its corollary in IPv6. But that's not the case since some 232/8 addresses could be ASM and some SSM channels could use addresses outside the 232/8 range. This means that something needs to signal to IPsec that an SA is an SSM SA, and that's probably going to be key management. by implication, key mgt thus also signals when an SA is ASM (i.e. NOT SSM). Many applications, moreover, don't want just SSM because it has one SA per sender. Nice for replay protection but bad when there are many senders. So we (Thomas, Brian, Ran and me) are working up a proposal that encompasses both. One complication is that in some cases an IPsec host does a 4-tuple (source addr, dest addr, protocol, spi) lookup and sometimes 3 (source address is a wildcard). Another complication is in having a replay window for ASM when there are multiple senders that are not known when the SA is established; thus, replay windows need to be brought up on the fly. Mark At 12:43 PM 1/15/2003 -0500, Hugh Holbrook wrote: >I'm not sure. > >I think it will be somewhat easier but I suspect not "much easier" to >do an SSM-only solution. But I don't know and I'm waiting to see the >msec proposal. I do think it would be prudent to take your points >under consideration when looking at the msec proposal, though. > >-Hugh > > > Date: Wed, 15 Jan 2003 09:11:37 -0800 > > From: Toerless Eckert > > Cc: Brad Huntting , ssm@ietf.org, > > mbaugher@cisco.com, bew@cisco.com > > > > On Wed, Jan 15, 2003 at 11:48:22AM -0500, Hugh Holbrook wrote: > > > > > > I agree with you, and I didn't mean to imply that this was an SSM-only > > > problem. NTP is a good example of an ASM app that has the same > > > problem. The fact that this problem occurs with ASM is a complicating > > > factor in determining the right solution (which is a major reason that > > > I don't want to tackle it in SSM). > > > > I don't yet understand the details of the key management yet, but > > correct me if i'm wrong: Wouldn't a solution with channel-only > > support (eg: SSM only) be able to be much easier than one that > > needs to support a multi-source group concept ? Given that simplicity > > is one key argument for SSM, it would be good if the security solution > > in support of SSM was not necessarily encumbered by additional > > complexity only required for ASM. Eg: probably have two approaches, > > one that will only work with SSM and one which will work for ASM > > but of course also SSM. > > > > Wrong line of thought ? _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Wed Jan 15 16:06: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 QAA10000 for ; Wed, 15 Jan 2003 16:06:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FLL5h09990 for ssm-archive@odin.ietf.org; Wed, 15 Jan 2003 16:21:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FLL4J09985 for ; Wed, 15 Jan 2003 16:21:04 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09985 for ; Wed, 15 Jan 2003 16:05:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FLGqJ09685; Wed, 15 Jan 2003 16:16:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FL9UJ09440 for ; Wed, 15 Jan 2003 16:09:30 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09716 for ; Wed, 15 Jan 2003 15:54:11 -0500 (EST) Received: from cscoamera13263.cisco.com ([10.21.83.87]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id h0FKumjT014654; Wed, 15 Jan 2003 12:56:49 -0800 (PST) Message-Id: <5.1.1.5.2.20030115123146.021e95a8@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 15 Jan 2003 12:57:24 -0800 To: holbrook@cisco.com From: Mark Baugher Subject: Re: Re: Re: [ssm] SSM with IPSec Cc: Toerless Eckert , Hugh Holbrook , Brad Huntting , ssm@ietf.org, Brian Weis In-Reply-To: <20030115174322.9E3FD10B7A7@holbrook-laptop.cisco.com> References: <20030115171137.GK2103@cypher.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ssm-admin@ietf.org Errors-To: ssm-admin@ietf.org X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , I started from Toerless' position and wanted to focus only on SSM for using the source address for looking up a security association. But how does an IPsec implementation identify that an incoming packet is SSM? I thought we could rely on a 232/8 address and its corollary in IPv6. But that's not the case since some 232/8 addresses could be ASM and some SSM channels could use addresses outside the 232/8 range. This means that something needs to signal to IPsec that an SA is an SSM SA, and that's probably going to be key management. by implication, key mgt thus also signals when an SA is ASM (i.e. NOT SSM). Many applications, moreover, don't want just SSM because it has one SA per sender. Nice for replay protection but bad when there are many senders. So we (Thomas, Brian, Ran and me) are working up a proposal that encompasses both. One complication is that in some cases an IPsec host does a 4-tuple (source addr, dest addr, protocol, spi) lookup and sometimes 3 (source address is a wildcard). Another complication is in having a replay window for ASM when there are multiple senders that are not known when the SA is established; thus, replay windows need to be brought up on the fly. Mark At 12:43 PM 1/15/2003 -0500, Hugh Holbrook wrote: >I'm not sure. > >I think it will be somewhat easier but I suspect not "much easier" to >do an SSM-only solution. But I don't know and I'm waiting to see the >msec proposal. I do think it would be prudent to take your points >under consideration when looking at the msec proposal, though. > >-Hugh > > > Date: Wed, 15 Jan 2003 09:11:37 -0800 > > From: Toerless Eckert > > Cc: Brad Huntting , ssm@ietf.org, > > mbaugher@cisco.com, bew@cisco.com > > > > On Wed, Jan 15, 2003 at 11:48:22AM -0500, Hugh Holbrook wrote: > > > > > > I agree with you, and I didn't mean to imply that this was an SSM-only > > > problem. NTP is a good example of an ASM app that has the same > > > problem. The fact that this problem occurs with ASM is a complicating > > > factor in determining the right solution (which is a major reason that > > > I don't want to tackle it in SSM). > > > > I don't yet understand the details of the key management yet, but > > correct me if i'm wrong: Wouldn't a solution with channel-only > > support (eg: SSM only) be able to be much easier than one that > > needs to support a multi-source group concept ? Given that simplicity > > is one key argument for SSM, it would be good if the security solution > > in support of SSM was not necessarily encumbered by additional > > complexity only required for ASM. Eg: probably have two approaches, > > one that will only work with SSM and one which will work for ASM > > but of course also SSM. > > > > Wrong line of thought ? _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-admin@ietf.org Wed Jan 15 16:58:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11297 for ; Wed, 15 Jan 2003 16:58:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FMDdJ13804; Wed, 15 Jan 2003 17:13:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FM6xJ12919 for ; Wed, 15 Jan 2003 17:06:59 -0500 Received: from possum.icir.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11162 for ; Wed, 15 Jan 2003 16:51:38 -0500 (EST) Received: from possum.icir.org (localhost [127.0.0.1]) by possum.icir.org (8.12.3/8.12.3) with ESMTP id h0FLsv2U079721; Wed, 15 Jan 2003 13:54:57 -0800 (PST) (envelope-from pavlin@possum.icir.org) Message-Id: <200301152154.h0FLsv2U079721@possum.icir.org> To: holbrook@cisco.com cc: ssm@ietf.org, pavlin@icir.org Subject: Re: [ssm] Re: last call comments on ssm-arch doc In-Reply-To: Message from Hugh Holbrook of "Wed, 15 Jan 2003 04:33:05 EST." <20030115093305.E7BE610B7A7@holbrook-laptop.cisco.com> Date: Wed, 15 Jan 2003 13:54:57 -0800 From: Pavlin Radoslavov Sender: ssm-admin@ietf.org Errors-To: ssm-admin@ietf.org X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , > > > * After enumerating the benefits of the SSM model in Section 1, > > > what about enumerating its limitations/drawbacks? :) > > > > Fair enough. I'll come up with something. > > I promised to come up with some text. How about this: Overall looks good to me. Few comments included below. > SSM is particularly well-suited to dissemination-style applications with > a single sender. It can be used in multi-source applications, but the > multi-source "rendezvous" functionality must be implemented by the > application or by an application-layer library. For instance, an "must" is probably a too strong word. Indeed, even though it appears that application-level solution is the only (reasonable) solution, someone might be able to come-up with some alternative, so it should not appear that the document discourages other solutions. Rewording suggestion: Replace "must be implemented by the application or by an application-layer library." With something like "might be implemented in the application level or by some other alternative solution." > application that desires to provide a secondary data source in case the > primary source fails must implement the failover mechanism in the ~~~~ Similar to above: "must" -> "might" > application itself, presumably by using two channels, as two hosts > cannot both send to a single SSM channel. SSM does not support network- > layer multicast resource discovery. Strictly speaking, the last sentence is not absolutely true. For example, lets say that there is something like Resource Discovery Agent with address S1. Then, all servers supporting service X might join SSM group (S1,G1), and all servers supporting Y might join SSM group (S1,G2). If someone wants to do resource discovery, the Resource Discovery Agent can relay the request to discover the servers supporting X or Y. Hence, what about modifying the last sentence to say that resource discovery might be possible, but with the help of additional support, such as application-level relay. Thanks, Pavlin _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Wed Jan 15 17:02:38 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 RAA11522 for ; Wed, 15 Jan 2003 17:02:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FMHRs14102 for ssm-archive@odin.ietf.org; Wed, 15 Jan 2003 17:17:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FMHRJ14099 for ; Wed, 15 Jan 2003 17:17:27 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11496 for ; Wed, 15 Jan 2003 17:02:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FMDdJ13804; Wed, 15 Jan 2003 17:13:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FM6xJ12919 for ; Wed, 15 Jan 2003 17:06:59 -0500 Received: from possum.icir.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11162 for ; Wed, 15 Jan 2003 16:51:38 -0500 (EST) Received: from possum.icir.org (localhost [127.0.0.1]) by possum.icir.org (8.12.3/8.12.3) with ESMTP id h0FLsv2U079721; Wed, 15 Jan 2003 13:54:57 -0800 (PST) (envelope-from pavlin@possum.icir.org) Message-Id: <200301152154.h0FLsv2U079721@possum.icir.org> To: holbrook@cisco.com cc: ssm@ietf.org, pavlin@icir.org Subject: Re: [ssm] Re: last call comments on ssm-arch doc In-Reply-To: Message from Hugh Holbrook of "Wed, 15 Jan 2003 04:33:05 EST." <20030115093305.E7BE610B7A7@holbrook-laptop.cisco.com> Date: Wed, 15 Jan 2003 13:54:57 -0800 From: Pavlin Radoslavov Sender: ssm-admin@ietf.org Errors-To: ssm-admin@ietf.org X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , > > > * After enumerating the benefits of the SSM model in Section 1, > > > what about enumerating its limitations/drawbacks? :) > > > > Fair enough. I'll come up with something. > > I promised to come up with some text. How about this: Overall looks good to me. Few comments included below. > SSM is particularly well-suited to dissemination-style applications with > a single sender. It can be used in multi-source applications, but the > multi-source "rendezvous" functionality must be implemented by the > application or by an application-layer library. For instance, an "must" is probably a too strong word. Indeed, even though it appears that application-level solution is the only (reasonable) solution, someone might be able to come-up with some alternative, so it should not appear that the document discourages other solutions. Rewording suggestion: Replace "must be implemented by the application or by an application-layer library." With something like "might be implemented in the application level or by some other alternative solution." > application that desires to provide a secondary data source in case the > primary source fails must implement the failover mechanism in the ~~~~ Similar to above: "must" -> "might" > application itself, presumably by using two channels, as two hosts > cannot both send to a single SSM channel. SSM does not support network- > layer multicast resource discovery. Strictly speaking, the last sentence is not absolutely true. For example, lets say that there is something like Resource Discovery Agent with address S1. Then, all servers supporting service X might join SSM group (S1,G1), and all servers supporting Y might join SSM group (S1,G2). If someone wants to do resource discovery, the Resource Discovery Agent can relay the request to discover the servers supporting X or Y. Hence, what about modifying the last sentence to say that resource discovery might be possible, but with the help of additional support, such as application-level relay. Thanks, Pavlin _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-admin@ietf.org Wed Jan 15 17:15: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 RAA11894 for ; Wed, 15 Jan 2003 17:15:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FMTpJ14825; Wed, 15 Jan 2003 17:29:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FMKOJ14252 for ; Wed, 15 Jan 2003 17:20:24 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11564 for ; Wed, 15 Jan 2003 17:05:05 -0500 (EST) Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id h0FM8Sfm017552; Wed, 15 Jan 2003 14:08:28 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id OAA04648; Wed, 15 Jan 2003 14:08:17 -0800 (PST) Date: Wed, 15 Jan 2003 14:08:17 -0800 From: Toerless Eckert To: Mark Baugher Cc: holbrook@cisco.com, Toerless Eckert , Brad Huntting , ssm@ietf.org, Brian Weis Subject: Re: Re: Re: [ssm] SSM with IPSec Message-ID: <20030115220817.GA23021@cypher.cisco.com> References: <20030115171137.GK2103@cypher.cisco.com> <5.1.1.5.2.20030115123146.021e95a8@mira-sjc5-6.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.1.5.2.20030115123146.021e95a8@mira-sjc5-6.cisco.com> 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: , Ok, thanks for the insight. One issue is still that the solution needs to support the two cases: - independent security associations for (S1,G) and (S2,G) if G is an SSM group, because (S1,G) and (S2,G) don't necessarily have a connection. - same security association for (S1,G) and (S2,G) if G is an ASM group. Now how to determine what kind of security association is needed, i don't know. Probably it would be a good thing if that could be determined somewhat application specific, but not necessarily requiring the IPsec framework to know the distinction between ASM/SSM. Cheers Toerless _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Wed Jan 15 17:19:04 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 RAA12064 for ; Wed, 15 Jan 2003 17:19:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FMXpp15280 for ssm-archive@odin.ietf.org; Wed, 15 Jan 2003 17:33:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FMXpJ15277 for ; Wed, 15 Jan 2003 17:33:51 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12060 for ; Wed, 15 Jan 2003 17:18:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FMTpJ14825; Wed, 15 Jan 2003 17:29:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FMKOJ14252 for ; Wed, 15 Jan 2003 17:20:24 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11564 for ; Wed, 15 Jan 2003 17:05:05 -0500 (EST) Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id h0FM8Sfm017552; Wed, 15 Jan 2003 14:08:28 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id OAA04648; Wed, 15 Jan 2003 14:08:17 -0800 (PST) Date: Wed, 15 Jan 2003 14:08:17 -0800 From: Toerless Eckert To: Mark Baugher Cc: holbrook@cisco.com, Toerless Eckert , Brad Huntting , ssm@ietf.org, Brian Weis Subject: Re: Re: Re: [ssm] SSM with IPSec Message-ID: <20030115220817.GA23021@cypher.cisco.com> References: <20030115171137.GK2103@cypher.cisco.com> <5.1.1.5.2.20030115123146.021e95a8@mira-sjc5-6.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.1.5.2.20030115123146.021e95a8@mira-sjc5-6.cisco.com> 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: , Ok, thanks for the insight. One issue is still that the solution needs to support the two cases: - independent security associations for (S1,G) and (S2,G) if G is an SSM group, because (S1,G) and (S2,G) don't necessarily have a connection. - same security association for (S1,G) and (S2,G) if G is an ASM group. Now how to determine what kind of security association is needed, i don't know. Probably it would be a good thing if that could be determined somewhat application specific, but not necessarily requiring the IPsec framework to know the distinction between ASM/SSM. Cheers Toerless _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-admin@ietf.org Wed Jan 15 17:32: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 RAA12563 for ; Wed, 15 Jan 2003 17:32:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FMlDJ16743; Wed, 15 Jan 2003 17:47:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FMeSJ16419 for ; Wed, 15 Jan 2003 17:40:28 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12335 for ; Wed, 15 Jan 2003 17:25:09 -0500 (EST) Received: from cscoamera13263.cisco.com ([10.21.83.87]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id h0FMRjjT012785; Wed, 15 Jan 2003 14:27:46 -0800 (PST) Message-Id: <5.1.1.5.2.20030115142209.0219a158@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 15 Jan 2003 14:28:20 -0800 To: Toerless Eckert From: Mark Baugher Subject: Re: Re: Re: [ssm] SSM with IPSec Cc: holbrook@cisco.com, Toerless Eckert , Brad Huntting , ssm@ietf.org, Brian Weis In-Reply-To: <20030115220817.GA23021@cypher.cisco.com> References: <5.1.1.5.2.20030115123146.021e95a8@mira-sjc5-6.cisco.com> <20030115171137.GK2103@cypher.cisco.com> <5.1.1.5.2.20030115123146.021e95a8@mira-sjc5-6.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , Toerless, At 02:08 PM 1/15/2003 -0800, Toerless Eckert wrote: >Ok, thanks for the insight. One issue is still that the solution >needs to support the two cases: > > - independent security associations for (S1,G) and (S2,G) if > G is an SSM group, because (S1,G) and (S2,G) don't necessarily > have a connection. > - same security association for (S1,G) and (S2,G) if G is an ASM > group. > >Now how to determine what kind of security association is needed, >i don't know. Probably it would be a good thing if that could be determined >somewhat application specific, but not necessarily requiring the IPsec >framework to know the distinction between ASM/SSM. When the security association is pushed down to the member by key management, there will need to be a flag that declares whether it is indexed with the source address (SSM) or not (ASM), i.e. whether multiple sources will share that SA. We might be able to leave it at this level without explicitly declaring it to be ASM or SSM to IPsec. In fact, this would allow ASM groups to be indexed by source address (a separate SA for each sender) or SSM to not be indexed by source address (one SA for multiple channels). Whether this makes sense or not is a matter of policy that is implemented in the key server. Mark >Cheers > Toerless _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Wed Jan 15 17:36: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 RAA12790 for ; Wed, 15 Jan 2003 17:36:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FMpGG17175 for ssm-archive@odin.ietf.org; Wed, 15 Jan 2003 17:51:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FMpFJ17172 for ; Wed, 15 Jan 2003 17:51:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12755 for ; Wed, 15 Jan 2003 17:35:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FMlDJ16743; Wed, 15 Jan 2003 17:47:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FMeSJ16419 for ; Wed, 15 Jan 2003 17:40:28 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12335 for ; Wed, 15 Jan 2003 17:25:09 -0500 (EST) Received: from cscoamera13263.cisco.com ([10.21.83.87]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id h0FMRjjT012785; Wed, 15 Jan 2003 14:27:46 -0800 (PST) Message-Id: <5.1.1.5.2.20030115142209.0219a158@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 15 Jan 2003 14:28:20 -0800 To: Toerless Eckert From: Mark Baugher Subject: Re: Re: Re: [ssm] SSM with IPSec Cc: holbrook@cisco.com, Toerless Eckert , Brad Huntting , ssm@ietf.org, Brian Weis In-Reply-To: <20030115220817.GA23021@cypher.cisco.com> References: <5.1.1.5.2.20030115123146.021e95a8@mira-sjc5-6.cisco.com> <20030115171137.GK2103@cypher.cisco.com> <5.1.1.5.2.20030115123146.021e95a8@mira-sjc5-6.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , Toerless, At 02:08 PM 1/15/2003 -0800, Toerless Eckert wrote: >Ok, thanks for the insight. One issue is still that the solution >needs to support the two cases: > > - independent security associations for (S1,G) and (S2,G) if > G is an SSM group, because (S1,G) and (S2,G) don't necessarily > have a connection. > - same security association for (S1,G) and (S2,G) if G is an ASM > group. > >Now how to determine what kind of security association is needed, >i don't know. Probably it would be a good thing if that could be determined >somewhat application specific, but not necessarily requiring the IPsec >framework to know the distinction between ASM/SSM. When the security association is pushed down to the member by key management, there will need to be a flag that declares whether it is indexed with the source address (SSM) or not (ASM), i.e. whether multiple sources will share that SA. We might be able to leave it at this level without explicitly declaring it to be ASM or SSM to IPsec. In fact, this would allow ASM groups to be indexed by source address (a separate SA for each sender) or SSM to not be indexed by source address (one SA for multiple channels). Whether this makes sense or not is a matter of policy that is implemented in the key server. Mark >Cheers > Toerless _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-admin@ietf.org Wed Jan 15 18:07: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 SAA13786 for ; Wed, 15 Jan 2003 18:07:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FNLNJ19525; Wed, 15 Jan 2003 18:21:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FNEuJ19247 for ; Wed, 15 Jan 2003 18:14:56 -0500 Received: from mx.webfountain.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13593 for ; Wed, 15 Jan 2003 17:59:36 -0500 (EST) Received: (qmail 20381 invoked from network); 15 Jan 2003 23:02:56 -0000 Received: from mail.intranet (10.1.1.37) by mx.webfountain.com with SMTP; 15 Jan 2003 23:02:56 -0000 Received: by mail.intranet (8.12.1/8.12.1/Debian -5) with SMTP id h0FNBSev031229; Wed, 15 Jan 2003 15:11:28 -0800 From: "Michael Luby" To: Cc: "Pavlin Radoslavov" , Subject: RE: [ssm] Re: last call comments on ssm-arch doc Date: Wed, 15 Jan 2003 15:02:31 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-reply-to: <200301152154.h0FLsv2U079721@possum.icir.org> 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 Good direction to go, and I'd go even a bit farther, see comments below (lines that start with ***). -----Original Message----- From: ssm-admin@ietf.org [mailto:ssm-admin@ietf.org]On Behalf Of Pavlin Radoslavov Sent: Wednesday, January 15, 2003 1:55 PM To: holbrook@cisco.com Cc: ssm@ietf.org; pavlin@icir.org Subject: Re: [ssm] Re: last call comments on ssm-arch doc > > > * After enumerating the benefits of the SSM model in Section 1, > > > what about enumerating its limitations/drawbacks? :) > > > > Fair enough. I'll come up with something. > > I promised to come up with some text. How about this: Overall looks good to me. Few comments included below. > SSM is particularly well-suited to dissemination-style applications with > a single sender. It can be used in multi-source applications, but the > multi-source "rendezvous" functionality must be implemented by the > application or by an application-layer library. For instance, an "must" is probably a too strong word. Indeed, even though it appears that application-level solution is the only (reasonable) solution, someone might be able to come-up with some alternative, so it should not appear that the document discourages other solutions. Rewording suggestion: Replace "must be implemented by the application or by an application-layer library." With something like "might be implemented in the application level or by some other alternative solution." *** Suggested further rewording: ... It can be used in multi-source applications, *** but just like applications that use unicast as the underlying transport *** the multi-source "rendezvous" functionality can be implemented by the *** application or by some other alternative solution. > application that desires to provide a secondary data source in case the > primary source fails must implement the failover mechanism in the ~~~~ Similar to above: "must" -> "might" > application itself, presumably by using two channels, as two hosts > cannot both send to a single SSM channel. SSM does not support network- > layer multicast resource discovery. Strictly speaking, the last sentence is not absolutely true. For example, lets say that there is something like Resource Discovery Agent with address S1. Then, all servers supporting service X might join SSM group (S1,G1), and all servers supporting Y might join SSM group (S1,G2). If someone wants to do resource discovery, the Resource Discovery Agent can relay the request to discover the servers supporting X or Y. Hence, what about modifying the last sentence to say that resource discovery might be possible, but with the help of additional support, such as application-level relay. Thanks, Pavlin _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Wed Jan 15 18:10: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 SAA13978 for ; Wed, 15 Jan 2003 18:10:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FNPmE19832 for ssm-archive@odin.ietf.org; Wed, 15 Jan 2003 18:25:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FNPmJ19829 for ; Wed, 15 Jan 2003 18:25:48 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13968 for ; Wed, 15 Jan 2003 18:10:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FNLNJ19525; Wed, 15 Jan 2003 18:21:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FNEuJ19247 for ; Wed, 15 Jan 2003 18:14:56 -0500 Received: from mx.webfountain.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13593 for ; Wed, 15 Jan 2003 17:59:36 -0500 (EST) Received: (qmail 20381 invoked from network); 15 Jan 2003 23:02:56 -0000 Received: from mail.intranet (10.1.1.37) by mx.webfountain.com with SMTP; 15 Jan 2003 23:02:56 -0000 Received: by mail.intranet (8.12.1/8.12.1/Debian -5) with SMTP id h0FNBSev031229; Wed, 15 Jan 2003 15:11:28 -0800 From: "Michael Luby" To: Cc: "Pavlin Radoslavov" , Subject: RE: [ssm] Re: last call comments on ssm-arch doc Date: Wed, 15 Jan 2003 15:02:31 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-reply-to: <200301152154.h0FLsv2U079721@possum.icir.org> 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 Good direction to go, and I'd go even a bit farther, see comments below (lines that start with ***). -----Original Message----- From: ssm-admin@ietf.org [mailto:ssm-admin@ietf.org]On Behalf Of Pavlin Radoslavov Sent: Wednesday, January 15, 2003 1:55 PM To: holbrook@cisco.com Cc: ssm@ietf.org; pavlin@icir.org Subject: Re: [ssm] Re: last call comments on ssm-arch doc > > > * After enumerating the benefits of the SSM model in Section 1, > > > what about enumerating its limitations/drawbacks? :) > > > > Fair enough. I'll come up with something. > > I promised to come up with some text. How about this: Overall looks good to me. Few comments included below. > SSM is particularly well-suited to dissemination-style applications with > a single sender. It can be used in multi-source applications, but the > multi-source "rendezvous" functionality must be implemented by the > application or by an application-layer library. For instance, an "must" is probably a too strong word. Indeed, even though it appears that application-level solution is the only (reasonable) solution, someone might be able to come-up with some alternative, so it should not appear that the document discourages other solutions. Rewording suggestion: Replace "must be implemented by the application or by an application-layer library." With something like "might be implemented in the application level or by some other alternative solution." *** Suggested further rewording: ... It can be used in multi-source applications, *** but just like applications that use unicast as the underlying transport *** the multi-source "rendezvous" functionality can be implemented by the *** application or by some other alternative solution. > application that desires to provide a secondary data source in case the > primary source fails must implement the failover mechanism in the ~~~~ Similar to above: "must" -> "might" > application itself, presumably by using two channels, as two hosts > cannot both send to a single SSM channel. SSM does not support network- > layer multicast resource discovery. Strictly speaking, the last sentence is not absolutely true. For example, lets say that there is something like Resource Discovery Agent with address S1. Then, all servers supporting service X might join SSM group (S1,G1), and all servers supporting Y might join SSM group (S1,G2). If someone wants to do resource discovery, the Resource Discovery Agent can relay the request to discover the servers supporting X or Y. Hence, what about modifying the last sentence to say that resource discovery might be possible, but with the help of additional support, such as application-level relay. Thanks, Pavlin _______________________________________________ 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 ssm-admin@ietf.org Wed Jan 15 22:17: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 WAA19324 for ; Wed, 15 Jan 2003 22:17:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G3W8J04066; Wed, 15 Jan 2003 22:32:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G3NtJ03804 for ; Wed, 15 Jan 2003 22:23:55 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19185 for ; Wed, 15 Jan 2003 22:08:29 -0500 (EST) Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id h0G3B8jS028739; Wed, 15 Jan 2003 19:11:08 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id TAA00431; Wed, 15 Jan 2003 19:08:04 -0800 (PST) Date: Wed, 15 Jan 2003 19:08:04 -0800 From: Toerless Eckert To: Mark Baugher Cc: Toerless Eckert , holbrook@cisco.com, Brad Huntting , ssm@ietf.org, Brian Weis Subject: Re: Re: Re: [ssm] SSM with IPSec Message-ID: <20030116030804.GF23021@cypher.cisco.com> References: <5.1.1.5.2.20030115123146.021e95a8@mira-sjc5-6.cisco.com> <20030115171137.GK2103@cypher.cisco.com> <5.1.1.5.2.20030115123146.021e95a8@mira-sjc5-6.cisco.com> <5.1.1.5.2.20030115142209.0219a158@mira-sjc5-6.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.1.5.2.20030115142209.0219a158@mira-sjc5-6.cisco.com> 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 Wed, Jan 15, 2003 at 02:28:20PM -0800, Mark Baugher wrote: > When the security association is pushed down to the member by key > management, there will need to be a flag that declares whether it is > indexed with the source address (SSM) or not (ASM), i.e. whether multiple > sources will share that SA. We might be able to leave it at this level > without explicitly declaring it to be ASM or SSM to IPsec. In fact, this > would allow ASM groups to be indexed by source address (a separate SA for > each sender) or SSM to not be indexed by source address (one SA for > multiple channels). Whether this makes sense or not is a matter of policy > that is implemented in the key server. Right, that sounds good. _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Wed Jan 15 22:21: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 WAA19411 for ; Wed, 15 Jan 2003 22:21:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0G3aBZ04301 for ssm-archive@odin.ietf.org; Wed, 15 Jan 2003 22:36:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G3aBJ04298 for ; Wed, 15 Jan 2003 22:36:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19406 for ; Wed, 15 Jan 2003 22:20:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G3W8J04066; Wed, 15 Jan 2003 22:32:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G3NtJ03804 for ; Wed, 15 Jan 2003 22:23:55 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19185 for ; Wed, 15 Jan 2003 22:08:29 -0500 (EST) Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id h0G3B8jS028739; Wed, 15 Jan 2003 19:11:08 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id TAA00431; Wed, 15 Jan 2003 19:08:04 -0800 (PST) Date: Wed, 15 Jan 2003 19:08:04 -0800 From: Toerless Eckert To: Mark Baugher Cc: Toerless Eckert , holbrook@cisco.com, Brad Huntting , ssm@ietf.org, Brian Weis Subject: Re: Re: Re: [ssm] SSM with IPSec Message-ID: <20030116030804.GF23021@cypher.cisco.com> References: <5.1.1.5.2.20030115123146.021e95a8@mira-sjc5-6.cisco.com> <20030115171137.GK2103@cypher.cisco.com> <5.1.1.5.2.20030115123146.021e95a8@mira-sjc5-6.cisco.com> <5.1.1.5.2.20030115142209.0219a158@mira-sjc5-6.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.1.5.2.20030115142209.0219a158@mira-sjc5-6.cisco.com> 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 Wed, Jan 15, 2003 at 02:28:20PM -0800, Mark Baugher wrote: > When the security association is pushed down to the member by key > management, there will need to be a flag that declares whether it is > indexed with the source address (SSM) or not (ASM), i.e. whether multiple > sources will share that SA. We might be able to leave it at this level > without explicitly declaring it to be ASM or SSM to IPsec. In fact, this > would allow ASM groups to be indexed by source address (a separate SA for > each sender) or SSM to not be indexed by source address (one SA for > multiple channels). Whether this makes sense or not is a matter of policy > that is implemented in the key server. Right, that sounds good. _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-admin@ietf.org Thu Jan 16 01:17:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22457 for ; Thu, 16 Jan 2003 01:17:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G6WRJ13934; Thu, 16 Jan 2003 01:32:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G6PmJ13685 for ; Thu, 16 Jan 2003 01:25:48 -0500 Received: from falcon.continet.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22339 for ; Thu, 16 Jan 2003 01:10:20 -0500 (EST) Received: from [192.168.254.17] ([206.58.103.26]) by falcon.continet.com (Post.Office MTA v3.5.3 release 223 ID# 0-60955U4500L350S0V35) with ESMTP id com for ; Wed, 15 Jan 2003 22:32:11 -0800 Subject: Re: [ssm] Re: last call comments on ssm-arch doc From: Daniel Zappala To: ssm@ietf.org In-Reply-To: <20030115155041.GF2103@cypher.cisco.com> References: <20030115150558.GD2103@cypher.cisco.com> <20030115155041.GF2103@cypher.cisco.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 15 Jan 2003 22:13:25 -0800 Message-Id: <1042697605.2622.44.camel@localhost> Mime-Version: 1.0 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 On Wed, 2003-01-15 at 07:50, Toerless Eckert wrote: > On Wed, Jan 15, 2003 at 04:38:01PM +0100, Rolland Vida wrote: > > Toerless, > > > > > If you're building the white board application as pure peer to peer, > > > each peer has to become a SSM channel source. If you implement the > > > application as a client/server system, the clients could unicast to > > > the server, and the server would have one SSM channel to all clients. > > > Advantages: Easier model for access control, session management > > > and ressource allocation then in a full peer to peer model. > > > > This is a nice trick to provide a multi-source service through SSM. However, > > there are also some drawbacks: no source filtering, no shortest path > > delivery. It is basicly like standard PIM-SM: everybody sends to the RP > > (server), which forwards then on the shared tree (here the SSM channel). And > > as in PIM-SM already the shared tree is switched for a source-specific tree > > (to optimize delivery), why should it be now acceptable to use such a shared > > tree just to enable multi-source SSM? > > Because in SSM the reflection is done at application level, so the > reflecting server can do a lot of useful stuff like source filtering > (access control), (re-)encoding/fec, (re-)encryption, filtering, > synchronization, buffering, shaping, adding coffee. And security > of the applications data flow is now completely under the control of > the application. Well put. I'd also like to add that you can get around the delay penalty (because shortest paths are no longer used if all data is relayed through a single source). You just use the primary source (the application-level relay) to bootstrap other relays. See: D. Zappala, and A. Fabbri, Using SSM Proxies to Provide Efficient Multiple-Source Multicast Delivery. IEEE Globecom, Sixth Global Internet Symposium, November, 2001. at http://www.cs.uoregon.edu/~zappala/uo/uo.publications.html or http://www.nrg.cs.uoregon.edu/pubs/ssm_gis01.pdf -- ====================================================================== Daniel Zappala Computer Science Assistant Professor University of Oregon _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Thu Jan 16 01:21: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 BAA22548 for ; Thu, 16 Jan 2003 01:21:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0G6acr14074 for ssm-archive@odin.ietf.org; Thu, 16 Jan 2003 01:36:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G6acJ14071 for ; Thu, 16 Jan 2003 01:36:38 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22533 for ; Thu, 16 Jan 2003 01:21:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G6WRJ13934; Thu, 16 Jan 2003 01:32:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G6PmJ13685 for ; Thu, 16 Jan 2003 01:25:48 -0500 Received: from falcon.continet.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22339 for ; Thu, 16 Jan 2003 01:10:20 -0500 (EST) Received: from [192.168.254.17] ([206.58.103.26]) by falcon.continet.com (Post.Office MTA v3.5.3 release 223 ID# 0-60955U4500L350S0V35) with ESMTP id com for ; Wed, 15 Jan 2003 22:32:11 -0800 Subject: Re: [ssm] Re: last call comments on ssm-arch doc From: Daniel Zappala To: ssm@ietf.org In-Reply-To: <20030115155041.GF2103@cypher.cisco.com> References: <20030115150558.GD2103@cypher.cisco.com> <20030115155041.GF2103@cypher.cisco.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 15 Jan 2003 22:13:25 -0800 Message-Id: <1042697605.2622.44.camel@localhost> Mime-Version: 1.0 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 On Wed, 2003-01-15 at 07:50, Toerless Eckert wrote: > On Wed, Jan 15, 2003 at 04:38:01PM +0100, Rolland Vida wrote: > > Toerless, > > > > > If you're building the white board application as pure peer to peer, > > > each peer has to become a SSM channel source. If you implement the > > > application as a client/server system, the clients could unicast to > > > the server, and the server would have one SSM channel to all clients. > > > Advantages: Easier model for access control, session management > > > and ressource allocation then in a full peer to peer model. > > > > This is a nice trick to provide a multi-source service through SSM. However, > > there are also some drawbacks: no source filtering, no shortest path > > delivery. It is basicly like standard PIM-SM: everybody sends to the RP > > (server), which forwards then on the shared tree (here the SSM channel). And > > as in PIM-SM already the shared tree is switched for a source-specific tree > > (to optimize delivery), why should it be now acceptable to use such a shared > > tree just to enable multi-source SSM? > > Because in SSM the reflection is done at application level, so the > reflecting server can do a lot of useful stuff like source filtering > (access control), (re-)encoding/fec, (re-)encryption, filtering, > synchronization, buffering, shaping, adding coffee. And security > of the applications data flow is now completely under the control of > the application. Well put. I'd also like to add that you can get around the delay penalty (because shortest paths are no longer used if all data is relayed through a single source). You just use the primary source (the application-level relay) to bootstrap other relays. See: D. Zappala, and A. Fabbri, Using SSM Proxies to Provide Efficient Multiple-Source Multicast Delivery. IEEE Globecom, Sixth Global Internet Symposium, November, 2001. at http://www.cs.uoregon.edu/~zappala/uo/uo.publications.html or http://www.nrg.cs.uoregon.edu/pubs/ssm_gis01.pdf -- ====================================================================== Daniel Zappala Computer Science Assistant Professor University of Oregon _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-admin@ietf.org Thu Jan 16 02:19: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 CAA03554 for ; Thu, 16 Jan 2003 02:19:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G7YLJ28323; Thu, 16 Jan 2003 02:34:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G7RBJ27831 for ; Thu, 16 Jan 2003 02:27:11 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03124 for ; Thu, 16 Jan 2003 02:11:40 -0500 (EST) Received: from holbrook-laptop.cisco.com ([10.21.84.168]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h0G7F00E028808; Wed, 15 Jan 2003 23:15:01 -0800 (PST) Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id 5A2D810B869; Thu, 16 Jan 2003 02:12:47 -0500 (EST) From: Hugh Holbrook To: "Michael Luby" , "Pavlin Radoslavov" Cc: , In-reply-to: Subject: Re: RE: [ssm] Re: last call comments on ssm-arch doc Reply-To: holbrook@cisco.com Message-Id: <20030116071247.5A2D810B869@holbrook-laptop.cisco.com> Date: Thu, 16 Jan 2003 02:12:47 -0500 (EST) 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: , Pavlin and Mike: I like both your suggestions regarding the building of multi-sender apps with SSM. Here's a revision that incorporates your requests; I think this is an improvement. SSM is particularly well-suited to dissemination-style applications with a single sender. It can be used to build multi-source applications, but the multi-source "rendezvous" functionality does not occur in the network layer. Just like in an application that uses unicast as the underlying transport, this functionality can be implemented by the application or by an application-layer library. For instance, an application that desires to provide a secondary data source in case the primary source fails over might implement this by using one channel for each source and advertising both of them to receivers. I'm having more trouble addressing Pavlin's comments regarding what I wrote about resource discovery: > Hence, what about modifying the last sentence to say that resource > discovery might be possible, but with the help of additional > support, such as application-level relay. I don't like the specific phrase that you suggest, Pavlin: "with the help of additional support, such as application-level relay" because it leaves me wondering what other possibilities there might be besides application-level relaying, and I can't actually think of any. So how about if I simply say this: Peer-to-peer multicast resource discovery of the form in which a client sends a multicast query directly to a "service location group" to which servers listen is not directly supported by SSM This is true and doesn't rule out other forms of service discovery. If the group thinks we need to say more about resource discovery than this, then I also wrote this SSM might play a role in a resource discovery service as a mechanism that, for instance, well-known relays can use to forward client queries or server advertisements to interested recipients. The latter bit of text has the problem for me that I don't actually think this is a very good application architecture and I hesitate to make the text look like it endorses it as a good use of SSM. Once you've got a set of well-known servers, why wouldn't you just register the services with them via unicast and let clients do normal unicast queries? Any comments or suggestions? -Hugh > > SSM is particularly well-suited to dissemination-style applications with > > a single sender. It can be used in multi-source applications, but the > > multi-source "rendezvous" functionality must be implemented by the > > application or by an application-layer library. For instance, an > > "must" is probably a too strong word. Indeed, even though it appears > that application-level solution is the only (reasonable) solution, > someone might be able to come-up with some alternative, so it should > not appear that the document discourages other solutions. > Rewording suggestion: > Replace > "must be implemented by the application or by an application-layer > library." > With something like > "might be implemented in the application level or by some other > alternative solution." > > *** Suggested further rewording: ... It can be used in multi-source > applications, > *** but just like applications that use unicast as the underlying transport > *** the multi-source "rendezvous" functionality can be implemented by the > *** application or by some other alternative solution. > > > application that desires to provide a secondary data source in case the > > primary source fails must implement the failover mechanism in the > ~~~~ > Similar to above: "must" -> "might" > > > application itself, presumably by using two channels, as two hosts > > cannot both send to a single SSM channel. SSM does not support network- > > layer multicast resource discovery. > > Strictly speaking, the last sentence is not absolutely true. For > example, lets say that there is something like Resource Discovery > Agent with address S1. Then, all servers supporting service X might > join SSM group (S1,G1), and all servers supporting Y might join SSM > group (S1,G2). If someone wants to do resource discovery, the > Resource Discovery Agent can relay the request to discover the > servers supporting X or Y. > > Hence, what about modifying the last sentence to say that resource > discovery might be possible, but with the help of additional > support, such as application-level relay. > > Thanks, > Pavlin > _______________________________________________ > ssm mailing list > ssm@ietf.org > https://www1.ietf.org/mailman/listinfo/ssm > > _______________________________________________ > ssm mailing list > ssm@ietf.org > https://www1.ietf.org/mailman/listinfo/ssm _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Thu Jan 16 02:23:26 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 CAA03608 for ; Thu, 16 Jan 2003 02:23:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0G7cPn29230 for ssm-archive@odin.ietf.org; Thu, 16 Jan 2003 02:38:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G7cPJ29227 for ; Thu, 16 Jan 2003 02:38:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03602 for ; Thu, 16 Jan 2003 02:22:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G7YLJ28323; Thu, 16 Jan 2003 02:34:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G7RBJ27831 for ; Thu, 16 Jan 2003 02:27:11 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03124 for ; Thu, 16 Jan 2003 02:11:40 -0500 (EST) Received: from holbrook-laptop.cisco.com ([10.21.84.168]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h0G7F00E028808; Wed, 15 Jan 2003 23:15:01 -0800 (PST) Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id 5A2D810B869; Thu, 16 Jan 2003 02:12:47 -0500 (EST) From: Hugh Holbrook To: "Michael Luby" , "Pavlin Radoslavov" Cc: , In-reply-to: Subject: Re: RE: [ssm] Re: last call comments on ssm-arch doc Reply-To: holbrook@cisco.com Message-Id: <20030116071247.5A2D810B869@holbrook-laptop.cisco.com> Date: Thu, 16 Jan 2003 02:12:47 -0500 (EST) 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: , Pavlin and Mike: I like both your suggestions regarding the building of multi-sender apps with SSM. Here's a revision that incorporates your requests; I think this is an improvement. SSM is particularly well-suited to dissemination-style applications with a single sender. It can be used to build multi-source applications, but the multi-source "rendezvous" functionality does not occur in the network layer. Just like in an application that uses unicast as the underlying transport, this functionality can be implemented by the application or by an application-layer library. For instance, an application that desires to provide a secondary data source in case the primary source fails over might implement this by using one channel for each source and advertising both of them to receivers. I'm having more trouble addressing Pavlin's comments regarding what I wrote about resource discovery: > Hence, what about modifying the last sentence to say that resource > discovery might be possible, but with the help of additional > support, such as application-level relay. I don't like the specific phrase that you suggest, Pavlin: "with the help of additional support, such as application-level relay" because it leaves me wondering what other possibilities there might be besides application-level relaying, and I can't actually think of any. So how about if I simply say this: Peer-to-peer multicast resource discovery of the form in which a client sends a multicast query directly to a "service location group" to which servers listen is not directly supported by SSM This is true and doesn't rule out other forms of service discovery. If the group thinks we need to say more about resource discovery than this, then I also wrote this SSM might play a role in a resource discovery service as a mechanism that, for instance, well-known relays can use to forward client queries or server advertisements to interested recipients. The latter bit of text has the problem for me that I don't actually think this is a very good application architecture and I hesitate to make the text look like it endorses it as a good use of SSM. Once you've got a set of well-known servers, why wouldn't you just register the services with them via unicast and let clients do normal unicast queries? Any comments or suggestions? -Hugh > > SSM is particularly well-suited to dissemination-style applications with > > a single sender. It can be used in multi-source applications, but the > > multi-source "rendezvous" functionality must be implemented by the > > application or by an application-layer library. For instance, an > > "must" is probably a too strong word. Indeed, even though it appears > that application-level solution is the only (reasonable) solution, > someone might be able to come-up with some alternative, so it should > not appear that the document discourages other solutions. > Rewording suggestion: > Replace > "must be implemented by the application or by an application-layer > library." > With something like > "might be implemented in the application level or by some other > alternative solution." > > *** Suggested further rewording: ... It can be used in multi-source > applications, > *** but just like applications that use unicast as the underlying transport > *** the multi-source "rendezvous" functionality can be implemented by the > *** application or by some other alternative solution. > > > application that desires to provide a secondary data source in case the > > primary source fails must implement the failover mechanism in the > ~~~~ > Similar to above: "must" -> "might" > > > application itself, presumably by using two channels, as two hosts > > cannot both send to a single SSM channel. SSM does not support network- > > layer multicast resource discovery. > > Strictly speaking, the last sentence is not absolutely true. For > example, lets say that there is something like Resource Discovery > Agent with address S1. Then, all servers supporting service X might > join SSM group (S1,G1), and all servers supporting Y might join SSM > group (S1,G2). If someone wants to do resource discovery, the > Resource Discovery Agent can relay the request to discover the > servers supporting X or Y. > > Hence, what about modifying the last sentence to say that resource > discovery might be possible, but with the help of additional > support, such as application-level relay. > > Thanks, > Pavlin > _______________________________________________ > ssm mailing list > ssm@ietf.org > https://www1.ietf.org/mailman/listinfo/ssm > > _______________________________________________ > ssm mailing list > ssm@ietf.org > https://www1.ietf.org/mailman/listinfo/ssm _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-admin@ietf.org Thu Jan 16 09:43:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12502 for ; Thu, 16 Jan 2003 09:43:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GEwYJ27371; Thu, 16 Jan 2003 09:58:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GEpYJ27127 for ; Thu, 16 Jan 2003 09:51:34 -0500 Received: from merlot.juniper.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12334 for ; Thu, 16 Jan 2003 09:35:54 -0500 (EST) Received: from maroon.jnpr.net (maroon.jnpr.net [172.24.244.36]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h0GEd9S04116; Thu, 16 Jan 2003 06:39:09 -0800 (PST) (envelope-from lenny@juniper.net) Received: from localhost (lenny@localhost) by maroon.jnpr.net (8.11.6/8.11.3) with ESMTP id h0GEd8j90595; Thu, 16 Jan 2003 06:39:09 -0800 (PST) (envelope-from lenny@juniper.net) X-Authentication-Warning: maroon.jnpr.net: lenny owned process doing -bs Date: Thu, 16 Jan 2003 06:39:08 -0800 (PST) From: Leonard Giuliano X-X-Sender: To: cc: Message-ID: <20030116063737.E89747-100000@maroon.jnpr.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [ssm] Re: a few ssm comments (fwd) 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, 17 Dec 2002 pekkas@netcore.fi wrote: -) -) Hello, -) -) I quickly read the two SSM drafts properly for the first time. A few -) minor comments. -) -) ssm-overview-04: -) -) Thus -) the complexity of the multicast routing infrastructure for SSM is -) low, making it viable for immediate deployment. Note that MBGP is -) still required for distribution of multicast reachability -) information. -) -) ==> I would dispute the last sentence a bit. It's not really necessary to -) use MBGP at all if you're using PIM. -) Agreed, you don't NEED MBGP for PIM to work. I think the point trying to be made here is that SSM is no different than ASM when it comes to MBGP, but the way it is currently worded doesn't make that clear. Perhaps the following wording might be better: "Note that the necessity for MBGP in SSM is no different than in ASM. That is, when topology incongruity or a separate M-RIB for RPF is desired, MBGP can be used." -Lenny _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Thu Jan 16 09:47: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 JAA12628 for ; Thu, 16 Jan 2003 09:47:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GF2jH27686 for ssm-archive@odin.ietf.org; Thu, 16 Jan 2003 10:02:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GF2jJ27683 for ; Thu, 16 Jan 2003 10:02:45 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12623 for ; Thu, 16 Jan 2003 09:47:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GEwYJ27371; Thu, 16 Jan 2003 09:58:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GEpYJ27127 for ; Thu, 16 Jan 2003 09:51:34 -0500 Received: from merlot.juniper.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12334 for ; Thu, 16 Jan 2003 09:35:54 -0500 (EST) Received: from maroon.jnpr.net (maroon.jnpr.net [172.24.244.36]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h0GEd9S04116; Thu, 16 Jan 2003 06:39:09 -0800 (PST) (envelope-from lenny@juniper.net) Received: from localhost (lenny@localhost) by maroon.jnpr.net (8.11.6/8.11.3) with ESMTP id h0GEd8j90595; Thu, 16 Jan 2003 06:39:09 -0800 (PST) (envelope-from lenny@juniper.net) X-Authentication-Warning: maroon.jnpr.net: lenny owned process doing -bs Date: Thu, 16 Jan 2003 06:39:08 -0800 (PST) From: Leonard Giuliano X-X-Sender: To: cc: Message-ID: <20030116063737.E89747-100000@maroon.jnpr.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [ssm] Re: a few ssm comments (fwd) 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, 17 Dec 2002 pekkas@netcore.fi wrote: -) -) Hello, -) -) I quickly read the two SSM drafts properly for the first time. A few -) minor comments. -) -) ssm-overview-04: -) -) Thus -) the complexity of the multicast routing infrastructure for SSM is -) low, making it viable for immediate deployment. Note that MBGP is -) still required for distribution of multicast reachability -) information. -) -) ==> I would dispute the last sentence a bit. It's not really necessary to -) use MBGP at all if you're using PIM. -) Agreed, you don't NEED MBGP for PIM to work. I think the point trying to be made here is that SSM is no different than ASM when it comes to MBGP, but the way it is currently worded doesn't make that clear. Perhaps the following wording might be better: "Note that the necessity for MBGP in SSM is no different than in ASM. That is, when topology incongruity or a separate M-RIB for RPF is desired, MBGP can be used." -Lenny _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-admin@ietf.org Thu Jan 16 11:38:38 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 LAA15589 for ; Thu, 16 Jan 2003 11:38:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GGrTJ03811; Thu, 16 Jan 2003 11:53:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GFtVJ31931 for ; Thu, 16 Jan 2003 10:55:31 -0500 Received: from ns1.u-strasbg.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14065 for ; Thu, 16 Jan 2003 10:39:49 -0500 (EST) Received: from crc.u-strasbg.fr (crc.u-strasbg.fr [130.79.201.129]) by ns1.u-strasbg.fr (8.12.3/jtpda-5.4) with ESMTP id h0GFhBIh099200 ; Thu, 16 Jan 2003 16:43:11 +0100 (CET) Received: from crc.u-strasbg.fr (sixnet.u-strasbg.fr [130.79.90.153]) by crc.u-strasbg.fr (8.12.3/jtpda-5.4) with ESMTP id h0GFhBFX055977 ; Thu, 16 Jan 2003 16:43:11 +0100 (CET) Message-ID: <3E26D30F.6010001@crc.u-strasbg.fr> Date: Thu, 16 Jan 2003 16:43:11 +0100 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: Leonard Giuliano CC: ssm@ietf.org, pekkas@netcore.fi Subject: Re: [ssm] Re: a few ssm comments (fwd) References: <20030116063737.E89747-100000@maroon.jnpr.net> 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 Leonard Giuliano wrote: > On Tue, 17 Dec 2002 pekkas@netcore.fi wrote: > > -) > -) Hello, > -) > -) I quickly read the two SSM drafts properly for the first time. A few > -) minor comments. > -) > -) ssm-overview-04: > -) > -) Thus > -) the complexity of the multicast routing infrastructure for SSM is > -) low, making it viable for immediate deployment. Note that MBGP is > -) still required for distribution of multicast reachability > -) information. > -) > -) ==> I would dispute the last sentence a bit. It's not really necessary to > -) use MBGP at all if you're using PIM. > -) > > Agreed, you don't NEED MBGP for PIM to work. I think the point trying to > be made here is that SSM is no different than ASM when it comes to MBGP, > but the way it is currently worded doesn't make that clear. Perhaps the > following wording might be better: > > "Note that the necessity for MBGP in SSM is no different than in ASM. > That is, when topology incongruity or a separate M-RIB for RPF is desired, > MBGP can be used." I am not sure that the necessity is no different in the inter-domain case. With ASM you may need an extra mechanism to interconnect intra- domain trees, such as MSDP or BGMP. These protocols may need more information from MBGP (in fact this was the case in the BGMP proposal where multicast addresses where associated to domains) Jean-Jacques > > > -Lenny > > > > _______________________________________________ > ssm mailing list > ssm@ietf.org > https://www1.ietf.org/mailman/listinfo/ssm _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Thu Jan 16 11:42:38 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 LAA15729 for ; Thu, 16 Jan 2003 11:42:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GGvmp04110 for ssm-archive@odin.ietf.org; Thu, 16 Jan 2003 11:57:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GGvmJ04107 for ; Thu, 16 Jan 2003 11:57:48 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15709 for ; Thu, 16 Jan 2003 11:42:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GGrTJ03811; Thu, 16 Jan 2003 11:53:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GFtVJ31931 for ; Thu, 16 Jan 2003 10:55:31 -0500 Received: from ns1.u-strasbg.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14065 for ; Thu, 16 Jan 2003 10:39:49 -0500 (EST) Received: from crc.u-strasbg.fr (crc.u-strasbg.fr [130.79.201.129]) by ns1.u-strasbg.fr (8.12.3/jtpda-5.4) with ESMTP id h0GFhBIh099200 ; Thu, 16 Jan 2003 16:43:11 +0100 (CET) Received: from crc.u-strasbg.fr (sixnet.u-strasbg.fr [130.79.90.153]) by crc.u-strasbg.fr (8.12.3/jtpda-5.4) with ESMTP id h0GFhBFX055977 ; Thu, 16 Jan 2003 16:43:11 +0100 (CET) Message-ID: <3E26D30F.6010001@crc.u-strasbg.fr> Date: Thu, 16 Jan 2003 16:43:11 +0100 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: Leonard Giuliano CC: ssm@ietf.org, pekkas@netcore.fi Subject: Re: [ssm] Re: a few ssm comments (fwd) References: <20030116063737.E89747-100000@maroon.jnpr.net> 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 Leonard Giuliano wrote: > On Tue, 17 Dec 2002 pekkas@netcore.fi wrote: > > -) > -) Hello, > -) > -) I quickly read the two SSM drafts properly for the first time. A few > -) minor comments. > -) > -) ssm-overview-04: > -) > -) Thus > -) the complexity of the multicast routing infrastructure for SSM is > -) low, making it viable for immediate deployment. Note that MBGP is > -) still required for distribution of multicast reachability > -) information. > -) > -) ==> I would dispute the last sentence a bit. It's not really necessary to > -) use MBGP at all if you're using PIM. > -) > > Agreed, you don't NEED MBGP for PIM to work. I think the point trying to > be made here is that SSM is no different than ASM when it comes to MBGP, > but the way it is currently worded doesn't make that clear. Perhaps the > following wording might be better: > > "Note that the necessity for MBGP in SSM is no different than in ASM. > That is, when topology incongruity or a separate M-RIB for RPF is desired, > MBGP can be used." I am not sure that the necessity is no different in the inter-domain case. With ASM you may need an extra mechanism to interconnect intra- domain trees, such as MSDP or BGMP. These protocols may need more information from MBGP (in fact this was the case in the BGMP proposal where multicast addresses where associated to domains) Jean-Jacques > > > -Lenny > > > > _______________________________________________ > 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 ssm-admin@ietf.org Thu Jan 16 20:48:00 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 UAA29112 for ; Thu, 16 Jan 2003 20:48:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H22wJ08883; Thu, 16 Jan 2003 21:02:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H1tiJ08581 for ; Thu, 16 Jan 2003 20:55:44 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28809 for ; Thu, 16 Jan 2003 20:39:51 -0500 (EST) Received: from holbrook-laptop.cisco.com (sjc-vpn2-304.cisco.com [10.21.113.48]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h0H1hB0E000371; Thu, 16 Jan 2003 17:43:12 -0800 (PST) Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id EC8D210B7A7; Thu, 16 Jan 2003 20:40:56 -0500 (EST) From: Hugh Holbrook To: Toerless Eckert Cc: Rolland Vida , Toerless Eckert , ssm@ietf.org In-reply-to: <20030115155041.GF2103@cypher.cisco.com> Subject: Re: Re: [ssm] Re: last call comments on ssm-arch doc Reply-To: holbrook@cisco.com Message-Id: <20030117014056.EC8D210B7A7@holbrook-laptop.cisco.com> Date: Thu, 16 Jan 2003 20:40:56 -0500 (EST) 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: , While we're on the topic, I may as well plug my PhD Thesis (which is basically about SSM), because it talks at some length about all of the possible application architectures that Toerless laid out below. http://www.dsg.stanford.edu/holbrook/dissertation.ps.gz (two-sided) http://www.dsg.stanford.edu/holbrook/dissertation-oneside.ps.gz (one-sided) Chapters 6, 7, and 8 deal at some length with ways of building multi-participant applications using SSM and the associated costs and tradeoffs, including comparisons to various flavors of ASM. Regards, -Hugh > Date: Wed, 15 Jan 2003 07:50:41 -0800 > From: Toerless Eckert > Cc: Toerless Eckert , ssm@ietf.org > > On Wed, Jan 15, 2003 at 04:38:01PM +0100, Rolland Vida wrote: > > Toerless, > > > > > If you're building the white board application as pure peer to peer, > > > each peer has to become a SSM channel source. If you implement the > > > application as a client/server system, the clients could unicast to > > > the server, and the server would have one SSM channel to all clients. > > > Advantages: Easier model for access control, session management > > > and ressource allocation then in a full peer to peer model. > > > > This is a nice trick to provide a multi-source service through SSM. However, > > there are also some drawbacks: no source filtering, no shortest path > > delivery. It is basicly like standard PIM-SM: everybody sends to the RP > > (server), which forwards then on the shared tree (here the SSM channel). And > > as in PIM-SM already the shared tree is switched for a source-specific tree > > (to optimize delivery), why should it be now acceptable to use such a shared > > tree just to enable multi-source SSM? > > Because in SSM the reflection is done at application level, so the > reflecting server can do a lot of useful stuff like source filtering > (access control), (re-)encoding/fec, (re-)encryption, filtering, > synchronization, buffering, shaping, adding coffee. And security > of the applications data flow is now completely under the control of > the application. > > Reflection at the PIM-SM RP is not under application control, and source > filtering on the RP doesn't really work except for well controlled and > architected intradomain applications. Also, it's static only. Besides, > there are so many shortcut possiblities in PIM-SM that it's almost not > possible to really guarantee in all situations that traffic has to go > through the RP for means of filtering. > > > > b) client/server control, peer-to-peer data: > > > clients have control connection with server to learn > > > about peers multicasting. Data itself is multicasted > > > on SSM channels from each client to other interested > > > clients. > > > > > > c) peer-to-peer control and data: > > > There is no central server. Instead new peers have to > > > somehow discover at least one existing peer, who can then > > > signal to all other peers the existance of this new peer. > > > This peer-to-peer control connections can be unicast > > > with some topology between peers or can be SSM. > > > > The difference between b) and c) seems to be only the way how the receivers > > learn the address of the SSM source. But, as far as I know, it was always > > said that this is out of scope of the SSM specs. Hugh said in its last > > sentence: "SSM does not support network-layer multicast resource discovery". > > In my understanding, this is related exactly to our discussion. > > I was talking about the application architecture on layers above SSM, > and the difference between b) and c) is mostly complexity: b) is simple > and well understood. c) is highly complex, like a self learning topology. > You can try to approach c) very simple, but that means full mesh and that > means wasted ressources. > > Cheers > Toerless > _______________________________________________ > Ssm mailing list > Ssm@ietf.org > https://www1.ietf.org/mailman/listinfo/ssm _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Thu Jan 16 20:51: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 UAA29159 for ; Thu, 16 Jan 2003 20:51:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0H275q09222 for ssm-archive@odin.ietf.org; Thu, 16 Jan 2003 21:07:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H275J09219 for ; Thu, 16 Jan 2003 21:07:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29153 for ; Thu, 16 Jan 2003 20:51:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H22wJ08883; Thu, 16 Jan 2003 21:02:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H1tiJ08581 for ; Thu, 16 Jan 2003 20:55:44 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28809 for ; Thu, 16 Jan 2003 20:39:51 -0500 (EST) Received: from holbrook-laptop.cisco.com (sjc-vpn2-304.cisco.com [10.21.113.48]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h0H1hB0E000371; Thu, 16 Jan 2003 17:43:12 -0800 (PST) Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id EC8D210B7A7; Thu, 16 Jan 2003 20:40:56 -0500 (EST) From: Hugh Holbrook To: Toerless Eckert Cc: Rolland Vida , Toerless Eckert , ssm@ietf.org In-reply-to: <20030115155041.GF2103@cypher.cisco.com> Subject: Re: Re: [ssm] Re: last call comments on ssm-arch doc Reply-To: holbrook@cisco.com Message-Id: <20030117014056.EC8D210B7A7@holbrook-laptop.cisco.com> Date: Thu, 16 Jan 2003 20:40:56 -0500 (EST) 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: , While we're on the topic, I may as well plug my PhD Thesis (which is basically about SSM), because it talks at some length about all of the possible application architectures that Toerless laid out below. http://www.dsg.stanford.edu/holbrook/dissertation.ps.gz (two-sided) http://www.dsg.stanford.edu/holbrook/dissertation-oneside.ps.gz (one-sided) Chapters 6, 7, and 8 deal at some length with ways of building multi-participant applications using SSM and the associated costs and tradeoffs, including comparisons to various flavors of ASM. Regards, -Hugh > Date: Wed, 15 Jan 2003 07:50:41 -0800 > From: Toerless Eckert > Cc: Toerless Eckert , ssm@ietf.org > > On Wed, Jan 15, 2003 at 04:38:01PM +0100, Rolland Vida wrote: > > Toerless, > > > > > If you're building the white board application as pure peer to peer, > > > each peer has to become a SSM channel source. If you implement the > > > application as a client/server system, the clients could unicast to > > > the server, and the server would have one SSM channel to all clients. > > > Advantages: Easier model for access control, session management > > > and ressource allocation then in a full peer to peer model. > > > > This is a nice trick to provide a multi-source service through SSM. However, > > there are also some drawbacks: no source filtering, no shortest path > > delivery. It is basicly like standard PIM-SM: everybody sends to the RP > > (server), which forwards then on the shared tree (here the SSM channel). And > > as in PIM-SM already the shared tree is switched for a source-specific tree > > (to optimize delivery), why should it be now acceptable to use such a shared > > tree just to enable multi-source SSM? > > Because in SSM the reflection is done at application level, so the > reflecting server can do a lot of useful stuff like source filtering > (access control), (re-)encoding/fec, (re-)encryption, filtering, > synchronization, buffering, shaping, adding coffee. And security > of the applications data flow is now completely under the control of > the application. > > Reflection at the PIM-SM RP is not under application control, and source > filtering on the RP doesn't really work except for well controlled and > architected intradomain applications. Also, it's static only. Besides, > there are so many shortcut possiblities in PIM-SM that it's almost not > possible to really guarantee in all situations that traffic has to go > through the RP for means of filtering. > > > > b) client/server control, peer-to-peer data: > > > clients have control connection with server to learn > > > about peers multicasting. Data itself is multicasted > > > on SSM channels from each client to other interested > > > clients. > > > > > > c) peer-to-peer control and data: > > > There is no central server. Instead new peers have to > > > somehow discover at least one existing peer, who can then > > > signal to all other peers the existance of this new peer. > > > This peer-to-peer control connections can be unicast > > > with some topology between peers or can be SSM. > > > > The difference between b) and c) seems to be only the way how the receivers > > learn the address of the SSM source. But, as far as I know, it was always > > said that this is out of scope of the SSM specs. Hugh said in its last > > sentence: "SSM does not support network-layer multicast resource discovery". > > In my understanding, this is related exactly to our discussion. > > I was talking about the application architecture on layers above SSM, > and the difference between b) and c) is mostly complexity: b) is simple > and well understood. c) is highly complex, like a self learning topology. > You can try to approach c) very simple, but that means full mesh and that > means wasted ressources. > > Cheers > Toerless > _______________________________________________ > 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 ssm-admin@ietf.org Thu Jan 16 23:39:31 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 XAA02312 for ; Thu, 16 Jan 2003 23:39:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H4snJ18801; Thu, 16 Jan 2003 23:54:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H4lRJ18548 for ; Thu, 16 Jan 2003 23:47:27 -0500 Received: from possum.icir.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02229 for ; Thu, 16 Jan 2003 23:31:30 -0500 (EST) Received: from possum.icir.org (localhost [127.0.0.1]) by possum.icir.org (8.12.3/8.12.3) with ESMTP id h0H4Yp2U067291; Thu, 16 Jan 2003 20:34:51 -0800 (PST) (envelope-from pavlin@possum.icir.org) Message-Id: <200301170434.h0H4Yp2U067291@possum.icir.org> To: holbrook@cisco.com cc: "Michael Luby" , "Pavlin Radoslavov" , ssm@ietf.org Subject: Re: [ssm] Re: last call comments on ssm-arch doc In-Reply-To: Message from Hugh Holbrook of "Thu, 16 Jan 2003 02:12:47 EST." <20030116071247.5A2D810B869@holbrook-laptop.cisco.com> Date: Thu, 16 Jan 2003 20:34:51 -0800 From: Pavlin Radoslavov Sender: ssm-admin@ietf.org Errors-To: ssm-admin@ietf.org X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , > I like both your suggestions regarding the building of multi-sender > apps with SSM. Here's a revision that incorporates your requests; I > think this is an improvement. > > SSM is particularly well-suited to dissemination-style applications > with a single sender. It can be used to build multi-source > applications, but the multi-source "rendezvous" functionality does not > occur in the network layer. Just like in an application that uses > unicast as the underlying transport, this functionality can be > implemented by the application or by an application-layer library. > For instance, an application that desires to provide a secondary data > source in case the primary source fails over might implement this by > using one channel for each source and advertising both of them to > receivers. Looks good to me. > I'm having more trouble addressing Pavlin's comments regarding what I > wrote about resource discovery: > > > Hence, what about modifying the last sentence to say that resource > > discovery might be possible, but with the help of additional > > support, such as application-level relay. > > I don't like the specific phrase that you suggest, Pavlin: "with the > help of additional support, such as application-level relay" because > it leaves me wondering what other possibilities there might be besides > application-level relaying, and I can't actually think of any. > > So how about if I simply say this: > > Peer-to-peer multicast resource discovery of the form in > which a client sends a multicast query directly to a "service > location group" to which servers listen is not directly supported > by SSM Fine with me. > > This is true and doesn't rule out other forms of service discovery. > If the group thinks we need to say more about resource discovery than > this, then I also wrote this > > SSM might play a role in a resource discovery > service as a mechanism that, for instance, well-known relays can > use to forward client queries or server advertisements to > interested recipients. I think there is no need to say that, so the "Peer-to-peer..." paragraph is just fine. Thanks, Pavlin > The latter bit of text has the problem for me that I don't actually > think this is a very good application architecture and I hesitate to > make the text look like it endorses it as a good use of SSM. Once > you've got a set of well-known servers, why wouldn't you just register > the services with them via unicast and let clients do normal unicast > queries? _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Thu Jan 16 23:43:14 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 XAA02361 for ; Thu, 16 Jan 2003 23:43:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0H4wfe18944 for ssm-archive@odin.ietf.org; Thu, 16 Jan 2003 23:58:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H4weJ18941 for ; Thu, 16 Jan 2003 23:58:40 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02358 for ; Thu, 16 Jan 2003 23:42:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H4snJ18801; Thu, 16 Jan 2003 23:54:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H4lRJ18548 for ; Thu, 16 Jan 2003 23:47:27 -0500 Received: from possum.icir.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02229 for ; Thu, 16 Jan 2003 23:31:30 -0500 (EST) Received: from possum.icir.org (localhost [127.0.0.1]) by possum.icir.org (8.12.3/8.12.3) with ESMTP id h0H4Yp2U067291; Thu, 16 Jan 2003 20:34:51 -0800 (PST) (envelope-from pavlin@possum.icir.org) Message-Id: <200301170434.h0H4Yp2U067291@possum.icir.org> To: holbrook@cisco.com cc: "Michael Luby" , "Pavlin Radoslavov" , ssm@ietf.org Subject: Re: [ssm] Re: last call comments on ssm-arch doc In-Reply-To: Message from Hugh Holbrook of "Thu, 16 Jan 2003 02:12:47 EST." <20030116071247.5A2D810B869@holbrook-laptop.cisco.com> Date: Thu, 16 Jan 2003 20:34:51 -0800 From: Pavlin Radoslavov Sender: ssm-admin@ietf.org Errors-To: ssm-admin@ietf.org X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , > I like both your suggestions regarding the building of multi-sender > apps with SSM. Here's a revision that incorporates your requests; I > think this is an improvement. > > SSM is particularly well-suited to dissemination-style applications > with a single sender. It can be used to build multi-source > applications, but the multi-source "rendezvous" functionality does not > occur in the network layer. Just like in an application that uses > unicast as the underlying transport, this functionality can be > implemented by the application or by an application-layer library. > For instance, an application that desires to provide a secondary data > source in case the primary source fails over might implement this by > using one channel for each source and advertising both of them to > receivers. Looks good to me. > I'm having more trouble addressing Pavlin's comments regarding what I > wrote about resource discovery: > > > Hence, what about modifying the last sentence to say that resource > > discovery might be possible, but with the help of additional > > support, such as application-level relay. > > I don't like the specific phrase that you suggest, Pavlin: "with the > help of additional support, such as application-level relay" because > it leaves me wondering what other possibilities there might be besides > application-level relaying, and I can't actually think of any. > > So how about if I simply say this: > > Peer-to-peer multicast resource discovery of the form in > which a client sends a multicast query directly to a "service > location group" to which servers listen is not directly supported > by SSM Fine with me. > > This is true and doesn't rule out other forms of service discovery. > If the group thinks we need to say more about resource discovery than > this, then I also wrote this > > SSM might play a role in a resource discovery > service as a mechanism that, for instance, well-known relays can > use to forward client queries or server advertisements to > interested recipients. I think there is no need to say that, so the "Peer-to-peer..." paragraph is just fine. Thanks, Pavlin > The latter bit of text has the problem for me that I don't actually > think this is a very good application architecture and I hesitate to > make the text look like it endorses it as a good use of SSM. Once > you've got a set of well-known servers, why wouldn't you just register > the services with them via unicast and let clients do normal unicast > queries? _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-admin@ietf.org Fri Jan 17 12:55:56 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 MAA29943 for ; Fri, 17 Jan 2003 12:55:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HIB1J19022; Fri, 17 Jan 2003 13:11:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HI1tJ17946 for ; Fri, 17 Jan 2003 13:01:55 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29660 for ; Fri, 17 Jan 2003 12:45:43 -0500 (EST) Received: from holbrook-laptop.cisco.com (sjc-vpn2-304.cisco.com [10.21.113.48]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0HHmxFp013308; Fri, 17 Jan 2003 09:48:59 -0800 (PST) Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id 67CD010B7A7; Fri, 17 Jan 2003 01:55:57 -0500 (EST) From: Hugh Holbrook To: Pavlin Radoslavov Cc: holbrook@cisco.com, "Michael Luby" , "Pavlin Radoslavov" , ssm@ietf.org In-reply-to: <200301170434.h0H4Yp2U067291@possum.icir.org> Subject: Re: Re: [ssm] Re: last call comments on ssm-arch doc Reply-To: holbrook@dsg.stanford.edu Message-Id: <20030117065557.67CD010B7A7@holbrook-laptop.cisco.com> Date: Fri, 17 Jan 2003 01:55:57 -0500 (EST) 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: , Great. Thanks for your comments. -Hugh > Cc: "Michael Luby" , > "Pavlin Radoslavov" , ssm@ietf.org > Date: Thu, 16 Jan 2003 20:34:51 -0800 > From: Pavlin Radoslavov > > > I like both your suggestions regarding the building of multi-sender > > apps with SSM. Here's a revision that incorporates your requests; I > > think this is an improvement. > > > > SSM is particularly well-suited to dissemination-style applications > > with a single sender. It can be used to build multi-source > > applications, but the multi-source "rendezvous" functionality does not > > occur in the network layer. Just like in an application that uses > > unicast as the underlying transport, this functionality can be > > implemented by the application or by an application-layer library. > > For instance, an application that desires to provide a secondary data > > source in case the primary source fails over might implement this by > > using one channel for each source and advertising both of them to > > receivers. > > Looks good to me. > > > I'm having more trouble addressing Pavlin's comments regarding what I > > wrote about resource discovery: > > > > > Hence, what about modifying the last sentence to say that resource > > > discovery might be possible, but with the help of additional > > > support, such as application-level relay. > > > > I don't like the specific phrase that you suggest, Pavlin: "with the > > help of additional support, such as application-level relay" because > > it leaves me wondering what other possibilities there might be besides > > application-level relaying, and I can't actually think of any. > > > > So how about if I simply say this: > > > > Peer-to-peer multicast resource discovery of the form in > > which a client sends a multicast query directly to a "service > > location group" to which servers listen is not directly supported > > by SSM > > Fine with me. > > > > > This is true and doesn't rule out other forms of service discovery. > > If the group thinks we need to say more about resource discovery than > > this, then I also wrote this > > > > SSM might play a role in a resource discovery > > service as a mechanism that, for instance, well-known relays can > > use to forward client queries or server advertisements to > > interested recipients. > > I think there is no need to say that, so the "Peer-to-peer..." > paragraph is just fine. > > Thanks, > Pavlin > > > The latter bit of text has the problem for me that I don't actually > > think this is a very good application architecture and I hesitate to > > make the text look like it endorses it as a good use of SSM. Once > > you've got a set of well-known servers, why wouldn't you just register > > the services with them via unicast and let clients do normal unicast > > queries? > _______________________________________________ > 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 Jan 17 12:59:56 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 MAA00056 for ; Fri, 17 Jan 2003 12:59:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0HIFau19313 for ssm-archive@odin.ietf.org; Fri, 17 Jan 2003 13:15:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HIFaJ19310 for ; Fri, 17 Jan 2003 13:15:36 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00036 for ; Fri, 17 Jan 2003 12:59:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HIB1J19022; Fri, 17 Jan 2003 13:11:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HI1tJ17946 for ; Fri, 17 Jan 2003 13:01:55 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29660 for ; Fri, 17 Jan 2003 12:45:43 -0500 (EST) Received: from holbrook-laptop.cisco.com (sjc-vpn2-304.cisco.com [10.21.113.48]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0HHmxFp013308; Fri, 17 Jan 2003 09:48:59 -0800 (PST) Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id 67CD010B7A7; Fri, 17 Jan 2003 01:55:57 -0500 (EST) From: Hugh Holbrook To: Pavlin Radoslavov Cc: holbrook@cisco.com, "Michael Luby" , "Pavlin Radoslavov" , ssm@ietf.org In-reply-to: <200301170434.h0H4Yp2U067291@possum.icir.org> Subject: Re: Re: [ssm] Re: last call comments on ssm-arch doc Reply-To: holbrook@dsg.stanford.edu Message-Id: <20030117065557.67CD010B7A7@holbrook-laptop.cisco.com> Date: Fri, 17 Jan 2003 01:55:57 -0500 (EST) 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: , Great. Thanks for your comments. -Hugh > Cc: "Michael Luby" , > "Pavlin Radoslavov" , ssm@ietf.org > Date: Thu, 16 Jan 2003 20:34:51 -0800 > From: Pavlin Radoslavov > > > I like both your suggestions regarding the building of multi-sender > > apps with SSM. Here's a revision that incorporates your requests; I > > think this is an improvement. > > > > SSM is particularly well-suited to dissemination-style applications > > with a single sender. It can be used to build multi-source > > applications, but the multi-source "rendezvous" functionality does not > > occur in the network layer. Just like in an application that uses > > unicast as the underlying transport, this functionality can be > > implemented by the application or by an application-layer library. > > For instance, an application that desires to provide a secondary data > > source in case the primary source fails over might implement this by > > using one channel for each source and advertising both of them to > > receivers. > > Looks good to me. > > > I'm having more trouble addressing Pavlin's comments regarding what I > > wrote about resource discovery: > > > > > Hence, what about modifying the last sentence to say that resource > > > discovery might be possible, but with the help of additional > > > support, such as application-level relay. > > > > I don't like the specific phrase that you suggest, Pavlin: "with the > > help of additional support, such as application-level relay" because > > it leaves me wondering what other possibilities there might be besides > > application-level relaying, and I can't actually think of any. > > > > So how about if I simply say this: > > > > Peer-to-peer multicast resource discovery of the form in > > which a client sends a multicast query directly to a "service > > location group" to which servers listen is not directly supported > > by SSM > > Fine with me. > > > > > This is true and doesn't rule out other forms of service discovery. > > If the group thinks we need to say more about resource discovery than > > this, then I also wrote this > > > > SSM might play a role in a resource discovery > > service as a mechanism that, for instance, well-known relays can > > use to forward client queries or server advertisements to > > interested recipients. > > I think there is no need to say that, so the "Peer-to-peer..." > paragraph is just fine. > > Thanks, > Pavlin > > > The latter bit of text has the problem for me that I don't actually > > think this is a very good application architecture and I hesitate to > > make the text look like it endorses it as a good use of SSM. Once > > you've got a set of well-known servers, why wouldn't you just register > > the services with them via unicast and let clients do normal unicast > > queries? > _______________________________________________ > 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 ssm-admin@ietf.org Fri Jan 17 13:22:04 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 NAA00852 for ; Fri, 17 Jan 2003 13:22:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HIbLJ20794; Fri, 17 Jan 2003 13:37:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HISsJ19914 for ; Fri, 17 Jan 2003 13:28:54 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00528 for ; Fri, 17 Jan 2003 13:12:41 -0500 (EST) Received: from holbrook-laptop.cisco.com (sjc-vpn2-304.cisco.com [10.21.113.48]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h0HIC50E020826; Fri, 17 Jan 2003 10:12:09 -0800 (PST) Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id 96D1710B7A7; Fri, 17 Jan 2003 13:09:43 -0500 (EST) From: Hugh Holbrook To: holbrook@dsg.stanford.edu Cc: Pavlin Radoslavov , holbrook@cisco.com, "Michael Luby" , "Pavlin Radoslavov" , ssm@ietf.org In-reply-to: <20030117065557.67CD010B7A7@holbrook-laptop.cisco.com> Reply-To: holbrook@cisco.com Message-Id: <20030117180943.96D1710B7A7@holbrook-laptop.cisco.com> Date: Fri, 17 Jan 2003 13:09:43 -0500 (EST) Subject: [ssm] building multi-sender apps with ssm 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: , [Was Re: Re: Re: [ssm] Re: last call comments on ssm-arch doc ] Hopefully these are the last tweaks. Hitoshi pointed out that this sentence of what I wrote > SSM is particularly well-suited to dissemination-style applications > with a single sender. can be interpreted to mean that SSM isn't well-suited to applications with more than one sender. I think he is right and furthermore, I realized that I'm missing a fundamental aspect in this paragraph: The key attribute of an SSM-based application that introduces the need for application-layer rendezvous is not the fact that there are multiple senders but the fact that the senders are not all known in advance, so I ought to say that. Furthermore, my example application of a backup data source is more in the category one of an application with two sources that are known in advance, so I moved it to follow the text that describes that application model. So... this is hopefully my last try on this paragraph. SSM is particularly well-suited to dissemination-style applications with one or more senders whose identities are known before the application begins. For instance, a data dissemination application that desires to provide a secondary data source in case the primary source fails over might implement this by using one channel for each source and advertising both of them to receivers. It can be used to build multi-source applications where all participants' identities are not known in advance, but the multi-source "rendezvous" functionality does not occur in the network layer. Just like in an application that uses unicast as the underlying transport, this functionality can be implemented by the application or by an application-layer library. Peer-to-peer multicast resource discovery of the form in which a client sends a multicast query directly to a "service location group" to which servers listen is not directly supported by SSM -Hugh _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Fri Jan 17 13:25:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00926 for ; Fri, 17 Jan 2003 13:25:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0HIfS821084 for ssm-archive@odin.ietf.org; Fri, 17 Jan 2003 13:41:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HIfSJ21081 for ; Fri, 17 Jan 2003 13:41:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00917 for ; Fri, 17 Jan 2003 13:25:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HIbLJ20794; Fri, 17 Jan 2003 13:37:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HISsJ19914 for ; Fri, 17 Jan 2003 13:28:54 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00528 for ; Fri, 17 Jan 2003 13:12:41 -0500 (EST) Received: from holbrook-laptop.cisco.com (sjc-vpn2-304.cisco.com [10.21.113.48]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h0HIC50E020826; Fri, 17 Jan 2003 10:12:09 -0800 (PST) Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id 96D1710B7A7; Fri, 17 Jan 2003 13:09:43 -0500 (EST) From: Hugh Holbrook To: holbrook@dsg.stanford.edu Cc: Pavlin Radoslavov , holbrook@cisco.com, "Michael Luby" , "Pavlin Radoslavov" , ssm@ietf.org In-reply-to: <20030117065557.67CD010B7A7@holbrook-laptop.cisco.com> Reply-To: holbrook@cisco.com Message-Id: <20030117180943.96D1710B7A7@holbrook-laptop.cisco.com> Date: Fri, 17 Jan 2003 13:09:43 -0500 (EST) Subject: [ssm] building multi-sender apps with ssm 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: , [Was Re: Re: Re: [ssm] Re: last call comments on ssm-arch doc ] Hopefully these are the last tweaks. Hitoshi pointed out that this sentence of what I wrote > SSM is particularly well-suited to dissemination-style applications > with a single sender. can be interpreted to mean that SSM isn't well-suited to applications with more than one sender. I think he is right and furthermore, I realized that I'm missing a fundamental aspect in this paragraph: The key attribute of an SSM-based application that introduces the need for application-layer rendezvous is not the fact that there are multiple senders but the fact that the senders are not all known in advance, so I ought to say that. Furthermore, my example application of a backup data source is more in the category one of an application with two sources that are known in advance, so I moved it to follow the text that describes that application model. So... this is hopefully my last try on this paragraph. SSM is particularly well-suited to dissemination-style applications with one or more senders whose identities are known before the application begins. For instance, a data dissemination application that desires to provide a secondary data source in case the primary source fails over might implement this by using one channel for each source and advertising both of them to receivers. It can be used to build multi-source applications where all participants' identities are not known in advance, but the multi-source "rendezvous" functionality does not occur in the network layer. Just like in an application that uses unicast as the underlying transport, this functionality can be implemented by the application or by an application-layer library. Peer-to-peer multicast resource discovery of the form in which a client sends a multicast query directly to a "service location group" to which servers listen is not directly supported by SSM -Hugh _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-admin@ietf.org Fri Jan 17 14:32: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 OAA02400 for ; Fri, 17 Jan 2003 14:32:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HJlUJ24733; Fri, 17 Jan 2003 14:47:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HJcMJ24354 for ; Fri, 17 Jan 2003 14:38:22 -0500 Received: from possum.icir.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02176 for ; Fri, 17 Jan 2003 14:22:08 -0500 (EST) Received: from possum.icir.org (localhost [127.0.0.1]) by possum.icir.org (8.12.3/8.12.3) with ESMTP id h0HJNm2U075570; Fri, 17 Jan 2003 11:23:48 -0800 (PST) (envelope-from pavlin@possum.icir.org) Message-Id: <200301171923.h0HJNm2U075570@possum.icir.org> To: holbrook@cisco.com cc: holbrook@dsg.stanford.edu, Pavlin Radoslavov , "Michael Luby" , ssm@ietf.org Subject: Re: [ssm] building multi-sender apps with ssm In-Reply-To: Message from Hugh Holbrook of "Fri, 17 Jan 2003 13:09:43 EST." <20030117180943.96D1710B7A7@holbrook-laptop.cisco.com> Date: Fri, 17 Jan 2003 11:23:48 -0800 From: Pavlin Radoslavov 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: , [ Hopefully my last comment :) ] > Peer-to-peer multicast resource discovery of the form in What about removing "Peer-to-peer", because I think it is not really needed here. Further, to me it has some association with application-level multicast, and I guess this is not what you meant here. Pavlin > which a client sends a multicast query directly to a "service > location group" to which servers listen is not directly supported > by SSM _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Fri Jan 17 14:35: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 OAA02510 for ; Fri, 17 Jan 2003 14:35:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0HJpQD24959 for ssm-archive@odin.ietf.org; Fri, 17 Jan 2003 14:51:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HJpQJ24956 for ; Fri, 17 Jan 2003 14:51:26 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02505 for ; Fri, 17 Jan 2003 14:35:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HJlUJ24733; Fri, 17 Jan 2003 14:47:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HJcMJ24354 for ; Fri, 17 Jan 2003 14:38:22 -0500 Received: from possum.icir.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02176 for ; Fri, 17 Jan 2003 14:22:08 -0500 (EST) Received: from possum.icir.org (localhost [127.0.0.1]) by possum.icir.org (8.12.3/8.12.3) with ESMTP id h0HJNm2U075570; Fri, 17 Jan 2003 11:23:48 -0800 (PST) (envelope-from pavlin@possum.icir.org) Message-Id: <200301171923.h0HJNm2U075570@possum.icir.org> To: holbrook@cisco.com cc: holbrook@dsg.stanford.edu, Pavlin Radoslavov , "Michael Luby" , ssm@ietf.org Subject: Re: [ssm] building multi-sender apps with ssm In-Reply-To: Message from Hugh Holbrook of "Fri, 17 Jan 2003 13:09:43 EST." <20030117180943.96D1710B7A7@holbrook-laptop.cisco.com> Date: Fri, 17 Jan 2003 11:23:48 -0800 From: Pavlin Radoslavov 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: , [ Hopefully my last comment :) ] > Peer-to-peer multicast resource discovery of the form in What about removing "Peer-to-peer", because I think it is not really needed here. Further, to me it has some association with application-level multicast, and I guess this is not what you meant here. Pavlin > which a client sends a multicast query directly to a "service > location group" to which servers listen is not directly supported > by SSM _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-admin@ietf.org Fri Jan 17 14:49: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 OAA02927 for ; Fri, 17 Jan 2003 14:49:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HK4fJ25486; Fri, 17 Jan 2003 15:04:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HJtRJ25136 for ; Fri, 17 Jan 2003 14:55:27 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02606 for ; Fri, 17 Jan 2003 14:39:13 -0500 (EST) Received: from holbrook-laptop.cisco.com (sjc-vpn2-304.cisco.com [10.21.113.48]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0HJcWFp001179; Fri, 17 Jan 2003 11:38:37 -0800 (PST) Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id 8AEC310B7A7; Fri, 17 Jan 2003 14:36:12 -0500 (EST) From: Hugh Holbrook To: Pavlin Radoslavov Cc: holbrook@cisco.com, holbrook@dsg.stanford.edu, Pavlin Radoslavov , "Michael Luby" , ssm@ietf.org In-reply-to: <200301171923.h0HJNm2U075570@possum.icir.org> Subject: Re: Re: [ssm] building multi-sender apps with ssm Reply-To: holbrook@cisco.com Message-Id: <20030117193612.8AEC310B7A7@holbrook-laptop.cisco.com> Date: Fri, 17 Jan 2003 14:36:12 -0500 (EST) Sender: ssm-admin@ietf.org Errors-To: ssm-admin@ietf.org X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , I agree. Done. -Hugh > Cc: holbrook@dsg.stanford.edu, Pavlin Radoslavov , > "Michael Luby" , ssm@ietf.org > Date: Fri, 17 Jan 2003 11:23:48 -0800 > From: Pavlin Radoslavov > > > [ Hopefully my last comment :) ] > > > Peer-to-peer multicast resource discovery of the form in > > What about removing "Peer-to-peer", because I think it is not really > needed here. Further, to me it has some association with > application-level multicast, and I guess this is not what you meant > here. > > Pavlin > > > which a client sends a multicast query directly to a "service > > location group" to which servers listen is not directly supported > > by SSM _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From mailnull@www1.ietf.org Fri Jan 17 14:53: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 OAA03005 for ; Fri, 17 Jan 2003 14:53:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0HK8nS26405 for ssm-archive@odin.ietf.org; Fri, 17 Jan 2003 15:08:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HK8nJ26402 for ; Fri, 17 Jan 2003 15:08:49 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03001 for ; Fri, 17 Jan 2003 14:52:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HK4fJ25486; Fri, 17 Jan 2003 15:04:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HJtRJ25136 for ; Fri, 17 Jan 2003 14:55:27 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02606 for ; Fri, 17 Jan 2003 14:39:13 -0500 (EST) Received: from holbrook-laptop.cisco.com (sjc-vpn2-304.cisco.com [10.21.113.48]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0HJcWFp001179; Fri, 17 Jan 2003 11:38:37 -0800 (PST) Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id 8AEC310B7A7; Fri, 17 Jan 2003 14:36:12 -0500 (EST) From: Hugh Holbrook To: Pavlin Radoslavov Cc: holbrook@cisco.com, holbrook@dsg.stanford.edu, Pavlin Radoslavov , "Michael Luby" , ssm@ietf.org In-reply-to: <200301171923.h0HJNm2U075570@possum.icir.org> Subject: Re: Re: [ssm] building multi-sender apps with ssm Reply-To: holbrook@cisco.com Message-Id: <20030117193612.8AEC310B7A7@holbrook-laptop.cisco.com> Date: Fri, 17 Jan 2003 14:36:12 -0500 (EST) Sender: ssm-admin@ietf.org Errors-To: ssm-admin@ietf.org X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Source-Specific Multicast List-Post: List-Help: List-Subscribe: , I agree. Done. -Hugh > Cc: holbrook@dsg.stanford.edu, Pavlin Radoslavov , > "Michael Luby" , ssm@ietf.org > Date: Fri, 17 Jan 2003 11:23:48 -0800 > From: Pavlin Radoslavov > > > [ Hopefully my last comment :) ] > > > Peer-to-peer multicast resource discovery of the form in > > What about removing "Peer-to-peer", because I think it is not really > needed here. Further, to me it has some association with > application-level multicast, and I guess this is not what you meant > here. > > Pavlin > > > which a client sends a multicast query directly to a "service > > location group" to which servers listen is not directly supported > > by SSM _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm