draft-ietf-ippm-twamp-08.txt   draft-ietf-ippm-twamp-09.txt 
Network Working Group K. Hedayat Network Working Group K. Hedayat
Internet Draft Brix Networks Internet Draft Brix Networks
Expires: Dec 2008 R. Krzanowski Expires: Jan 2009 R. Krzanowski
Intended Status:Standards Track Verizon Intended Status:Standards Track Verizon
A. Morton A. Morton
AT&T Labs AT&T Labs
K. Yum K. Yum
Juniper Networks Juniper Networks
J. Babiarz J. Babiarz
Nortel Networks Nortel Networks
June 6, 2008 July 30, 2008
A Two-way Active Measurement Protocol (TWAMP) A Two-way Active Measurement Protocol (TWAMP)
draft-ietf-ippm-twamp-08 draft-ietf-ippm-twamp-09
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 23 skipping to change at page 2, line 23
on the OWAMP, that adds two-way or round-trip measurement on the OWAMP, that adds two-way or round-trip measurement
capabilities. The TWAMP measurement architecture is usually capabilities. The TWAMP measurement architecture is usually
comprised of two hosts with specific roles, and this allows for comprised of two hosts with specific roles, and this allows for
some protocol simplifications, making it an attractive alternative some protocol simplifications, making it an attractive alternative
in some circumstances. in some circumstances.
Table of Contents Table of Contents
1. Introduction..................................................3 1. Introduction..................................................3
1.1 Relationship of Test and Control Protocols................3 1.1 Relationship of Test and Control Protocols................3
1.2 Logical Model.............................................3 1.2 Logical Model.............................................4
1.3 Pronunciation Guide.......................................5 1.3 Pronunciation Guide.......................................5
2. Protocol Overview.............................................5 2. Protocol Overview.............................................5
3. TWAMP Control.................................................6 3. TWAMP Control.................................................6
3.1 Connection Setup..........................................6 3.1 Connection Setup..........................................6
3.2 Integrity Protection......................................7 3.2 Integrity Protection......................................7
3.3 Value of the Accept Fields................................7 3.3 Value of the Accept Fields................................8
3.4 TWAMP Control Commands....................................7 3.4 TWAMP Control Commands....................................8
3.5 Creating Test Sessions....................................8 3.5 Creating Test Sessions....................................8
3.6 Send Schedules...........................................10 3.6 Send Schedules...........................................10
3.7 Starting Test Sessions...................................10 3.7 Starting Test Sessions...................................11
3.8 Stop-Sessions............................................10 3.8 Stop-Sessions............................................11
3.9 Fetch-Session............................................11 3.9 Fetch-Session............................................12
4. TWAMP Test...................................................11 4. TWAMP Test...................................................12
4.1 Sender Behavior..........................................12 4.1 Sender Behavior..........................................13
4.2 Reflector Behavior.......................................12 4.2 Reflector Behavior.......................................13
5. Implementers Guide...........................................19 5. Implementers Guide...........................................21
6. Security Considerations......................................19 6. Security Considerations......................................21
7. Acknowledgements.............................................20 7. Acknowledgements.............................................22
8. IANA Considerations..........................................20 8. IANA Considerations..........................................22
8.1 Registry Specification...................................20 8.1 Registry Specification...................................23
8.2 Registry Management......................................21 8.2 Registry Management......................................23
8.3 Experimental Numbers.....................................21 8.3 Experimental Numbers.....................................23
8.4 Initial Registry Contents................................21 8.4 Initial Registry Contents................................23
9. Internationalization Considerations..........................21 9. Internationalization Considerations..........................24
10. APPENDIX I - TWAMP Light (Informative)......................22 10. APPENDIX I - TWAMP Light (Informative)......................24
11. References..................................................23 11. References..................................................25
11.1 Normative References....................................23 11.1 Normative References....................................25
11.2 Informative References..................................23 11.2 Informative References..................................26
1. Introduction 1. Introduction
The Internet Engineering Task Force (IETF) has completed a Proposed The Internet Engineering Task Force (IETF) has completed a Proposed
standard for the round-trip delay [RFC2681] metric. IETF has also standard for the round-trip delay [RFC2681] metric. IETF has also
completed a protocol for the control and collection of one-way completed a protocol for the control and collection of one-way
measurements, the One-way Active Measurement Protocol (OWAMP) measurements, the One-way Active Measurement Protocol (OWAMP)
[RFC4656]. However, OWAMP does not accommodate round-trip or two- [RFC4656]. However, OWAMP does not accommodate round-trip or two-
way measurements. way measurements.
Two-way measurements are common in IP networks, primarily because Two-way measurements are common in IP networks, primarily because
synchronization between local and remote clocks is unnecessary for synchronization between local and remote clocks is unnecessary for
round-trip delay, and measurement support at the remote end may be round-trip delay, and measurement support at the remote end may be
limited to a simple echo function. This memo specifies the Two-way limited to a simple echo function. However, the most common
Active Measurement Protocol, or TWAMP. TWAMP uses the methodology facility for round-trip measurements is the ICMP Echo Request/Reply
and architecture of OWAMP [RFC4656] to define an open protocol for (used by the ping tool), and issues with this method are documented
in section 2.6 of [RFC2681]. This memo specifies the Two-way Active
Measurement Protocol, or TWAMP. TWAMP uses the methodology and
architecture of OWAMP [RFC4656] to define an open protocol for
measurement of two-way or round-trip metrics (henceforth in this measurement of two-way or round-trip metrics (henceforth in this
document the term two-way also signifies round-trip). The TWAMP document the term two-way also signifies round-trip), in addition
measurement architecture is usually comprised of only two hosts to the one-way metrics of OWAMP. TWAMP employs time stamps applied
with specific roles, and this allows for some protocol at the echo destination (reflector) to enable greater accuracy
simplifications, making it an attractive alternative to OWAMP in (processing delays can be accounted for). The TWAMP measurement
some circumstances. architecture is usually comprised of only two hosts with specific
roles, and this allows for some protocol simplifications, making it
an attractive alternative to OWAMP in some circumstances.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and NOT", "SHOULD", "SHOULD 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
RFC 2119 [RFC2119]. RFC 2119 [RFC2119].
1.1 Relationship of Test and Control Protocols 1.1 Relationship of Test and Control Protocols
Similar to OWAMP [RFC4656], TWAMP consists of two inter-related Similar to OWAMP [RFC4656], TWAMP consists of two inter-related
protocols: TWAMP-Control and TWAMP-Test. The relationship of these protocols: TWAMP-Control and TWAMP-Test. The relationship of these
skipping to change at page 5, line 13 skipping to change at page 5, line 16
actually two hosts: one playing the roles of Control-Client and actually two hosts: one playing the roles of Control-Client and
Session-Sender, and the other playing the roles of Server and Session-Sender, and the other playing the roles of Server and
Session-Reflector. This example is shown below. Session-Reflector. This example is shown below.
+-----------------+ +-------------------+ +-----------------+ +-------------------+
| Control-Client |<--TWAMP Control-->| Server | | Control-Client |<--TWAMP Control-->| Server |
| | | | | | | |
| Session-Sender |<--TWAMP-Test----->| Session-Reflector | | Session-Sender |<--TWAMP-Test----->| Session-Reflector |
+-----------------+ +-------------------+ +-----------------+ +-------------------+
Additionally, following the guidelines of OWAMP [RFC4656], TWAMP Throughout this memo, the bits marked MBZ (Must Be Zero) MUST be
has been defined to allow for small test packets that would fit set to zero by senders and MUST be ignored by receivers.
inside the payload of a single ATM cell (only in unauthenticated
mode).
1.3 Pronunciation Guide 1.3 Pronunciation Guide
The acronym OWAMP is usually pronounced in two syllables, Oh-wamp. The acronym OWAMP is usually pronounced in two syllables, Oh-wamp.
The acronym TWAMP is also pronounced in two syllables, Tee-wamp. The acronym TWAMP is also pronounced in two syllables, Tee-wamp.
2. Protocol Overview 2. Protocol Overview
The Two-way Active Measurement Protocol is an open protocol for The Two-way Active Measurement Protocol is an open protocol for
skipping to change at page 7, line 5 skipping to change at page 7, line 8
values are identical to those used in OWAMP. The only exception is values are identical to those used in OWAMP. The only exception is
the well-known port number for TWAMP-control. A client opens a TCP the well-known port number for TWAMP-control. A client opens a TCP
connection to the server on well-known port N (Refer to the IANA connection to the server on well-known port N (Refer to the IANA
Considerations section below for the TWAMP-control port number Considerations section below for the TWAMP-control port number
assignment). The host that initiates the TCP connection takes the assignment). The host that initiates the TCP connection takes the
roles of Control-Client and (in the two-host implementation) the roles of Control-Client and (in the two-host implementation) the
Session-Sender. The host that acknowledges the TCP connection Session-Sender. The host that acknowledges the TCP connection
accepts the roles of Server and (in the two-host implementation) accepts the roles of Server and (in the two-host implementation)
the Session Reflector. the Session Reflector.
The Control-Client MAY set a desired code-point in the Diffserv
Code Point (DSCP) field in the IP header for ALL packets of a
specific control connection. The Server SHOULD use the DSCP of the
Control-Client's TCP SYN in ALL subsequent packets on that
connection (avoiding any ambiguity in case of re-marking).
The possibility exists for Control-Client failure after TWAMP- The possibility exists for Control-Client failure after TWAMP-
Control connection establishment, or the path between the Control- Control connection establishment, or the path between the Control-
Client and Server may fail while a connection is in-progress. The Client and Server may fail while a connection is in-progress. The
Server MAY discontinue any established control connection when no Server MAY discontinue any established control connection when no
packet associated with that connection has been received within packet associated with that connection has been received within
SERVWAIT seconds. The Server SHALL suspend monitoring control SERVWAIT seconds. The Server SHALL suspend monitoring control
connection activity after receiving a Start-Sessions command, and connection activity after receiving a Start-Sessions command, and
SHALL resume after receiving a Stop-Sessions command (IF the SHALL resume after receiving a Stop-Sessions command (IF the
SERVWAIT option is supported). Note that the REFWAIT time-out SERVWAIT option is supported). Note that the REFWAIT time-out
(described below) covers failures during test sessions. The default (described below) covers failures during test sessions. The default
value of SERVWAIT SHALL be 900 seconds, and this waiting time MAY value of SERVWAIT SHALL be 900 seconds, and this waiting time MAY
be configurable. This time-out allows a Server to free-up resources be configurable. This time-out allows a Server to free-up resources
in case of failure. in case of failure.
Both the server and the client use the same mappings from KeyIDs to
shared secrets. The server, being prepared to conduct sessions
with more than one client, uses KeyIDs to choose the appropriate
secret key; a client would typically have different secret keys for
different servers. The shared secret is a passphrase. To maximize
passphrase interoperability, the passphrase character set MUST be
encoded using Appendix B of [RFC 5198] (the ASCII Network Virtual
Terminal Definition) It MUST not contain newlines (any combination
of Carriage-Return (CR) and/or Line-Feed (LF) characters), and
control characters SHOULD be avoided.
3.2 Integrity Protection 3.2 Integrity Protection
Integrity protection of TWAMP follows the same procedure defined in Integrity protection of TWAMP follows the same procedure defined in
section 3.2 of OWAMP [RFC4656]. As in OWAMP, each HMAC sent covers section 3.2 of OWAMP [RFC4656]. As in OWAMP, each HMAC sent covers
everything sent in a given direction between the previous HMAC (but everything sent in a given direction between the previous HMAC (but
not including it) and up to the beginning of the new HMAC. This not including it) and up to the beginning of the new HMAC. This
way, once encryption is set up, each bit of the TWAMP-Control way, once encryption is set up, each bit of the TWAMP-Control
connection is authenticated by an HMAC exactly once. connection is authenticated by an HMAC exactly once.
Note that the Server-Start message (sent by a Server during the Note that the Server-Start message (sent by a Server during the
initial control connection exchanges) does not terminate with an initial control connection exchanges) does not terminate with an
HMAC field. Therefore, the HMAC in the first Accept-Session message HMAC field. Therefore, the HMAC in the first Accept-Session message
also covers the Server-Start message and includes the Start-Time also covers the Server-Start message and includes the Start-Time
field in the HMAC calculation. field in the HMAC calculation.
Also, in authenticated and encrypted modes, the HMAC in TWAMP-
Control packets is encrypted.
3.3 Value of the Accept Fields 3.3 Value of the Accept Fields
Accept values used in TWAMP are the same as the values defined in Accept values used in TWAMP are the same as the values defined in
section 3.3 of OWAMP [RFC4656]. section 3.3 of OWAMP [RFC4656].
3.4 TWAMP Control Commands 3.4 TWAMP Control Commands
TWAMP control commands conform to the rules defined in section 3.4 TWAMP control commands conform to the rules defined in section 3.4
of OWAMP [RFC4656] of OWAMP [RFC4656]
skipping to change at page 8, line 14 skipping to change at page 8, line 32
can send specific messages in response to the commands it receives can send specific messages in response to the commands it receives
(as described in the sections that follow). (as described in the sections that follow).
Note that the OWAMP Request-Session command is replaced by the Note that the OWAMP Request-Session command is replaced by the
TWAMP Request-TW-Session command, and the Fetch-Session command TWAMP Request-TW-Session command, and the Fetch-Session command
does not appear in TWAMP. does not appear in TWAMP.
3.5 Creating Test Sessions 3.5 Creating Test Sessions
Test session creation follows the same procedure as defined in Test session creation follows the same procedure as defined in
section 3.5 of OWAMP [RFC4656]. section 3.5 of OWAMP [RFC4656]. The Request-TW-Session command is
based on the OWAMP Request-Session command, and uses the message
format as described in OWAMP secition 3.5, but without the schedule
slot description field(s) and uses one HMAC. The description of the
Request-TW-Session format follows.
In TWAMP, the first octet is referred to as the Command Number, and In TWAMP, the first octet is referred to as the Command Number, and
the Command Number is a recognized extension mechanism. Readers are the Command Number is a recognized extension mechanism. Readers are
encouraged to consult the TWAMP-Control Command Number Registry to encouraged to consult the TWAMP-Control Command Number Registry to
determine if there have been additional values assigned. determine if there have been additional values assigned.
The Command Number value of 5 indicates a Request-TW-Session The Command Number value of 5 indicates a Request-TW-Session
Command, and the Server MUST interpret this command as a request Command, and the Server MUST interpret this command as a request
for a two-way test session using the TWAMP-Test protocol. for a two-way test session using the TWAMP-Test protocol.
skipping to change at page 11, line 23 skipping to change at page 11, line 41
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ (8 octets) | | MBZ (8 octets) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| HMAC (16 octets) | | HMAC (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Above, the Command Number in the first octet (3) indicates that
this is the Stop-Sessions command.
Non-zero Accept values indicate a failure of some sort. Zero
values indicate normal (but possibly premature) completion. The
full list of available Accept values is described in Section 3.3 of
[RFC4656], "Values of the Accept Field".
If Accept had a non-zero value, results of all TWAMP-Test sessions
spawned by this TWAMP-Control session SHOULD be considered invalid.
If the Accept message was not transmitted at all (for whatever
reason, including failure of the TCP connection used for TWAMP-
Control), the results of all TWAMP-Test sessions spawned by this
TWAMP-control session MAY be considered invalid.
Number of Sessions indicates the number of sessions that the
Control-Client intends to stop.
Number of Sessions MUST contain the number of send sessions started
by the Control-Client that have not been previously terminated by a
Stop-Sessions command (i.e., the Control-Client MUST account for
each accepted Request-Session). If the Stop-Sessions message does
not account for exactly the number of sessions in-progress, then it
is to be considered invalid and the TWAMP-Control connection SHOULD
be closed and any results obtained considered invalid.
Upon receipt of a TWAMP-Control Stop-Sessions command, the Session-
Reflector MUST discard any TWAMP-Test packets that arrive at the
current time plus the Timeout (in the Request-TW-Session command).
3.9 Fetch-Session 3.9 Fetch-Session
The purpose of TWAMP is measurement of two-way metrics. Two-way One purpose of TWAMP is measurement of two-way metrics. Two-way
measurement methods do not require packet level data to be measurement methods do not require packet level data to be
collected by the Session-Reflector (such as sequence number, collected by the Session-Reflector (such as sequence number,
timestamp, and TTL) because this data is communicated in the timestamp, and TTL) because this data is communicated in the
"reflected" test packets. As such the protocol does not require "reflected" test packets. As such the protocol does not require
the retrieval of packet level data from the Server and the OWAMP the retrieval of packet level data from the Server and the OWAMP
Fetch-Session command is not used in TWAMP. Fetch-Session command is not used in TWAMP.
4. TWAMP Test 4. TWAMP Test
The TWAMP test protocol is similar to the OWAMP [RFC4656] test The TWAMP test protocol is similar to the OWAMP [RFC4656] test
skipping to change at page 12, line 34 skipping to change at page 13, line 34
sent MUST have the best possible approximation of its real time of sent MUST have the best possible approximation of its real time of
departure as its timestamp (in the packet). departure as its timestamp (in the packet).
4.1.2 Packet Format and Content 4.1.2 Packet Format and Content
The Session-Sender packet format and content follow the same The Session-Sender packet format and content follow the same
procedure and guidelines as defined in section 4.1.2 of OWAMP procedure and guidelines as defined in section 4.1.2 of OWAMP
[RFC4656] (with the exception of the reference to the Send [RFC4656] (with the exception of the reference to the Send
Schedule). Schedule).
Note that the Reflector test packet formats are larger than the
Sender's formats. The Session-Sender MAY append sufficient Packet
Padding to allow the same IP packet payload lengths to be used in
each direction of transmission (this is usually desirable). To
compensate for the Reflector's larger test packet format, the
Sender appends at least 27 octets of padding in unauthenticated
mode, and at least 56 octets in authenticated and encrypted modes.
4.2 Reflector Behavior 4.2 Reflector Behavior
TWAMP requires the Session-Reflector to transmit a packet to the TWAMP requires the Session-Reflector to transmit a packet to the
Session-Sender in response to each packet it receives. Session-Sender in response to each packet it receives.
As packets are received the Session-Reflector will, As packets are received the Session-Reflector will,
- Timestamp the received packet. Each packet that is actually - Timestamp the received packet. Each packet that is actually
received MUST have the best possible approximation of its real received MUST have the best possible approximation of its real
time of arrival entered as its timestamp (in the packet). time of arrival entered as its timestamp (in the packet).
skipping to change at page 13, line 37 skipping to change at page 14, line 43
every received packet. The response MUST be generated as every received packet. The response MUST be generated as
immediately as possible. The format and content of the test immediately as possible. The format and content of the test
packet is defined in section 4.2.1. Prior to the transmission packet is defined in section 4.2.1. Prior to the transmission
of the test packet, the Session-Reflector MUST enter the best of the test packet, the Session-Reflector MUST enter the best
possible approximation of its actual sending time of as its possible approximation of its actual sending time of as its
Timestamp (in the packet). This permits the determination of Timestamp (in the packet). This permits the determination of
the elapsed time between the reception of the packet and its the elapsed time between the reception of the packet and its
transmission. transmission.
- Packets not received within the Timeout (following the Stop- - Packets not received within the Timeout (following the Stop-
Session command) MUST be ignored by the Session command) MUST be ignored by the Reflector. The
Reflector. The Session-Reflector MUST NOT generate a test Session-Reflector MUST NOT generate a test packet to the
packet to the Session-Sender for packets that are ignored. Session-Sender for packets that are ignored.
The possibility exists for Session-Sender failure during a session, The possibility exists for Session-Sender failure during a session,
or the path between the Session-Sender and Session-Reflector may or the path between the Session-Sender and Session-Reflector may
fail while a test session is in-progress. The Session-Reflector MAY fail while a test session is in-progress. The Session-Reflector MAY
discontinue any session which has been Started when no packet discontinue any session which has been Started when no packet
associated with that session has been received for REFWAIT seconds. associated with that session has been received for REFWAIT seconds.
The default value of REFWAIT SHALL be 900 seconds, and this waiting The default value of REFWAIT SHALL be 900 seconds, and this waiting
time MAY be configurable. This time-out allows a Session-Reflector time MAY be configurable. This time-out allows a Session-Reflector
to free-up resources in case of failure. to free-up resources in case of failure.
4.2.1 TWAMP-Test Packet Format and Content 4.2.1 TWAMP-Test Packet Format and Content
The Session-Reflector MUST transmit a packet to the Session-Sender The Session-Reflector MUST transmit a packet to the Session-Sender
in response to each packet received. The Session-Reflector SHOULD in response to each packet received. The Session-Reflector SHOULD
transmit the packets as immediately as possible. The transmit the packets as immediately as possible. The
Session-Reflector SHOULD set the TTL in IPV4 (or Hop Limit in IPv6) Session-Reflector SHOULD set the TTL in IPV4 (or Hop Limit in IPv6)
in the UDP packet to 255. in the UDP packet to 255.
The test packet will have the necessary information for calculating The test packet will have the necessary information for calculating
two-way metrics by the Session-Sender. The format of the test two-way metrics by the Session-Sender. The format of the test
packet depends on the mode being used. The various formats of the packet depends on the mode being used. The two formats are
packet are presented below. presented below.
For unauthenticated mode: For unauthenticated mode:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
| | | |
skipping to change at page 16, line 31 skipping to change at page 18, line 31
Sequence Number is the sequence number of the test packet according Sequence Number is the sequence number of the test packet according
to its transmit order. It starts with zero and is incremented by to its transmit order. It starts with zero and is incremented by
one for each subsequent packet. The Sequence Number generated by one for each subsequent packet. The Sequence Number generated by
the Session-Reflector is independent from the sequence number of the Session-Reflector is independent from the sequence number of
the arriving packets. the arriving packets.
Timestamp and Error Estimate are the Session-Reflector's transmit Timestamp and Error Estimate are the Session-Reflector's transmit
timestamp and error estimate for the reflected test packet, timestamp and error estimate for the reflected test packet,
respectively. The format of all timestamp and error estimate respectively. The format of all timestamp and error estimate
fields follow the definition and formats defined by OWAMP[RFC4656]. fields follow the definition and formats defined by OWAMP section
4.1.2, in [RFC4656].
Sender Timestamp and Sender Error Estimate are exact copies of the Sender Timestamp and Sender Error Estimate are exact copies of the
timestamp and error estimate from the Session-Sender test packet timestamp and error estimate from the Session-Sender test packet
that corresponds to this test packet. that corresponds to this test packet.
Sender TTL is 255 when transmitted by the Session Sender. Sender Sender TTL is 255 when transmitted by the Session Sender. Sender
TTL is set to the Time To Live (or Hop Count) value of the received TTL is set to the Time To Live (or Hop Count) value of the received
packet from the IP packet header when transmitted by the Session packet from the IP packet header when transmitted by the Session
Reflector. Reflector.
Receive Timestamp is the time the test packet was received by the Receive Timestamp is the time the test packet was received by the
reflector. The difference between Timestamp and Receive Timestamp reflector. The difference between Timestamp and Receive Timestamp
is the amount of time the packet was in transition in the is the amount of time the packet was in transition in the
Session-Reflector. The Error Estimate associated with the Session-Reflector. The Error Estimate associated with the
Timestamp field also applies to the Receive Timestamp. Timestamp field also applies to the Receive Timestamp.
Sender Sequence Number is a copy of the Sequence Number of the Sender Sequence Number is a copy of the Sequence Number of the
packet transmitted by the Session-Sender that caused the packet transmitted by the Session-Sender that caused the
Session-Reflector to generate and send this test packet. Session-Reflector to generate and send this test packet.
Similar to OWAMP [RFC4656] the TWAMP packet layout is the same in The HMAC field in TWAMP-Test packets covers the same fields as the
authenticated and encrypted modes. The encryption operation of AES encryption. Thus, in authenticated mode, HMAC covers the first
Session-Sender packet follow the same rules of Session-Sender block (16 octets). In encrypted mode, HMAC covers the first six
packets as defined in OWAMP [RFC4656]. blocks (96 octets). In TWAMP-Test, the HMAC field MUST NOT be
encrypted.
The minimum data segment length is, therefore, 41 octets in Packet Padding in TWAMP-Test SHOULD be pseudo-random (it MUST be
unauthenticated mode, and 104 octets in both authenticated mode and generated independently of any other pseudo-random numbers
encrypted modes (with the implication that the later two modes will mentioned in this document). However, implementations MUST provide
not fit in a single ATM cell). a configuration parameter, an option, or a different means of
making Packet Padding consist of all zeros. Packet Padding MUST NOT
be covered by the HMAC and MUST NOT be encrypted.
The Session-Reflector TWAMP-Test packet layout is the same in The minimum data segment length of TWAMP-Test packets in
authenticated and encrypted modes. The encryption operations are, unauthenticated mode is 41 octets, and 104 octets in both
however, different. The difference is that in encrypted mode both authenticated mode and encrypted modes.
the sequence numbers and timestamps are encrypted to provide
maximum data integrity protection while in authenticated mode the
sequence numbers are encrypted and the timestamps are sent in clear
text. Sending the timestamp in clear text in authenticated mode
allows one to reduce the time between when a timestamp is obtained
by a reflector and when the packet is reflected out. In encrypted
mode, both the sender and reflector have to fetch the timestamp,
encrypt it, and send it; in authenticated mode, the middle step is
removed, potentially improving accuracy (the sequence number can be
encrypted before the timestamp is fetched). Authenticated mode
permits the timestamp to be fetched after a portion of the packet
is encrypted. Thus, the main differences between authenticated mode
and encrypted mode are the portions of the test packets that are
covered by HMAC and encrypted.
In authenticated mode, the first block (16 octets) of each packet Note that the Session-Reflector Test Packet Formats are larger than
is encrypted using AES Electronic Cookbook (ECB) mode. the Sender's formats. The Session-Reflector SHOULD reduce the
length of the Sender's Packet Padding to achieve equal IP packet
payload lengths in each direction of transmission, when sufficient
padding is present. The Session-Reflector MAY re-use the Sender's
Packet Padding (since the requirements for padding generation are
the same for each), and in this case the Session-Reflector SHOULD
truncate the padding such that the highest number octets are
discarded.
Obtaining the key, encryption method, and packet padding follows In unauthenticated mode, encryption or authentication MUST NOT be
the same procedure as OWAMP as described below. applied.
Similarly to each TWAMP-Control session, each TWAMP-Test session
has two keys: an AES Session-key and an HMAC Session-key. However, The TWAMP-Test packet layout is identical in authenticated and
there is a difference in how the keys are obtained: in the case of encrypted modes. The encryption operation for a Session-Sender
TWAMP-Control, the keys are generated by the client and packet follows the same rules of Session-Sender packets as defined
communicated (as part of the Token) during connection setup as part in OWAMP section 4.1.2 of [RFC4656].
of Set-Up-Response message; in the case of TWAMP-Test, described
here, the keys are derived from the TWAMP-Control keys and the SID. The main difference between authenticated mode and encrypted mode
is the portions of the test packets that are covered by HMAC and
encrypted. Authenticated mode permits the timestamp to be fetched
after a portion of the packet is encrypted, but in encrypted mode
all the sequence numbers and timestamps are fetched before
encryption to provide maximum data integrity protection.
In authenticated mode, only the sequence number in the first block
is encrypted and the subsequent timestamps and sequence numbers are
sent in clear text. Sending the timestamp in clear text allows one
to reduce the time between when a timestamp is obtained by a
Session-Reflector and when that packet is sent out. This
potentially improves the timestamp accuracy, because the sequence
number can be encrypted before the timestamp is fetched.
In encrypted mode, the reflector MUST fetch the timestamps,
generate the HMAC and encrypt the packet, then send it.
Obtaining the keys and encryption methods follow the same procedure
as OWAMP as described below. Each TWAMP-Test session has two keys
an AES Session-key and an HMAC Session-key, and the keys are
derived from the TWAMP-Control keys and the SID.
The TWAMP-Test AES Session-key is obtained as follows: the The TWAMP-Test AES Session-key is obtained as follows: the
TWAMP-Control AES Session-key (the same AES Session-key as is used TWAMP-Control AES Session-key (the same AES Session-key as used for
for the corresponding TWAMP-Control session, where it is used in a the corresponding TWAMP-Control session) is encrypted with the 16-
different chaining mode) is encrypted, using AES, with the 16-octet octet session identifier (SID) as the key, using a single-block
session identifier (SID) as the key; this is a single-block ECB AES-ECB encryption. The result is the TWAMP-Test AES Session-key to
encryption; its result is the TWAMP-Test AES Session-key to use in use in encrypting (and decrypting) the packets of the particular
encrypting (and decrypting) the packets of the particular TWAMP-Test session. Note that the TWAMP-Test AES Session-key,
TWAMP-Test session. Note that all of TWAMP-Test AES Session-key, TWAMP-Control AES Session-key, and the SID are all comprised of 16
TWAMP-Control AES Session-key, and the SID are comprised of 16
octets. octets.
The TWAMP-Test HMAC Session-key is obtained as follows: the The TWAMP-Test HMAC Session-key is obtained as follows: the
TWAMP-Control HMAC Session-key (the same HMAC Session-key as is TWAMP-Control HMAC Session-key (the same HMAC Session-key as used
used for the corresponding TWAMP-Control session) is encrypted, for the corresponding TWAMP-Control session) is encrypted using
using AES, with the 16-octet session identifier (SID) as the key; AES-CBC with the 16-octet session identifier (SID) as the key. This
this is a two-block CBC encryption, always performed with IV=0; its is a two-block CBC encryption always performed with IV=0. Note that
result is the TWAMP-Test HMAC Session-key to use in authenticating the TWAMP-Test HMAC Session-key and TWAMP-Control HMAC Session-key
the packets of the particular TWAMP-Test session. Note that all of are comprised of 32 octets, while the SID is 16 octets.
TWAMP-Test HMAC Session-key and TWAMP-Control HMAC Session-key are
comprised of 32 octets, while the SID is 16 octets.
ECB mode used for encrypting the first block of TWAMP-Test packets In authenticated mode, the first block (16 octets) of each TWAMP-
in authenticated mode does not involve any actual chaining; this Test packet is encrypted using AES Electronic Codebook (ECB) mode.
way, lost, duplicated, or reordered packets do not cause problems This mode does not involve any chaining, and lost, duplicated, or
with deciphering any packet in a TWAMP-Test session. reordered packets do not cause problems with deciphering any packet
in a TWAMP-Test session.
In encrypted mode, the first six blocks (96octets) are encrypted In encrypted mode, the first six blocks (96octets) are encrypted
using AES CBC mode. The AES Session-key to use is obtained in the using AES CBC mode. The AES Session-key to use is obtained in the
same way as the key for authenticated mode. Each TWAMP-Test packet same way as the key for authenticated mode. Each TWAMP-Test packet
is encrypted as a separate stream, with just one chaining is encrypted as a separate stream, with just one chaining
operation; chaining does not span multiple packets so that lost, operation; chaining does not span multiple packets so that lost,
duplicated, or reordered packets do not cause problems. The duplicated, or reordered packets do not cause problems. The
initialization vector for the CBC encryption is a value with all initialization vector for the CBC encryption is a value with all
bits equal to zero. bits equal to zero.
Implementation note: Naturally, the key schedule for each Implementation note: Naturally, the key schedule for each
TWAMP-Test session MUST be set up at most once per session, not TWAMP-Test session MUST be set up at most once per session, not
once per packet. once per packet.
HMAC in TWAMP-Test only covers the part of the packet that is also
encrypted. So, in authenticated mode, HMAC covers the first block
(16 octets); in encrypted mode, HMAC covers the first six blocks
(96 octets). In TWAMP-Test HMAC is not encrypted (note that this
is different from TWAMP-Control, where encryption in stream mode is
used, so everything including the HMAC blocks ends up being
encrypted).
In unauthenticated mode, no encryption or authentication is
applied.
Packet Padding in TWAMP-Test SHOULD be pseudo-random (it MUST be
generated independently of any other pseudo-random numbers
mentioned in this document). However, implementations MUST provide
a configuration parameter, an option, or a different means of
making Packet Padding consist of all zeros.
5. Implementers Guide 5. Implementers Guide
This section serves as guidance to implementers of TWAMP. The This section serves as guidance to implementers of TWAMP. The
example architecture presented here is not a requirement. Similar example architecture presented here is not a requirement. Similar
to OWAMP [RFC4656], TWAMP is designed with enough flexibility to to OWAMP [RFC4656], TWAMP is designed with enough flexibility to
allow different architectures that suit multiple system allow different architectures that suit multiple system
requirements. requirements.
In this example the roles of Control-Client and Session-Sender are In this example the roles of Control-Client and Session-Sender are
implemented in one host referred to as the controller and the roles implemented in one host referred to as the controller and the roles
skipping to change at page 20, line 5 skipping to change at page 21, line 46
6. Security Considerations 6. Security Considerations
Fundamentally TWAMP and OWAMP use the same protocol for Fundamentally TWAMP and OWAMP use the same protocol for
establishment of Control and Test procedures. The main difference establishment of Control and Test procedures. The main difference
between TWAMP and OWAMP is the Session-Reflector behavior in TWAMP between TWAMP and OWAMP is the Session-Reflector behavior in TWAMP
vs. the Session-Receiver behavior in OWAMP. This difference in vs. the Session-Receiver behavior in OWAMP. This difference in
behavior does not introduce any known security vulnerabilities that behavior does not introduce any known security vulnerabilities that
are not already addressed by the security features of OWAMP. The are not already addressed by the security features of OWAMP. The
entire security considerations of OWAMP [RFC4656] applies to TWAMP. entire security considerations of OWAMP [RFC4656] applies to TWAMP.
The Server Greeting message (defined in OWAMP, section 3.1
[RFC4656]) includes a "Count" field to specify the iteration
counter used in PKCS #5 to generate keys from shared secrets. OWAMP
recommends a lower limit of 1024 iterations, but no upper limit.
The Count field provides an opportunity for a DOS attack because it
is 32 bits long. If an attacking system set the maximum value in
Count (2**32), it could stall a system attempting to generate keys
for a significant period of time. Therefore, TWAMP-compliant
systems SHOULD have a configuration control to limit the maximum
Count value. The default maximum Count value SHOULD be 32768. As
suggested in OWAMP, this value MAY be increased when greater
computing power becomes common. If a Control-Client receives a
Server Greeting Message with Count greater that its maximum
configured value, it SHOULD close the control connection.
7. Acknowledgements 7. Acknowledgements
We would like to thank Nagarjuna Venna, Sharee McNab, Nick Kinraid, We would like to thank Nagarjuna Venna, Sharee McNab, Nick Kinraid,
Stanislav Shalunov, Matt Zekauskas, Walt Steverson, Jeff Boote, and Stanislav Shalunov, Matt Zekauskas, Walt Steverson, Jeff Boote, and
Murtaza Chiba for their comments, suggestions, reviews, helpful Murtaza Chiba for their comments, suggestions, reviews, helpful
discussion and proof-reading. discussion and proof-reading. Lars Eggert, Sam Hartman, and Tim
Polk contributed very useful AD-level reviews, and the authors
thank them for their contributions to the memo.
8. IANA Considerations 8. IANA Considerations
IANA has allocated a well-known TCP port number (861) for the IANA has allocated a well-known TCP port number (861) for the
OWAMP-Control part of the OWAMP [RFC4656] protocol. OWAMP-Control part of the OWAMP [RFC4656] protocol.
... ...
owamp-control 861/tcp OWAMP-Control owamp-control 861/tcp OWAMP-Control
owamp-control 861/udp OWAMP-Control owamp-control 861/udp OWAMP-Control
# [RFC4656] # [RFC4656]
# 862-872 Unassigned # 862-872 Unassigned
skipping to change at page 21, line 45 skipping to change at page 24, line 15
2 Start-Sessions RFC4656, Section 3.7 2 Start-Sessions RFC4656, Section 3.7
3 Stop-Sessions RFC4656, Section 3.8 3 Stop-Sessions RFC4656, Section 3.8
4 Reserved 4 Reserved
5 Request-TW-Session this document, Section 3.5 5 Request-TW-Session this document, Section 3.5
6 Experimentation undefined, see Section 8.3. 6 Experimentation undefined, see Section 8.3.
9. Internationalization Considerations 9. Internationalization Considerations
The protocol does not carry any information in a natural language, The protocol does not carry any information in a natural language,
with the possible exception of the KeyID in TWAMP-Control, which is with the possible exception of the KeyID in TWAMP-Control, which is
encoded in UTF-8. encoded in UTF-8 [RFC3629, RFC5198].
10. APPENDIX I - TWAMP Light (Informative) 10. APPENDIX I - TWAMP Light (Informative)
In this example the roles of Control-Client, Server, and In this example the roles of Control-Client, Server, and
Session-Sender are implemented in one host referred to as the Session-Sender are implemented in one host referred to as the
controller and the role of Session-Reflector is implemented in controller and the role of Session-Reflector is implemented in
another host referred to as the responder. another host referred to as the responder.
controller responder controller responder
+-----------------+ +-------------------+ +-----------------+ +-------------------+
skipping to change at page 23, line 9 skipping to change at page 25, line 23
sessions SHOULD offer the features listed below. sessions SHOULD offer the features listed below.
The non-standard responder control protocol SHOULD have an The non-standard responder control protocol SHOULD have an
authenticated mode of operation. The responder SHOULD be authenticated mode of operation. The responder SHOULD be
configurable to accept only authenticated control sessions. configurable to accept only authenticated control sessions.
The non-standard responder control protocol SHOULD have a means to The non-standard responder control protocol SHOULD have a means to
activate the authenticated and encrypted modes of the TWAMP-Test activate the authenticated and encrypted modes of the TWAMP-Test
protocol. protocol.
When the TWAMP Light test sessions operate in authenticated or
encrypted mode, the Session-Reflector MUST have some mechanism for
generating keys (because the TWAMP-Control protocol normally plays
a role in this process, but is not present here). The specification
of the key generation mechanism is beyond the scope of this memo.
11. References 11. References
11.1 Normative References 11.1 Normative References
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J.,
Zekauskas, M., "A One-way Active Measurement Protocol Zekauskas, M., "A One-way Active Measurement Protocol
(OWAMP)", RFC 4656, October 2004. (OWAMP)", RFC 4656, October 2004.
[RFC2681] Almes, G., Kalidindi, S., Zekauskas, M., "A [RFC2681] Almes, G., Kalidindi, S., Zekauskas, M., "A
Round-Trip Delay Metric for IPPM". RFC 2681, STD 1, Round-Trip Delay Metric for IPPM". RFC 2681,
September 1999. September 1999.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
Definition of the Differentiated Services Field (DS Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998. December 1998.
[RFC2434] Narten, T., Alvestrand, H., Guidelines for Writing [RFC2434] Narten, T., Alvestrand, H., Guidelines for Writing
an IANA Considerations Section in RFCs, RFC 2434, an IANA Considerations Section in RFCs, RFC 2434,
October 1998. October 1998.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC5198] Klensin, J., Padlipsky, M., "Unicode Format for
Network Interchange", RFC 5198, March 2008.
11.2 Informative References 11.2 Informative References
[RFC3692] Narten, T., Assigning Experimental and Testing Numbers [RFC3692] Narten, T., Assigning Experimental and Testing Numbers
Considered Useful, RFC 3692, January 2004. Considered Useful, RFC 3692, January 2004.
Authors' Addresses Authors' Addresses
Kaynam Hedayat Kaynam Hedayat
Brix Networks Brix Networks
285 Mill Road 285 Mill Road
 End of changes. 34 change blocks. 
121 lines changed or deleted 214 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/