[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposed text changes to ESPbis and AHbis for multicastsupport
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