draft-ietf-rmt-pi-alc-revised-06.txt   draft-ietf-rmt-pi-alc-revised-07.txt 
Reliable Multicast Transport (RMT) Luby Reliable Multicast Transport (RMT) Luby
Working Group Watson Working Group Watson
Internet-Draft Vicisano Internet-Draft Vicisano
Obsoletes: 3450 (if approved) Digital Fountain Obsoletes: 3450 (if approved) Qualcomm Inc.
Intended status: Standards Track November 1, 2008 Intended status: Standards Track July 13, 2009
Expires: May 5, 2009 Expires: January 14, 2010
Asynchronous Layered Coding (ALC) Protocol Instantiation Asynchronous Layered Coding (ALC) Protocol Instantiation
draft-ietf-rmt-pi-alc-revised-06 draft-ietf-rmt-pi-alc-revised-07
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 5, 2009. This Internet-Draft will expire on January 14, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
This document describes the Asynchronous Layered Coding (ALC) This document describes the Asynchronous Layered Coding (ALC)
protocol, a massively scalable reliable content delivery protocol. protocol, a massively scalable reliable content delivery protocol.
Asynchronous Layered Coding combines the Layered Coding Transport Asynchronous Layered Coding combines the Layered Coding Transport
(LCT) building block, a multiple rate congestion control building (LCT) building block, a multiple rate congestion control building
block and the Forward Error Correction (FEC) building block to block and the Forward Error Correction (FEC) building block to
provide congestion controlled reliable asynchronous delivery of provide congestion controlled reliable asynchronous delivery of
content to an unlimited number of concurrent receivers from a single content to an unlimited number of concurrent receivers from a single
skipping to change at page 2, line 34 skipping to change at page 2, line 34
2.2. Multiple rate congestion control building block . . . . . 9 2.2. Multiple rate congestion control building block . . . . . 9
2.3. FEC building block . . . . . . . . . . . . . . . . . . . . 9 2.3. FEC building block . . . . . . . . . . . . . . . . . . . . 9
2.4. Session Description . . . . . . . . . . . . . . . . . . . 11 2.4. Session Description . . . . . . . . . . . . . . . . . . . 11
2.5. Packet authentication building block . . . . . . . . . . . 12 2.5. Packet authentication building block . . . . . . . . . . . 12
3. Conformance Statement . . . . . . . . . . . . . . . . . . . . 14 3. Conformance Statement . . . . . . . . . . . . . . . . . . . . 14
4. Functionality Definition . . . . . . . . . . . . . . . . . . . 15 4. Functionality Definition . . . . . . . . . . . . . . . . . . . 15
4.1. Packet format used by ALC . . . . . . . . . . . . . . . . 15 4.1. Packet format used by ALC . . . . . . . . . . . . . . . . 15
4.2. LCT Header-Extension Fields . . . . . . . . . . . . . . . 16 4.2. LCT Header-Extension Fields . . . . . . . . . . . . . . . 16
4.3. Sender Operation . . . . . . . . . . . . . . . . . . . . . 17 4.3. Sender Operation . . . . . . . . . . . . . . . . . . . . . 17
4.4. Receiver Operation . . . . . . . . . . . . . . . . . . . . 17 4.4. Receiver Operation . . . . . . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
5.1. Baseline Secure ALC Operation . . . . . . . . . . . . . . 21 5.1. Baseline Secure ALC Operation . . . . . . . . . . . . . . 20
5.1.1. IPsec Approach . . . . . . . . . . . . . . . . . . . . 21 5.1.1. IPsec Approach . . . . . . . . . . . . . . . . . . . . 20
5.1.2. IPsec Requirements . . . . . . . . . . . . . . . . . . 22 5.1.2. IPsec Requirements . . . . . . . . . . . . . . . . . . 21
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
8. Changes from RFC3450 . . . . . . . . . . . . . . . . . . . . . 27 8. Changes from RFC3450 . . . . . . . . . . . . . . . . . . . . . 26
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
9.1. Normative references . . . . . . . . . . . . . . . . . . . 28 9.1. Normative references . . . . . . . . . . . . . . . . . . . 27
9.2. Informative references . . . . . . . . . . . . . . . . . . 29 9.2. Informative references . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Intellectual Property and Copyright Statements . . . . . . . . . . 31
1. Introduction 1. Introduction
This document describes a massively scalable reliable content This document describes a massively scalable reliable content
delivery protocol, Asynchronous Layered Coding (ALC), for multiple delivery protocol, Asynchronous Layered Coding (ALC), for multiple
rate congestion controlled reliable content delivery. The protocol rate congestion controlled reliable content delivery. The protocol
is specifically designed to provide massive scalability using IP is specifically designed to provide massive scalability using IP
multicast as the underlying network service. Massive scalability in multicast as the underlying network service. Massive scalability in
this context means the number of concurrent receivers for an object this context means the number of concurrent receivers for an object
is potentially in the millions, the aggregate size of objects to be is potentially in the millions, the aggregate size of objects to be
skipping to change at page 3, line 52 skipping to change at page 3, line 52
application that uses ALC may require that receivers report application that uses ALC may require that receivers report
statistics on their reception experience back to the sender, but the statistics on their reception experience back to the sender, but the
mechanisms by which receivers report back statistics is outside the mechanisms by which receivers report back statistics is outside the
scope of ALC. In general, ALC is designed to be a minimal protocol scope of ALC. In general, ALC is designed to be a minimal protocol
instantiation that provides reliable content delivery without instantiation that provides reliable content delivery without
unnecessary limitations to the scalability of the basic protocol. unnecessary limitations to the scalability of the basic protocol.
This document is a product of the IETF RMT WG and follows the general This document is a product of the IETF RMT WG and follows the general
guidelines provided in [RFC3269]. guidelines provided in [RFC3269].
RFC3450 [RFC3450], which is obsoleted by this document, contained a [RFC3450], which was published in the "Experimental" category and
previous versions of the protocol. RFC3450 was published in the which is obsoleted by this document, contained a previous versions of
"Experimental" category. It was the stated intent of the RMT working the protocol.
group to re-submit these specifications as an IETF Proposed Standard
in due course.
This Proposed Standard specification is thus based on and backwards This Proposed Standard specification is thus based on and backwards
compatible with the protocol defined in RFC3450 [RFC3450] updated compatible with the protocol defined in [RFC3450] updated according
according to accumulated experience and growing protocol maturity to accumulated experience and growing protocol maturity since its
since its original publication. Said experience applies both to this original publication. Said experience applies both to this
specification itself and to congestion control strategies related to specification itself and to congestion control strategies related to
the use of this specification. the use of this specification.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, [RFC2119]. document are to be interpreted as described in BCP 14, [RFC2119].
1.1. Delivery service models 1.1. Delivery service models
ALC can support several different reliable content delivery service ALC can support several different reliable content delivery service
skipping to change at page 6, line 43 skipping to change at page 6, line 43
to a a different session to which congestion control is individually to a a different session to which congestion control is individually
applied. Although receiving concurrently from multiple sessions is applied. Although receiving concurrently from multiple sessions is
allowed, how this is done at the application level is outside the allowed, how this is done at the application level is outside the
scope of this document. scope of this document.
ALC is a protocol instantiation as defined in [RFC3048]. This ALC is a protocol instantiation as defined in [RFC3048]. This
document describes version 1 of ALC which MUST use version 1 of LCT document describes version 1 of ALC which MUST use version 1 of LCT
described in [I-D.ietf-rmt-bb-lct-revised]. Like LCT, ALC is described in [I-D.ietf-rmt-bb-lct-revised]. Like LCT, ALC is
designed to be used with the IP multicast network service. This designed to be used with the IP multicast network service. This
specification defines ALC as payload of the UDP transport protocol specification defines ALC as payload of the UDP transport protocol
[RFC0768] that supports IP multicast delivery of packets. Future [RFC0768] that supports IP multicast delivery of packets.
versions of this specification, or companion documents may extend ALC
to use the IP network layer service directly. ALC could be used as
the basis for designing a protocol that uses a different underlying
network service such as unicast UDP, but the design of such a
protocol is outside the scope of this document.
An ALC packet header immediately follows the UDP header and consists An ALC packet header immediately follows the UDP header and consists
of the default LCT header that is described in of the default LCT header that is described in
[I-D.ietf-rmt-bb-lct-revised] followed by the FEC Payload ID that is [I-D.ietf-rmt-bb-lct-revised] followed by the FEC Payload ID that is
described in [RFC5052]. The Congestion Control Information field described in [RFC5052]. The Congestion Control Information field
within the LCT header carries the required Congestion Control within the LCT header carries the required Congestion Control
Information that is described in the multiple rate congestion control Information that is described in the multiple rate congestion control
building block specified that is compliant with [RFC2357]. The building block specified that is compliant with [RFC2357]. The
packet payload that follows the ALC packet header consists of packet payload that follows the ALC packet header consists of
encoding symbols that are identified by the FEC Payload ID as encoding symbols that are identified by the FEC Payload ID as
skipping to change at page 8, line 11 skipping to change at page 8, line 5
could be used to communicate the FEC Encoding ID to be used for each could be used to communicate the FEC Encoding ID to be used for each
object. The mapping between FEC Encoding IDs and Codepoints could object. The mapping between FEC Encoding IDs and Codepoints could
be, for example, the identity mapping. be, for example, the identity mapping.
If more than one object is to be carried within a session then the If more than one object is to be carried within a session then the
Transmission Object Identifier (TOI) MUST be used in the LCT header Transmission Object Identifier (TOI) MUST be used in the LCT header
to identify which packets are to be associated with which objects. to identify which packets are to be associated with which objects.
In this case the receiver MUST use the TOI to associate received In this case the receiver MUST use the TOI to associate received
packets with objects. The TOI is scoped by the IP address of the packets with objects. The TOI is scoped by the IP address of the
sender and the TSI, i.e., the TOI is scoped by the session. The TOI sender and the TSI, i.e., the TOI is scoped by the session. The TOI
for each object is REQUIRED to be unique within a session, but MAY for each object is REQUIRED to be unique within a session, but is not
NOT be unique across sessions. Furthermore, the same object MAY have required be unique across sessions. Furthermore, the same object MAY
a different TOI in different sessions. The mapping between TOIs and have a different TOI in different sessions. The mapping between TOIs
objects carried in a session is outside the scope of this document. and objects carried in a session is outside the scope of this
document.
If only one object is carried within a session then the TOI MAY be If only one object is carried within a session then the TOI MAY be
omitted from the LCT header. omitted from the LCT header.
The LCT header from version 1 of the LCT building block The LCT header from version 1 of the LCT building block
[I-D.ietf-rmt-bb-lct-revised] MUST be used. [I-D.ietf-rmt-bb-lct-revised] MUST be used.
The LCT Header includes a two-bit Protocol Specific Indication (PSI) The LCT Header includes a two-bit Protocol Specific Indication (PSI)
field in bits 6 and 7 of the first word of the LCT header. These two field in bits 6 and 7 of the first word of the LCT header. These two
bits are used by ALC as follows: bits are used by ALC as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+ +-+-+
...|A|B|... ...|X|Y|...
+-+-+ +-+-+
Figure 1: PSI bits within LCT Headder Figure 1: PSI bits within LCT Headder
PSI bit A - Source Packet Indicator (SPI) PSI bit X - Source Packet Indicator (SPI)
PSI bit B - Reserved PSI bit Y - Reserved
The Source Packet Indicator is used with systematic FEC Schemes which The Source Packet Indicator is used with systematic FEC Schemes which
define a different FEC Payload ID format for packets containing only define a different FEC Payload ID format for packets containing only
source data compared to the FEC Payload ID format for packets source data compared to the FEC Payload ID format for packets
containing repair data. For such FEC Schemes, then the SPI MUST be containing repair data. For such FEC Schemes, then the SPI MUST be
set to 1 when the FEC Payload ID format for packets containing only set to 1 when the FEC Payload ID format for packets containing only
source data is used and the SPI MUST be set to zero, when the FEC source data is used and the SPI MUST be set to zero, when the FEC
Payload ID for packerts containing repair data is used. In the case Payload ID for packerts containing repair data is used. In the case
of FEC Schemes which define only a single FEC Payload ID format, then of FEC Schemes which define only a single FEC Payload ID format, then
the SPI MUST be set to zero by the sender and MUST be ignored by the the SPI MUST be set to zero by the sender and MUST be ignored by the
skipping to change at page 9, line 10 skipping to change at page 9, line 7
Support of two FEC Payload ID formats allows FEC Payload ID Support of two FEC Payload ID formats allows FEC Payload ID
information which is only of relevance when FEC decoding is to be information which is only of relevance when FEC decoding is to be
performed to be provided in the FEC Payload ID format for packets performed to be provided in the FEC Payload ID format for packets
containing repair data. This information need not be processed by containing repair data. This information need not be processed by
receivers which do not perform FEC decoding (either because no FEC receivers which do not perform FEC decoding (either because no FEC
decoding is required or because the receiver does not support FEC decoding is required or because the receiver does not support FEC
decoding). decoding).
2.2. Multiple rate congestion control building block 2.2. Multiple rate congestion control building block
Implementors of ALC MUST implement a multiple rate feedback-free At a minimum, implementions of ALC MUST support [RFC3738].
congestion control building block that is in accordance to [RFC2357].
Congestion control MUST be applied to all packets within a session Congestion control MUST be applied to all packets within a session
independently of which information about which object is carried in independently of which information about which object is carried in
each packet. Multiple rate congestion control is specified because each packet. Multiple rate congestion control is specified because
of its suitability to scale massively and because of its suitability of its suitability to scale massively and because of its suitability
for reliable content delivery. The multiple rate congestion control for reliable content delivery. [RFC3738] specifies in-band
building block MUST specify in-band Congestion Control Information Congestion Control Information (CCI) that MUST be carried in the CCI
(CCI) that MUST be carried in the CCI field of the LCT header. The field of the LCT header.
multiple rate congestion control building block MAY specify more than
one format, but it MUST specify at most one format for each of the Alternative multiple rate congestion control building blocks MAY be
possible lengths 32, 64, 96 or 128 bits. The value of C in the LCT supported. The multiple rate congestion control building block MAY
header that determines the length of the CCI field MUST correspond to specify more than one format for the CCI field, but it MUST specify
one of the lengths for the CCI defined in the multiple rate at most one format for each of the possible lengths 32, 64, 96 or 128
congestion control building block, this length MUST be the same for bits. The value of C in the LCT header that determines the length of
all packets sent to a session, and the CCI format that corresponds to the CCI field MUST correspond to one of the lengths for the CCI
the length as specified in the multiple rate congestion control defined in the multiple rate congestion control building block, this
building block MUST be the format used for the CCI field in the LCT length MUST be the same for all packets sent to a session, and the
header. CCI format that corresponds to the length as specified in the
multiple rate congestion control building block MUST be the format
used for the CCI field in the LCT header.
When using a multiple rate congestion control building block a sender When using a multiple rate congestion control building block a sender
sends packets in the session to several channels at potentially sends packets in the session to several channels at potentially
different rates. Then, individual receivers adjust their reception different rates. Then, individual receivers adjust their reception
rate within a session by adjusting which set of channels they are rate within a session by adjusting which set of channels they are
joined to at each point in time depending on the available bandwidth joined to at each point in time depending on the available bandwidth
between the receiver and the sender, but independent of other between the receiver and the sender, but independent of other
receivers. receivers.
2.3. FEC building block 2.3. FEC building block
skipping to change at page 12, line 40 skipping to change at page 12, line 38
o The data rates used for each channel; o The data rates used for each channel;
o The length of the packet payload; o The length of the packet payload;
o Any information that is relevant to each object being transported, o Any information that is relevant to each object being transported,
such as the Object Transmission Information for each object, when such as the Object Transmission Information for each object, when
the object will be available within the session and for how long. the object will be available within the session and for how long.
The Session Description could be in a form such as SDP as defined in The Session Description could be in a form such as SDP as defined in
[RFC2327], or XML metadata as defined in [RFC3023], or HTTP/Mime [RFC4566], or XML metadata as defined in [RFC3023], or HTTP/Mime
headers as defined in [RFC2616], etc. It might be carried in a headers as defined in [RFC2616], etc. It might be carried in a
session announcement protocol such as SAP as defined in [RFC2974], session announcement protocol such as SAP as defined in [RFC2974],
obtained using a proprietary session control protocol, located on a obtained using a proprietary session control protocol, located on a
web page with scheduling information, or conveyed via E-mail or other web page with scheduling information, or conveyed via E-mail or other
out-of-band methods. Discussion of Session Description formats and out-of-band methods. Discussion of Session Description formats and
methods for communication of Session Descriptions to receivers is methods for communication of Session Descriptions to receivers is
beyond the scope of this document. beyond the scope of this document.
2.5. Packet authentication building block 2.5. Packet authentication building block
It is RECOMMENDED that implementors of ALC use some packet It is RECOMMENDED that implementors of ALC use some packet
authentication scheme to protect the protocol from attacks. An authentication scheme to protect the protocol from attacks. Suitable
example of a possibly suitable scheme is described in [PER2001]. schemes are described in [I-D.ietf-msec-tesla-for-alc-norm] and
Packet authentication in ALC, if used, is to be integrated through [I-D.ietf-rmt-simple-auth-for-alc-norm].
the Header Extension support for packet authentication provided in
the LCT building block.
3. Conformance Statement 3. Conformance Statement
This Protocol Instantiation document, in conjunction with the LCT This Protocol Instantiation document, in conjunction with the LCT
building block [I-D.ietf-rmt-bb-lct-revised], the FEC building block building block [I-D.ietf-rmt-bb-lct-revised], the FEC building block
[RFC5052] and with a multiple rate congestion control building block [RFC5052] and [RFC3738] completely specifies a working reliable
completely specifies a working reliable multicast transport protocol multicast transport protocol that conforms to the requirements
that conforms to the requirements described in [RFC2357]. described in [RFC2357].
4. Functionality Definition 4. Functionality Definition
This section describes the format and functionality of the data This section describes the format and functionality of the data
packets carried in an ALC session as well as the sender and receiver packets carried in an ALC session as well as the sender and receiver
operations for a session. operations for a session.
4.1. Packet format used by ALC 4.1. Packet format used by ALC
The packet format used by ALC is the UDP header followed by the LCT The packet format used by ALC is the UDP header followed by the LCT
skipping to change at page 16, line 39 skipping to change at page 16, line 39
header), enables receivers to detect the absence of the ALC payload header), enables receivers to detect the absence of the ALC payload
and FEC Payload ID. and FEC Payload ID.
For ALC the length of the TSI field within the LCT header is REQUIRED For ALC the length of the TSI field within the LCT header is REQUIRED
to be non-zero. This implies that the sender MUST NOT set both the to be non-zero. This implies that the sender MUST NOT set both the
LCT flags S and H to zero. LCT flags S and H to zero.
4.2. LCT Header-Extension Fields 4.2. LCT Header-Extension Fields
All senders and receivers implementing ALC MUST support the EXT_NOP All senders and receivers implementing ALC MUST support the EXT_NOP
Header Extension and MUST recognize EXT_AUTH, but MAY NOT be able to Header Extension and MUST recognize EXT_AUTH, but are not required be
parse its content. The EXT_NOP and EXT_AUTH LCT Header Extensions able to parse its content. The EXT_NOP and EXT_AUTH LCT Header
are defined in [I-D.ietf-rmt-bb-lct-revised] Extensions are defined in [I-D.ietf-rmt-bb-lct-revised]
This specification defines a new LCT Header Extension, "EXT_FTI", for This specification defines a new LCT Header Extension, "EXT_FTI", for
the purpose of communicating the FEC Object Transmission Information the purpose of communicating the FEC Object Transmission Information
in association with data packets of an object. The LCT Header in association with data packets of an object. The LCT Header
Extension Type for EXT_FTI is 64. Extension Type for EXT_FTI is 64.
The Header Extension Content (HEC) field of the EXT_FTI LCT Header The Header Extension Content (HEC) field of the EXT_FTI LCT Header
Extension contains the encoded FEC Object Transmission Information as Extension contains the encoded FEC Object Transmission Information as
defined in [RFC5052]. The format of the encoded FEC Object defined in [RFC5052]. The format of the encoded FEC Object
Transmission Information is dependent on the FEC Scheme in use and so Transmission Information is dependent on the FEC Scheme in use and so
skipping to change at page 17, line 36 skipping to change at page 17, line 36
Several objects MAY be delivered within the same ALC session. If Several objects MAY be delivered within the same ALC session. If
more than one object is to be delivered within a session then the more than one object is to be delivered within a session then the
sender MUST use the TOI field and each object MUST be identified by a sender MUST use the TOI field and each object MUST be identified by a
unique TOI within the session, and the sender MUST use corresponding unique TOI within the session, and the sender MUST use corresponding
TOI for all packets pertaining to the same object. The FEC Payload TOI for all packets pertaining to the same object. The FEC Payload
ID MUST correspond to the encoding symbol(s) for the object carried ID MUST correspond to the encoding symbol(s) for the object carried
in the payload of the packet. in the payload of the packet.
It is RECOMMENDED that packet authentication be used. If packet It is RECOMMENDED that packet authentication be used. If packet
authentication is used then the Header Extensions described in authentication is used then the Header Extensions described in
Section 4.2 MUST be used to carry the authentication. Section 4.2 MAY be used to carry the authentication.
4.4. Receiver Operation 4.4. Receiver Operation
The receiver operation when using ALC includes all the points made The receiver operation when using ALC includes all the points made
about the receiver operation when using the LCT building block about the receiver operation when using the LCT building block
[I-D.ietf-rmt-bb-lct-revised], the FEC building block [RFC5052] and [I-D.ietf-rmt-bb-lct-revised], the FEC building block [RFC5052] and
the multiple rate congestion control building block. the multiple rate congestion control building block.
To be able to participate in a session, a receiver MUST obtain the To be able to participate in a session, a receiver MUST obtain the
REQUIRED Session Description as listed in Section 2.4. How receivers REQUIRED Session Description as listed in Section 2.4. How receivers
obtain a Session Description is outside the scope of this document. obtain a Session Description is outside the scope of this document.
To be able to be a receiver in a session, the receiver MUST be able
to process the ALC header. The receiver MUST be able to discard,
forward, store or process the other headers and the packet payload.
If a receiver is not able to process the ALC header, it MUST drop
from the session.
As described in Section 2.3, a receiver MUST obtain the required FEC As described in Section 2.3, a receiver MUST obtain the required FEC
Object Transmission Information for each object for which the Object Transmission Information for each object for which the
receiver receives and processes packets. receiver receives and processes packets.
Upon receipt of each packet the receiver proceeds with the following Upon receipt of each packet the receiver proceeds with the following
steps in the order listed. steps in the order listed.
1. The receiver MUST parse the packet header and verify that it is a 1. The receiver MUST parse the packet header and verify that it is a
valid header. If it is not valid then the packet MUST be valid header. If it is not valid then the packet MUST be
discarded without further processing. If multiple packets are discarded without further processing.
received that cannot be parsed then the receiver SHOULD leave the
session.
2. The receiver MUST verify that the sender IP address together with 2. The receiver MUST verify that the sender IP address together with
the TSI carried in the header matches one of the (sender IP the TSI carried in the header matches one of the (sender IP
address, TSI) pairs that was received in a Session Description address, TSI) pairs that was received in a Session Description
and that the receiver is currently joined to. If there is not a and that the receiver is currently joined to. If there is not a
match then the packet MUST be discarded without further match then the packet MUST be silently discarded without further
processing. If multiple packets are received with non-matching processing. The remaining steps are performed within the scope
(sender IP address, TSI) values then the receiver SHOULD leave of the (sender IP address, TSI) session of the received packet.
the session. If the receiver is joined to multiple ALC sessions
then the remainder of the steps are performed within the scope of
the (sender IP address, TSI) session of the received packet.
3. The receiver MUST process and act on the CCI field in accordance 3. The receiver MUST process and act on the CCI field in accordance
with the multiple rate congestion control building block. with the multiple rate congestion control building block.
4. If more than one object is carried in the session, the receiver 4. If more than one object is carried in the session, the receiver
MUST verify that the TOI carried in the LCT header is valid. If MUST verify that the TOI carried in the LCT header is valid. If
the TOI is not valid, the packet MUST be discarded without the TOI is not valid, the packet MUST be discarded without
further processing. further processing.
5. The receiver SHOULD process the remainder of the packet, 5. The receiver SHOULD process the remainder of the packet,
including interpreting the other header fields appropriately, and including interpreting the other header fields appropriately, and
using the FEC Payload ID and the encoding symbol(s) in the using the FEC Payload ID and the encoding symbol(s) in the
payload to reconstruct the corresponding object. payload to reconstruct the corresponding object.
It is RECOMMENDED that packet authentication be used. If packet It is RECOMMENDED that packet authentication be used. If packet
authentication is used then it is RECOMMENDED that the receiver authentication is used then it is RECOMMENDED that the receiver
immediately check the authenticity of a packet before proceeding with immediately check the authenticity of a packet before proceeding with
step (3) above. If immediate checking is possible and if the packet step (3) above. If immediate checking is possible and if the packet
fails the check then the receiver MUST discard the packet and reduce fails the check then the receiver MUST silently discard the packet.
its reception rate to a minimum before continuing to regulate its
reception rate using the multiple rate congestion control.
Some packet authentication schemes such as TESLA [PER2001] do not Some packet authentication schemes such as TESLA
allow an immediate authenticity check. In this case the receiver [I-D.ietf-msec-tesla-for-alc-norm] do not allow an immediate
SHOULD check the authenticity of a packet as soon as possible, and if authenticity check. In this case the receiver SHOULD check the
the packet fails the check then it MUST be discarded before step (5) authenticity of a packet as soon as possible, and if the packet fails
above and reduce its reception rate to a minimum before continuing to the check then it MUST be silently discarded before step (5) above.
regulate its reception rate using the multiple rate congestion It is RECOMMENDED that if receivers detect many packets which fail
control. authentication checks within a session then the above procedure
should be modified for this session so that Step 3 is delayed until
after the authentication check and only performed if the check
succeeds.
5. Security Considerations 5. Security Considerations
The same security consideration that apply to the LCT, FEC and the The same security consideration that apply to the LCT, FEC and the
multiple rate congestion control building blocks also apply to ALC. multiple rate congestion control building blocks also apply to ALC.
Because of the use of FEC, ALC is especially vulnerable to denial- ALC is especially vulnerable to denial- of-service attacks by
of-service attacks by attackers that try to send forged packets to attackers that try to send forged packets to the session which would
the session which would prevent successful reconstruction or cause prevent successful reconstruction or cause inaccurate reconstruction
inaccurate reconstruction of large portions of the object by of large portions of the object by receivers. ALC is also
receivers. ALC is also particularly affected by such an attack particularly affected by such an attack because many receivers may
because many receivers may receive the same forged packet. There are receive the same forged packet. There are two ways to protect
two ways to protect against such attacks, one at the application against such attacks, one at the application level and one at the
level and one at the packet level. It is RECOMMENDED that prevention packet level. It is RECOMMENDED that prevention be provided at both
be provided at both levels. levels.
At the application level, it is RECOMMENDED that an integrity check At the application level, it is RECOMMENDED that an integrity check
on the entire received object be done once the object is on the entire received object be done once the object is
reconstructed to ensure it is the same as the sent object. Moreover, reconstructed to ensure it is the same as the sent object. Moreover,
in order to obtain strong cryptographic integrity protection a in order to obtain strong cryptographic integrity protection a
digital signature verifiable by the receiver SHOULD be used to digital signature verifiable by the receiver SHOULD be used to
provide this application level integrity check. However, if even one provide this application level integrity check. However, if even one
corrupted or forged packet is used to reconstruct the object, it is corrupted or forged packet is used to reconstruct the object, it is
likely that the received object will be reconstructed incorrectly. likely that the received object will be reconstructed incorrectly.
This will appropriately cause the integrity check to fail and in this This will appropriately cause the integrity check to fail and in this
case the inaccurately reconstructed object SHOULD be discarded. case the inaccurately reconstructed object SHOULD be discarded.
Thus, the acceptance of a single forged packet can be an effective Thus, the acceptance of a single forged packet can be an effective
denial of service attack for distributing objects, but an object denial of service attack for distributing objects, but an object
integrity check at least prevents inadvertent use of inaccurately integrity check at least prevents inadvertent use of inaccurately
reconstructed objects. The specification of an application level reconstructed objects. The specification of an application level
integrity check of the received object is outside the scope of this integrity check of the received object is outside the scope of this
document. document.
At the packet level, it is RECOMMENDED that a packet level At the packet level, it is RECOMMENDED that a packet level
authentication be used to ensure that each received packet is an authentication be used to ensure that each received packet is an
authentic and uncorrupted packet containing FEC data for the object authentic and uncorrupted packet containing data for the object
arriving from the specified sender. Packet level authentication has arriving from the specified sender. Packet level authentication has
the advantage that corrupt or forged packets can be discarded the advantage that corrupt or forged packets can be discarded
individually and the received authenticated packets can be used to individually and the received authenticated packets can be used to
accurately reconstruct the object. Thus, the effect of a denial of accurately reconstruct the object. Thus, the effect of a denial of
service attack that injects forged packets is proportional only to service attack that injects forged packets is proportional only to
the number of forged packets, and not to the object size. Although the number of forged packets, and not to the object size.
there is currently no IETF standard that specifies how to do [I-D.ietf-rmt-simple-auth-for-alc-norm]and
multicast packet level authentication, TESLA [PER2001] is a known [I-D.ietf-msec-tesla-for-alc-norm] described packet level
multicast packet authentication scheme that would work. authentication schemes which can be used with the ALC protocol.
In addition to providing protection against reconstruction of In addition to providing protection against reconstruction of
inaccurate objects, packet level authentication can also provide some inaccurate objects, packet level authentication can also provide some
protection against denial of service attacks on the multiple rate protection against denial of service attacks on the multiple rate
congestion control. Attackers can try to inject forged packets with congestion control. Attackers can try to inject forged packets with
incorrect congestion control information into the multicast stream, incorrect congestion control information into the multicast stream,
thereby potentially adversely affecting network elements and thereby potentially adversely affecting network elements and
receivers downstream of the attack, and much less significantly the receivers downstream of the attack, and much less significantly the
rest of the network and other receivers. Thus, it is also rest of the network and other receivers. Thus, it is also
RECOMMENDED that packet level authentication be used to protect RECOMMENDED that packet level authentication be used to protect
against such attacks. TESLA [PER2001] can also be used to some against such attacks. TESLA [I-D.ietf-msec-tesla-for-alc-norm] can
extent to limit the damage caused by such attacks. However, with also be used to some extent to limit the damage caused by such
TESLA a receiver can only determine if a packet is authentic several attacks. However, with TESLA a receiver can only determine if a
seconds after it is received, and thus an attack against the packet is authentic several seconds after it is received, and thus an
congestion control protocol can be effective for several seconds attack against the congestion control protocol can be effective for
before the receiver can react to slow down the session reception several seconds before the receiver can react to slow down the
rate. session reception rate.
Reverse Path Forwarding checks SHOULD be enabled in all network Reverse Path Forwarding checks SHOULD be enabled in all network
routers and switches along the path from the sender to receivers to routers and switches along the path from the sender to receivers to
limit the possibility of a bad agent injecting forged packets into limit the possibility of a bad agent injecting forged packets into
the multicast tree data path. the multicast tree data path.
5.1. Baseline Secure ALC Operation 5.1. Baseline Secure ALC Operation
This section describes a baseline mode of secure ALC protocol This section describes a baseline mode of secure ALC protocol
operation based on application of the IPsec security protocol. This operation based on application of the IPsec security protocol. This
approach is documented here to provide a reference, interoperable approach is documented here to provide a reference, interoperable
secure mode of operation. However, additional approaches to ALC secure mode of operation. However, additional approaches to ALC
security, including other forms of IPsec application, MAY be security, including other forms of IPsec application, MAY be
specified in the future. For example, the use of the EXT_AUTH header specified in the future. For example, the use of the EXT_AUTH header
extension could enable ALC-specific authentication or security extension could enable ALC-specific authentication or security
encapsulation headers similar to those of IPsec to be specified and encapsulation headers similar to those of IPsec to be specified and
inserted into the ALC/LCT protocol message headers. This would allow inserted into the ALC/LCT protocol message headers. This would allow
header compression techniques to be applied to IP and ALC protocol header compression techniques to be applied to IP and ALC protocol
headers when needed in a similar fashion to that of RTP [RFC1889] and headers when needed in a similar fashion to that of RTP [RFC3550] and
as preserved in the specification for Secure Real Time Protocol as preserved in the specification for Secure Real Time Protocol
(SRTP) [RFC3711]. (SRTP) [RFC3711].
The baseline approach described is applicable to ALC operation The baseline approach described is applicable to ALC operation
configured for SSM (or SSM-like) operation where there is a single configured for SSM (or SSM-like) operation where there is a single
sender. The receiver set would maintain a single IPSec Security sender. The receiver set would maintain a single IPSec Security
Association (SA) for each ALC sender. Association (SA) for each ALC sender.
5.1.1. IPsec Approach 5.1.1. IPsec Approach
To suppor this baseline form of secure ALC one-to-many SSM operation, To support this baseline form of secure ALC one-to-many SSM
each node SHALL be configured with a transport mode IPsec Security operation, each node SHALL be configured with a transport mode IPsec
Association and corresponding Security Policy Database (SPD) entry. Security Association and corresponding Security Policy Database (SPD)
This entry will be used for sender-to-group multicast packet entry. This entry will be used for sender-to-group multicast packet
authentication and optionally encryption. authentication and optionally encryption.
The ALC sender SHALL use an IPsec SA configured for ESP protocol The ALC sender SHALL use an IPsec SA configured for ESP protocol
[RFC4303] operation with the option for data origination [RFC4303] operation with the option for data origination
authentication enabled. It is also RECOMMENDED that this IPsec ESP authentication enabled. It is also RECOMMENDED that this IPsec ESP
SA be also configured to provide confidentiality protection for IP SA be also configured to provide confidentiality protection for IP
packets containing ALC protocol messages. This is suggested to make packets containing ALC protocol messages. This is suggested to make
the realization of complex replay attacks much more difficult. The the realization of complex replay attacks much more difficult. The
encryption key for this SA SHALL be preplaced at the sender and encryption key for this SA SHALL be preplaced at the sender and
receiver(s) prior to ALC protocol operation. Use of automated key receiver(s) prior to ALC protocol operation. Use of automated key
skipping to change at page 28, line 12 skipping to change at page 27, line 12
o Definition and IANA registration of the EXT_FTI LCT Header o Definition and IANA registration of the EXT_FTI LCT Header
Extension Extension
9. References 9. References
9.1. Normative references 9.1. Normative references
[I-D.ietf-rmt-bb-lct-revised] [I-D.ietf-rmt-bb-lct-revised]
Luby, M., Watson, M., and L. Vicisano, "Layered Coding Luby, M., Watson, M., and L. Vicisano, "Layered Coding
Transport (LCT) Building Block", Transport (LCT) Building Block",
draft-ietf-rmt-bb-lct-revised-07 (work in progress), draft-ietf-rmt-bb-lct-revised-09 (work in progress),
July 2008. March 2009.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, August 1989. RFC 1112, August 1989.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[RFC2357] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF
Criteria for Evaluating Reliable Multicast Transport and
Application Protocols", RFC 2357, June 1998.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001. Types", RFC 3023, January 2001.
[RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate
Control (WEBRC) Building Block", RFC 3738, April 2004.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error
Correction (FEC) Building Block", RFC 5052, August 2007. Correction (FEC) Building Block", RFC 5052, August 2007.
9.2. Informative references 9.2. Informative references
[PER2001] Perrig, A., Canetti, R., Song, D., and J. Tygar, [I-D.ietf-msec-tesla-for-alc-norm]
"Efficient and Secure Source Authentication for Roca, V., Francillon, A., and S. Faurite, "Use of TESLA in
Multicast", Network and Distributed System Security the ALC and NORM Protocols",
Symposium, NDSS 2001, pp. 35-46 , February 2001. draft-ietf-msec-tesla-for-alc-norm-07 (work in progress),
December 2008.
[RFC1889] Schulzrinne, H., Casner, S., Frederick, R., and V. [I-D.ietf-rmt-simple-auth-for-alc-norm]
Jacobson, "RTP: A Transport Protocol for Real-Time Roca, V., "Simple Authentication Schemes for the ALC and
Applications", RFC 1889, January 1996. NORM Protocols",
draft-ietf-rmt-simple-auth-for-alc-norm-01 (work in
progress), March 2009.
[RFC2357] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF
Criteria for Evaluating Reliable Multicast Transport and
Application Protocols", RFC 2357, June 1998.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000.
[RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M., [RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M.,
Floyd, S., and M. Luby, "Reliable Multicast Transport Floyd, S., and M. Luby, "Reliable Multicast Transport
Building Blocks for One-to-Many Bulk-Data Transfer", Building Blocks for One-to-Many Bulk-Data Transfer",
RFC 3048, January 2001. RFC 3048, January 2001.
[RFC3269] Kermode, R. and L. Vicisano, "Author Guidelines for [RFC3269] Kermode, R. and L. Vicisano, "Author Guidelines for
Reliable Multicast Transport (RMT) Building Blocks and Reliable Multicast Transport (RMT) Building Blocks and
Protocol Instantiation documents", RFC 3269, April 2002. Protocol Instantiation documents", RFC 3269, April 2002.
skipping to change at page 29, line 36 skipping to change at page 28, line 38
Crowcroft, "Asynchronous Layered Coding (ALC) Protocol Crowcroft, "Asynchronous Layered Coding (ALC) Protocol
Instantiation", RFC 3450, December 2002. Instantiation", RFC 3450, December 2002.
[RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, [RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley,
M., and J. Crowcroft, "The Use of Forward Error Correction M., and J. Crowcroft, "The Use of Forward Error Correction
(FEC) in Reliable Multicast", RFC 3453, December 2002. (FEC) in Reliable Multicast", RFC 3453, December 2002.
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The
Group Domain of Interpretation", RFC 3547, July 2003. Group Domain of Interpretation", RFC 3547, July 2003.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004. August 2004.
[RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross,
"GSAKMP: Group Secure Association Key Management "GSAKMP: Group Secure Association Key Management
Protocol", RFC 4535, June 2006. Protocol", RFC 4535, June 2006.
Authors' Addresses Authors' Addresses
Michael Luby Michael Luby
Digital Fountain Qualcomm Inc.
39141 Civic Center Dr. 3165 Kifer Road
Suite 300 Santa Clara, CA 95051
Fremont, CA 94538
US US
Email: luby@digitalfountain.com Email: luby@qualcomm.com
Mark Watson Mark Watson
Digital Fountain Qualcomm Inc.
39141 Civic Center Dr. 3165 Kifer Road
Suite 300 Santa Clara, CA 95051
Fremont, CA 94538
US US
Email: mark@digitalfountain.com Email: watson@qualcomm.com
Lorenzo Vicisano Lorenzo Vicisano
Digital Fountain Qualcomm Inc.
39141 Civic Center Dr. 3165 Kifer Road
Suite 300 Santa Clara, CA 95051
Fremont, CA 94538
US US
Email: lorenzo@digitalfountain.com Email: vicisano@qualcomm.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 44 change blocks. 
155 lines changed or deleted 153 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/