--- 1/draft-ietf-ippm-twamp-02.txt 2007-03-02 22:12:41.000000000 +0100 +++ 2/draft-ietf-ippm-twamp-03.txt 2007-03-02 22:12:41.000000000 +0100 @@ -1,25 +1,23 @@ K. Hedayat Internet Draft Brix Networks - Expires: April 2007 R. Krzanowski + Expires: September 2007 R. Krzanowski Verizon K. Yum Juniper Networks A. Morton AT&T Labs J. Babiarz Nortel Networks - November 2006 - A Two-way Active Measurement Protocol (TWAMP) - draft-ietf-ippm-twamp-02 + draft-ietf-ippm-twamp-03 Status of this Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -32,21 +30,21 @@ as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice - Copyright (C) The Internet Society (2006). + Copyright (C) The IETF Trust (2007). Abstract The IPPM One-way Active Measurement Protocol [RFC4656] (OWAMP) provides a common protocol for measuring one-way metrics between network devices. OWAMP can be used bi-directionally to measure one-way metrics in both directions between two network elements. However, it does not accommodate round-trip or two-way measurements. This memo specifies a Two-way Active Measurement Protocol (TWAMP), based on the OWAMP, that adds two-way or @@ -67,29 +65,29 @@ 3.3 Value of the Accept Fields................................6 3.4 TWAMP Control Commands....................................6 3.5 Creating Test Sessions....................................6 3.6 Send Schedules............................................8 3.7 Starting Test Sessions....................................8 3.8 Stop-Sessions.............................................8 3.9 Fetch-Session.............................................8 4. TWAMP Test....................................................8 4.1 Sender Behavior...........................................9 4.2 Reflector Behavior........................................9 - 5. Implementers Guide...........................................14 - 5.1 Complete TWAMP...........................................14 - 5.2 TWAMP Light..............................................14 - 6. Security Considerations......................................15 - 7. Acknowledgements.............................................15 - 8. IANA Considerations..........................................15 - 9. Internationalization Considerations..........................16 - 10. References..................................................16 - 10.1 Normative References....................................16 + 5. Implementers Guide...........................................15 + 5.1 Complete TWAMP...........................................15 + 5.2 TWAMP Light..............................................16 + 6. Security Considerations......................................17 + 7. Acknowledgements.............................................17 + 8. IANA Considerations..........................................17 + 9. Internationalization Considerations..........................17 + 10. References..................................................18 + 10.1 Normative References....................................18 1. Introduction The IETF IP Performance Metrics (IPPM) working group has completed a draft standard for the round-trip delay [RFC2681] metric. IPPM has also completed a protocol for the control and collection of one-way measurements, the One-way Active Measurement Protocol (OWAMP) [RFC4656]. However, OWAMP does not accommodate round-trip or two-way measurements. Two-way measurements are common in IP networks, primarily because @@ -288,22 +286,22 @@ timeout interval following the reception of the Stop-Sessions message. The Session-Reflector MUST NOT reflect packets that are received beyond the timeout. Type-P descriptor is as defined in OWAMP [RFC4656]. The only capability of this field is to set the Differentiated Services Code Point (DSCP) as defined in [RFC2474]. The same value of DCSP MUST be used in test packets reflected by the Session-Reflector. Since there are no Schedule Slot Descriptions, the Request-Session - Message is followed by HMAC. This completes one logical message, - referred to as the Request-Session Command. + Message is completed by MBZ and HMAC fields. This completes one + logical message, referred to as the Request-Session Command. The Session-Reflector MUST respond to each Request-Session Command with an Accept-Message as defined in OWAMP [RFC4656]. The Port is the port to which TWAMP test packets are sent by the Session-Sender toward the Session-Reflector. In other words, the Port field indicates the port number where the Session-Reflector expects to receive packets from the Session-Sender. 3.6 Send Schedules @@ -449,57 +447,61 @@ . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For authenticated and encrypted modes: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | IZP (12 octets) | + | MBZ (12 octets) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Estimate | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | - | IZP (6 octets) | + | MBZ (6 octets) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receive Timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | IZP (8 octets) | + | MBZ (8 octets) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | Sender Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | IZP (12 octets) | + | MBZ (12 octets) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Error Estimate | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | - | IZP (6 octets) | + | MBZ (6 octets) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | HMAC (16 octets) | + | | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | | . . . Packet Padding . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Sequence Number is the sequence number of the test packet according to its arrival at the Session-Reflector. It starts with zero and is incremented by one for each subsequent packet. The Sequence Number generated by the Session-Reflector is independent from the sequence number of the arriving packets. Timestamp and Error Estimate are the Session-Reflector's transmit timestamp and error estimate for the reflected test packet, respectively. The format of all timestamp and error estimate fields follow the definition and formats defined by OWAMP[RFC4656]. @@ -535,26 +537,88 @@ 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). - In authenticated mode, the first block (32 octets) of each packet + In authenticated mode, the first block (16 octets) of each packet is encrypted using AES Electronic Cookbook (ECB) mode. - Obtaining the key, encryption method, and packet padding is as - defined in section 4.1.2 of OWAMP [RFC4656]. In unauthenticated - mode, no encryption is applied. + Obtaining the key, encryption method, and packet padding follows + the same procedure as OWAMP as described below. + Similarly to each TWAMP-Control session, each TWAMP-Test session + has two keys: an AES Session-key and an HMAC Session-key. However, + there is a difference in how the keys are obtained: in the case of + TWAMP-Control, the keys are generated by the client and + communicated (as part of the Token) during connection setup as part + 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 TWAMP-Test AES Session-key is obtained as follows: the + TWAMP-Control AES Session-key (the same AES Session-key as is used + for the corresponding TWAMP-Control session, where it is used in a + different chaining mode) is encrypted, using AES, with the 16-octet + session identifier (SID) as the key; this is a single-block ECB + encryption; its result is the TWAMP-Test AES Session-key to use in + encrypting (and decrypting) the packets of the particular + TWAMP-Test session. Note that all of TWAMP-Test AES Session-key, + TWAMP-Control AES Session-key, and the SID are comprised of 16 + octets. + + The TWAMP-Test HMAC Session-key is obtained as follows: the + TWAMP-Control HMAC Session-key (the same HMAC Session-key as is + used for the corresponding TWAMP-Control session) is encrypted, + using AES, with the 16-octet session identifier (SID) as the key; + this is a two-block CBC encryption, always performed with IV=0; its + result is the TWAMP-Test HMAC Session-key to use in authenticating + the packets of the particular TWAMP-Test session. Note that all of + 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 does not involve any actual chaining; this + way, lost, duplicated, or reordered packets do not cause problems + with deciphering any packet in an TWAMP-Test session. + + In encrypted mode, the first two blocks (32 octets) are encrypted + 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 + is encrypted as a separate stream, with just one chaining + operation; chaining does not span multiple packets so that lost, + duplicated, or reordered packets do not cause problems. The + initialization vector for the CBC encryption is a value with all + bits equal to zero. + + Implementation note: Naturally, the key schedule for each + TWAMP-Test session MAY be set up only once per session, not 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 two first blocks (32 + 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 This section serves as guidance to implementers of TWAMP. Two architectures are presented in this section for implementations where two hosts play the subsystem roles of TWAMP. Although only two architectures are presented here the protocol does not require their use. Similar to OWAMP [RFC4656] TWAMP is designed with complete flexibility to allow different architectures that suite multiple system requirements. @@ -610,29 +674,36 @@ This example eliminates the need for the TWAMP-Control protocol and assumes that the Session-Reflector is configured and communicates its configuration with the Server through non-standard means. The Session-Reflector simply reflects the incoming packets back to the controller while copying the necessary information and generating sequence number and timestamp values per section 5.2.1. 6. Security Considerations - The security considerations of OWAMP [RFC4656] apply. + Fundamentally TWAMP and OWAMP use the same protocol for + establishment of Control and Test procedures. The main difference + between TWAMP and OWAMP is the Session-Reflector behavior in TWAMP + vs. the Session-Receiver behavior in OWAMP. This difference in + behavior does not introduce any known security vulnerabilities that + are not already addressed by the security features of OWAMP. The + entire security considerations of OWAMP [RFC4656] applies to TWAMP. 7. Acknowledgements - We would like to thank Nagarjuna Venn, Sharee McNab, Nick Kinraid, + We would like to thank Nagarjuna Venna, Sharee McNab, Nick Kinraid, and Stanislav Shalunov for their comments, suggestions, reviews, helpful discussion and proof-reading. 8. IANA Considerations + IANA has allocated a well-known TCP port number (861) for the OWAMP-Control part of the OWAMP [RFC4656] protocol which also applies to the TWAMP-Control part of the TWAMP protocol. 9. Internationalization Considerations The protocol does not carry any information in a natural language, with the possible exception of the KeyID in TWAMP-Control, which is encoded in UTF-8. @@ -700,34 +770,34 @@ Nortel Networks 3500 Carling Avenue Ottawa, Ont K2H 8E9 Canada Email: babiarz@nortel.com URI: http://www.nortel.com/ Full Copyright Statement - Copyright (C) The Internet Society (2006). + Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE - REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND - THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, - EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT - THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR - ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A - PARTICULAR PURPOSE. + REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE + IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL + WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY + WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE + ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS + FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC