Subject: [MSEC] Proposed text changes to ESPbis and AHbis for multicast support

From: Thomas Hardjono <[email-masked]>
Date: Mon, 23 Dec 2002 16:11:34 -0500

The MSEC working group has a number of proposed changes to the text of
ESPbis (draft-ietf-ipsec-esp-v3-03.txt) and  AHbis 
(draft-ietf-ipsec-rfc2402bis-01.txt)

These proposed changes and its implications to the usability of IPsec in 
multicast have been rationalized in the following draft:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-msec-ipsec-multicast-issues-01.txt

The draft explains at length the motivations, though below is a list of the 
suggested changes.

We would like to see some discussion on the IPsec mailing-list regarding
these proposed changes.

Regards,

Thomas/Ran
----------

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

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

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

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

---------------------------------------------------------------------
AHbis-change#1: SPI allocation and SA lookup

Section 2.4 (Security Parameters Index) specifies exactly how the
SPI should be dealt with. It is identical to [ESPbis] wording:

       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) [AHbis].

As in the case with [ESPbis], we propose this section to be replaced
with the following wording:

       For broadcast, multicast, and anycast SAs, the SPI and protocol
       ID (AH) 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.

---------------------------------------------------------------------
AHbis-change#2: (appended text)

Section 3.4.2 (Security Association Lookup) of [AHbis] also needs to
be modified to reflect these semantics. It currently states:

       Upon receipt of a packet containing an IP Authentication Header,
       the receiver determines the appropriate (unidirectional) SA,
       based on the destination IP address, security protocol (AH), and
       the SPI [AHbis].

No change to this text is necessary. We propose that the following
text be appended to it.

       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 AH
       packets for a group if that is known a priori.

---------------------------------------------------------------------
AHbis-change#3: Multiple sender SAs and replay protection

Same as ESPbis-change#3  above.

---------------------------------------------------------------------

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

---

From: Mark Baugher <[email-masked]>
Date: Wed, 25 Dec 2002 00:41:23 -0800

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

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

>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