draft-ietf-rmt-pi-alc-revised-05.txt   draft-ietf-rmt-pi-alc-revised-06.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) Digital Fountain
Intended status: Standards Track November 16, 2007 Intended status: Standards Track November 1, 2008
Expires: May 19, 2008 Expires: May 5, 2009
Asynchronous Layered Coding (ALC) Protocol Instantiation Asynchronous Layered Coding (ALC) Protocol Instantiation
draft-ietf-rmt-pi-alc-revised-05 draft-ietf-rmt-pi-alc-revised-06
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes 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. 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
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 19, 2008. This Internet-Draft will expire on May 5, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2007).
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 35 skipping to change at page 2, line 35
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 . . . . . . . . . . . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 5.1. Baseline Secure ALC Operation . . . . . . . . . . . . . . 21
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 5.1.1. IPsec Approach . . . . . . . . . . . . . . . . . . . . 21
8. Changes from RFC3450 . . . . . . . . . . . . . . . . . . . . . 24 5.1.2. IPsec Requirements . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
9.1. Normative references . . . . . . . . . . . . . . . . . . . 25 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
9.2. Informative references . . . . . . . . . . . . . . . . . . 25 8. Changes from RFC3450 . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . . . 28 9.1. Normative references . . . . . . . . . . . . . . . . . . . 28
9.2. Informative references . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
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 22, line 5 skipping to change at page 21, line 23
seconds after it is received, and thus an attack against the seconds after it is received, and thus an attack against the
congestion control protocol can be effective for several seconds congestion control protocol can be effective for several seconds
before the receiver can react to slow down the session reception before the receiver can react to slow down the session reception
rate. 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
This section describes a baseline mode of secure ALC protocol
operation based on application of the IPsec security protocol. This
approach is documented here to provide a reference, interoperable
secure mode of operation. However, additional approaches to ALC
security, including other forms of IPsec application, MAY be
specified in the future. For example, the use of the EXT_AUTH header
extension could enable ALC-specific authentication or security
encapsulation headers similar to those of IPsec to be specified and
inserted into the ALC/LCT protocol message headers. This would allow
header compression techniques to be applied to IP and ALC protocol
headers when needed in a similar fashion to that of RTP [RFC1889] and
as preserved in the specification for Secure Real Time Protocol
(SRTP) [RFC3711].
The baseline approach described is applicable to ALC operation
configured for SSM (or SSM-like) operation where there is a single
sender. The receiver set would maintain a single IPSec Security
Association (SA) for each ALC sender.
5.1.1. IPsec Approach
To suppor this baseline form of secure ALC one-to-many SSM operation,
each node SHALL be configured with a transport mode IPsec Security
Association and corresponding Security Policy Database (SPD) entry.
This entry will be used for sender-to-group multicast packet
authentication and optionally encryption.
The ALC sender SHALL use an IPsec SA configured for ESP protocol
[RFC4303] operation with the option for data origination
authentication enabled. It is also RECOMMENDED that this IPsec ESP
SA be also configured to provide confidentiality protection for IP
packets containing ALC protocol messages. This is suggested to make
the realization of complex replay attacks much more difficult. The
encryption key for this SA SHALL be preplaced at the sender and
receiver(s) prior to ALC protocol operation. Use of automated key
management is RECOMMENDED as a rekey SHALL be required prior to
expiration of the sequence space for the SA. This is necessary so
that receivers may use the built-in IPsec replay attack protection
possible for an IPsec SA with a single source (the ALC sender). Thus
the receivers SHALL enable replay attack protection for this SA used
to secure ALC sender traffic. The sender IPsec SPD entry MUST be
configured to process outbound packets to the destination address and
UDP port number of the applicable ALC session.
The ALC receiver(s) MUST be configured with the SA and SPD entry to
properly process the IPsec-secured packets from the sender. Note
that use of ESP confidentiality, as RECOMMENDED, for secure ALC
protocol operation makes it more difficult for adversaries to conduct
effective replay attacks that may mislead receivers on content
reception. This baseline approach can be used for ALC protocol
sessions with multiple senders if a distinct SA is established for
each sender.
It is anticipated in early deployments of this baseline approach to
ALC security that key management will be conducted out-of-band with
respect to ALC protocol operation. For ALC unidirectional operation,
it is possible that receivers may retrieve keying information from a
central server via out-of-band (with respect to ALC) communication as
needed or otherwise conduct group key updates with a similar
centralized approach. However, it may be possible with some key
management schemes for rekey messages to be transmitted to the group
as a message or transport object within the ALC reliable transfer
session. Additional specification is necessary to define an in-band
key management scheme for ALC sessions perhaps using the mechanisms
of the automated group key management specifications cited in this
document.
5.1.2. IPsec Requirements
In order to implement this secure mode of ALC protocol operation, the
following IPsec capabilities are required.
5.1.2.1. Selectors
The implementation MUST be able to use the source address,
destination address, protocol (UDP), and UDP port numbers as
selectors in the SPD.
5.1.2.2. Mode
IPsec in transport mode MUST be supported. The use of IPsec
[RFC4301] processing for secure ALC traffic SHOULD also be REQUIRED
such that unauthenticated packets are not received by the ALC
protocol implementation .
5.1.2.3. Key Management
An automated key management scheme for group key distribution and
rekeying such as GDOI [RFC3547], GSAKMP [RFC4535], or MIKEY [RFC3830]
SHOULD be used. Relatively short-lived ALC sessions MAY be able to
use Manual Keying with a single, preplaced key, particularly if
Extended Sequence Numbering (ESN) [RFC4303] is available in the IPsec
implementation used. It should also be noted that it may be possible
for key update messages (e.g., the GDOI GROUPKEY-PUSH message) to be
included in the ALC application reliable data transmission as
transport objects if appropriate interfaces were available between
the ALC application and the key management daemon.
5.1.2.4. Security Policy
Receivers SHOULD accept connections only from the designated,
authorized sender(s). It is expected that appropriate key management
will provide encryption keys only to receivers authorized to
participate in a designated session. The approach outlined here
allows receiver sets to be controlled on a per-sender basis.
5.1.2.5. Authentication and Encryption
Large ALC group sizes may necessitate some form of key management
that does rely upon shared secrets. The GDOI and GSAKMP protocols
mentioned here allow for certificate-based authentication. These
certificates SHOULD use IP addresses for authentication. However, it
is likely that available group key management implementations will
not be ALC-specific.
5.1.2.6. Availability
The IPsec requirements profile outlined here is commonly available on
many potential ALC hosts. The principal issue is that configuration
and operation of IPsec typically requires privileged user
authorization. Automated key management implementations are
typically configured with the privileges necessary to effect system
IPsec configuration needed.
6. IANA Considerations 6. IANA Considerations
This specification registers the following LCT Header Extensions This specification registers the following LCT Header Extensions
Types in namespace ietf:rmt:lct:headerExtensionTypes:variableLength: Types in namespace ietf:rmt:lct:headerExtensionTypes:variableLength:
+-------+---------+--------------------+ +-------+---------+--------------------+
| Value | Name | Reference | | Value | Name | Reference |
+-------+---------+--------------------+ +-------+---------+--------------------+
| 64 | EXT_FTI | This specification | | 64 | EXT_FTI | This specification |
+-------+---------+--------------------+ +-------+---------+--------------------+
skipping to change at page 24, line 31 skipping to change at page 27, line 31
o Update references for LCT and FEC Building Block to new versions o Update references for LCT and FEC Building Block to new versions
and align with changes in the FEC Building Block. and align with changes in the FEC Building Block.
o Split normative and informative references o Split normative and informative references
o Material applicable in a general LCT context, not just for ALC has o Material applicable in a general LCT context, not just for ALC has
been moved to LCT been moved to LCT
o The first bit of the "Protocol Specific Indication" in the LCT o The first bit of the "Protocol Specific Indication" in the LCT
Headert is defined as a "Source Packet Indication". This is used Header is defined as a "Source Packet Indication". This is used
in the case that an FEC Scheme defines two FEC Payload ID formats, in the case that an FEC Scheme defines two FEC Payload ID formats,
one of which is for packets containing only source symbols which one of which is for packets containing only source symbols which
can be processed by receivers that do not support FEC Decoding. can be processed by receivers that do not support FEC Decoding.
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., "Layered Coding Transport (LCT) Building Block", Luby, M., Watson, M., and L. Vicisano, "Layered Coding
draft-ietf-rmt-bb-lct-revised-05 (work in progress), Transport (LCT) Building Block",
February 2007. draft-ietf-rmt-bb-lct-revised-07 (work in progress),
July 2008.
[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.
skipping to change at page 25, line 40 skipping to change at page 28, line 41
[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 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000. 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.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[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, [PER2001] Perrig, A., Canetti, R., Song, D., and J. Tygar,
"Efficient and Secure Source Authentication for "Efficient and Secure Source Authentication for
Multicast", Network and Distributed System Security Multicast", Network and Distributed System Security
Symposium, NDSS 2001, pp. 35-46 , February 2001. Symposium, NDSS 2001, pp. 35-46 , February 2001.
[RFC1889] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", RFC 1889, January 1996.
[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.
[RFC3450] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and J. [RFC3450] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and J.
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
Group Domain of Interpretation", RFC 3547, July 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004.
[RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross,
"GSAKMP: Group Secure Association Key Management
Protocol", RFC 4535, June 2006.
Authors' Addresses Authors' Addresses
Michael Luby Michael Luby
Digital Fountain Digital Fountain
39141 Civic Center Dr. 39141 Civic Center Dr.
Suite 300 Suite 300
Fremont, CA 94538 Fremont, CA 94538
US US
Email: luby@digitalfountain.com Email: luby@digitalfountain.com
skipping to change at page 28, line 7 skipping to change at page 31, line 7
Digital Fountain Digital Fountain
39141 Civic Center Dr. 39141 Civic Center Dr.
Suite 300 Suite 300
Fremont, CA 94538 Fremont, CA 94538
US US
Email: lorenzo@digitalfountain.com Email: lorenzo@digitalfountain.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
skipping to change at page 28, line 44 skipping to change at line 1152
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 12 change blocks. 
21 lines changed or deleted 172 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/