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