Re: [ssm] SSM with IPSec

[Mark Baugher <mbaugher@cisco.com>]

At 08:03 AM 1/15/2003 -0500, Brian Haberman wrote:
>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.

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.

Mark


>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