draft-thornburgh-adobe-rtmfp-07.txt   draft-thornburgh-adobe-rtmfp-08.txt 
Network Working Group M. Thornburgh Network Working Group M. Thornburgh
Internet-Draft Adobe Internet-Draft Adobe
Intended status: Informational May 2, 2013 Intended status: Informational June 25, 2013
Expires: November 3, 2013 Expires: December 27, 2013
Adobe's Secure Real-Time Media Flow Protocol Adobe's Secure Real-Time Media Flow Protocol
draft-thornburgh-adobe-rtmfp-07 draft-thornburgh-adobe-rtmfp-08
Abstract Abstract
This memo describes the Secure Real-Time Media Flow Protocol (RTMFP), This memo describes Adobe's Secure Real-Time Media Flow Protocol
an endpoint-to-endpoint communication protocol designed to securely (RTMFP), an endpoint-to-endpoint communication protocol designed to
transport parallel flows of real-time video, audio, and data securely transport parallel flows of real-time video, audio, and data
messages, as well as bulk data, over IP networks. RTMFP has features messages, as well as bulk data, over IP networks. RTMFP has features
making it effective for peer-to-peer (P2P) as well as client-server making it effective for peer-to-peer (P2P) as well as client-server
communications, even when Network Address Translators (NATs) are communications, even when Network Address Translators (NATs) are
used. used.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified, provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, except to format it and derivative works of it may not be created, except to format it
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on November 3, 2013. This Internet-Draft will expire on December 27, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Design Highlights of RTMFP . . . . . . . . . . . . . . . 5 1.1. Design Highlights of RTMFP . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Common Elements . . . . . . . . . . . . . . . . . . . . . 7 2.1. Common Elements . . . . . . . . . . . . . . . . . . . . . 7
2.1.1. Elementary Types and Constructs . . . . . . . . . . . 7 2.1.1. Elementary Types and Constructs . . . . . . . . . . . 8
2.1.2. Variable Length Unsigned Integer (VLU) . . . . . . . 9 2.1.2. Variable Length Unsigned Integer (VLU) . . . . . . . 9
2.1.3. Option . . . . . . . . . . . . . . . . . . . . . . . 9 2.1.3. Option . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.4. Option List . . . . . . . . . . . . . . . . . . . . . 10 2.1.4. Option List . . . . . . . . . . . . . . . . . . . . . 10
2.1.5. Internet Socket Address (Address) . . . . . . . . . . 11 2.1.5. Internet Socket Address (Address) . . . . . . . . . . 11
2.2. Network Layer . . . . . . . . . . . . . . . . . . . . . . 12 2.2. Network Layer . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1. Encapsulation . . . . . . . . . . . . . . . . . . . . 12 2.2.1. Encapsulation . . . . . . . . . . . . . . . . . . . . 12
2.2.2. Multiplex . . . . . . . . . . . . . . . . . . . . . . 12 2.2.2. Multiplex . . . . . . . . . . . . . . . . . . . . . . 13
2.2.3. Encryption . . . . . . . . . . . . . . . . . . . . . 13 2.2.3. Encryption . . . . . . . . . . . . . . . . . . . . . 14
2.2.4. Packet . . . . . . . . . . . . . . . . . . . . . . . 14 2.2.4. Packet . . . . . . . . . . . . . . . . . . . . . . . 14
2.3. Chunks . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.3. Chunks . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.1. Packet Fragment Chunk . . . . . . . . . . . . . . . . 19 2.3.1. Packet Fragment Chunk . . . . . . . . . . . . . . . . 19
2.3.2. Initiator Hello Chunk (IHello) . . . . . . . . . . . 20 2.3.2. Initiator Hello Chunk (IHello) . . . . . . . . . . . 20
2.3.3. Forwarded Initiator Hello Chunk (FIHello) . . . . . . 20 2.3.3. Forwarded Initiator Hello Chunk (FIHello) . . . . . . 20
2.3.4. Responder Hello Chunk (RHello) . . . . . . . . . . . 21 2.3.4. Responder Hello Chunk (RHello) . . . . . . . . . . . 21
2.3.5. Responder Redirect Chunk (Redirect) . . . . . . . . . 22 2.3.5. Responder Redirect Chunk (Redirect) . . . . . . . . . 22
2.3.6. RHello Cookie Change Chunk . . . . . . . . . . . . . 24 2.3.6. RHello Cookie Change Chunk . . . . . . . . . . . . . 24
2.3.7. Initiator Initial Keying Chunk (IIKeying) . . . . . . 25 2.3.7. Initiator Initial Keying Chunk (IIKeying) . . . . . . 25
2.3.8. Responder Initial Keying Chunk (RIKeying) . . . . . . 26 2.3.8. Responder Initial Keying Chunk (RIKeying) . . . . . . 26
skipping to change at page 3, line 7 skipping to change at page 3, line 7
2.3.14. Data Acknowledgement Ranges Chunk (Range Ack) . . . . 37 2.3.14. Data Acknowledgement Ranges Chunk (Range Ack) . . . . 37
2.3.15. Buffer Probe Chunk . . . . . . . . . . . . . . . . . 39 2.3.15. Buffer Probe Chunk . . . . . . . . . . . . . . . . . 39
2.3.16. Flow Exception Report Chunk . . . . . . . . . . . . . 40 2.3.16. Flow Exception Report Chunk . . . . . . . . . . . . . 40
2.3.17. Session Close Request Chunk (Close) . . . . . . . . . 41 2.3.17. Session Close Request Chunk (Close) . . . . . . . . . 41
2.3.18. Session Close Acknowledgement Chunk (Close Ack) . . . 41 2.3.18. Session Close Acknowledgement Chunk (Close Ack) . . . 41
3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 42 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 42
3.2. Endpoint Identity . . . . . . . . . . . . . . . . . . . . 43 3.2. Endpoint Identity . . . . . . . . . . . . . . . . . . . . 43
3.3. Packet Multiplex . . . . . . . . . . . . . . . . . . . . 45 3.3. Packet Multiplex . . . . . . . . . . . . . . . . . . . . 45
3.4. Packet Fragmentation . . . . . . . . . . . . . . . . . . 45 3.4. Packet Fragmentation . . . . . . . . . . . . . . . . . . 45
3.5. Sessions . . . . . . . . . . . . . . . . . . . . . . . . 46 3.5. Sessions . . . . . . . . . . . . . . . . . . . . . . . . 47
3.5.1. Startup . . . . . . . . . . . . . . . . . . . . . . . 49 3.5.1. Startup . . . . . . . . . . . . . . . . . . . . . . . 49
3.5.1.1. Normal Handshake . . . . . . . . . . . . . . . . 49 3.5.1.1. Normal Handshake . . . . . . . . . . . . . . . . 49
3.5.1.1.1. Initiator . . . . . . . . . . . . . . . . . 50 3.5.1.1.1. Initiator . . . . . . . . . . . . . . . . . 50
3.5.1.1.2. Responder . . . . . . . . . . . . . . . . . 51 3.5.1.1.2. Responder . . . . . . . . . . . . . . . . . 52
3.5.1.2. Cookie Change . . . . . . . . . . . . . . . . . 53 3.5.1.2. Cookie Change . . . . . . . . . . . . . . . . . 54
3.5.1.3. Glare . . . . . . . . . . . . . . . . . . . . . 55 3.5.1.3. Glare . . . . . . . . . . . . . . . . . . . . . 56
3.5.1.4. Redirector . . . . . . . . . . . . . . . . . . . 56 3.5.1.4. Redirector . . . . . . . . . . . . . . . . . . . 57
3.5.1.5. Forwarder . . . . . . . . . . . . . . . . . . . 57 3.5.1.5. Forwarder . . . . . . . . . . . . . . . . . . . 58
3.5.1.6. Redirector and Forwarder with NAT . . . . . . . 59 3.5.1.6. Redirector and Forwarder with NAT . . . . . . . 60
3.5.1.7. Load Distribution and Fault Tolerance . . . . . 62 3.5.1.7. Load Distribution and Fault Tolerance . . . . . 63
3.5.2. Congestion Control . . . . . . . . . . . . . . . . . 63 3.5.2. Congestion Control . . . . . . . . . . . . . . . . . 64
3.5.2.1. Time Critical Reverse Notification . . . . . . . 64 3.5.2.1. Time Critical Reverse Notification . . . . . . . 65
3.5.2.2. Retransmission Timeout . . . . . . . . . . . . . 64 3.5.2.2. Retransmission Timeout . . . . . . . . . . . . . 65
3.5.2.3. Burst Avoidance . . . . . . . . . . . . . . . . 66 3.5.2.3. Burst Avoidance . . . . . . . . . . . . . . . . 67
3.5.3. Address Mobility . . . . . . . . . . . . . . . . . . 67 3.5.3. Address Mobility . . . . . . . . . . . . . . . . . . 68
3.5.4. Ping . . . . . . . . . . . . . . . . . . . . . . . . 67 3.5.4. Ping . . . . . . . . . . . . . . . . . . . . . . . . 68
3.5.4.1. Keepalive . . . . . . . . . . . . . . . . . . . 68 3.5.4.1. Keepalive . . . . . . . . . . . . . . . . . . . 69
3.5.4.2. Address Mobility . . . . . . . . . . . . . . . . 68 3.5.4.2. Address Mobility . . . . . . . . . . . . . . . . 69
3.5.4.3. Path MTU Discovery . . . . . . . . . . . . . . . 69 3.5.4.3. Path MTU Discovery . . . . . . . . . . . . . . . 70
3.5.5. Close . . . . . . . . . . . . . . . . . . . . . . . . 69 3.5.5. Close . . . . . . . . . . . . . . . . . . . . . . . . 70
3.6. Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 70 3.6. Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.6.1. Overview . . . . . . . . . . . . . . . . . . . . . . 70 3.6.1. Overview . . . . . . . . . . . . . . . . . . . . . . 71
3.6.1.1. Identity . . . . . . . . . . . . . . . . . . . . 71 3.6.1.1. Identity . . . . . . . . . . . . . . . . . . . . 72
3.6.1.2. Messages and Sequencing . . . . . . . . . . . . 71 3.6.1.2. Messages and Sequencing . . . . . . . . . . . . 72
3.6.1.3. Lifetime . . . . . . . . . . . . . . . . . . . . 72 3.6.1.3. Lifetime . . . . . . . . . . . . . . . . . . . . 73
3.6.2. Sender . . . . . . . . . . . . . . . . . . . . . . . 73 3.6.2. Sender . . . . . . . . . . . . . . . . . . . . . . . 74
3.6.2.1. Startup . . . . . . . . . . . . . . . . . . . . 75 3.6.2.1. Startup . . . . . . . . . . . . . . . . . . . . 76
3.6.2.2. Queuing Data . . . . . . . . . . . . . . . . . . 76 3.6.2.2. Queuing Data . . . . . . . . . . . . . . . . . . 77
3.6.2.3. Sending Data . . . . . . . . . . . . . . . . . . 76 3.6.2.3. Sending Data . . . . . . . . . . . . . . . . . . 77
3.6.2.3.1. Startup Options . . . . . . . . . . . . . . 78 3.6.2.3.1. Startup Options . . . . . . . . . . . . . . 79
3.6.2.3.2. Send Next Data . . . . . . . . . . . . . . . 78 3.6.2.3.2. Send Next Data . . . . . . . . . . . . . . . 79
3.6.2.4. Processing Acknowledgements . . . . . . . . . . 79 3.6.2.4. Processing Acknowledgements . . . . . . . . . . 80
3.6.2.5. Negative Acknowledgement and Loss . . . . . . . 79 3.6.2.5. Negative Acknowledgement and Loss . . . . . . . 80
3.6.2.6. Timeout . . . . . . . . . . . . . . . . . . . . 80 3.6.2.6. Timeout . . . . . . . . . . . . . . . . . . . . 81
3.6.2.7. Abandoning Data . . . . . . . . . . . . . . . . 81 3.6.2.7. Abandoning Data . . . . . . . . . . . . . . . . 82
3.6.2.7.1. Forward Sequence Number Update . . . . . . . 81 3.6.2.7.1. Forward Sequence Number Update . . . . . . . 82
3.6.2.8. Examples . . . . . . . . . . . . . . . . . . . . 82 3.6.2.8. Examples . . . . . . . . . . . . . . . . . . . . 83
3.6.2.9. Flow Control . . . . . . . . . . . . . . . . . . 83 3.6.2.9. Flow Control . . . . . . . . . . . . . . . . . . 84
3.6.2.9.1. Buffer Probe . . . . . . . . . . . . . . . . 84 3.6.2.9.1. Buffer Probe . . . . . . . . . . . . . . . . 85
3.6.2.10. Exception . . . . . . . . . . . . . . . . . . . 84 3.6.2.10. Exception . . . . . . . . . . . . . . . . . . . 85
3.6.2.11. Close . . . . . . . . . . . . . . . . . . . . . 84 3.6.2.11. Close . . . . . . . . . . . . . . . . . . . . . 85
3.6.3. Receiver . . . . . . . . . . . . . . . . . . . . . . 85 3.6.3. Receiver . . . . . . . . . . . . . . . . . . . . . . 86
3.6.3.1. Startup . . . . . . . . . . . . . . . . . . . . 87 3.6.3.1. Startup . . . . . . . . . . . . . . . . . . . . 88
3.6.3.2. Receiving Data . . . . . . . . . . . . . . . . . 88 3.6.3.2. Receiving Data . . . . . . . . . . . . . . . . . 89
3.6.3.3. Buffering and Delivering Data . . . . . . . . . 90 3.6.3.3. Buffering and Delivering Data . . . . . . . . . 91
3.6.3.4. Acknowledging Data . . . . . . . . . . . . . . . 92 3.6.3.4. Acknowledging Data . . . . . . . . . . . . . . . 93
3.6.3.4.1. Timing . . . . . . . . . . . . . . . . . . . 92 3.6.3.4.1. Timing . . . . . . . . . . . . . . . . . . . 93
3.6.3.4.2. Size and Truncation . . . . . . . . . . . . 93 3.6.3.4.2. Size and Truncation . . . . . . . . . . . . 94
3.6.3.4.3. Constructing . . . . . . . . . . . . . . . . 94 3.6.3.4.3. Constructing . . . . . . . . . . . . . . . . 95
3.6.3.4.4. Delayed Acknowledgement . . . . . . . . . . 94 3.6.3.4.4. Delayed Acknowledgement . . . . . . . . . . 95
3.6.3.4.5. Obligatory Acknowledgement . . . . . . . . . 94 3.6.3.4.5. Obligatory Acknowledgement . . . . . . . . . 95
3.6.3.4.6. Opportunistic Acknowledgement . . . . . . . 95 3.6.3.4.6. Opportunistic Acknowledgement . . . . . . . 96
3.6.3.4.7. Example . . . . . . . . . . . . . . . . . . 95 3.6.3.4.7. Example . . . . . . . . . . . . . . . . . . 96
3.6.3.5. Flow Control . . . . . . . . . . . . . . . . . . 96 3.6.3.5. Flow Control . . . . . . . . . . . . . . . . . . 97
3.6.3.6. Receiving a Buffer Probe . . . . . . . . . . . . 97 3.6.3.6. Receiving a Buffer Probe . . . . . . . . . . . . 98
3.6.3.7. Rejecting a Flow . . . . . . . . . . . . . . . . 98 3.6.3.7. Rejecting a Flow . . . . . . . . . . . . . . . . 99
3.6.3.8. Close . . . . . . . . . . . . . . . . . . . . . 98 3.6.3.8. Close . . . . . . . . . . . . . . . . . . . . . 99
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 99 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 100
5. Security Considerations . . . . . . . . . . . . . . . . . . . 99 5. Security Considerations . . . . . . . . . . . . . . . . . . . 100
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 100 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 102
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 101 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 102
7.1. Normative References . . . . . . . . . . . . . . . . . . 101 7.1. Normative References . . . . . . . . . . . . . . . . . . 102
7.2. Informative References . . . . . . . . . . . . . . . . . 101 7.2. Informative References . . . . . . . . . . . . . . . . . 102
Appendix A. Example Congestion Control Algorithm . . . . . . . . 101 Appendix A. Example Congestion Control Algorithm . . . . . . . . 103
A.1. Discussion . . . . . . . . . . . . . . . . . . . . . . . 102 A.1. Discussion . . . . . . . . . . . . . . . . . . . . . . . 103
A.2. Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 103 A.2. Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 104
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 106 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 107
1. Introduction 1. Introduction
Adobe's Secure Real-Time Media Flow Protocol (RTMFP) is intended for Adobe's Secure Real-Time Media Flow Protocol (RTMFP) is intended for
use as an endpoint-to-endpoint data transport service in IP networks. use as an endpoint-to-endpoint data transport service in IP networks.
It has features that make it well suited to the transport of real- It has features that make it well suited to the transport of real-
time media (such as low-delay video, audio, and data) as well as bulk time media (such as low-delay video, audio, and data) as well as bulk
data, and for client-server as well as peer-to-peer (P2P) data, and for client-server as well as peer-to-peer (P2P)
communication. These features include independent parallel message communication. These features include independent parallel message
flows which may have different delivery priorities, variable message flows which may have different delivery priorities, variable message
reliability (from TCP-like full reliability to UDP-like best effort), reliability (from TCP-like full reliability to UDP-like best effort),
multi-point congestion control, and built-in security. Session multi-point congestion control, and built-in security. Session
multiplexing and facilities to support UDP hole-punching simplify multiplexing and facilities to support UDP hole-punching simplify
Network Address Translator (NAT) traversal in peer-to-peer systems. Network Address Translator (NAT) traversal in peer-to-peer systems.
RTMFP is implemented in Flash Player, Adobe Integrated Runtime (AIR), RTMFP is implemented in Flash Player, Adobe Integrated Runtime (AIR),
and Adobe Media Server (AMS, formerly Flash Media Server or FMS), all and Adobe Media Server (AMS, formerly Flash Media Server or FMS), all
from Adobe Systems Incorporated, and is used as the foundation from Adobe Systems Incorporated, and is used as the foundation
transport protocol for real-time and P2P communication in those transport protocol for real-time video, audio, and data
products. At the time of writing, the Adobe Flash Player runtime is communication, both client-server and P2P, in those products. At the
installed on more than one billion end-user desktop computers. time of writing, the Adobe Flash Player runtime is installed on more
than one billion end-user desktop computers.
RTMFP was developed by Adobe Systems Incorporated, and is not the
product of an IETF activity.
This memo describes the syntax and operation of the Secure Real-Time This memo describes the syntax and operation of the Secure Real-Time
Media Flow Protocol. Media Flow Protocol.
1.1. Design Highlights of RTMFP 1.1. Design Highlights of RTMFP
Between any pair of communicating endpoints is a single,
bidirectional, secured, congestion controlled session.
Unidirectional flows convey messages from one end to the other within
the session. An endpoint can have concurrent sessions with multiple
other far endpoints.
Design highlights of RTMFP include:
o The security framework is an in-band part of the basic protocol o The security framework is an in-band part of the basic protocol
and is always on. The application designer chooses the and is always on. The application designer chooses the
cryptographic formats and algorithms to suit the needs of the cryptographic formats and algorithms to suit the needs of the
application, and may update them as the state of the security arts application, and may update them as the state of the security arts
progresses. progresses.
o Cryptographic Endpoint Discriminators can resist port scanning. o Cryptographic Endpoint Discriminators can resist port scanning.
o All header, control, and framing information, except for network o All header, control, and framing information, except for network
addressing information and a session identifier, is encrypted. addressing information and a session identifier, is encrypted.
skipping to change at page 6, line 47 skipping to change at page 7, line 10
o P2P lookup and peer introduction (including UDP hole punching for o P2P lookup and peer introduction (including UDP hole punching for
NAT and firewall traversal) is supported directly by the session NAT and firewall traversal) is supported directly by the session
startup handshake. startup handshake.
o Session identifiers allow an endpoint to multiplex many sessions o Session identifiers allow an endpoint to multiplex many sessions
over a single local transport address while allowing sessions to over a single local transport address while allowing sessions to
survive changes in transport address (as may happen in mobile or survive changes in transport address (as may happen in mobile or
wireless deployments). wireless deployments).
The syntax of the protocol is detailed in Section 2. The operation
of the protocol is detailed in Section 3.
1.2. Terminology 1.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
The key phrase "MUST ONLY" in this document means that a particular
item is absolutely prohibited if the conditional circumstance does
not hold. The item is allowed if the conditional circumstance holds.
2. Syntax 2. Syntax
Definitions of types and structures in this specification use Definitions of types and structures in this specification use
traditional text diagrams paired with procedural descriptions using a traditional text diagrams paired with procedural descriptions using a
C-like syntax. The C-like procedural descriptions SHALL be construed C-like syntax. The C-like procedural descriptions SHALL be construed
as definitive. as definitive.
Structures are packed to take only as many bytes as explicitly Structures are packed to take only as many bytes as explicitly
indicated. There is no 32-bit alignment constraint, and fields are indicated. There is no 32-bit alignment constraint, and fields are
not padded for alignment unless explicitly indicated or described. not padded for alignment unless explicitly indicated or described.
skipping to change at page 13, line 35 skipping to change at page 14, line 18
This specification doesn't mandate a particular choice of This specification doesn't mandate a particular choice of
cryptography. The application defines the cryptographic syntax and cryptography. The application defines the cryptographic syntax and
algorithms. algorithms.
Packet encryption is RECOMMENDED to be a block cipher operating in Packet encryption is RECOMMENDED to be a block cipher operating in
Cipher Block Chaining [CBC] or similar mode. Encrypted packets MUST Cipher Block Chaining [CBC] or similar mode. Encrypted packets MUST
be decipherable without inter-packet dependency, since packets may be be decipherable without inter-packet dependency, since packets may be
lost, duplicated, or reordered in the network. lost, duplicated, or reordered in the network.
The packet encryption layer is responsible for data integrity and The packet encryption layer is responsible for data integrity and
authenticity, for example by means of a checksum or cryptographic authenticity of packets, for example by means of a checksum or
message authentication code. cryptographic message authentication code. To mitigate replay
attacks, data integrity SHOULD comprise duplicate packet detection,
for example by means of a session-wide packet sequence number. The
packet encryption layer SHALL discard a received packet that does not
pass integrity or authenticity tests.
Note that the structures described below are of plain, unencrypted Note that the structures described below are of plain, unencrypted
packets. Encrypted packets MUST be decrypted according to the packets. Encrypted packets MUST be decrypted according to the
Session Key associated with the Multiplex Session ID before being Session Key associated with the Multiplex Session ID before being
interpreted according to this specification. interpreted according to this specification.
The cryptography profile defines a well-known Default Session Key The cryptography profile defines a well-known Default Session Key
that is used at session startup, during which per-session key(s) are that is used at session startup, during which per-session key(s) are
negotiated by the two endpoints. A Session ID of zero denotes use of negotiated by the two endpoints. A Session ID of zero denotes use of
the Default Session Key. The Default Session Key is also used with the Default Session Key. The Default Session Key is also used with
skipping to change at page 17, line 16 skipping to change at page 17, line 16
invalid and MUST be discarded. invalid and MUST be discarded.
The original initiator of a session MUST mark all non-startup packets The original initiator of a session MUST mark all non-startup packets
it sends in that session with packet mode 1 "Initiator Mark". It it sends in that session with packet mode 1 "Initiator Mark". It
SHOULD ignore any packet received in that session with packet mode 1. SHOULD ignore any packet received in that session with packet mode 1.
The original responder of a session MUST mark all non-startup packets The original responder of a session MUST mark all non-startup packets
it sends in that session with packet mode 2 "Responder Mark". It it sends in that session with packet mode 2 "Responder Mark". It
SHOULD ignore any packet received in that session with packet mode 2. SHOULD ignore any packet received in that session with packet mode 2.
Packet mode 3 is for session startup. Session startup chunks MUST Packet mode 3 is for session startup. Session startup chunks are
ONLY be in packets with this mode. only allowed in packets with this mode.
Chunks that are not for session startup MUST ONLY be in packets with Chunks that are not for session startup are only allowed in packets
modes 1 or 2. with modes 1 or 2.
2.3. Chunks 2.3. Chunks
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunkType | chunkLength | | chunkType | chunkLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
| chunkPayload (chunkLength bytes, may be zero) | | chunkPayload (chunkLength bytes, may be zero) |
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/
skipping to change at page 20, line 13 skipping to change at page 20, line 13
Fragments are numbered consecutively. Fragments are numbered consecutively.
packetFragment : The bytes of the indicated segment of the indicated packetFragment : The bytes of the indicated segment of the indicated
original plain RTMFP packet. A packetFragment MUST NOT be empty. original plain RTMFP packet. A packetFragment MUST NOT be empty.
The use of this mechanism is detailed in Section 3.4. The use of this mechanism is detailed in Section 3.4.
2.3.2. Initiator Hello Chunk (IHello) 2.3.2. Initiator Hello Chunk (IHello)
This chunk is sent by the initiator of a new session to begin the This chunk is sent by the initiator of a new session to begin the
startup handshake. This chunk MUST ONLY be in a packet with Session startup handshake. This chunk is only allowed in a packet with
ID 0, encrypted with the default session key, and having packet mode Session ID 0, encrypted with the default session key, and having
3 (Startup). packet mode 3 (Startup).
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x30 | chunkLength | | 0x30 | chunkLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-------------/-+-----------------------------------------------+ +-------------/-+-----------------------------------------------+
| epdLength \ | endpointDiscriminator (epdLength bytes) | | epdLength \ | endpointDiscriminator (epdLength bytes) |
+-------------/-+-----------------------------------------------/ +-------------/-+-----------------------------------------------/
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| tag | | tag |
skipping to change at page 20, line 50 skipping to change at page 20, line 50
tag : Initiator-provided data to be returned in a Responder Hello's tag : Initiator-provided data to be returned in a Responder Hello's
tagEcho field. The tag/tagEcho is used to match Responder Hellos tagEcho field. The tag/tagEcho is used to match Responder Hellos
to the initiator's session startup state independent of the to the initiator's session startup state independent of the
responder's address. responder's address.
The use of IHello is detailed in Section 3.5.1. The use of IHello is detailed in Section 3.5.1.
2.3.3. Forwarded Initiator Hello Chunk (FIHello) 2.3.3. Forwarded Initiator Hello Chunk (FIHello)
This chunk is sent on behalf of an initiator by a Forwarder. It MUST This chunk is sent on behalf of an initiator by a Forwarder. It is
ONLY be sent in an established session having packet mode 1 or 2. A only allowed in packets of an established session having packet mode
receiver MAY treat this chunk as though it was an Initiator Hello 1 or 2. A receiver MAY treat this chunk as though it was an
received directly from replyAddress. Alternatively, if the receiver Initiator Hello received directly from replyAddress. Alternatively,
is selected by the Endpoint Discriminator, it MAY respond to if the receiver is selected by the Endpoint Discriminator, it MAY
replyAddress with an Implied Redirect (Section 2.3.5). respond to replyAddress with an Implied Redirect (Section 2.3.5).
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0f | chunkLength | | 0x0f | chunkLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-------------/-+-----------------------------------------------+ +-------------/-+-----------------------------------------------+
| epdLength \ | endpointDiscriminator (epdLength bytes) | | epdLength \ | endpointDiscriminator (epdLength bytes) |
+-------------/-+-----------------------------------------------/ +-------------/-+-----------------------------------------------/
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| replyAddress | | replyAddress |
skipping to change at page 21, line 49 skipping to change at page 21, line 49
which the receiver should respond. which the receiver should respond.
tag : Copied from the original Initiator Hello. tag : Copied from the original Initiator Hello.
The use of FIHello is detailed in Section 3.5.1.5. The use of FIHello is detailed in Section 3.5.1.5.
2.3.4. Responder Hello Chunk (RHello) 2.3.4. Responder Hello Chunk (RHello)
This chunk is sent by a responder in response to an Initiator Hello This chunk is sent by a responder in response to an Initiator Hello
or Forwarded Initiator Hello if the Endpoint Discriminator indicates or Forwarded Initiator Hello if the Endpoint Discriminator indicates
the responder's identity. This chunk MUST ONLY be in a packet with the responder's identity. This chunk is only allowed in a packet
Session ID 0, encrypted with the default session key, and having with Session ID 0, encrypted with the default session key, and having
packet mode 3 (Startup). packet mode 3 (Startup).
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x70 | chunkLength | | 0x70 | chunkLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-------------/-+-----------------------------------------------+ +-------------/-+-----------------------------------------------+
| tagLength \ | tagEcho (tagLength bytes) | | tagLength \ | tagEcho (tagLength bytes) |
+-------------/-+-----------------------------------------------/ +-------------/-+-----------------------------------------------/
+-------------/-+-----------------------------------------------+ +-------------/-+-----------------------------------------------+
skipping to change at page 23, line 5 skipping to change at page 23, line 5
The use of RHello is detailed in Section 3.5.1. The use of RHello is detailed in Section 3.5.1.
2.3.5. Responder Redirect Chunk (Redirect) 2.3.5. Responder Redirect Chunk (Redirect)
This chunk is sent in response to an Initiator Hello or Forwarded This chunk is sent in response to an Initiator Hello or Forwarded
Initiator Hello to indicate that the requested endpoint can be Initiator Hello to indicate that the requested endpoint can be
reached at one or more of the indicated address(es). A receiver can reached at one or more of the indicated address(es). A receiver can
add none, some, or all of the indicated address(es) to the set of add none, some, or all of the indicated address(es) to the set of
addresses to which it is sending Initiator Hello messages for the addresses to which it is sending Initiator Hello messages for the
opening session associated with tagEcho. This chunk MUST ONLY be in opening session associated with tagEcho. This chunk is only allowed
a packet with Session ID 0, encrypted with the default session key, in a packet with Session ID 0, encrypted with the default session
and having packet mode 3 (Startup). key, and having packet mode 3 (Startup).
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x71 | chunkLength | | 0x71 | chunkLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-------------/-+-----------------------------------------------+ +-------------/-+-----------------------------------------------+
| tagLength \ | tagEcho (tagLength bytes) | | tagLength \ | tagEcho (tagLength bytes) |
+-------------/-+-----------------------------------------------/ +-------------/-+-----------------------------------------------/
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
| redirectDestination 1 | | redirectDestination 1 |
skipping to change at page 24, line 14 skipping to change at page 24, line 14
2.3.6. RHello Cookie Change Chunk 2.3.6. RHello Cookie Change Chunk
This chunk SHOULD be sent by a responder to an initiator in response This chunk SHOULD be sent by a responder to an initiator in response
to an Initiator Initial Keying if that chunk's cookie appears to have to an Initiator Initial Keying if that chunk's cookie appears to have
been created by the responder but the cookie is incorrect (for been created by the responder but the cookie is incorrect (for
example, it includes a hash of the initiator's address, but the example, it includes a hash of the initiator's address, but the
initiator's address is different than the one which elicited the initiator's address is different than the one which elicited the
Responder Hello containing the original cookie). Responder Hello containing the original cookie).
This chunk MUST ONLY be sent in a packet encrypted with the default This chunk is only allowed in a packet encrypted with the default
session key and having packet mode 3, and with the Session ID session key and having packet mode 3, and with the Session ID
indicated in the initiatorSessionID field of the Initiator Initial indicated in the initiatorSessionID field of the Initiator Initial
Keying to which this is a response. Keying to which this is a response.
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x79 | chunkLength | | 0x79 | chunkLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-------------/-+-----------------------------------------------+ +-------------/-+-----------------------------------------------+
| oldCookieLen\ | oldCookie (oldCookieLen bytes) | | oldCookieLen\ | oldCookie (oldCookieLen bytes) |
skipping to change at page 25, line 10 skipping to change at page 25, line 10
On receipt of this chunk, the initiator SHOULD compute, sign, and On receipt of this chunk, the initiator SHOULD compute, sign, and
send a new Initiator Initial Keying having newCookie in place of send a new Initiator Initial Keying having newCookie in place of
oldCookie. The use of this chunk is detailed in Section 3.5.1.2. oldCookie. The use of this chunk is detailed in Section 3.5.1.2.
2.3.7. Initiator Initial Keying Chunk (IIKeying) 2.3.7. Initiator Initial Keying Chunk (IIKeying)
This chunk is sent by an initiator to establish a session with a This chunk is sent by an initiator to establish a session with a
responder. The initiator MUST have obtained a valid cookie to use responder. The initiator MUST have obtained a valid cookie to use
with the responder, typically by receiving a Responder Hello from it. with the responder, typically by receiving a Responder Hello from it.
This chunk MUST ONLY be in a packet with Session ID 0, encrypted with This chunk is only allowed in a packet with Session ID 0, encrypted
the default session key, and having packet mode 3 (Startup). with the default session key, and having packet mode 3 (Startup).
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x38 | chunkLength | | 0x38 | chunkLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| initiatorSessionID | | initiatorSessionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-------------/-+-----------------------------------------------+ +-------------/-+-----------------------------------------------+
| cookieLength\ | cookieEcho | | cookieLength\ | cookieEcho |
skipping to change at page 26, line 40 skipping to change at page 26, line 40
responderCertificate, sessionKeyInitiatorComponent, responderCertificate, sessionKeyInitiatorComponent,
sessionKeyResponderComponent, and signature, and how the sessionKeyResponderComponent, and signature, and how the
sessionKeyInitiatorComponent and sessionKeyResponderComponent are sessionKeyInitiatorComponent and sessionKeyResponderComponent are
combined to derive the session keys. combined to derive the session keys.
The use of IIKeying is detailed in Section 3.5.1. The use of IIKeying is detailed in Section 3.5.1.
2.3.8. Responder Initial Keying Chunk (RIKeying) 2.3.8. Responder Initial Keying Chunk (RIKeying)
This chunk is sent by a responder in response to an Initiator Initial This chunk is sent by a responder in response to an Initiator Initial
Keying as the final phase of session startup. This chunk MUST ONLY Keying as the final phase of session startup. This chunk is only
be in a packet encrypted with the default session key, having packet allowed in a packet encrypted with the default session key, having
mode 3 (Startup), and sent to the initiator with the Session ID packet mode 3 (Startup), and sent to the initiator with the Session
specified by the initiatorSessionID field from the Initiator Initial ID specified by the initiatorSessionID field from the Initiator
Keying. Initial Keying.
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x78 | chunkLength | | 0x78 | chunkLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| responderSessionID | | responderSessionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-------------/-+-----------------------------------------------+ +-------------/-+-----------------------------------------------+
| skrcLength \ | sessionKeyResponderComponent | | skrcLength \ | sessionKeyResponderComponent |
skipping to change at page 28, line 35 skipping to change at page 28, line 35
Once the initiator receives, verifies, and processes this chunk, it Once the initiator receives, verifies, and processes this chunk, it
has all of the information and state necessary for an established has all of the information and state necessary for an established
session with the responder. The session is established and ready to session with the responder. The session is established and ready to
carry flows of user data. carry flows of user data.
The use of RIKeying is detailed in Section 3.5.1. The use of RIKeying is detailed in Section 3.5.1.
2.3.9. Ping Chunk 2.3.9. Ping Chunk
This chunk is sent in order to elicit a Ping Reply from the receiver. This chunk is sent in order to elicit a Ping Reply from the receiver.
It MUST ONLY be in a packet belonging to an established session and It is only allowed in a packet belonging to an established session
having packet mode 1 or 2. and having packet mode 1 or 2.
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x01 | chunkLength | | 0x01 | chunkLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
| message | | message |
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/
struct pingChunkPayload_t struct pingChunkPayload_t
skipping to change at page 29, line 16 skipping to change at page 29, line 16
The receiver of this chunk SHOULD reply as immediately as is The receiver of this chunk SHOULD reply as immediately as is
practical with a Ping Reply. practical with a Ping Reply.
Ping and the expected Ping Reply are typically used for session Ping and the expected Ping Reply are typically used for session
keepalive, endpoint address change verification, and path MTU keepalive, endpoint address change verification, and path MTU
discovery. See Section 3.5.4 for details. discovery. See Section 3.5.4 for details.
2.3.10. Ping Reply Chunk 2.3.10. Ping Reply Chunk
This chunk is sent in response to a Ping chunk. It MUST ONLY be in a This chunk is sent in response to a Ping chunk. It is only allowed
packet belonging to an established session and having packet mode 1 in a packet belonging to an established session and having packet
or 2. mode 1 or 2.
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x41 | chunkLength | | 0x41 | chunkLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
| messageEcho | | messageEcho |
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/
struct pingReplyChunkPayload_t struct pingReplyChunkPayload_t
skipping to change at page 29, line 41 skipping to change at page 29, line 41
} :chunkLength*8; } :chunkLength*8;
messageEcho : The message from the Ping to which this is a response, messageEcho : The message from the Ping to which this is a response,
unaltered. unaltered.
2.3.11. User Data Chunk 2.3.11. User Data Chunk
This chunk is the basic unit of transmission for the user messages of This chunk is the basic unit of transmission for the user messages of
a flow. A user message comprises one or more fragments. Each a flow. A user message comprises one or more fragments. Each
fragment is carried in its own chunk and has a unique sequence number fragment is carried in its own chunk and has a unique sequence number
in its flow. It MUST ONLY be in a packet belonging to an established in its flow. It is only allowed in a packet belonging to an
session and having packet mode 1 or 2. established session and having packet mode 1 or 2.
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x10 | chunkLength | | 0x10 | chunkLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|O|r| F | r |A|F| |O|r| F | r |A|F|
|P|s| R | s |B|I| |P|s| R | s |B|I|
|T|v| A | v |N|N| |T|v| A | v |N|N|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
skipping to change at page 33, line 41 skipping to change at page 33, line 41
A flow MUST indicate its return association, if any, upon its first A flow MUST indicate its return association, if any, upon its first
transmission of a User Data chunk. A return association can't be transmission of a User Data chunk. A return association can't be
added to a sending flow after it begins. added to a sending flow after it begins.
A flow receiver MUST reject a new receiving flow having a return flow A flow receiver MUST reject a new receiving flow having a return flow
association that does not indicate an F_OPEN sending flow. association that does not indicate an F_OPEN sending flow.
2.3.12. Next User Data Chunk 2.3.12. Next User Data Chunk
This chunk is equivalent to the User Data Chunk for purposes of This chunk is equivalent to the User Data Chunk for purposes of
sending the user messages of a flow. When used, it MUST ONLY follow sending the user messages of a flow. When used, it MUST follow a
a User Data or another Next User Data chunk in the same packet. User Data or another Next User Data chunk in the same packet.
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x11 | chunkLength | | 0x11 | chunkLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|O|r| F | r |A|F| |O|r| F | r |A|F|
|P|s| R | s |B|I| |P|s| R | s |B|I|
|T|v| A | v |N|N| |T|v| A | v |N|N|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
skipping to change at page 35, line 31 skipping to change at page 35, line 31
----------+------------------------------------ ----------+------------------------------------
Figure 3: Sequential messages in one packet using Next User Data Figure 3: Sequential messages in one packet using Next User Data
The use of Next User Data is detailed in Section 3.6.2.3.2. The use of Next User Data is detailed in Section 3.6.2.3.2.
2.3.13. Data Acknowledgement Bitmap Chunk (Bitmap Ack) 2.3.13. Data Acknowledgement Bitmap Chunk (Bitmap Ack)
This chunk is sent by the flow receiver to indicate to the flow This chunk is sent by the flow receiver to indicate to the flow
sender the User Data fragment sequence numbers that have been sender the User Data fragment sequence numbers that have been
received for one flow. It MUST ONLY be in a packet belonging to an received for one flow. It is only allowed in a packet belonging to
established session and having packet mode 1 or 2. an established session and having packet mode 1 or 2.
The flow receiver can choose to acknowledge User Data with this chunk The flow receiver can choose to acknowledge User Data with this chunk
or with a Range Ack. It SHOULD choose whichever format has the most or with a Range Ack. It SHOULD choose whichever format has the most
compact encoding of the sequence numbers received. compact encoding of the sequence numbers received.
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x50 | chunkLength | | 0x50 | chunkLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-------------/-+-------------/-+-------------/-+ +-------------/-+-------------/-+-------------/-+
skipping to change at page 37, line 27 skipping to change at page 37, line 27
Example bitmap ack indicating acknowledgement of fragment sequence Example bitmap ack indicating acknowledgement of fragment sequence
numbers 0 through 16, 18, 21 through 24, 27 and 28. numbers 0 through 16, 18, 21 through 24, 27 and 28.
Figure 4 Figure 4
2.3.14. Data Acknowledgement Ranges Chunk (Range Ack) 2.3.14. Data Acknowledgement Ranges Chunk (Range Ack)
This chunk is sent by the flow receiver to indicate to the flow This chunk is sent by the flow receiver to indicate to the flow
sender the User Data fragment sequence numbers that have been sender the User Data fragment sequence numbers that have been
received for one flow. It MUST ONLY be in a packet belonging to an received for one flow. It is only allowed in a packet belonging to
established session and having packet mode 1 or 2. an established session and having packet mode 1 or 2.
The flow receiver can choose to acknowledge User Data with this chunk The flow receiver can choose to acknowledge User Data with this chunk
or with a Bitmap Ack. It SHOULD choose whichever format has the most or with a Bitmap Ack. It SHOULD choose whichever format has the most
compact encoding of the sequence numbers received. compact encoding of the sequence numbers received.
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x51 | chunkLength | | 0x51 | chunkLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-------------/-+-------------/-+-------------/-+ +-------------/-+-------------/-+-------------/-+
skipping to change at page 39, line 42 skipping to change at page 39, line 42
numbers 0 through 16 and 18, with a truncated last range. Note the numbers 0 through 16 and 18, with a truncated last range. Note the
truncation and parse error does not abort the entire chunk in this truncation and parse error does not abort the entire chunk in this
case. case.
Figure 6 Figure 6
2.3.15. Buffer Probe Chunk 2.3.15. Buffer Probe Chunk
This chunk is sent by the flow sender in order to request the current This chunk is sent by the flow sender in order to request the current
available receive buffer (in the form of a Data Acknowledgement) for available receive buffer (in the form of a Data Acknowledgement) for
a flow. It MUST ONLY be in a packet belonging to an established a flow. It is only allowed in a packet belonging to an established
session and having packet mode 1 or 2. session and having packet mode 1 or 2.
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x18 | chunkLength | | 0x18 | chunkLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-------------/-+ +-------------/-+
| flowID \ | | flowID \ |
+-------------/-+ +-------------/-+
skipping to change at page 40, line 30 skipping to change at page 40, line 30
The receiver of this chunk SHOULD reply as immediately as is The receiver of this chunk SHOULD reply as immediately as is
practical with a Data Acknowledgement. practical with a Data Acknowledgement.
2.3.16. Flow Exception Report Chunk 2.3.16. Flow Exception Report Chunk
This chunk is sent by the flow receiver to indicate that it is not This chunk is sent by the flow receiver to indicate that it is not
(or is no longer) interested in the flow and would like the flow (or is no longer) interested in the flow and would like the flow
sender to close the flow. This chunk SHOULD precede every Data sender to close the flow. This chunk SHOULD precede every Data
Acknowledgement chunk for the same flow in this condition. Acknowledgement chunk for the same flow in this condition.
This chunk MUST ONLY be in a packet belonging to an established This chunk is only allowed in a packet belonging to an established
session and having packet mode 1 or 2. session and having packet mode 1 or 2.
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x5e | chunkLength | | 0x5e | chunkLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-------------/-+-------------/-+ +-------------/-+-------------/-+
| flowID \ | exception \ | | flowID \ | exception \ |
+-------------/-+-------------/-+ +-------------/-+-------------/-+
skipping to change at page 41, line 12 skipping to change at page 41, line 12
A receiving RTMFP might reject a flow automatically, for example if A receiving RTMFP might reject a flow automatically, for example if
it is missing metadata, or if an invalid return association is it is missing metadata, or if an invalid return association is
specified. In circumstances where an RTMFP rejects a flow specified. In circumstances where an RTMFP rejects a flow
automatically, the exception code MUST be 0. The application can automatically, the exception code MUST be 0. The application can
specify any exception code, including 0, when rejecting a flow. All specify any exception code, including 0, when rejecting a flow. All
non-zero exception codes are reserved for the application. non-zero exception codes are reserved for the application.
2.3.17. Session Close Request Chunk (Close) 2.3.17. Session Close Request Chunk (Close)
This chunk is sent to cleanly terminate a session. It MUST ONLY be This chunk is sent to cleanly terminate a session. It is only
in a packet belonging to an established or closing session and having allowed in a packet belonging to an established or closing session
packet mode 1 or 2. and having packet mode 1 or 2.
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0c | 0 | | 0x0c | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This chunk has no payload. This chunk has no payload.
The use of Close is detailed in Section 3.5.5. The use of Close is detailed in Section 3.5.5.
2.3.18. Session Close Acknowledgement Chunk (Close Ack) 2.3.18. Session Close Acknowledgement Chunk (Close Ack)
This chunk is sent in response to a Session Close Request to indicate This chunk is sent in response to a Session Close Request to indicate
the sender has terminated the session. It MUST ONLY be in a packet the sender has terminated the session. It is only allowed in a
belonging to an established or closing session and having packet mode packet belonging to an established or closing session and having
1 or 2. packet mode 1 or 2.
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x4c | 0 | | 0x4c | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This chunk has no payload. This chunk has no payload.
The use of Close Ack is detailed in Section 3.5.5. The use of Close Ack is detailed in Section 3.5.5.
skipping to change at page 44, line 5 skipping to change at page 44, line 5
An endpoint is named by an Endpoint Discriminator. This An endpoint is named by an Endpoint Discriminator. This
specification doesn't mandate any particular format for Endpoint specification doesn't mandate any particular format for Endpoint
Discriminators. Discriminators.
An Endpoint Discriminator MAY select more than one identity, and MAY An Endpoint Discriminator MAY select more than one identity, and MAY
match more than one distinct certificate. match more than one distinct certificate.
Multiple distinct Endpoint Discriminators MAY match one certificate. Multiple distinct Endpoint Discriminators MAY match one certificate.
Multiple endpoints SHOULD NOT have the same identity. It is RECOMMENDED that multiple endpoints not have the same identity.
Entities with the same identity are indistinguishable during session
startup, which could be undesirable in some applications.
An endpoint MAY have more than one address. An endpoint MAY have more than one address.
The Cryptography Profile implements the following functions for The Cryptography Profile implements the following functions for
identities, certificates, and Endpoint Discriminators, whose identities, certificates, and Endpoint Discriminators, whose
operation MUST be deterministic: operation MUST be deterministic:
o Test whether a given certificate is authentic. Authenticity MAY o Test whether a given certificate is authentic. Authenticity can
comprise verifying an issuer signature chain in a public key comprise verifying an issuer signature chain in a public key
infrastructure. infrastructure.
o Test whether a given Endpoint Discriminator selects a given o Test whether a given Endpoint Discriminator selects a given
certificate. certificate.
o Test whether a given Endpoint Discriminator selects the local o Test whether a given Endpoint Discriminator selects the local
endpoint. endpoint.
o Generate a Canonical Endpoint Discriminator for a given o Generate a Canonical Endpoint Discriminator for a given
certificate. Canonical Endpoint Discriminators for distinct certificate. Canonical Endpoint Discriminators for distinct
identities SHOULD be distinct. identities SHOULD be distinct. If two distinct identities have
the same Canonical Endpoint Discriminator, an initiator might
abort a new opening session to the second identity
(Section 3.5.1.1.1), which might not be desired.
o Given a certificate, a message, and a digital signature over the o Given a certificate, a message, and a digital signature over the
message, test whether the signature is valid and generated by the message, test whether the signature is valid and generated by the
owner of the certificate. owner of the certificate.
o Generate a digital signature for a given message corresponding to o Generate a digital signature for a given message corresponding to
the near identity. the near identity.
o Given the near identity and a far certificate, determine which one o Given the near identity and a far certificate, determine which one
shall prevail as Initiator and which shall assume the Responder shall prevail as Initiator and which shall assume the Responder
role in the case of startup glare. The far end MUST arrive at the role in the case of startup glare. The far end MUST arrive at the
same conclusion. A comparison function MAY comprise performing a same conclusion. A comparison function can comprise performing a
lexicographic ordering of the binary certificates, and declaring lexicographic ordering of the binary certificates, and declaring
the far identity the prevailing endpoint if the far certificate is the far identity the prevailing endpoint if the far certificate is
ordered before the near certificate, and otherwise declaring the ordered before the near certificate, and otherwise declaring the
near identity to be the prevailing endpoint. near identity to be the prevailing endpoint.
o Given a first certificate and a second certificate, test whether a o Given a first certificate and a second certificate, test whether a
new incoming session from the second shall override an existing new incoming session from the second shall override an existing
session with the first. A test SHOULD comprise testing whether session with the first. It is RECOMMENDED that the test comprise
the certificates are identical. testing whether the certificates are bitwise identical.
All other semantics for certificates and Endpoint Discriminators are All other semantics for certificates and Endpoint Discriminators are
determined by the Cryptography Profile and the application. determined by the Cryptography Profile and the application.
3.3. Packet Multiplex 3.3. Packet Multiplex
An RTMFP typically has one or more interfaces through which it An RTMFP typically has one or more interfaces through which it
communicates with other RTMFP endpoints. RTMFP can communicate with communicates with other RTMFP endpoints. RTMFP can communicate with
multiple distinct other RTMFP endpoints through each local interface. multiple distinct other RTMFP endpoints through each local interface.
Session multiplexing over a shared interface can facilitate peer-to- Session multiplexing over a shared interface can facilitate peer-to-
skipping to change at page 45, line 43 skipping to change at page 45, line 46
Session Key as defined by the Cryptography Profile. Session Key as defined by the Cryptography Profile.
3.4. Packet Fragmentation 3.4. Packet Fragmentation
When an RTMFP packet (Section 2.2.4) is unavoidably larger than the When an RTMFP packet (Section 2.2.4) is unavoidably larger than the
path MTU (such as a startup packet containing an RHello path MTU (such as a startup packet containing an RHello
(Section 2.3.4) or IIKeying (Section 2.3.7) chunk with a large (Section 2.3.4) or IIKeying (Section 2.3.7) chunk with a large
certificate), it can be fragmented into segments that do not exceed certificate), it can be fragmented into segments that do not exceed
the path MTU using the Packet Fragment chunk (Section 2.3.1). the path MTU using the Packet Fragment chunk (Section 2.3.1).
The packet fragmentation mechanism SHOULD ONLY be used to segment The packet fragmentation mechanism SHOULD be used only to segment
unavoidably large packets. Accordingly, this mechanism SHOULD ONLY unavoidably large packets. Accordingly, this mechanism SHOULD be
be employed during session startup with session ID 0. This mechanism employed only during session startup with session ID 0. This
MUST NOT be used instead of the natural fragmentation mechanism of mechanism MUST NOT be used instead of the natural fragmentation
the User Data (Section 2.3.11) and Next User Data (Section 2.3.12) mechanism of the User Data (Section 2.3.11) and Next User Data
chunks for dividing the messages of the user's data flows into (Section 2.3.12) chunks for dividing the messages of the user's data
segments that do not exceed the path MTU. flows into segments that do not exceed the path MTU.
A fragmented plain RTMFP packet is reassembled by concatenating the A fragmented plain RTMFP packet is reassembled by concatenating the
packetFragment fields of the fragments for the packet in contiguous packetFragment fields of the fragments for the packet in contiguous
ascending order, starting from index 0 through and including the ascending order, starting from index 0 through and including the
final fragment. final fragment.
When reassembling packets for Session ID 0, a receiver SHOULD When reassembling packets for Session ID 0, a receiver SHOULD
identify the packets by both the socket address from which the packet identify the packets by both the socket address from which the packet
containing the fragment was received as well as the indicated containing the fragment was received as well as the indicated
packetID. packetID.
skipping to change at page 46, line 36 skipping to change at page 46, line 39
fragments. fragments.
In order to avoid jamming the network, the sender MUST rate limit In order to avoid jamming the network, the sender MUST rate limit
packet transmission. In the absence of specific path capacity packet transmission. In the absence of specific path capacity
information (for instance, during session startup), a sender SHOULD information (for instance, during session startup), a sender SHOULD
NOT send more than 4380 bytes nor more than four packets per distinct NOT send more than 4380 bytes nor more than four packets per distinct
endpoint every 200ms. endpoint every 200ms.
To avoid resource exhaustion, a receiver SHOULD limit the number of To avoid resource exhaustion, a receiver SHOULD limit the number of
concurrent packet reassembly buffers and the size of each buffer. concurrent packet reassembly buffers and the size of each buffer.
Limits can depend on the expected size of reassembled packets, the
rate at which fragmented packets are expected to be received and
degree of interleaving, and the expected function of the receiver.
Limits can depend on the available resources of the receiver. There
can be different limits for packets with Session ID 0 and packets for
established sessions. For example, a busy server might need to allow
for several hundred concurrent packet reassembly buffers to
accommodate hundreds of connection requests per second with
potentially interleaved fragments, but a client device with
constrained resources could allow just a few reassembly buffers. In
the absence of specific information regarding the expected size of
reassembled packets, a receiver should set the limit for each packet
reassembly buffer to 65536 bytes.
3.5. Sessions 3.5. Sessions
A session is the protocol relationship between a pair of A session is the protocol relationship between a pair of
communicating endpoints, comprising the shared and endpoint-specific communicating endpoints, comprising the shared and endpoint-specific
information context necessary to carry out the communication. The information context necessary to carry out the communication. The
session context at each end includes at least: session context at each end includes at least:
o TS_RX: the last timestamp received from the far end; o TS_RX: the last timestamp received from the far end;
skipping to change at page 50, line 17 skipping to change at page 51, line 10
The Initiator determines that a session is needed for an Endpoint The Initiator determines that a session is needed for an Endpoint
Discriminator. The Initiator creates state for a new opening session Discriminator. The Initiator creates state for a new opening session
and begins with a candidate endpoint address set containing at least and begins with a candidate endpoint address set containing at least
one address. The new session is placed in the S_IHELLO_SENT state. one address. The new session is placed in the S_IHELLO_SENT state.
If the session does not move to the S_OPEN state before an ultimate If the session does not move to the S_OPEN state before an ultimate
open timeout, the session has failed and moves to the S_OPEN_FAILED open timeout, the session has failed and moves to the S_OPEN_FAILED
state. The RECOMMENDED ultimate open timeout is 95 seconds. state. The RECOMMENDED ultimate open timeout is 95 seconds.
The Initiator chooses a new, unique Tag not used by any currently The Initiator chooses a new, unique Tag not used by any currently
opening session. The Tag SHOULD be cryptographically pseudorandom opening session. It is RECOMMENDED that the Tag be cryptographically
and SHOULD NOT be less than 8 bytes in length. The Initiator pseudorandom and be at least 8 bytes in length, so that it is hard to
constructs an IHello chunk (Section 2.3.2) with the Endpoint guess. The Initiator constructs an IHello chunk (Section 2.3.2) with
Discriminator and the Tag. the Endpoint Discriminator and the Tag.
While the Initiator is in the S_IHELLO_SENT state, it sends the While the Initiator is in the S_IHELLO_SENT state, it sends the
IHello to each candidate endpoint address in the set, on a backoff IHello to each candidate endpoint address in the set, on a backoff
schedule. The backoff SHOULD NOT be less than multiplicative with schedule. The backoff SHOULD NOT be less than multiplicative with
not less than 1.5 seconds added to the interval between each attempt. not less than 1.5 seconds added to the interval between each attempt.
The backoff SHOULD be scheduled separately for each candidate The backoff SHOULD be scheduled separately for each candidate
address, since new candidates can be added over time. address, since new candidates can be added over time.
If the Initiator receives a Redirect chunk (Section 2.3.5) with a Tag If the Initiator receives a Redirect chunk (Section 2.3.5) with a Tag
Echo matching this session, AND this session is in the S_IHELLO_SENT Echo matching this session, AND this session is in the S_IHELLO_SENT
skipping to change at page 56, line 49 skipping to change at page 57, line 49
| IIKeying | | IIKeying |
|----------------------------------------------------------------->| |----------------------------------------------------------------->|
| | | |
| RIKeying | | RIKeying |
|<-----------------------------------------------------------------| |<-----------------------------------------------------------------|
| | | |
|<======================== S E S S I O N =========================>| |<======================== S E S S I O N =========================>|
Figure 12: Handshake using a Redirector Figure 12: Handshake using a Redirector
Deployment Note: Redirectors SHOULD NOT initiate new sessions to Deployment Design Note: Redirectors SHOULD NOT initiate new sessions
endpoints which might use the Redirector's address as a candidate for to endpoints that might use the Redirector's address as a candidate
another endpoint, since the far end might interpret the Redirector's for another endpoint, since the far end might interpret the
IIKeying as glare for the far end's initiation to the other endpoint. Redirector's IIKeying as glare for the far end's initiation to the
other endpoint.
3.5.1.5. Forwarder 3.5.1.5. Forwarder
+-----------+ +-----------+ +---+ +-----------+ +-----------+ +-----------+ +---+ +-----------+
| Initiator |---->| Forwarder |<===>| N |<===>| Responder | | Initiator |---->| Forwarder |<===>| N |<===>| Responder |
| | +-----------+ | A | | | | | +-----------+ | A | | |
| |<=====================>| T |<===>| | | |<=====================>| T |<===>| |
+-----------+ +---+ +-----------+ +-----------+ +---+ +-----------+
Figure 13: Forwarder Figure 13: Forwarder
skipping to change at page 61, line 43 skipping to change at page 62, line 43
| :-------------------------------->:--------------->| | :-------------------------------->:--------------->|
| : : | | : : |
| : : RIKeying | | : : RIKeying |
| : :<---------------| | : :<---------------|
|<--------------:<--------------------------------: | |<--------------:<--------------------------------: |
| : : | | : : |
|<=============>:<======== S E S S I O N ========>:<==============>| |<=============>:<======== S E S S I O N ========>:<==============>|
Figure 17: Handshake with Redirector and Forwarder Figure 17: Handshake with Redirector and Forwarder
At the point in the diagram marked (*), Responder's RHello from the At the point in Figure 17 marked (*), Responder's RHello from the
FIHello might arrive at Initiator's NAT before or after Initiator's FIHello might arrive at Initiator's NAT before or after Initiator's
IHello is sent outbound to Responder's public NAT address. If it IHello is sent outbound to Responder's public NAT address. If it
arrives before, it may be dropped by the NAT. If it arrives after, arrives before, it may be dropped by the NAT. If it arrives after,
it will transit the NAT and trigger keying without waiting for it will transit the NAT and trigger keying without waiting for
another round trip time. The timing of this race depends, among another round trip time. The timing of this race depends, among
other factors, on the relative distances of Initiator and Responder other factors, on the relative distances of Initiator and Responder
to each other and the introduction service. to each other and the introduction service.
3.5.1.7. Load Distribution and Fault Tolerance 3.5.1.7. Load Distribution and Fault Tolerance
skipping to change at page 62, line 28 skipping to change at page 63, line 28
+---+ +-------------+ +---+ +-------------+
Figure 18: Parallel Open to Multiple Endpoints Figure 18: Parallel Open to Multiple Endpoints
Section 3.2 allows more than one endpoint to be selected by one Section 3.2 allows more than one endpoint to be selected by one
Endpoint Discriminator. This will typically be the case for a set of Endpoint Discriminator. This will typically be the case for a set of
servers, any of which could accommodate a connecting client. servers, any of which could accommodate a connecting client.
Section 3.5.1.1.1 allows an Initiator to use multiple candidate Section 3.5.1.1.1 allows an Initiator to use multiple candidate
endpoint addresses when starting a session, and specifies that the endpoint addresses when starting a session, and specifies that the
the sender of the first acceptable RHello chunk to be received is sender of the first acceptable RHello chunk to be received is
selected to complete the session, with later responses ignored. An selected to complete the session, with later responses ignored. An
Initiator can start with the multiple candidate endpoint addresses, Initiator can start with the multiple candidate endpoint addresses,
or it may learn them during startup from one or more Redirectors or it may learn them during startup from one or more Redirectors
(Section 3.5.1.4). (Section 3.5.1.4).
Parallel open to multiple endpoints for the same Endpoint Parallel open to multiple endpoints for the same Endpoint
Discriminator combined with selection by earliest RHello can be used Discriminator combined with selection by earliest RHello can be used
for load distribution and fault tolerance. The cost at each endpoint for load distribution and fault tolerance. The cost at each endpoint
that is not selected is limited to receiving and processing an that is not selected is limited to receiving and processing an
IHello, and generating and sending an RHello. IHello, and generating and sending an RHello.
skipping to change at page 63, line 15 skipping to change at page 64, line 15
the multiple servers. In normal operation, the multiple servers will the multiple servers. In normal operation, the multiple servers will
all respond, and the client will select one of them as described all respond, and the client will select one of them as described
above. If one of the multiple servers fails, other servers in the above. If one of the multiple servers fails, other servers in the
pool can still respond to the client, allowing the client to pool can still respond to the client, allowing the client to
successfully complete to an S_OPEN session with one of them. successfully complete to an S_OPEN session with one of them.
3.5.2. Congestion Control 3.5.2. Congestion Control
An RTMFP MUST implement congestion control and avoidance algorithms An RTMFP MUST implement congestion control and avoidance algorithms
that are "TCP compatible", in accordance with Internet best current that are "TCP compatible", in accordance with Internet best current
practice [RFC2914]. The algorithms SHOULD NOT be more aggressive practice [RFC2914]. The algorithms SHOULD NOT be more aggressive in
than those described in TCP Congestion Control [RFC5681], and MUST sending data than those described in TCP Congestion Control
NOT be more aggressive than the "slow start algorithm" described in [RFC5681], and MUST NOT be more aggressive in sending data than the
RFC 5681 Section 3.1. "slow start algorithm" described in RFC 5681 Section 3.1.
An endpoint maintains a transmission budget in the session An endpoint maintains a transmission budget in the session
information context of each S_OPEN session (Section 3.5), controlling information context of each S_OPEN session (Section 3.5), controlling
the rate at which the endpoint sends data into the network. the rate at which the endpoint sends data into the network.
For window-based congestion control and avoidance algorithms, the For window-based congestion control and avoidance algorithms, the
transmission budget is the congestion window, which is the amount of transmission budget is the congestion window, which is the amount of
user data that is allowed to be outstanding, or in flight, in the user data that is allowed to be outstanding, or in flight, in the
network. Transmission is allowed when S_OUTSTANDING_BYTES network. Transmission is allowed when S_OUTSTANDING_BYTES
(Section 3.5) is less than the congestion window (Section 3.6.2.3). (Section 3.5) is less than the congestion window (Section 3.6.2.3).
skipping to change at page 66, line 31 skipping to change at page 67, line 31
3. SRTT = ((7 * SRTT) + RTT) / 8; 3. SRTT = ((7 * SRTT) + RTT) / 8;
6. If SRTT has no value, then set SRTT = RTT and RTTVAR = RTT / 2; 6. If SRTT has no value, then set SRTT = RTT and RTTVAR = RTT / 2;
7. Set MRTO = SRTT + 4 * RTTVAR + 200 milliseconds; 7. Set MRTO = SRTT + 4 * RTTVAR + 200 milliseconds;
8. Set ERTO to the greater of MRTO or 250 milliseconds. 8. Set ERTO to the greater of MRTO or 250 milliseconds.
A retransmission timeout occurs when the most recently transmitted A retransmission timeout occurs when the most recently transmitted
user data fragment has remained outstanding in the network for ETRO. user data fragment has remained outstanding in the network for ERTO.
When this timeout occurs, increase ERTO on an exponential backoff When this timeout occurs, increase ERTO on an exponential backoff
with an ultimate backoff cap of 10 seconds: with an ultimate backoff cap of 10 seconds:
1. Calculate ERTO_BACKOFF = ERTO * 1.4142; 1. Calculate ERTO_BACKOFF = ERTO * 1.4142;
2. Calculate ERTO_CAPPED to be the lesser of ERTO_BACKOFF and 10 2. Calculate ERTO_CAPPED to be the lesser of ERTO_BACKOFF and 10
seconds; seconds;
3. Set ERTO to the greater of ERTO_CAPPED and MRTO. 3. Set ERTO to the greater of ERTO_CAPPED and MRTO.
skipping to change at page 68, line 5 skipping to change at page 69, line 5
the S_OPEN state, it SHOULD construct and send a Ping Reply chunk the S_OPEN state, it SHOULD construct and send a Ping Reply chunk
(Section 2.3.10) in response if possible, copying the message (Section 2.3.10) in response if possible, copying the message
unaltered. A Ping Reply response SHOULD be sent as quickly as unaltered. A Ping Reply response SHOULD be sent as quickly as
possible following receipt of a Ping. The semantics of a Ping's possible following receipt of a Ping. The semantics of a Ping's
message is reserved for the sender; a receiver SHOULD NOT interpret message is reserved for the sender; a receiver SHOULD NOT interpret
the Ping's message. the Ping's message.
Endpoints can use the mechanism of the Ping chunk and the expected Endpoints can use the mechanism of the Ping chunk and the expected
Ping Reply for any purpose. This specification doesn't mandate any Ping Reply for any purpose. This specification doesn't mandate any
specific constraints on the format or semantics of a Ping message. A specific constraints on the format or semantics of a Ping message. A
Ping Reply MUST ONLY be sent as a response to a Ping. Ping Reply MUST be sent only as a response to a Ping.
Receipt of a Ping Reply implies live bidirectional connectivity. Receipt of a Ping Reply implies live bidirectional connectivity.
This specification doesn't mandate any other semantics for a Ping This specification doesn't mandate any other semantics for a Ping
Reply. Reply.
3.5.4.1. Keepalive 3.5.4.1. Keepalive
An endpoint can use Ping to test for live bidirectional connectivity, An endpoint can use Ping to test for live bidirectional connectivity,
to test that the far end of a session is still S_OPEN, to keep NAT to test that the far end of a session is still S_OPEN, to keep NAT
translations alive, and to keep firewall holes open. translations alive, and to keep firewall holes open.
skipping to change at page 78, line 42 skipping to change at page 79, line 42
3.6.2.3.1. Startup Options 3.6.2.3.1. Startup Options
If STARTUP_OPTIONS is not empty, then when assembling the FIRST User If STARTUP_OPTIONS is not empty, then when assembling the FIRST User
Data chunk for this flow into a packet, add the encoded Data chunk for this flow into a packet, add the encoded
STARTUP_OPTIONS to that chunk's option list. STARTUP_OPTIONS to that chunk's option list.
3.6.2.3.2. Send Next Data 3.6.2.3.2. Send Next Data
The Next User Data chunk (Section 2.3.12) is a compact encoding for a The Next User Data chunk (Section 2.3.12) is a compact encoding for a
user message fragment when multiple contiguous fragments are user message fragment when multiple contiguous fragments are
assembled into one packet. assembled into one packet. Using this chunk where possible can
conserve space in a packet, potentially reducing transmission
overhead or allowing additional information to be sent in a packet.
If, after assembling a user message fragment of a flow into a packet If, after assembling a user message fragment of a flow into a packet
(Section 3.6.2.3), the next eligible fragment to be selected for (Section 3.6.2.3), the next eligible fragment to be selected for
assembly belongs to the same flow AND its sequence number is one assembly into that packet belongs to the same flow AND its sequence
greater than that of the fragment just assembled, an implementation number is one greater than that of the fragment just assembled, it is
SHOULD encode a Next User Data chunk instead of a User Data chunk. RECOMMENDED that an implementation encode a Next User Data chunk
instead of a User Data chunk.
The FIRST fragment of a flow assembled into a packet MUST be encoded The FIRST fragment of a flow assembled into a packet MUST be encoded
as a User Data chunk. as a User Data chunk.
3.6.2.4. Processing Acknowledgements 3.6.2.4. Processing Acknowledgements
A Data Acknowledgement Bitmap chunk (Section 2.3.13) or a Data A Data Acknowledgement Bitmap chunk (Section 2.3.13) or a Data
Acknowledgement Ranges chunk (Section 2.3.14) encodes the Acknowledgement Ranges chunk (Section 2.3.14) encodes the
acknowledgement of receipt of one or more sequence numbers of a flow, acknowledgement of receipt of one or more sequence numbers of a flow,
as well as the receiver's current receive window advertisement. as well as the receiver's current receive window advertisement.
skipping to change at page 100, line 37 skipping to change at page 101, line 37
An attacker that can passively observe an IHello and that possesses a An attacker that can passively observe an IHello and that possesses a
certificate matching the Endpoint Discriminator (without having to certificate matching the Endpoint Discriminator (without having to
know the private key, if any, associated with it) can deny the know the private key, if any, associated with it) can deny the
Initiator access to the desired Responder by sending an RHello before Initiator access to the desired Responder by sending an RHello before
the desired Responder does, since only the first received RHello is the desired Responder does, since only the first received RHello is
selected by the Initiator. The attacker needn't forge the desired selected by the Initiator. The attacker needn't forge the desired
Responder's source address, since the RHello is selected based on the Responder's source address, since the RHello is selected based on the
tag echo and not the packet's source address. This can simplify the tag echo and not the packet's source address. This can simplify the
attack in some network or host configurations. attack in some network or host configurations.
An attacker that can passively observe and record the packets of an
established session can use traffic analysis techniques to infer the
start and completion of flows without decrypting the packets. The
User Data fragments of flows have unique sequence numbers, so flows
are immune to replay while they are open. However, once a flow has
completed and the linger period has concluded, the attacker could
replay the recorded packets, opening a new flow in the receiver and
duplicating the flow's data, which might have undesirable effects in
the receiver's application. The attacker could also infer that a new
flow has begun reusing the recorded flow's identifier, and replay the
final sequence number or any of the other fragments in the flow,
potentially denying or interfering with legitimate traffic to the
receiver. Therefore, the data integrity aspect of packet encryption
SHOULD comprise anti-replay measures.
6. Acknowledgements 6. Acknowledgements
Special thanks go to Matthew Kaufman for his contributions to the Special thanks go to Matthew Kaufman for his contributions to the
creation and design of RTMFP. creation and design of RTMFP.
Thanks to Wesley Eddy, Philipp Hancke, Bela Lubkin, Richard Thanks to Ben Campbell, Wesley Eddy, Philipp Hancke, Bela Lubkin,
Scheffenegger, and Martin Stiemerling for their detailed reviews of Hilarie Orman, Richard Scheffenegger, and Martin Stiemerling for
this memo. their detailed reviews of this memo.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981. September 1981.
[RFC1122] Braden, R., "Requirements for Internet Hosts - [RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122, October 1989.
 End of changes. 53 change blocks. 
169 lines changed or deleted 222 lines changed or added

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