[ssm] SSM with IPSec

[Hugh Holbrook <[e-mail]>]

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.

Cheers,

-Hugh
_______________________________________________
Ssm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ssm