Re: [ssm] SSM with IPSec

[Brian Haberman <[e-mail]>]

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 [e-mail] 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/ssm