Re: Re: Re: [ssm] SSM with IPSec

Mark Baugher <mbaugher@cisco.com> Wed, 15 January 2003 22:32 UTC

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 <ssm-archive@lists.ietf.org>; 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 <ssm@optimus.ietf.org>; 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 <ssm@ietf.org>; 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 <eckert@cisco.com>
From: Mark Baugher <mbaugher@cisco.com>
Subject: Re: Re: Re: [ssm] SSM with IPSec
Cc: holbrook@cisco.com, Toerless Eckert <eckert@cisco.com>, Brad Huntting <huntting@glarp.com>, ssm@ietf.org, Brian Weis <bew@cisco.com>
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: <https://www1.ietf.org/mailman/listinfo/ssm>, <mailto:ssm-request@ietf.org?subject=unsubscribe>
List-Id: Source-Specific Multicast <ssm.ietf.org>
List-Post: <mailto:ssm@ietf.org>
List-Help: <mailto:ssm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ssm>, <mailto:ssm-request@ietf.org?subject=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