Re: [ssm] SSM with IPSec

Brian Haberman <bkhabs@nc.rr.com> Wed, 15 January 2003 13:07 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 IAA24863 for <ssm-archive@lists.ietf.org>; 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 <ssm@optimus.ietf.org>; 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 <ssm@ietf.org>; 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 <bkhabs@nc.rr.com>
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: <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>
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 <IPDA,SPI> 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