Subject: [ssm] SSM with IPSec

From: Hugh Holbrook <[email-masked]>
Date: Wed, 15 Jan 2003 01:25:34 -0500 (EST)

Hello, SSM working group.

[ Welcome to the brand spanking new [email-masked] 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ssm

---

From: Brian Haberman <[email-masked]>
Date: Wed, 15 Jan 2003 08:03:33 -0500

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

---

From: Brian Haberman <[email-masked]>
Date: Wed, 15 Jan 2003 08:03:33 -0500

Hugh,

Brian

---

From: Brad Huntting <[email-masked]>
Date: Wed, 15 Jan 2003 08:57:05 -0700

> working group is looking at solving the problem this way.

What if the destination address is not in the SSM range?  For
example: A host wishes to receive NTP (network time protocol)
multicast traffic (destination address 224.0.1.1) from three specific
hosts that it trusts (whether PIM-SSM can honor this request
efficiently is, I think, a separate issue).  I assume there is no
global group `owner' for this well known address 224.0.1.1, so the
SA for this traffic would, I suspect, need to be indexed by source
and destination just like SSM.

One could easily imagine similar situations for other group addresses.
However, as you pointed out, it's probably not necessary that the
SSM group solve this problem; at least not right away.

brad
ssm mailing list
[email-masked]

---

From: Brad Huntting <[email-masked]>
Date: Wed, 15 Jan 2003 08:57:05 -0700

brad

---

From: Hugh Holbrook <[email-masked]>
Date: Wed, 15 Jan 2003 11:48:22 -0500 (EST)

I agree with you, and I didn't mean to imply that this was an SSM-only
problem.  NTP is a good example of an ASM app that has the same
problem.  The fact that this problem occurs with ASM is a complicating
factor in determining the right solution (which is a major reason that
I don't want to tackle it in SSM).

I think it would be relatively easy to specify IPSec modifications to
fix the SSM problem.  But to solve the ASM problem you have to do
source-based SAD lookups in some cases for ASM addresses.  There are
some design choices to consider in how to specify the SAD lookups and
some and backwards compatibility issues that need to be worked out to
solve the ASM problem, or so I am told.

Given that the tricky issues arise mostly from ASM and that msec has
the ipsec expertise and the charter, I think it makes sense to solve
this in msec rather than in ssm.  Sounds like you agree with that
anyway..

I'll find out where msec is at in terms of solving this problem and
report back.

-Hugh

> Cc: [email-masked], [email-masked], [email-masked]
> Date: Wed, 15 Jan 2003 08:57:05 -0700
> From: Brad Huntting <[email-masked]>
> 
>

---

From: Hugh Holbrook <[email-masked]>
Date: Wed, 15 Jan 2003 11:48:22 -0500 (EST)

-Hugh

---

From: Mark Baugher <[email-masked]>
Date: Wed, 15 Jan 2003 08:33:35 -0800

>with the details of SSM if needed.  I am willing to help them

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

---

From: Mark Baugher <[email-masked]>
Date: Wed, 15 Jan 2003 08:33:35 -0800

Mark

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 15 Jan 2003 09:11:37 -0800

> I don't want to tackle it in SSM).

I don't yet understand the details of the key management yet, but
correct me if i'm wrong: Wouldn't a solution with channel-only
support (eg: SSM only) be able to be much easier than one that
needs to support a multi-source group concept ? Given that simplicity
is one key argument for SSM, it would be good if the security solution
in support of SSM was not necessarily encumbered by additional
complexity only required for ASM. Eg: probably have two approaches,
one that will only work with SSM and one which will work for ASM
but of course also SSM.

Wrong line of thought ?

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 15 Jan 2003 09:11:37 -0800

Wrong line of thought ?

---

From: Hugh Holbrook <[email-masked]>
Date: Wed, 15 Jan 2003 12:43:22 -0500 (EST)

I'm not sure.

I think it will be somewhat easier but I suspect not "much easier" to
do an SSM-only solution.  But I don't know and I'm waiting to see the
msec proposal.  I do think it would be prudent to take your points
under consideration when looking at the msec proposal, though.

-Hugh

> Date: Wed, 15 Jan 2003 09:11:37 -0800
> From: Toerless Eckert <[email-masked]>
> Cc: Brad Huntting <[email-masked]>, [email-masked],
> 	[email-masked], [email-masked]
>

---

From: Hugh Holbrook <[email-masked]>
Date: Wed, 15 Jan 2003 12:43:22 -0500 (EST)

I'm not sure.

-Hugh

---

From: Mark Baugher <[email-masked]>
Date: Wed, 15 Jan 2003 12:57:24 -0800

I started from Toerless' position and wanted to focus only on SSM for using 
the source address for looking up a security association.  But how does an 
IPsec implementation identify that an incoming packet is SSM?  I thought we 
could rely on a 232/8 address and its corollary in IPv6.  But that's not 
the case since some 232/8 addresses could be ASM and some SSM channels 
could use addresses outside the 232/8 range.  This means that something 
needs to signal to IPsec that an SA is an SSM SA, and that's probably going 
to be key management.  by implication, key mgt thus also signals when an SA 
is ASM (i.e. NOT SSM).

Many applications, moreover, don't want just SSM because it has one SA per 
sender.  Nice for replay protection but bad when there are many 
senders.  So we (Thomas, Brian, Ran and me) are working up a proposal that 
encompasses both.  One complication is that in some cases an IPsec host 
does a 4-tuple (source addr, dest addr, protocol, spi) lookup and sometimes 
3 (source address is a wildcard).  Another complication is in having a 
replay window for ASM when there are multiple senders that are not known 
when the SA is established; thus, replay windows need to be brought up on 
the fly.

Mark

---

From: Mark Baugher <[email-masked]>
Date: Wed, 15 Jan 2003 12:57:24 -0800

Mark

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 15 Jan 2003 14:08:17 -0800

Ok, thanks for the insight. One issue is still that the solution
needs to support the two cases:

   - independent security associations for (S1,G) and (S2,G) if
     G is an SSM group, because (S1,G) and (S2,G) don't necessarily
     have a connection.
   - same security association for (S1,G) and (S2,G) if G is an ASM
     group.

Now how to determine what kind of security association is needed, 
i don't know. Probably it would be a good thing if that could be determined
somewhat application specific, but not necessarily requiring the IPsec
framework to know the distinction between ASM/SSM.

Cheers
	Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 15 Jan 2003 14:08:17 -0800

Cheers
	Toerless

---

From: Mark Baugher <[email-masked]>
Date: Wed, 15 Jan 2003 14:28:20 -0800

Toerless,

>framework to know the distinction between ASM/SSM.

When the security association is pushed down to the member by key 
management, there will need to be a flag that declares whether it is 
indexed with the source address (SSM) or not (ASM), i.e. whether multiple 
sources will share that SA.  We might be able to leave it at this level 
without explicitly declaring it to be ASM or SSM to IPsec.  In fact, this 
would allow ASM groups to be indexed by source address (a separate SA for 
each sender) or SSM to not be indexed by source address (one SA for 
multiple channels).  Whether this makes sense or not is a matter of policy 
that is implemented in the key server.

Mark

---

From: Mark Baugher <[email-masked]>
Date: Wed, 15 Jan 2003 14:28:20 -0800

Toerless,

Mark

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 15 Jan 2003 19:08:04 -0800

> that is implemented in the key server.

Right, that sounds good.

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 15 Jan 2003 19:08:04 -0800

Right, that sounds good.