Re: [ssm] SSM with IPSec

Mark Baugher <> Wed, 15 January 2003 17:04 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id MAA03331 for <>; Wed, 15 Jan 2003 12:04:03 -0500 (EST)
Received: from (localhost.localdomain []) by (8.11.6/8.11.6) with ESMTP id h0FHIWJ26693; Wed, 15 Jan 2003 12:18:32 -0500
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id h0FGjTJ24030 for <>; Wed, 15 Jan 2003 11:45:29 -0500
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id LAA02368 for <>; Wed, 15 Jan 2003 11:30:17 -0500 (EST)
Received: from ([]) by (8.12.2/8.12.2) with ESMTP id h0FGX0jT014708; Wed, 15 Jan 2003 08:33:00 -0800 (PST)
Message-Id: <>
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:,, Brian Weis <>
In-Reply-To: <>
References: <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
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:
>      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.


>Hugh Holbrook wrote:
>>Hello, SSM working group.
>>[ Welcome to the brand spanking new 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 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
>>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
>>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