draft-ietf-rmt-pi-norm-revised-13.txt   draft-ietf-rmt-pi-norm-revised-14.txt 
Network Working Group B. Adamson Network Working Group B. Adamson
Internet-Draft Naval Research Laboratory Internet-Draft Naval Research Laboratory
Obsoletes: 3940 (if approved) C. Bormann Obsoletes: 3940 (if approved) C. Bormann
Intended status: Standards Track Universitaet Bremen TZI Intended status: Standards Track Universitaet Bremen TZI
Expires: December 5, 2009 M. Handley Expires: March 15, 2010 M. Handley
University College London University College London
J. Macker J. Macker
Naval Research Laboratory Naval Research Laboratory
June 3, 2009 September 11, 2009
NACK-Oriented Reliable Multicast Transport Protocol NACK-Oriented Reliable Multicast Transport Protocol
draft-ietf-rmt-pi-norm-revised-13 draft-ietf-rmt-pi-norm-revised-14
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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 December 5, 2009. This Internet-Draft will expire on March 15, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
skipping to change at page 3, line 47 skipping to change at page 3, line 47
5.4.4. Sender NORM_CMD(REPAIR_ADV) Generation . . . . . . . . 66 5.4.4. Sender NORM_CMD(REPAIR_ADV) Generation . . . . . . . . 66
5.5. Additional Protocol Mechanisms . . . . . . . . . . . . . . 66 5.5. Additional Protocol Mechanisms . . . . . . . . . . . . . . 66
5.5.1. Group Round-trip Time (GRTT) Collection . . . . . . . 66 5.5.1. Group Round-trip Time (GRTT) Collection . . . . . . . 66
5.5.2. NORM Congestion Control Operation . . . . . . . . . . 68 5.5.2. NORM Congestion Control Operation . . . . . . . . . . 68
5.5.3. NORM Positive Acknowledgment Procedure . . . . . . . . 76 5.5.3. NORM Positive Acknowledgment Procedure . . . . . . . . 76
5.5.4. Group Size Estimate . . . . . . . . . . . . . . . . . 78 5.5.4. Group Size Estimate . . . . . . . . . . . . . . . . . 78
6. Configurable Elements . . . . . . . . . . . . . . . . . . . . 78 6. Configurable Elements . . . . . . . . . . . . . . . . . . . . 78
7. Security Considerations . . . . . . . . . . . . . . . . . . . 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 81
7.1. Baseline Secure NORM Operation . . . . . . . . . . . . . . 83 7.1. Baseline Secure NORM Operation . . . . . . . . . . . . . . 83
7.1.1. IPsec Approach . . . . . . . . . . . . . . . . . . . . 83 7.1.1. IPsec Approach . . . . . . . . . . . . . . . . . . . . 83
7.1.2. IPsec Requirements . . . . . . . . . . . . . . . . . . 85 7.1.2. IPsec Requirements . . . . . . . . . . . . . . . . . . 86
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 87
8.1. Explicit IANA Assignment Guidelines . . . . . . . . . . . 87 8.1. Explicit IANA Assignment Guidelines . . . . . . . . . . . 88
8.1.1. NORM Header Extension Types . . . . . . . . . . . . . 87 8.1.1. NORM Header Extension Types . . . . . . . . . . . . . 88
8.1.2. NORM Stream Control Codes . . . . . . . . . . . . . . 88 8.1.2. NORM Stream Control Codes . . . . . . . . . . . . . . 88
8.1.3. NORM_CMD Message Sub-types . . . . . . . . . . . . . . 88 8.1.3. NORM_CMD Message Sub-types . . . . . . . . . . . . . . 89
9. Suggested Use . . . . . . . . . . . . . . . . . . . . . . . . 89 9. Suggested Use . . . . . . . . . . . . . . . . . . . . . . . . 90
10. Changes from RFC3940 . . . . . . . . . . . . . . . . . . . . . 90 10. Changes from RFC3940 . . . . . . . . . . . . . . . . . . . . . 91
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 91 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 91
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 91 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 92
12.1. Normative References . . . . . . . . . . . . . . . . . . . 91 12.1. Normative References . . . . . . . . . . . . . . . . . . . 92
12.2. Informative References . . . . . . . . . . . . . . . . . . 92 12.2. Informative References . . . . . . . . . . . . . . . . . . 92
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 94
1. Introduction and Applicability 1. Introduction and Applicability
The Negative-acknowledgment (NACK) Oriented Reliable Multicast (NORM) The Negative-acknowledgment (NACK) Oriented Reliable Multicast (NORM)
protocol can provide reliable transport of data from one or more protocol can provide reliable transport of data from one or more
sender(s) to a group of receivers over an IP multicast network. The sender(s) to a group of receivers over an IP multicast network. The
primary design goals of NORM are to provide efficient, scalable, and primary design goals of NORM are to provide efficient, scalable, and
robust bulk data (e.g., computer files, transmission of persistent robust bulk data (e.g., computer files, transmission of persistent
data) transfer across possibly heterogeneous IP networks and data) transfer across possibly heterogeneous IP networks and
topologies. The NORM protocol design provides support for topologies. The NORM protocol design provides support for
skipping to change at page 14, line 43 skipping to change at page 14, line 43
that are REQUIRED in complying NORM protocol implementations: that are REQUIRED in complying NORM protocol implementations:
+------------------------+------------------------------------------+ +------------------------+------------------------------------------+
| Message Type | Purpose | | Message Type | Purpose |
+------------------------+------------------------------------------+ +------------------------+------------------------------------------+
| "NORM_DATA" | Sender message for application data | | "NORM_DATA" | Sender message for application data |
| | transmission. Implementations MUST | | | transmission. Implementations MUST |
| | support at least one of the | | | support at least one of the |
| | "NORM_OBJECT_DATA", "NORM_OBJECT_FILE", | | | "NORM_OBJECT_DATA", "NORM_OBJECT_FILE", |
| | or "NORM_OBJECT_STREAM" delivery | | | or "NORM_OBJECT_STREAM" delivery |
| | services. The use of the NORM FEC | | | services. The use of the NORM FEC Object |
| | Object Transmission Information header | | | Transmission Information header |
| | extension is OPTIONAL with "NORM_DATA" | | | extension is OPTIONAL with "NORM_DATA" |
| | messages. | | | messages. |
| "NORM_CMD(FLUSH)" | Sender command to excite receivers for | | "NORM_CMD(FLUSH)" | Sender command to excite receivers for |
| | repair requests in lieu of ongoing | | | repair requests in lieu of ongoing |
| | "NORM_DATA" transmissions. Note the use | | | "NORM_DATA" transmissions. Note the use |
| | of the "NORM_CMD(FLUSH)" for positive | | | of the "NORM_CMD(FLUSH)" for positive |
| | acknowledgment of data receipt is | | | acknowledgment of data receipt is |
| | OPTIONAL. | | | OPTIONAL. |
| "NORM_CMD(SQUELCH)" | Sender command to advertise its current | | "NORM_CMD(SQUELCH)" | Sender command to advertise its current |
| | valid repair window in response to | | | valid repair window in response to |
skipping to change at page 18, line 37 skipping to change at page 18, line 37
node that sent the message within the context of a single node that sent the message within the context of a single
NormSession. This value is termed the NORM node identifier NormSession. This value is termed the NORM node identifier
(NormNodeId) and unique NormNodeId identifiers MUST be assigned (NormNodeId) and unique NormNodeId identifiers MUST be assigned
within a single NormSession. In some cases, use of the host IPv4 within a single NormSession. In some cases, use of the host IPv4
address or a hash of an address can suffice, but alternative address or a hash of an address can suffice, but alternative
methodologies for assignment and potential collision resolution of methodologies for assignment and potential collision resolution of
node identifiers within a multicast session SHOULD be considered. node identifiers within a multicast session SHOULD be considered.
For example, the techniques for managing the 32-bit "synchronization For example, the techniques for managing the 32-bit "synchronization
source" (SSRC) identifiers defined in the Real-Time Protocol (RTP) source" (SSRC) identifiers defined in the Real-Time Protocol (RTP)
specification [RFC3550] are applicable for use with NORM node specification [RFC3550] are applicable for use with NORM node
identifiers. In most deployments of the NORM protocol to date, the identifiers when an ASM traffic model is observed. In most
NormNodeId assignments are administratively configured. deployments of the NORM protocol to date, the NormNodeId assignments
are administratively configured and this form of NormNodeId
assignment is RECOMMENDED for most purposes. NORM sender NormNodeId
values MUST be unique within an ASM session so that NORM receiver
feedback can be properly demultiplexed by senders and NORM receiver
NormNodeId values MUST be unique to for congestion control operation
and when the OPTIONAL positive acknowledgement mechanism is used.
NORM Header Extensions NORM Header Extensions
When header extensions are applied, they follow the message type's When header extensions are applied, they follow the message type's
base header and precede any payload portion. There are two formats base header and precede any payload portion. There are two formats
for header extensions, both of which begin with an 8-bit "het" for header extensions, both of which begin with an 8-bit "het"
(header extension type) field. One format is provided for variable- (header extension type) field. One format is provided for variable-
length extensions with "het" values in the range from 0 through 127. length extensions with "het" values in the range from 0 through 127.
The other format is for fixed length (one 32-bit word) extensions The other format is for fixed length (one 32-bit word) extensions
with "het" values in the range from 128 through 255. with "het" values in the range from 128 through 255.
skipping to change at page 38, line 15 skipping to change at page 38, line 15
The "invalid_object_list" is a list of 16-bit NormTransportIds that, The "invalid_object_list" is a list of 16-bit NormTransportIds that,
although they are within the range of the sender's current repair although they are within the range of the sender's current repair
window, are no longer available for repair from the sender. For window, are no longer available for repair from the sender. For
example, a sender application MAY dequeue an out-of-date object even example, a sender application MAY dequeue an out-of-date object even
though it is still within the repair window. The total size of the though it is still within the repair window. The total size of the
"invalid_object_list" content is can be determined from the packet's "invalid_object_list" content is can be determined from the packet's
payload length and is limited to a maximum of the NormSegmentSize of payload length and is limited to a maximum of the NormSegmentSize of
the sender. Thus, for very large repair windows, it is possible that the sender. Thus, for very large repair windows, it is possible that
a single "NORM_CMD(SQUELCH)" message cannot include the entire set of a single "NORM_CMD(SQUELCH)" message cannot include the entire set of
invalid objects in the repair window. In this case, the sender SHALL invalid objects in the repair window. In this case, the sender SHALL
ensure that the list begins with a NormObjectId that is greater than ensure that the list begins with a NormTransportId that is greater
or equal to the lowest ordinal invalid NormObjectId from the NACK than or equal to the lowest ordinal invalid NormTransportId from the
message(s) that prompted the "NORM_CMD(SQUELCH)" generation. The NACK message(s) that prompted the "NORM_CMD(SQUELCH)" generation.
NormObjectIds in the "invalid_object_list" MUST be ordinally greater The NormTransportId in the "invalid_object_list" MUST be ordinally
than the "object_transport_id" marking the beginning of the sender's greater than the "object_transport_id" marking the beginning of the
repair window. This insures convergence of the squelch process, even sender's repair window. This insures convergence of the squelch
if multiple invalid NACK/ squelch iterations are required. This process, even if multiple invalid NACK/ squelch iterations are
explicit description of invalid content within the sender's current required. This explicit description of invalid content within the
window allows the sender application (most notably for discrete sender's current window allows the sender application (most notably
object transport) to arbitrarily invalidate (i.e., dequeue) portions for discrete object transport) to arbitrarily invalidate (i.e.,
of enqueued content (e.g., certain objects) for which it no longer dequeue) portions of enqueued content (e.g., certain objects) for
wishes to provide reliable transport. which it no longer wishes to provide reliable transport.
4.2.3.4. NORM_CMD(CC) Message 4.2.3.4. NORM_CMD(CC) Message
The "NORM_CMD(CC)" messages contains fields to enable sender-to-group The "NORM_CMD(CC)" messages contains fields to enable sender-to-group
GRTT measurement and to excite the group for congestion control GRTT measurement and to excite the group for congestion control
feedback. A baseline NORM congestion control scheme (NORM-CC), based feedback. A baseline NORM congestion control scheme (NORM-CC), based
on the TCP-Friendly Multicast Congestion Control (TFMCC) scheme of on the TCP-Friendly Multicast Congestion Control (TFMCC) scheme of
RFC 4654 is fully specified in Section 5.5.2 of this document. The RFC 4654 is fully specified in Section 5.5.2 of this document. The
"NORM_CMD(CC)" message is usually transmitted as part of NORM-CC "NORM_CMD(CC)" message is usually transmitted as part of NORM-CC
congestion control operation. A NORM header extension is defined congestion control operation. A NORM header extension is defined
skipping to change at page 43, line 18 skipping to change at page 43, line 18
the "hdr_len" field when no extensions are present is 4. the "hdr_len" field when no extensions are present is 4.
The "flags" field provide information on the "NORM_CMD(REPAIR_ADV)" The "flags" field provide information on the "NORM_CMD(REPAIR_ADV)"
content. There is currently one "NORM_CMD(REPAIR_ADV)" flag defined: content. There is currently one "NORM_CMD(REPAIR_ADV)" flag defined:
NORM_REPAIR_ADV_FLAG_LIMIT = 0x01 NORM_REPAIR_ADV_FLAG_LIMIT = 0x01
This flag is set by the sender when it is unable to fit its full This flag is set by the sender when it is unable to fit its full
current repair state into a single NormSegmentSize. If this flag is current repair state into a single NormSegmentSize. If this flag is
set, receivers SHALL limit their NACK response to generating NACK set, receivers SHALL limit their NACK response to generating NACK
content only up through the maximum ordinal transmission position content only up through the maximum ordinal transmission position
(objectId::fecPayloadId) included in the "repair_adv_content". (objectTransportId::fecPayloadId) included in the
"repair_adv_content".
When congestion control operation is enabled, a header extension When congestion control operation is enabled, a header extension
SHOULD be applied to the "NORM_CMD(REPAIR_ADV)" representing the most SHOULD be applied to the "NORM_CMD(REPAIR_ADV)" representing the most
limiting (in terms of congestion control feedback suppression) limiting (in terms of congestion control feedback suppression)
congestion control response. This allows the "NORM_CMD(REPAIR_ADV)" congestion control response. This allows the "NORM_CMD(REPAIR_ADV)"
message to suppress receiver congestion control responses as well as message to suppress receiver congestion control responses as well as
NACK feedback messages. The field is defined as a header extension NACK feedback messages. The field is defined as a header extension
so that alternative congestion control schemes can be used for NORM so that alternative congestion control schemes can be used for NORM
without revision to this document. A NORM-CC Feedback Header without revision to this document. A NORM-CC Feedback Header
Extension (EXT_CC) is defined to encapsulate congestion control Extension (EXT_CC) is defined to encapsulate congestion control
skipping to change at page 57, line 14 skipping to change at page 57, line 14
2. The sender transmits an ordinal set of NormObjects segmented in 2. The sender transmits an ordinal set of NormObjects segmented in
the form of "NORM_DATA" messages labeled with NormTransportIds the form of "NORM_DATA" messages labeled with NormTransportIds
and logically identified with FEC encoding block numbers and and logically identified with FEC encoding block numbers and
symbol identifiers. "When applicable, NORM_INFO" messages MAY symbol identifiers. "When applicable, NORM_INFO" messages MAY
optionally precede the transmission of data content for NORM optionally precede the transmission of data content for NORM
transport objects. transport objects.
3. As receivers detect missing content from the sender, they 3. As receivers detect missing content from the sender, they
initiate repair requests with "NORM_NACK" messages. The initiate repair requests with "NORM_NACK" messages. The
receivers track the sender's most recent objectId::fecPayloadId receivers track the sender's most recent objectTransportId::
transmit position and NACK only for content that is ordinally fecPayloadId transmit position and NACK only for content that is
prior to that current transmit position. The receivers schedule ordinally prior to that current transmit position. The receivers
random backoff timeouts before generating "NORM_NACK" messages schedule random backoff timeouts before generating "NORM_NACK"
and wait an appropriate amount of time before repeating the messages and wait an appropriate amount of time before repeating
"NORM_NACK" if their repair request is not satisfied. the "NORM_NACK" if their repair request is not satisfied.
4. The sender aggregates repair requests from the receivers and 4. The sender aggregates repair requests from the receivers and
logically "rewinds" its transmit position to send appropriate logically "rewinds" its transmit position to send appropriate
repair messages. The sender sends repairs for the earliest repair messages. The sender sends repairs for the earliest
ordinal transmit position first and maintains this ordinal repair ordinal transmit position first and maintains this ordinal repair
transmission sequence. FEC parity content not previously transmission sequence. FEC parity content not previously
transmitted for the applicable FEC coding block is used for transmitted for the applicable FEC coding block is used for
repair transmissions to the greatest extent possible. If the repair transmissions to the greatest extent possible. If the
sender exhausts its available FEC parity content on multiple sender exhausts its available FEC parity content on multiple
repair cycles for the same coding block, it resorts to an repair cycles for the same coding block, it resorts to an
skipping to change at page 60, line 42 skipping to change at page 60, line 42
In some deployments, different multicast receivers might have In some deployments, different multicast receivers might have
differing quality of network connectivity. Some receivers may suffer differing quality of network connectivity. Some receivers may suffer
significantly poorer performance with very limited goodput due to low significantly poorer performance with very limited goodput due to low
connection rate or substantial packet loss. Similar to the "join connection rate or substantial packet loss. Similar to the "join
policies" described above, a NORM sender implementation MAY choose to policies" described above, a NORM sender implementation MAY choose to
enforce different "service policies" to perhaps exclude exceptionally enforce different "service policies" to perhaps exclude exceptionally
poor-performing (or otherwise badly-behaving) receivers from the poor-performing (or otherwise badly-behaving) receivers from the
group. The sender implementation could choose to ignore NACKs from group. The sender implementation could choose to ignore NACKs from
such receivers and/or force advancement of its logical "repair such receivers and/or force advancement of its logical "repair
window" (i.e. enforcing a minimal level of service) and use the window" (i.e. Enforcing a minimal level of service) and use the
"NORM_CMD(SQUELCH)" message to advise those poor performers of its "NORM_CMD(SQUELCH)" message to advise those poor performers of its
advance. Note in some cases, the application may need to support the advance. Note in some cases, the application may need to support the
"weakest member" regardless of the time needed to achieve reliable "weakest member" regardless of the time needed to achieve reliable
delivery. When implemented, the protocol instantiation SHOULD expose delivery. When implemented, the protocol instantiation SHOULD expose
controls to the set of "join" and/or "service" policies available to controls to the set of "join" and/or "service" policies available to
support the needs of different applications. support the needs of different applications.
5.3. Receiver NACK Procedure 5.3. Receiver NACK Procedure
When the receiver detects it is missing data from a sender's NORM When the receiver detects it is missing data from a sender's NORM
skipping to change at page 61, line 29 skipping to change at page 61, line 29
SHOULD reset this inactivity timer and repeat NACK initiation upon SHOULD reset this inactivity timer and repeat NACK initiation upon
timeout for up to "NORM_ROBUST_FACTOR" times or more depending upon timeout for up to "NORM_ROBUST_FACTOR" times or more depending upon
the application's need for persistence by its receivers. It is also the application's need for persistence by its receivers. It is also
important receivers rescale the ""T_inactivity"" timeout as the important receivers rescale the ""T_inactivity"" timeout as the
sender's advertised GRTT changes. sender's advertised GRTT changes.
The NACKing procedure begins with a random backoff timeout. The The NACKing procedure begins with a random backoff timeout. The
duration of the backoff timeout is chosen using the "RandomBackoff" duration of the backoff timeout is chosen using the "RandomBackoff"
algorithm described in the Multicast NACK Building Block [RFC5401] algorithm described in the Multicast NACK Building Block [RFC5401]
using ("K_sender*GRTT_sender") for the "maxTime" parameter and the using ("K_sender*GRTT_sender") for the "maxTime" parameter and the
sender advertised group size ("GSIZEsender") as the "groupSize" sender advertised group size ("GSIZE_sender") as the "groupSize"
parameter. NORM senders provide values for "GRTT_sender", "K_sender" parameter. NORM senders provide values for "GRTT_sender", "K_sender"
and "GSIZE_sender" via the "grtt", "backoff", and "gsize" fields of and "GSIZE_sender" via the "grtt", "backoff", and "gsize" fields of
transmitted messages. The "GRTT_sender" value is determined by the transmitted messages. The "GRTT_sender" value is determined by the
sender based on feedback it has received from the group while the sender based on feedback it has received from the group while the
"K_sender" and "GSIZE_sender" values can be determined by application "K_sender" and "GSIZE_sender" values can be determined by application
requirements and expectations or ancillary information. The backoff requirements and expectations or ancillary information. The backoff
factor ""K_sender"" MUST be greater than "one" to provide for factor ""K_sender"" MUST be greater than "one" to provide for
effective feedback suppression. A value of "K_sender = 4" is effective feedback suppression. A value of "K_sender = 4" is
RECOMMENDED for the Any Source Multicast (ASM) model while a value of RECOMMENDED for the Any Source Multicast (ASM) model while a value of
"K_sender = 6" is RECOMMENDED for Single Source Multicast (SSM) "K_sender = 6" is RECOMMENDED for Single Source Multicast (SSM)
skipping to change at page 62, line 6 skipping to change at page 62, line 6
To avoid the possibility of NACK implosion in the case of sender or To avoid the possibility of NACK implosion in the case of sender or
network failure during SSM operation, the receiver SHALL network failure during SSM operation, the receiver SHALL
automatically suppress its NACK and immediately enter the "holdoff" automatically suppress its NACK and immediately enter the "holdoff"
period described below when "T_backoff" is greater than period described below when "T_backoff" is greater than
"(K_sender-1)*GRTT_sender". Otherwise, the backoff period is entered "(K_sender-1)*GRTT_sender". Otherwise, the backoff period is entered
and the receiver MUST accumulate external pending repair state from and the receiver MUST accumulate external pending repair state from
"NORM_NACK" messages and "NORM_CMD(REPAIR_ADV)" messages received. "NORM_NACK" messages and "NORM_CMD(REPAIR_ADV)" messages received.
At the end of the backoff time, the receiver SHALL generate a At the end of the backoff time, the receiver SHALL generate a
"NORM_NACK" message only if the following conditions are met: "NORM_NACK" message only if the following conditions are met:
1. The sender's current transmit position (in terms of objectId:: 1. The sender's current transmit position (in terms of
fecPayloadId) exceeds the earliest repair position of the objectTransportId::fecPayloadId) exceeds the earliest repair
receiver. position of the receiver.
2. The repair state accumulated from "NORM_NACK" and 2. The repair state accumulated from "NORM_NACK" and
"NORM_CMD(REPAIR_ADV)" messages do not equal or supersede the "NORM_CMD(REPAIR_ADV)" messages do not equal or supersede the
receiver's repair needs up to the sender transmission position at receiver's repair needs up to the sender transmission position at
the time the NACK procedure (backoff timeout) was initiated. the time the NACK procedure (backoff timeout) was initiated.
If these conditions are met, the receiver immediately generates a If these conditions are met, the receiver immediately generates a
"NORM_NACK" message when the backoff timeout expires. Otherwise, the "NORM_NACK" message when the backoff timeout expires. Otherwise, the
receiver's NACK is considered to be "suppressed" and the message is receiver's NACK is considered to be "suppressed" and the message is
not sent. At this time, the receiver begins a "holdoff" period not sent. At this time, the receiver begins a "holdoff" period
skipping to change at page 81, line 21 skipping to change at page 81, line 21
7. Security Considerations 7. Security Considerations
The same security considerations that apply to the Multicast NACK The same security considerations that apply to the Multicast NACK
[RFC5401], TFMCC [RFC4654], and FEC [RFC5052] Building Blocks also [RFC5401], TFMCC [RFC4654], and FEC [RFC5052] Building Blocks also
apply to the NORM protocol. In addition to the vulnerabilities to apply to the NORM protocol. In addition to the vulnerabilities to
which any IP and IP multicast protocol implementation are subject, which any IP and IP multicast protocol implementation are subject,
malicious hosts might engage in excessive NACKing in an attempt to malicious hosts might engage in excessive NACKing in an attempt to
prevent the NORM sender(s) from making forward progress in reliable prevent the NORM sender(s) from making forward progress in reliable
transmission. Receiver "join" and "service" policy enforcement as transmission. Receiver "join" and "service" policy enforcement as
described in Section 5.2 can be applied if such activity is detected. described in Section 5.2 can be applied if such activity is detected.
The use of cryptographic authentication and/or confidentiality The use of cryptographic peer authentication, integrity checks,
measures can be used to provide a more effective degree of protection and/or confidentiality mechanisms can be used to provide a more
from objectionable transmissions from unauthorized hosts. But in effective degree of protection from objectionable transmissions from
some cases, even with authentication, the NACK-based feedback of NORM unauthorized hosts. But in some cases, even with authentication and
can be exploited by replay attacks forcing the NORM sender to integrity checks, the NACK-based feedback of NORM can be exploited by
unnecessarily transmit repair information. This MAY be addressed in replay attacks forcing the NORM sender to unnecessarily transmit
part with network layer IP security implementations that guard repair information. This MAY be addressed in part with network layer
against this potential security exploitation or alternatively with a IP security implementations that guard against this potential
security mechanism using the "EXT_AUTH" header extension for similar security exploitation or alternatively with a security mechanism
purposes. Such security mechanisms SHOULD be deployed and used when using the "EXT_AUTH" header extension for similar purposes. Such
available. security mechanisms SHOULD be deployed and used when available. Use
of security mechanisms will impose additional "a priori"
configuration upon the NORM deployment depending upon the techniques
used.
The NORM protocol is compatible with the use of IP security (IPsec) The NORM protocol is compatible with the use of IP security (IPsec)
[RFC4301] and the IPsec Encapsulating Security Payload (ESP) protocol [RFC4301] and the IPsec Encapsulating Security Payload (ESP) protocol
or Authentication Header (AF) extension can be used to secure IP or Authentication Header (AH) extension can be used to secure IP
packets transmitted by NORM participants. A baseline approach to packets transmitted by NORM participants. A baseline approach to
secure NORM operation using IPsec is described below. Compliant secure NORM operation using IPsec is described below. Compliant
implementations of this specification are REQUIRED to be compatible implementations of this specification are REQUIRED to be compatible
with IPsec usage as described in Section 7.1. with IPsec usage as described in Section 7.1. IPsec can be used to
provide peer authentication, integrity protection, and/or encryption
of packets containing NORM messages.
Additionally, the "EXT_AUTH" header extension (HET = 1) is reserved Additionally, the "EXT_AUTH" header extension (HET = 1) is reserved
for use by security mechanisms to provide an alternative form of for use by security mechanisms to provide alternatives to IPsec for
authentication and/or encryption of NORM messages. The format of security of NORM messages. The format of this header extension and
this header extension and its processing is outside the scope of this its processing is outside the scope of this document and is to be
document and is to be communicated out-of-band as part of the session communicated out-of-band as part of the session description. It is
description. It is possible an "EXT_AUTH" implementation of MAY also possible an "EXT_AUTH" implementation of MAY also provide for
provide for encryption of NORM message payloads as well as encryption of NORM message payloads as well as peer authentication
authentication. The use of this approach as compared to IPsec can and integrity protection. The use of this approach as compared to
allow for header compression techniques to be applied jointly to IP IPsec can allow for header compression techniques to be applied
and NORM protocol headers. In cases where security analysis deems jointly to IP and NORM protocol headers. In cases where security
encryption of NORM protocol header content is beneficial or analysis deems encryption of NORM protocol header content is
necessary, the aforementioned use of IPsec ESP might be more beneficial or necessary, the aforementioned use of IPsec ESP might be
appropriate. If "EXT_AUTH" is present, whatever packet more appropriate. Additionally, use of the "EXT_AUTH" header
authentication checks that can be performed immediately upon extension can be used when NORM is used in a network with Network
reception of the packet MUST be performed before accepting the packet Address Translation (NAT) systems that are incompatible with use of
and performing any congestion control-related action on it. Some the IPsec AH extension. If "EXT_AUTH" is present, whatever packet
packet authentication schemes impose a delay of several seconds authentication or integrity checks that can be performed immediately
upon reception of the packet MUST be performed before accepting the
packet and performing any congestion control-related action on it.
Some packet authentication schemes impose a delay of several seconds
between when a packet is received and when the packet can be fully between when a packet is received and when the packet can be fully
authenticated. Any appropriate congestion control related action authenticated. Any appropriate congestion control related action
MUST NOT be postponed by any such full packet authentication (i.e. MUST NOT be postponed by any such packet security mechanism (i.e.
authentication mechanisms MUST NOT result in poor congestion control Security mechanisms MUST NOT result in poor congestion control
behavior). behavior).
Consideration MUST also be given to the potential for replay-attacks Consideration MUST also be given to the potential for replay-attacks
that would transplant authenticated packets from one NORM session to that would transplant authenticated packets from one NORM session to
another to disrupt service. To avoid this potential, unique keys another to disrupt service. To avoid this potential, unique keys
SHOULD be assigned on a per-session basis or NORM sender nodes SHOULD SHOULD be assigned on a per-session basis or NORM sender nodes SHOULD
be configured to use unique "instance_id" identifiers managed as part be configured to use unique "instance_id" identifiers managed as part
of the security association for the sessions. of the security association for the sessions.
Note NORM implementations can use the "sequence" field from the NORM Note NORM implementations can use the "sequence" field from the NORM
skipping to change at page 83, line 4 skipping to change at page 83, line 8
When applicable security measures are used, automated key management When applicable security measures are used, automated key management
mechanisms such as those described in the Group Domain of mechanisms such as those described in the Group Domain of
Interpretation (GDOI) [RFC3547], Multimedia Internet KEYing (MIKEY) Interpretation (GDOI) [RFC3547], Multimedia Internet KEYing (MIKEY)
[RFC3830] or Group Secure Association Key Management Protocol [RFC3830] or Group Secure Association Key Management Protocol
(GSAKMP) [RFC4535] specifications SHOULD be applied. (GSAKMP) [RFC4535] specifications SHOULD be applied.
While NORM does leverage FEC-based repair for scalability, this alone While NORM does leverage FEC-based repair for scalability, this alone
does not guarantee integrity of received data. Application-level does not guarantee integrity of received data. Application-level
integrity-checking of received data content is highly RECOMMENDED. integrity-checking of received data content is highly RECOMMENDED.
This recommendation also applies when the IPsec security approach
described below is used for added assurance in data content integrity
given the shared use of IPsec Security Association information among
the group.
7.1. Baseline Secure NORM Operation 7.1. Baseline Secure NORM Operation
This section describes a baseline mode of secure NORM protocol This section describes a baseline mode of secure NORM 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. Additional approaches to NORM security, secure mode of operation. This particular approach represents one
including other forms of IPsec application, MAY be specified in the possible trade-off in the level of assurance that can be achieved and
future. For example, the use of the EXT_AUTH header extension could the scalability of multicast group-size given current IPsec
enable NORM-specific authentication or security encapsulation headers mechanisms and the state required to support them. For example, this
similar to those of IPsec to be specified and inserted into the NORM baseline approach specifies the use of a Security Association that is
protocol message headers. This would allow header compression shared among the receiver set for feedback messages to the sender.
techniques to be applied to IP and NORM protocol headers when needed This model requires that the receiver membership receiving the
in a similar fashion to RTP [RFC3550] and as preserved in the session keys is trusted and only provides protection from attacks
specification for Secure Real Time Protocol (SRTP) [RFC3711]. that are external to the NORM group membership. More stateful and
complex IPsec approaches and key management schemes may be applied
for higher levels of assurance but those are beyond the scope of this
transport protocol specification. Additional approaches to NORM
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 NORM-specific authentication or security
encapsulation headers similar to those of IPsec to be specified and
inserted into the NORM protocol message headers. This would allow
header compression techniques to be applied to IP and NORM protocol
headers when needed in a similar fashion to RTP [RFC3550] and as
preserved in the specification for Secure Real Time Protocol (SRTP)
[RFC3711].
The baseline approach described is applicable to NORM operation The baseline approach described is applicable to NORM 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 and the receivers are providing unicast feedback. This form sender and the receivers are providing unicast feedback. This form
of NORM operation allows for IPsec to be used with a manageable of NORM operation allows for IPsec to be used with a manageable
number of security associations (SA). number of security associations (SA).
7.1.1. IPsec Approach 7.1.1. IPsec Approach
For NORM one-to-many SSM operation with unicast feedback from For NORM one-to-many SSM operation with unicast feedback from
receivers, each node SHALL be configured with two transport mode receivers, each node SHALL be configured with two transport mode
IPsec security associations and corresponding Security Policy IPsec security associations and corresponding Security Policy
Database (SPD) entries. One entry will be used for sender-to-group Database (SPD) entries. One entry will be used for sender-to-group
multicast packet authentication and optionally encryption while the multicast packet authentication and optionally encryption while the
other entry will be used to provide security for the unicast feedback other entry will be used to provide security for the unicast feedback
messaging from the receiver(s) to the sender. messaging from the receiver(s) to the sender. Note that this single
SA for NORM receiver feedback messages is shared to protect traffic
from possibly multiple receivers to the single sender.
The NORM sender SHALL use an IPsec SA configured for ESP protocol For each NormSession, the NORM sender SHALL use an IPsec SA
[RFC4303] operation with the option for data origination configured for ESP protocol [RFC4303] operation with the option for
authentication enabled. It is also RECOMMENDED this IPsec ESP SA be data origin authentication enabled. It is also RECOMMENDED this
also configured to provide confidentiality protection for IP packets IPsec ESP SA be also configured to provide confidentiality protection
containing NORM protocol messages. This is suggested to make the for IP packets containing NORM protocol messages. This is suggested
realization of complex replay attacks much more difficult. The to make the realization of complex replay attacks much more
encryption key for this SA SHALL be preplaced at the sender and difficult. The encryption key for this SA SHALL be preplaced at the
receiver(s) prior to NORM protocol operation. Use of automated key sender and receiver(s) prior to NORM protocol operation. Use of
management is RECOMMENDED as a rekey SHALL be REQUIRED prior to automated key management is RECOMMENDED as a rekey SHALL be REQUIRED
expiration of the sequence space for the SA. This is necessary so prior to expiration of the sequence space for the SA. This is
receivers can use the built-in IPsec replay attack protection necessary so receivers can use the built-in IPsec replay attack
possible for an IPsec SA with a single source (the NORM sender). protection possible for an IPsec SA with a single source (the NORM
Thus the receivers SHALL enable replay attack protection for this SA sender). Thus the receivers SHALL enable replay attack protection
used to secure NORM sender traffic. An IPsec SPD entry MUST be for this SA used to secure NORM sender traffic. An IPsec SPD entry
configured to process outbound packets to the session (destination) MUST be configured to process outbound packets to the session
address and UDP port number of the applicable (NormSession). (destination) address and UDP port number of the applicable
(NormSession).
The NORM receiver(s) MUST be configured with the SA and SPD entry to The NORM receiver(s) MUST be configured with the SA and SPD entry to
properly process the IPsec-secured packets from the sender. The NORM properly process the IPsec-secured packets from the sender. The NORM
receiver(s) SHALL also use a common, second IPsec SA (common Security receiver(s) SHALL also use a common, second IPsec SA (common Security
Parameter Index (SPI) and encryption key) configured for ESP Parameter Index (SPI) and encryption key) configured for ESP
operation with the option for data origination authentication operation with the option for data origination authentication
enabled. Similar to the NORM sender, is RECOMMENDED this IPsec ESP enabled. Similar to the NORM sender, is RECOMMENDED 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 NORM protocol messages. The receivers MUST have packets containing NORM protocol messages. The receivers MUST have
an IPsec SPD entry configured to process outbound NORM/UDP packets an IPsec SPD entry configured to process outbound NORM/UDP packets
skipping to change at page 84, line 31 skipping to change at page 85, line 5
configured with this common, second SA (and the corresponding SPD configured with this common, second SA (and the corresponding SPD
entry needed) in order to properly process messages from the entry needed) in order to properly process messages from the
receiver. receiver.
Multiple receivers using a common IPsec SA for traffic directed to Multiple receivers using a common IPsec SA for traffic directed to
the NORM sender (i.e., many-to-one) typically prevents the use of the NORM sender (i.e., many-to-one) typically prevents the use of
built-in IPsec replay attack protection by the NORM sender with built-in IPsec replay attack protection by the NORM sender with
current IPsec implementations. Thus the built-in IPsec replay attack current IPsec implementations. Thus the built-in IPsec replay attack
protection for this second SA at the sender MUST be disabled unless protection for this second SA at the sender MUST be disabled unless
the particular IPsec implementation manages its replay protection on the particular IPsec implementation manages its replay protection on
a per-source basis. So, to support a fully secure mode of operation, a per-source basis (which is not typical of existing IPsec
implementations). So, to support a fully secure mode of operation,
the NORM sender implementation MUST provide replay attack protection the NORM sender implementation MUST provide replay attack protection
based upon the "sequence" field of NORM protocol messages from based upon the "sequence" field of NORM protocol messages from
receivers. This can be accomplished with high assurance of security, receivers. This can be accomplished with high assurance of security,
even with the limited size (16-bits) of this field, because even with the limited size (16-bits) of this field, because
1. NORM receiver NACK and non-CLR ACK feedback messages are sparse. 1. NORM receiver NACK and non-CLR ACK feedback messages are sparse.
2. The more frequent "NORM_ACK" feedback from CLR or PLR nodes are 2. The more frequent "NORM_ACK" feedback from CLR or PLR nodes are
only a small set of receivers for which the sender needs to keep only a small set of receivers for which the sender needs to keep
more persistent replay attack state. more persistent replay attack state.
skipping to change at page 85, line 12 skipping to change at page 85, line 36
"NORM_CMD(CC)", or the sender's current repair window in the case "NORM_CMD(CC)", or the sender's current repair window in the case
of ACKs sent in response to "NORM_CMD(FLUSH)". Thus, the sender of ACKs sent in response to "NORM_CMD(FLUSH)". Thus, the sender
can prune any replay attack state for receivers that precede the can prune any replay attack state for receivers that precede the
current applicable sequence or repair window space. current applicable sequence or repair window space.
The use of ESP confidentiality for secure NORM protocol operation The use of ESP confidentiality for secure NORM protocol operation
makes it more difficult for adversaries to conduct any form of replay makes it more difficult for adversaries to conduct any form of replay
attacks. Additionally, a NORM sender implementation with access to attacks. Additionally, a NORM sender implementation with access to
the full ESP protocol header could also use the ESP sequence the full ESP protocol header could also use the ESP sequence
information to make replay attack protection even more robust by information to make replay attack protection even more robust by
maintaining per-source sequence state. The design of this baseline maintaining the per-source ESP sequence state that existing IPsec
security approach for NORM intentionally places any more complex implementations typically do not provide. The design of this
processing state or processing (e.g. replay attack protection given baseline security approach for NORM intentionally places any more
multiple receivers) at the NORM sender since NORM receiver complex processing state or processing (e.g. replay attack protection
given multiple receivers) at the NORM sender since NORM receiver
implementations might often need to be less complex. implementations might often need to be less complex.
This baseline approach can be used for NORM protocol sessions with This baseline approach can be used for NORM protocol sessions with
multiple senders if the SA pairs described are established for each multiple senders if the SA pairs described are established for each
sender. For small-sized groups, it is even possible many-to-many sender. For small-sized groups, it is even possible many-to-many
(ASM) IPsec configuration could be achieved where each participant (ASM) IPsec configuration could be achieved where each participant
uses a unique SA (with a unique SPI). This does not scale to larger uses a unique SA (with a unique SPI). In this case, the sender(s)
group sizes given the complex set of SA and SPD entries each would maintain a SA for each other participant rather than a single,
shared SA for receiver feedback messages. This does not scale to
larger group sizes given the complex set of SA and SPD entries each
participant would need to maintain. participant would need to maintain.
It is anticipated in early deployments of this baseline approach to It is anticipated in early deployments of this baseline approach to
NORM security that key management will be conducted out-of-band with NORM security that key management will be conducted out-of-band with
respect to NORM protocol operation. In the case of one-to-many NORM respect to NORM protocol operation. In the case of one-to-many NORM
operation, it is possible receivers will retrieve keying information operation, it is possible receivers will retrieve keying information
from a central server as needed or otherwise conduct group key from a central server as needed or otherwise conduct group key
updates with a similar centralized approach. Alternatively, it is updates with a similar centralized approach. Alternatively, it is
possible with some key management schemes for rekey messages to be possible with some key management schemes for rekey messages to be
transmitted to the group as a message or transport object within the transmitted to the group as a message or transport object within the
NORM reliable transfer session. Similarly, for group-wise NORM reliable transfer session. Similarly, for group-wise
communication sessions it is possible for potential group communication sessions it is possible for potential group
participants to request keying and/or rekeying as part of NORM participants to request keying and/or rekeying as part of NORM
communications. Additional specification is necessary to define an communications. Additional specification is necessary to define an
in-band key management scheme for NORM sessions perhaps using the in-band key management scheme for NORM sessions perhaps using the
mechanisms of the automated group key management specifications cited mechanisms of the automated group key management specifications cited
in this document. in this document. Additional specification outside of the scope of
this document would be needed to provide an interoperable approach
for key management in-band of a NORM reliable transport session.
7.1.2. IPsec Requirements 7.1.2. IPsec Requirements
In order to implement this secure mode of NORM protocol operation, In order to implement this secure mode of NORM protocol operation,
the following IPsec capabilities are REQUIRED. the following IPsec capabilities are REQUIRED.
7.1.2.1. Selectors 7.1.2.1. Selectors
The implementation MUST be able to use the source address, The implementation MUST be able to use the source address,
destination address, protocol (UDP), and UDP port numbers as destination address, protocol (UDP), and UDP port numbers as
skipping to change at page 86, line 16 skipping to change at page 86, line 45
IPsec in transport mode MUST be supported. The use of IPsec IPsec in transport mode MUST be supported. The use of IPsec
[RFC4301] processing for secure NORM traffic MUST be configured such [RFC4301] processing for secure NORM traffic MUST be configured such
that unauthenticated packets are not received by the NORM protocol that unauthenticated packets are not received by the NORM protocol
implementation. implementation.
7.1.2.3. Key Management 7.1.2.3. Key Management
An automated key management scheme for group key distribution and An automated key management scheme for group key distribution and
rekeying such as GDOI [RFC3547], GSAKMP [RFC4535], or MIKEY [RFC3830] rekeying such as GDOI [RFC3547], GSAKMP [RFC4535], or MIKEY [RFC3830]
is RECOMMENDED for use. Relatively short-lived NORM sessions MAY be is RECOMMENDED for use. Note it is possible for key update messages
able to use Manual Keying with a single, preplaced key, particularly (e.g., the GDOI GROUPKEY-PUSH message) to be included as part of the
if Extended Sequence Numbering (ESN) [RFC4303] is available in the NORM application reliable data transmission if appropriate interfaces
IPsec implementation used. Note it is possible for key update are available between the NORM application and the key management
messages (e.g., the GDOI GROUPKEY-PUSH message) to be included as daemon. Relatively short-lived NORM sessions MAY be able to use
part of the NORM application reliable data transmission if Manual Keying with a single, preplaced key, particularly if Extended
appropriate interfaces are available between the NORM application and Sequence Numbering (ESN) [RFC4303] is available in the IPsec
the key management daemon. implementation used. When manual keys are used, it is important that
cryptographic algorithms suitable for manual key use are selected.
7.1.2.4. Security Policy 7.1.2.4. Security Policy
Receivers MUST accept protocol messages only from the designated, Receivers MUST accept protocol messages only from the designated,
authorized sender(s). Appropriate key management will provide authorized sender(s). Appropriate key management will provide
encryption keys only to receivers authorized to participate in a authentication, integrity and/or encryption keys only to receivers
designated session. The approach outlined here allows receiver sets authorized to participate in a designated session. The approach
to be controlled on a per-sender basis. outlined here allows receiver sets to be controlled on a per-sender
basis.
7.1.2.5. Authentication and Encryption 7.1.2.5. Authentication and Encryption
Large NORM group sizes will necessitate some form of key management Large NORM group sizes will necessitate some form of key management
that does rely upon shared secrets. The GDOI and GSAKMP protocols that does rely upon shared secrets. The GDOI and GSAKMP protocols
mentioned here allow for certificate-based authentication. It is mentioned here allow for certificate-based authentication. It is
RECOMMENDED these certificates use IP addresses for authentication. RECOMMENDED these certificates use IP addresses for authentication.
7.1.2.6. Availability 7.1.2.6. Availability
 End of changes. 31 change blocks. 
118 lines changed or deleted 160 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/