One document matched: draft-ietf-msec-ipsec-multicast-issues-01.txt
Differences from draft-ietf-msec-ipsec-multicast-issues-00.txt
Internet Engineering Task Force Mark Baugher(Cisco)
INTERNET-DRAFT Ran Canetti (IBM)
draft-ietf-msec-ipsec-multicast-issues-01.txt Thomas Hardjono (Verisign)
Expires: June, 2003 Brian Weis (Cisco)
December, 2002
IP Multicast issues with IPsec
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working groups.
Note that other groups may also distribute working documents as
Internet Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
The IPsec Architecture [RFC2401] and IPsec transform RFCs [RFC2402,
RFC2406] define certain mechanisms for IP multicast traffic. The
recent revisions to each of the protocol documents [ESPbis, AHbis]
propose changes to those semantics. However, neither the existing
nor proposed semantics are sufficiently general such that IPsec can
be used to protect the wide variety of IPv4 and IPv6 multicast
applications that are expected by the IP multicast community. In
particular, they are not compatible with the needs of the protocols
developed in the MSEC WG and for Source Specific Multicast [RFC3376,
SSM-ARCH]. This document reviews these semantics and proposes some
minor changes, which would enable IPsec to be suitable for these
uses.
Baugher, et. al. Expires June, 2003 1
IP Multicast issues with IPsec December, 2002
Table of Contents
1.0 Introduction......................................................2
1.1 Addressing Scope................................................3
1.2 Key Words.......................................................3
2.0 General Issues....................................................3
2.1 SPI allocation and SA lookup....................................4
2.2 Multiple sender SAs and replay protection.......................5
2.3 Integrity vs. Authentication....................................5
3.0 Proposed Changes to ESPbis........................................5
3.1 SPI allocation and SA lookup....................................5
3.2 Multiple sender SAs and replay protection.......................6
3.3 Integrity vs. Authentication....................................7
4.0 Proposed Changes to AHbis.........................................8
4.1 SPI allocation and SA lookup....................................8
4.2 Multiple sender SAs and replay protection.......................8
4.3 Integrity vs. Authentication....................................9
5.0 Conclusion........................................................9
6.0 Security Considerations...........................................9
7.0 References........................................................9
7.1 Normative References............................................9
7.2 Informative References..........................................9
Authors Addresses....................................................10
1.0 Introduction
At the time RFCs 2401/2402/2406 were written, use of IPsec for
multicast was for the most part not deployed. However the authors of
those RFCs and the IPsec Working Group had the vision that IPsec
would someday be just as useful for IP multicast as IP unicast. At
that time there were a number of unsolved problems, and those are
candidly listed in RFC 2401.
However, because so little attention had been focused on using IPsec
to protect multicast traffic, and because new methods of IP
multicast have been invented since that time, it is only natural
that what is currently documented in those RFCs do not handle all of
the current IP multicast needs. We are thus faced with a situation
where the current specification of IPSec is inconsistent with the
secure multicast standard that is being developed in the MSEC WG.
Consequently, the IPSEC and MSEC working groups now have to make a
decision to take one of the following to standardization paths:
A. Decide that ESP/AH should not be modified for the purpose of
accommodating the needs of MSEC. In this case, MSEC will define
its own version of ESP [MESP]. MESP will be similar to ESP, but
will be incompatible with ESP in several ways. In particular,
MESP will use a different protocol number than that of ESP.
Baugher, et. al. Expires June, 2003 2
IP Multicast issues with IPsec December, 2002
B. Decide that ESP/AH should be modified to accommodate the needs of
MSEC. In this case, both MSEC and IPSec will use the same
definition of ESP, with the same protocol number. (MESP will
define additional authentication protocols for ESP, to obtain
source authentication.)
The main advantage of option A is that there is no need to
coordinate between the two working groups, and each WG is free to
define (and subsequently modify) its own protocols. The main
disadvantage of option A is the extra complexity involved in
defining, implementing, and maintaining a separate "multicast ESP"
protocol. Thus, the decision between options A and B has to weigh
the complexity of modifying ESP to accommodate MSEC, against the
complexity of having a different "multicast ESP" protocol.
The purpose of this draft is to explain and clarify the changes
needed to ESP/AH in order to make it compatible with MSEC, and thus
start a discussion on the MSEC and IPSEC working groups. In a
nutshell, three modifications to the IPSec protocol suite are
necessary:
1. Allow parties to further refine the SA lookup. (That is, allow a
party to have two different SA's, with the same destination
address, same IPSEC protocol, and same SPI, but with different
source addresses.
2. Allow parties a wider range of replay protection possibilities
for ESP/AH.
3. Better describe that a variety of authentication methods can be
used within the IPsec protocols.
It is our impression that the changes required of ESP/AH to
accommodate the needs of MSEC are minor, and in no case will
existing IPsec implementations be affected. Thus, option B is the
better one. We solicit discussion of this question on the IPSEC and
MSEC WGs.
1.1 Addressing Scope
Although this document is primarily concerned with IP multicast, the
issues raised are not restricted to multicast; IPv4 or IPv6
broadcast and anycast groups are similarly affected.
1.2 Key Words
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC2119].
2.0 General Issues
There are two distinct unrelated problems which have been
discovered, first by the SMuG IRTF WG and then by the IETF MSEC WG
Baugher, et. al. Expires June, 2003 3
IP Multicast issues with IPsec December, 2002
which was formed to focus on the security of IP multicast groups.
One other issue has arisen specifically with new wording in the
[ESPbis] and [AHbis] drafts.
2.1 SPI allocation and SA lookup
RFC 2401 states an SA will use the 3-tuple (destination address,
IPsec protocol, and SPI) to look up the SA in the SAD. That is
sufficient and satisfactory in many IP multicast cases. It can be
accomplished in those cases by using a multicast key management
scheme which is built around a centralized group controller. As long
as a single group controller synchronizes SPI values, this 3-tuple
is sufficient -- even as the authors of RFC 2401 predicted in
Section 4.7 of RFC 2401:
So some system or person will need to coordinate among all
multicast groups to select an SPI or SPIs on behalf of each
multicast group and then communicate the group's IPsec
information to all of the legitimate members of that multicast
group via mechanisms not defined here.
The text quoted above from RFC 2401 does not say that there MUST be
a single controller, but appears to be giving clarifying text based
on the expectations of the time.
Since the time RFC 2401 was written, Source-Specific Multicast (SSM)
has been specified. SSM allows for sender-specific SAs. An SSM
"group" is composed of a particular sender and its receivers.
Multiple SSM groups may use that same multicast address, but no
coordination between senders is assumed. Similarly, IGMP version 3
also operates on the basis of (Source, Group) pairs. Therefore, when
we wish to protect this traffic with IPsec we cannot assume any
security coordination between the senders. A 3-tuple is no longer
sufficient.
Section 4.7 of RFC 2401 also says
Specifications for other, more general multicast cases are
deferred to later IPsec documents.
Given the above two quotes it would seem that we should be able to
accommodate multiple multicast group controllers within the existing
architecture.
RFC 2402 and RFC 2406 did not further restrict the SA lookup as
described in RFC 2401. They also describe the 3-tuple to be used in
all cases (unicast and multicast).
The proposed new ESP [ESPbis] and AH [AHbis] do change the semantics
of SA lookup. It makes them less specific in both the unicast and
multicast cases. For the IP multicast case, the lookup has been
changed to a SPI lookup (and optionally the protocol ID) in
combination with the destination address. This is fine except in the
Baugher, et. al. Expires June, 2003 4
IP Multicast issues with IPsec December, 2002
case when multiple multicast group controllers are used for the
group.
In order to effectively differentiate between SAs administered by
different group controllers, we need a MORE specific SA lookup than
RFC 2406 rather than the less specific lookup as proposed in
[ESPbis].
2.2 Multiple sender SAs and replay protection
RFC 2401 points out that having senders share a single SA is useful
under some circumstances (see Section 4.7 of [RFC2401). It
acknowledges that the anti-replay service provided by a sequence
number in the AH or ESP packet is not possible with present
semantics.
RFC 2406 agrees with this, and further states that anti-replay
SHOULD NOT be used with a multi-sender SA in Section 3.4.3:
(Note that there are no provisions for managing transmitted
Sequence Number values among multiple senders directing traffic
to a single SA (irrespective of whether the destination address
is unicast, broadcast, or multicast). Thus the anti-replay
service SHOULD NOT be used in a multi-sender environment that
employs a single SA.) [RFC2406].
The new ESP [ESPbis] goes even further to deprecate multiple sender
SAs in Section 2.2. However, there are multicast applications with
very large numbers of senders to the same IP multicast group, where
the receivers are low end devices which cannot store a single SA per
sender.
2.3 Integrity vs. Authentication
RFC 2402 and RFC 2406 described an "Authentication Data" section as
providing connectionless integrity and data origin authentication.
However [ESPbis] and [AHbis] replaced the name of that field with
"Integrity Check Value" which doesn't really accurately describe the
field when group data origin authentication algorithms are used.
This is described more fully in following sections.
3.0 Proposed Changes to ESPbis
The following sections propose changes to [ESPbis] to address the
above general issues.
3.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
Baugher, et. al. Expires June, 2003 5
IP Multicast issues with IPsec December, 2002
controller, not by each IPsec receiver. (See the Security
Architecture document for more details) [ESPbis].
As noted above, this is not sufficient for IP multicastin the case
of multiple multicast group controllers. 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.
Section 3.4.2 (Security Association Lookup) of [ESPbis] would also
need to discuss these semantics. It 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.
3.2 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].
It is true that with the current semantics that synchronizing packet
counters across multiple senders is not possible. However, there is
a need to provide anti-replay in this situation and there is ongoing
research into methods which allow anti-replay in this situation.
Baugher, et. al. Expires June, 2003 6
IP Multicast issues with IPsec December, 2002
Therefore, rather than forbid the use of multiple-sender SAs we
propose relaxing the multiple-sender SA restriction found in RFC
2406 to accommodate new methods of replay detection as they become
available. 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.
This text intentionally restricts any new anti-replay functionality
being used unless it has been negotiated in or downloaded from key
management. In this way, older IPsec and hardware implementations of
IPsec will be shielded from having to implement or understand the
new semantics.
3.3 Integrity vs. Authentication
The name associated with the authentication portion of ESP is
"Authentication Data". However, [ESPbis] changed the name to
"Integrity Check Value". The rationale for this change is described
in Section 1:
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].
This is certainly true for a pairwise unicast connection. However
when ESP is used with multicast, data origin authentication can be
an authentication feature distinct from identity checks. At least
two forms of data origin authentication have been proposed: digital
signatures and TESLA.
Since this field can provide more than just integrity it is more
accurately named as "Authentication Data". 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.
Baugher, et. al. Expires June, 2003 7
IP Multicast issues with IPsec December, 2002
4.0 Proposed Changes to AHbis
The following sections propose changes to [AHbis] to address the
above general issues.
4.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.
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.
4.2 Multiple sender SAs and replay protection
Section 2.5 (Sequence Number) states the same text as [ESPbis]
Section 2.2. We propose the same text here as is proposed in Section
3.2.
Baugher, et. al. Expires June, 2003 8
IP Multicast issues with IPsec December, 2002
4.3 Integrity vs. Authentication
AH has the same issue as ESP regarding the use of the term
"Integrity" over "Authentication". We propose the "Integrity Check
Value" field in AHbis be named "Authentication Data", and all
references to that section should be updated.
5.0 Conclusion
The IPsec architecture is capable of accommodating multicast
applications, including source specific multicast applications, with
minor revisions in SA lookup and replay protection, which are
described in this memo. These minor changes will enable new
transforms for source authentication of multicast messages as well
as group authentication of multicast messages.
6.0 Security Considerations
This entire document discusses how multicast data packets can be
effectively protected within the IPsec architecture.
7.0 References
7.1 Normative References
[RFC2401] Kent, S., R. Atkinson, "Security Architecture for the
Internet Protocol", November 1998
[RFC2402] Kent, S., and R. Atkinson, "IP Authentication Header", RFC
2402, November 1998.
[RFC2406] Kent, S., and R. Atkinson, "IP Encapsulating Security
Payload", RFC 2406, November 1998.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Level", BCP 14, RFC 2119, March 1997.
[RFC3376] Cain, B., et. al., ?Internet Group Management Protocol,
Version 3?, RFC 3376, October 2002.
7.2 Informative References
[ESPbis] Kent, S., "IP Encapsulating Security Payload (ESP)",
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esp-v3-03.txt,
Work in progress 2002.
[AHbis] Kent, S., ?IP Authentication Header?,
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-rfc2402bis-
01.txt, Work in progress 2002.
[MESP] Baugher, M., et. al., ?MESP: Multicast Encapsulating Security
Payload?, http://www.ietf.org/internet-drafts/draft-ietf-msec-mesp-
00.txt, Work in progress 2002.
Baugher, et. al. Expires June, 2003 9
IP Multicast issues with IPsec December, 2002
[SSM-ARCH] Holbrook, H., Cain, B., ?Source-Specific Multicast for
IP?, http://www.ietf.org/internet-drafts/draft-ietf-ssm-arch-01.txt,
Work in progress 2002.
Authors Addresses
Mark Baugher
Cisco Systems
5510 SW Orchid Street
Portland, OR 97219, USA
(503) 245-4543
mbaugher@cisco.com
Ran Canetti
IBM T.J. Watson Research Center
30 Saw Mill River Road
Hawthorne, NY 10598, USA
canetti@watson.ibm.com
Tel: +1-914-784-6692
Thomas Hardjono
VeriSign
401 Edgewater Place, Suite 280
Wakefield, MA 01880
Tel: 781-245-6996
thardjono@verisign.com
Brian Weis
Cisco Systems
170 W. Tasman Drive,
San Jose, CA 95134-1706, USA
(408) 526-4796
bew@cisco.com
Baugher, et. al. Expires June, 2003 10 | PAFTECH AB 2003-2026 | 2026-04-23 03:40:19 |