Subject: [MSEC] Re: new version of ESP ID

From: Mark Baugher <[email-masked]>
Date: Wed, 10 Jul 2002 09:51:28 -0700

At 09:59 AM 7/9/2002 -0700, Bill Fenner wrote:

> >First, section 2.2 deprecates sharing an SA among multiple senders to a
> >multicast group and in effect mandates single-sender multicast for ESP
> >groups.  The same is true for AH.  I'm aware of only one protocol, the VRRP
> >specification, that is affected by this change.  VRRP uses AH or ESP but
> >allows multi-source multicast groups.  We should notify the VRRP WG of this
> >potential change.
>
>I brought this up at the WG meeting in Minneapolis.  Several protocols
>that send multicasts on a LAN use this model (VRRP, OSPFv3, PIM,
>IGMP come to mind).

Yes, of course, though a number of people think that IGMP security is
needless (and voiced that in the last gsec meeting).  You made an
important point in your previous note about SSM and the usefulness
of the source address to identifying the multicast SA.

>I'd like to see two possible modes for use with multicast:
>- anti-replay sequence number per sender, with a shared SA.
>- including the source address when demultiplexing to permit SSM semantics.
>
>I know that at least the first is completely opposite of the direction
>that the group has been going.  However, especially with 64-bit anti-replay
>sequence numbers, it permits protocols to use a standard, existing protocol
>even when using static shared SAs.  Yes, a static shared SA buys you much
>less protection than dynamically negotiated ones, but does that mean that it
>should be ruled out?

I don't understand the distinction between static and dynamic SAs.
Is the distinction between a single-sender multicast SA versus
a multi-sender multicast SA?

I think that it is a more robust solution to identify the multicast
SA using the source address as well as the SPI and destination
address.  This is what many of us who worked in smug thought we
would do with MESP.  Now that Steve is addressing multicast in
ESP and AH, it's not clear to me how msec should proceed with
MESP.

Mark

>   Bill

_______________________________________________
msec mailing list
[email-masked]
http://www.pairlist.net/mailman/listinfo/msec

---

From: Mark Baugher <[email-masked]>
Date: Sat, 20 Jul 2002 07:38:10 -0700

Steve,

At 05:54 PM 7/12/2002 -0400, Stephen Kent wrote:
>Mark,
>There is a big distinction between single and multi-sender SAs, as we have 
>discussed. One cannot make use of anti-replay for a multi-sender SA, 
>unless we seriously change the model and I explained in my message to Bill 
>why I don't think that's a reasonable change to pursue.

I think I understand your rationale.  We should at least document the fact 
that it may be necessary to identify the multicast ESP SA using the triple 
<source, destination, SPI> for source-specific multicast - for some 
applications.  I think Bill and Radia's previous comments to this thread 
explain why.  If all sources to a multicast address use the same group key 
controller, then I don't see a problem.  If some sources to a multicast 
address use distinct group key controllers (e.g., each source acts as its 
own controller), then there is the potential for SPI collisions and means 
must be invented to handle these collisions.

Mark

>I am opposed to the suggestion to use both source and destination address 
>for demuxing multicast SAs, as it just adds to the comparisons that need 
>to me made. As more folks go to high speed hardware implementations, using 
>more fields for demuxing turns into more CAM entries, ...  Why can't we 
>swap destination address demuxing for source address demuxing for multicast?
>
>Steve

---

From: Mark Baugher <[email-masked]>
Date: Mon, 29 Jul 2002 08:35:22 -0700

Steve,

At 12:47 AM 7/24/2002 -0400, Stephen Kent wrote:

<...>

>>I think I understand your rationale.  We should at least document the 
>>fact that it may be necessary to identify the multicast ESP SA using the 
>>triple <source, destination, SPI> for source-specific multicast - for 
>>some applications.  I think Bill and Radia's previous comments to this 
>>thread explain why.  If all sources to a multicast address use the same 
>>group key controller, then I don't see a problem.  If some sources to a 
>>multicast address use distinct group key controllers (e.g., each source 
>>acts as its own controller), then there is the potential for SPI 
>>collisions and means must be invented to handle these collisions.
>>
>>Mark
>
>Mark,
>
>I don't feel that we have a good enough answers to proceed, yet. We cannot 
>proceed on the basis of "may be necessary." What we need is a concise 
>description of what is required for multicast traffic demuxing, based on 
>extant protocol standards, including how SPIs will be assigned in the 
>context of these protocols.

My reading of the new AH and ESP I-Ds is that they both support a multicast 
SA from a single sender to a multicast group address.  Even this level of 
security has the important limitation that every member of the secure group 
has the key that is used for authenticating IPsec packets and a rogue 
member might use that key to impersonate a sender.

Is this security in the new I-Ds useful?  It would work for the one 
commercial multicast service I am familiar with that was offered by an 
international network service provider a few years back; this service 
allowed hosts to receive multicast but not send to a multicast address - 
there was only one sender.  I am also aware of a couple of companies that 
enabled multicast on their campuses for briefings and trainings.  I talked 
to more than a couple of companies who wanted only a single sender to a 
multicast address and wanted to configure their networks so hosts other 
than the single sender could not send.  This desire did not come from any 
security awareness but to mitigate unauthorized, high-volume traffic on 
their networks.

Will the new I-Ds support multicast in general?  Extant standards support 
what might be called "any source multicast" so the restriction of not 
allowing multiple senders to a secure group means that IGMPv2 host 
semantics are not supported.  If we identified a multicast IPsec SA with 
the source address, network address, and SPI, then we could assign an IPsec 
SA to an (S,G) without assuming that there is some central device 
allocating SPIs.  This would support both IGMPv2 and IGMPv3 in my 
opinion.  We still lack packet authentication unless all group members are 
trusted not to impersonate a source.  VRRP, some routing protocols, and 
other applications assume that kind of trust.  But at least some of these 
protocols (e.g. VRRP) have multiple S's sending to a single G. (the scheme 
in the new AH and ESP I-Ds could still work if we assume a central entity 
managing SPIs).

What about using (G, SPI) and have a central entity manage SPI for G? There 
is no reason why a particular host S that sends to a group G cannot manage 
keys for (S,G).  In this case, S would allocate the SPI.  A large scale 
service, however, such as a Fortune 500 company that sends multicast 
training and briefing content to campuses and field offices, would likely 
operate a network operations center and use a specialized key server to 
allocate keys and SPI.  Both scenaria are valid.  But in general, (G, SPI) 
does not support Si and Sj managing keys for their own traffic.

>Implementors cannot reasonably deal with the current level of vague 
>characterization of requirements floating around in this discussion. for 
>example, if there are two group key controllers for a multicast session, 
>and each assigns SPis independently to subscribers (and thus the collision 
>potential), which SPI will a sender put in an outbound packet to ensure 
>that all recipients will recognize it?

One way to do it: sender Sj sends SPIj when there is an SA in place for 
<Sj, G, SPIj> at members of Sj, G.  We can get this capability by including 
Sj to identify the IPsec multicast SA.  This of course does not mean that a 
single SA services all senders to the particular multicast address; for 
that you would need to have a replay table.  I think Bill asked for 
supporting (*, G) in addition to (S, G), but the former means that an IPsec 
host would need to support a replay list for every potential 
sender.  Rather than do that, there can be an SA for each source.  The new 
AH and ESP I-Ds accomplish this by limiting G to have one sender.  I would 
not do it that way.

I don't see any of this as urgent for IPsec because the new I-Ds still do 
not address a fundamental problem:  Packet source authentication.  I expect 
that this problem is in MSEC's realm.  As I see it, you are addressing a 
subset of the requirements, which would be suitable for some environments, 
but which does not support nascent multicast standards such as IGMPv3.  Nor 
does it support extant standards such as IGMPv2.  Neither are securable in 
general anyway without multicast packet source authentication or some 
restriction on who can send.

Mark