Re: new version of ESP ID

[Mark Baugher <mbaugher@cisco.com>]

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


>Steve