Re: Proposed text changes to ESPbis and AHbis for multicastsupport

[Stephen Kent <kent@bbn.com>]

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.

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.

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. 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?

  	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, 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.

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.

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.

>---------------------------------------------------------------------
>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, 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.


>---------------------------------------------------------------------
>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.

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.

Steve