[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Proposed text changes to ESPbis and AHbis for multicast support
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.
---------------------------------------------------------------------