[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposed text changes to ESPbis and AHbis for multicast support
Steve,
At 04:06 PM 12/24/2002 -0500, Stephen Kent wrote:
>Thomas,
>
>I have read the message and your ID on multicast and IPsec. Here are my
>comments:
>
>>---------------------------------------------------------------------
>>ESPbis-change#1: SPI allocation and SA lookup
>>
>>Section 2.1 (Security Parameters Index) specifies exactly how the
>>SPI should be dealt with:
>>
>> For multicast SAs, the SPI (and optionally the protocol ID) in
>> combination with the destination address is used to select an SA.
>> This is because multicast SAs are defined by a multicast
>> controller, not by each IPsec receiver. (See the Security
>> Architecture document for more details) [ESPbis].
>>
>>We propose this section to be replaced with the following wording:
>>
>> For broadcast, multicast, and anycast SAs, the SPI and protocol
>> ID (ESP) in combination with the destination address is used to
>> select an SA. In some cases, other parameters (such as a source
>> address) MAY be used by a receiver to further identify the
>> correct SA. This is because multicast SAs may be defined by more
>> than one multicast group controller.
>
>The text above does not provide a useful, testable specification. It
>allows (MAY) a receiver to use a source address and other, undefined
>parameters for SA selection, but does not require it. The result is that a
>complaint IPsec implementation need not do any of this, which makes for a
>weak standard and does nothing for interoperability. We need concrete
>specs for developers and this does not provide such specs. It has the
>feature of allowing a future implementation to able to claim compliance
>with the spec when someone figures out exactly what to do for
>multicast/broadcast/anycast, but this does nothing for interoperabilty,
>which is a primary goal of RFCs.
I agree and think think that the source address, and only the source
address, should be a MUST.
>At a minimum I think you need to be able to create text of the form "An
>IPsec implementation that supports multicast, broadcast, or anycast MUST
>..." in order for this to be useful. I get the sense, from the ID you just
>published, that the MSEC WG has not yet decided exactly what requirements
>need to be imposed and exactly how to deal with these issues, and thus it
>seems premature to write the sort of text I suggest is really required.
Inclusion of the source address in SA lookup was recommended by IRTF SMuG
years ago and nothing has changed in MSEC since that time.
>Your ID erroneously states that the revised AH and ESP IDs change the
>semantics of SA demuxing and make the lookups "less specific." The changes
>we made in the new AH & ESP drafts re what parameters define an SA and
>thus are used to demux incoming IPsec packets, are clarifications designed
>to reflect what many developers already knew and practiced in their
>implementations. The original text over-specified SA demuxing, imposing
>parameters (destination address and protocol) that were irrelevant for
>unicast SA demuxin. As a result, smart developers realized that they could
>manage the SPI space in a way that never made use of these values and they
>did so. The changes you suggest for multicast SA demuxing here, i.e., use
>of the source address, were NOT supported in the current AH and ESP RFCs
>not in 2401 and so the clarifications made in the revised AH and ESP specs
>did not adversely affect what you suggest might need to done to better
>support multicast SAs.
>
>Your ID cites two issues re what parameters are used to uniquely identify
>(demux) an SA, but seems to confuse the implications of these two issues,
>and the text above seems to reflect this confusion.
>
> Your ID says that an SSM group is defined by a single sender and
> a set of receivers. it may use the same multicast address as another,
> distinct SSM group, presumably with a different sender but perhaps an
> overlapping set of receivers. Hence you infer that using the destination
> (multicast) address and an SPI is not sufficient to uniquely identify
> (for receivers) an SA for this type of multicast group, because the
> senders do not coordinate with one another.
This is primarily a group controller issue and not a sender issue as
described in section 2.1 of the I-D.
>It would seem for this case that use of the sender address plus the
>multicast destination address provides a natural means of identifying the
>SA, but the ID does not discuss any other options that have been explored
>and rejected. For example, what sort of interactions do the sender and
>receivers engage in to create this sort of group, how is the key
>distributed, and might there be a way to use data from those interactions
>to create an SPI that would allow demuxing using the parameters currently
>defined?
I think the I-D states what it needs to: A group controller maintains the
key for the group and the members (senders and receivers) interact with the
group controller to establish the group key. A single multicast group can
support multiple SSM groups, each can be in a separate administrative
domain with a separate group controller.
> Separately, the ID discusses the notion that multiple controllers
> might be involved inn managing a multicast group (presumably not an SSM
> group) and that these controllers might not be able to coordinate to
> select a unique SPI (relative to a single multicast address). But if
> these controllers coordinate to distribute the single key used for
> encrypting/decrypting traffic on a multicast SA,
These controllers need not and do not coordinate to do anything. No such
protocol exists to my knowledge, at least not in the public domain.
>why are they unable to coordinate on assigning a single SPI for a
>multicast SA? Thus this latter argument for having to use some parameter
>other than the destination address and SPI for SA demuxing is not persuasive.
Maybe the I-D is not clear enough. There can be N SSM groups for an IP
multicast group and there can be as many as N group controllers operating
independently.
>I think a better analysis is required here before we impose new/additional
>constraints on SA demuxing in IPsec.
>
>>---------------------------------------------------------------------
>>ESPbis-change#2: SPI allocation and SA lookup
>>
>>Section 3.4.2 (Security Association Lookup) of [ESPbis] currently states:
>>
>> Upon receipt of a packet containing an ESP Header, the receiver
>> determines the appropriate (unidirectional) SA, based on the SPI
>> alone (unicast) or SPI combined with destination IP address
>> (multicast). (This process is described in more detail in the
>> Security Architecture document) [ESPbis].
>>
>>We propose this text be replaced as follows.
>>
>> Upon receipt of a unicast packet containing an ESP Header, the
>> receiver determines the appropriate (unidirectional) SA, based on
>> the SPI alone. (This process is described in more detail in the
>> Security Architecture document.)
>>
>> If the packet is a broadcast, multicast, or anycast packet, there
>> may be more than one SA pointed to by the combination of SPI,
>> security protocol and destination address. This can happen if
>> multiple non-cooperating multicast controllers are present in the
>> network. In this case the receiver MAY use other parameters (such
>> as a source address) to identify the correct SA. Key management
>> MAY indicate (e.g., with an SA attribute) that such processing is
>> necessary in order for a receiver to properly process the ESP
>> packets for a group if that is known a priori.
>
>The second paragraph begins by redefining what an SA is, and that's not a
>great start considering how long we have had a stable definition for an SA.
It's a matter of SA lookup. The second paragraph wants to redefine SA
lookup, which is the point of the I-D.
>Here too, the the lack of specific, testable requirements here makes for a
>poor spec. We want to ensure interoperability and MAYs don't cut it. This
>is essentially a placeholder that allows a later design to say it is
>compliant, but which does not contribute to interoperability. I don't
>think this is a good path for IPsec RFCs. If we cannot specify exactly
>what values are used by a receiver to identify traffic as belonging to a
>specific SA, then a developer cannot produce code or hardware that will
>perform the selection. Deferring this to the key management protocol is
>not a solution, it is just a level of indirection.
This is the same issue as above because the text was copied.
>>---------------------------------------------------------------------
>>ESPbis-change#3: Multiple sender SAs and replay protection
>>
>>
>>Section 2.2 (Sequence Number) states:
>>
>> Sharing an SA among multiple senders is deprecated, since there
>> is no general means of synchronizing packet counters among the
>> senders or meaningfully managing a receiver packet counter and
>> window in the context of multiple senders [ESPbis].
>>
>>
>>We propose the following replacement for the above text in [ESPbis].
>>
>> For a multi-sender multicast SA, the anti-replay service MUST NOT
>> be used unless key management signals its use. If the anti-replay
>> service is used in this case, each receiver must keep a replay
>> window per sender.
>
>I agree in principle with the intent of this notion, but the sticking
>point is that we have not yet agreed on a way to accommodate this
>requirement. Your ID states that requiring an SA per sender is unacceptable,
Where does it state that?
>and alludes to some scenario that motivates this statement, but provide no
>details to support the assertion. The text above has the flavor of a
>placeholder, rather than a useful spec to guide developers in producing
>interoperable implementations. The text imposes a vague requirement
>without any supporting analysis of the problems imposed by the requirement.
The requirement was stated in a note posted by Bill Fenner to this list
last Spring. The replacement text allows multi-sender SAs, it's clear that
this is a change from ESPbis, and designates key management as the entity
that determines whether or not a replay window is kept in the receiver.
>>---------------------------------------------------------------------
>>ESPbis-change#4: Integrity vs. Authentication
>>
>>The name associated with the authentication portion of ESP is
>>"Authentication Data". However, [ESPbis] changed the name to
>>"Integrity Check Value".
>>
>>Section 1 says:
>>
>> Data origin authentication and connectionless integrity are joint
>> services, hereafter referred to jointly as "integrity." (This
>> term is employed because, on a per-packet basis, the computation
>> being performed provides connectionless integrity directly; data
>> origin authentication is provided indirectly as a result of
>> binding the key used to verify the integrity to the identity of
>> the IPsec peer [ESPbis].
>>
>>We propose the following wording changes to [ESPbis].
>>
>> 1. The text quoted above from Section 1 should be replaced with:
>>
>> Data origin authentication and connectionless integrity are joint
>> services, hereafter referred to jointly as "authentication."
>>
>> 2. All occurrences of "Integrity-only ESP" should be
>> "Authentication-only ESP".
>>
>> 3. The "Integrity Check Value" field in AH should be named
>> "Authentication Data", and all references to that section should
>> be updated.
>
>We changed the term for good reasons. First, the ICV acronym expands to
>"Integrity Check Value" and it has been there since before the previous
>set of RFCs. Second, the function really does provide
>integrity. Authentication is a side effect that results from knowing the
>identity of the holder of the key used to generate the ICV, as noted above.
It's not suitable for multicast source authentication. I think this is
explained adequately in section 3.3 of the I-D.
>Overall, I found that the ID did not provide adequate motivation for most
>of the proposed changes, and I recommend that none of the proposed changes
>be made at this time. The text needs to be changed so that is
>sufficiently detailed to promote the development of interoperable
>implementations, something that it does not do as it stands. If such text
>is provided, then the IPsec WG needs to review any new requirements for
>multicast/broadcast/anycast support, to ensure that they do not impose
>unacceptable burdens, e.g., re support of anti-replay for multi-sender
>SAs. The IPsec WG chairs need to determine if they wish to delay the
>revisions to AH and ESP until both of these criteria are satisfied.
I hope you'll work with us to address the issues that you have identified.
Mark
>Steve