Re: Re: Re: [ssm] SSM with IPSec
Mark Baugher <mbaugher@cisco.com> Wed, 15 January 2003 21:02 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 QAA09922 for <ssm-archive@lists.ietf.org>; 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 <ssm@optimus.ietf.org>; 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 <ssm@ietf.org>; 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 <mbaugher@cisco.com>
Subject: Re: Re: Re: [ssm] SSM with IPSec
Cc: Toerless Eckert <eckert@cisco.com>, Hugh Holbrook <holbrook@cisco.com>, Brad Huntting <huntting@glarp.com>, ssm@ietf.org, Brian Weis <bew@cisco.com>
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: <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>
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 <eckert@cisco.com> > > Cc: Brad Huntting <huntting@glarp.com>, 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
- [ssm] SSM with IPSec Hugh Holbrook
- Re: [ssm] SSM with IPSec Brian Haberman
- Re: [ssm] SSM with IPSec Brad Huntting
- Re: Re: [ssm] SSM with IPSec Hugh Holbrook
- Re: [ssm] SSM with IPSec Mark Baugher
- Re: Re: [ssm] SSM with IPSec Toerless Eckert
- Re: Re: Re: [ssm] SSM with IPSec Hugh Holbrook
- Re: Re: Re: [ssm] SSM with IPSec Mark Baugher
- Re: Re: Re: [ssm] SSM with IPSec Toerless Eckert
- Re: Re: Re: [ssm] SSM with IPSec Mark Baugher
- Re: Re: Re: [ssm] SSM with IPSec Toerless Eckert