RFC 7717
IKEv2-Derived Shared Secret Key for the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)
RFC 7717: IKEv2-Derived Shared Secret Key for the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP) 🦋
Okay bestie, let's get the paperwork out of the way first 📋✨. This RFC comes from the Internet Engineering Task Force (IETF) and is Request for Comments 7717. It's a Standards Track document, which means it's an official Internet standard and not just somebody's opinion 💅. It was published in December 2015, and its ISSN is 2070-1721.
The authors are K. Pentikousis (the editor, from EICT), E. Zhang, and Y. Cui, who are from Huawei Technologies. Something to know: this RFC updates [RFC4656] and [RFC5357], which means it adds to those two documents without replacing them.
Abstract 💖
Okay, so the big idea: OWAMP and TWAMP security needs both the client and the server to have the same shared secret 🔐. This document says you can use keys derived from an IKEv2 security association (SA) as that shared key. If the key can be derived from the IKEv2 SA, then OWAMP or TWAMP can support certificate-based key exchange, which is so much more flexible and efficient ✨. The key derivation in here can also make automatic key management easier 🌸.
Status of This Memo 📜
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7717.
Copyright Notice 🎀
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Table of Contents 🗂️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. O/TWAMP Security . . . . . . . . . . . . . . . . . . . . . . 5
4.1. O/TWAMP-Control Security . . . . . . . . . . . . . . . . 5
4.2. O/TWAMP-Test Security . . . . . . . . . . . . . . . . . . 6
4.3. O/TWAMP Security Root . . . . . . . . . . . . . . . . . . 7
5. O/TWAMP for IPsec Networks . . . . . . . . . . . . . . . . . 7
5.1. Shared Key Derivation . . . . . . . . . . . . . . . . . . 7
5.2. Server Greeting Message Update . . . . . . . . . . . . . 8
5.3. Set-Up-Response Update . . . . . . . . . . . . . . . . . 9
5.4. O/TWAMP over an IPsec Tunnel . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 13
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 151. Introduction ✨
Okay so OWAMP [RFC4656] and TWAMP [RFC5357] are the protocols you use to measure network performance stuff like latency, bandwidth, and packet loss 📊. They work by sending probe packets and watching what happens to them on the way through the network 🛰️. To keep your measurement results accurate, security has to be part of the picture 🙈. Otherwise attacks can happen and the measurement results stop being authentic. For example, if there's no protection, an adversary in the middle may modify packet timestamps and totally mess up the results 💀.
According to [RFC4656] and [RFC5357], the OWAMP and TWAMP (O/TWAMP) security mechanisms require that endpoints (aka both the client and the server) possess a shared secret 🔑. Real talk though, pre-shared keys are not it in today's deployments 😩. For example, in wireless infrastructure networks, some network elements (which count as the two endpoints from an O/TWAMP point of view) already support certificate-based security 🌈. Picture this: you want to measure IP performance between an E-UTRAN Evolved Node B (eNB) and a Security Gateway (SeGW). Both are 3GPP Long Term Evolution (LTE) nodes, and both support certificate mode and the Internet Key Exchange Protocol version 2 (IKEv2) 🧚.
The O/TWAMP security mechanism in [RFC4656] and [RFC5357] only supports the pre-shared key (PSK) mode 🙃. That's a real problem for big deployments, because managing "shared secrets" at massive scale takes an insane amount of effort and is super prone to human error 😭. Meanwhile, IKEv2 keeps getting deployed more and more, so tunnel end-users and operators really need a standard way to measure one-way and two-way network performance 🦋.
Since IKEv2 is so widely deployed now, using shared keys derived from an IKEv2 security association (SA) is a totally viable alternative, and that's what this document describes 💅. If the shared key can be derived from the IKEv2 SA, O/TWAMP can support certificate-based key exchange, which makes operations way more flexible and efficient 🔥. Using IKEv2 also makes automatic key management easier to extend 🌸.
Generally speaking, O/TWAMP measurement packets can go inside the IPsec tunnel, like normal user traffic, or outside of it 🚇. Which one you pick depends on the operator's policy and what they're trying to evaluate, and this document doesn't care either way 🤷♀️. When IPsec is deployed, one option is to protect O/TWAMP traffic in unauthenticated mode using IPsec. Another option is to protect O/TWAMP traffic with the O/TWAMP security set up using the PSK derived from IKEv2, and skip the IPsec tunnel entirely 🧚♀️.
Protecting unauthenticated O/TWAMP control and/or test traffic with the Authentication Header (AH) [RFC4302] or the Encapsulating Security Payload (ESP) [RFC4303] can't give you various security options. For instance, it can't authenticate part of an O/TWAMP packet, as mentioned in [RFC4656] 🙅♀️. Now, for measuring latency, a timestamp gets carried in O/TWAMP test traffic. The sender has to fetch the timestamp, encrypt it, and then send it 🔁. With the mechanism in this document, partial authentication of O/TWAMP packets is possible, so that middle step can be skipped ⚡. That could improve accuracy, since the sequence number can be encrypted and authenticated before the timestamp is fetched 🎯. The receiver gets the timestamp without needing the matching decryption step 🫶. So in these cases, using O/TWAMP security but bypassing the IPsec tunnel has real advantages 👑.
This document specifies a way to enable network measurements between a TWAMP client and a TWAMP server 💜. The short version is that the shared key used to secure TWAMP traffic is derived from IKEv2 [RFC7296] ✨. TWAMP implementations signal that they're using this method by setting IKEv2Derived (see Section 7) 🚩. IKEv2-derived keys SHOULD be used instead of shared secrets when O/TWAMP is employed in a deployment using IKEv2 💖. From an operations and management perspective [RFC5706], the mechanism in this document requires that both the TWAMP Control-Client and Server support IPsec 🛠️.
Here's how the rest of the doc is laid out 🗺️. Section 4 sums up O/TWAMP protocol operation with respect to security. Section 5 presents the method for binding TWAMP and IKEv2 for network measurements between a client and a server that both support IKEv2. Finally, Section 6 talks through the security considerations that come with the proposed mechanisms 🔐.
2. Terminology 📖
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🎓.
3. Scope 🌷
This document specifies a method using keys derived from an IKEv2 SA as the shared key in O/TWAMP 🦋. O/TWAMP implementations signal that they're using this method by setting IKEv2Derived (see Section 7) 🚩.
4. O/TWAMP Security 🔥
Security for O/TWAMP-Control and O/TWAMP-Test gets a quick recap in the following subsections 👀.
4.1. O/TWAMP-Control Security ✨
okay so O/TWAMP keeps its crypto stack super simple, bestie 💅 it leans on just two things:
- AES-CBC for confidentiality 🔐
- HMAC-SHA1 truncated to 128 bits for message authentication 🧁
Three modes are supported in the OWAMP-Control protocol: unauthenticated, authenticated, and encrypted. TWAMP-Control also has a mixed mode, which is lowkey iconic: TWAMP-Control runs in encrypted mode while TWAMP-Test runs in unauthenticated mode 🦋. The authenticated, encrypted, and mixed modes all need the endpoints to share a secret, usually a passphrase 🎀. That secret gets turned into a key with the password-based key derivation function PBKDF2 (PKCS #5) [RFC2898] 🔑.
In unauthenticated mode the security parameters just sit there unused 💤. In authenticated, encrypted, and mixed modes, the security parameters get negotiated while the control connection is being set up ✨.
Figure 1 shows the start-up dance for O/TWAMP-Control between a Control-Client and a Server 🌸. The Control-Client opens a TCP connection to the Server so it can send O/TWAMP-Control commands. The Server replies with a Server Greeting, which carries the Modes, Challenge, Salt, Count, and MBZ ("MUST be zero") fields (see Section 3.1 of [RFC4656]) 🧚. If the Control-Client's preferred mode is available, the client answers with a Set-Up-Response message that includes the selected Mode, the KeyID, the Token, and the Client initialization vector (IV) 💖. The Token is the Challenge (16 octets), an AES Session-key for encryption (16 octets), and an HMAC-SHA1 Session-key for authentication (32 octets), all stuck together 🍓. The Token itself gets encrypted with AES-CBC 🔒.
+----------------+ +--------+
| Control-Client | | Server |
+----------------+ +--------+
| |
|<------ TCP Connection-- ----->|
| |
|<------ Greeting message ------|
| |
|------- Set-Up-Response ------>|
| |
|<------ Server-Start ----------|
| |Figure 1: Initiation of O/TWAMP-Control
Encryption uses a key derived from the shared secret tied to KeyID 🗝️. In authenticated, encrypted, and mixed modes, everything after that gets encrypted with the AES Session-key and authenticated with the HMAC Session-key 💜. Once the Set-Up-Response lands, the Server sends back a Server-Start message holding the Server-IV 🦋. The Control-Client encrypts everything it sends over the newly set-up O/TWAMP-Control connection with stream encryption, using Client-IV as the IV. The Server does the same on its side with Server-IV as the IV 🎀. The IVs themselves go over the wire in cleartext 👀. Encryption kicks in with the block right after the one that carries the IV 🌈.
The Control-Client generates the AES Session-key and HMAC Session-key randomly 🎲. The HMAC Session-key gets sent along with the AES Session-key during O/TWAMP-Control connection setup 🫶. It is derived independently of the AES Session-key ✨.
4.2. O/TWAMP-Test Security 💫
O/TWAMP-Test runs over UDP, using the Session-Sender and Session-Reflector IP and port numbers that were negotiated during the Request-Session exchange 🛰️. O/TWAMP-Test has the same mode as O/TWAMP-Control, and every O/TWAMP-Test session inherits its O/TWAMP-Control session's mode, except when that session is in mixed mode 🌸.
The O/TWAMP-Test packet format is the same in authenticated and encrypted modes, but the encryption and authentication operations are different 🔄. Just like the O/TWAMP-Control session, each O/TWAMP-Test session has two keys: an AES Session-key and an HMAC Session-key. The difference is in how they get their keys 👑:
- O/TWAMP-Control: the keys are generated by the Control-Client and handed to the Server during control connection establishment, inside the Token of the Set-Up-Response message 🔑.
- O/TWAMP-Test: the keys are derived from the O/TWAMP-Control keys plus the session identifier (SID), which act as inputs to the key derivation function (KDF) 🧪. The O/TWAMP-Test AES Session-key comes from the O/TWAMP-Control AES Session-key and the 16-octet SID, and it handles encrypting and decrypting packets for that particular O/TWAMP-Test session 🎀. The O/TWAMP-Test HMAC Session-key comes from the O/TWAMP-Control HMAC Session-key and the 16-octet SID, and it handles authenticating packets for that particular O/TWAMP-Test session 💜.
4.3. O/TWAMP Security Root 🌳
As we already covered, the O/TWAMP-Test AES Session-key and HMAC Session-key are derived from the O/TWAMP-Control AES Session-key and HMAC Session-key respectively 🔁. The O/TWAMP-Control AES and HMAC Session-keys are generated randomly by the Control-Client and then encrypted with the shared secret tied to KeyID 🔐. So the security root is the shared secret key 🗝️. This means that for big deployments, key provisioning and management can get overly complicated 😭. A certificate-based approach using IKEv2 can manage the security root automatically and solve that problem, as we explain in Section 5 🦋.
5. O/TWAMP for IPsec Networks ✨
This section describes a way to bind O/TWAMP and IKEv2 for network measurements between a client and a server that both support IPsec 🌐. In short, the shared key used to secure O/TWAMP traffic is derived using IKEv2 [RFC7296] 🔑.
5.1. Shared Key Derivation 🧩
In authenticated, encrypted, and mixed modes, the shared secret key MUST be derived from the IKEv2 SA 🔐. We explicitly choose to derive the shared secret key from the IKEv2 SA rather than the child SA, since an IKEv2 SA can be created without generating any child SA [RFC6023] 🙈.
When the shared secret key is derived from the IKEv2 SA, SK_d must be generated first 🪄. SK_d must be computed as per [RFC7296] 💫.
The shared secret key MUST be generated as follows:
Shared secret key = prf( SK_d, "IPPM" )Here the string "IPPM" is encoded in ASCII, and "prf" is a pseudorandom function 🎀.
It is recommended that the shared secret key is derived in the IPsec layer, so that IPsec keying material is not exposed to the O/TWAMP client 🛡️. Note, however, that the interaction between the O/TWAMP and IPsec layers is host internal and implementation specific 🏠. That makes it clearly outside the scope of this document, which focuses on the interaction between the O/TWAMP client and server 🙌. Still, one possible approach is this: on the Control-Client side, the IPsec layer can look up the Security Association Database (SAD) using the IP address of the Server, and thereby match the corresponding IKEv2 SA 🔍. On the Server side, the IPsec layer can look up the corresponding IKEv2 SA by using the Security Parameter Indexes (SPIs) sent by the Control-Client (see Section 5.3), and therefore extract the shared secret key 🧠.
If both the client and server support IKEv2 but there is no current IKEv2 SA, there are two alternatives 🤔. In the first, the O/TWAMP Control-Client initiates the establishment of the IKEv2 SA, logs this operation, and selects the mode that supports IKEv2 📝. In the second, the O/TWAMP Control-Client does not initiate the IKEv2 SA, logs an error for operational management purposes, and goes ahead with the modes defined in [RFC4656], [RFC5357], and [RFC5618] 🍓. Both alternatives are feasible, but they are implementation specific, so it's up to the implementer 🫶.
If rekeying of the IKEv2 SA or deletion of the IKEv2 SA happens, the corresponding shared secret key generated from the SA MUST continue to be used until the O/TWAMP session terminates ⏳.
5.2. Server Greeting Message Update 📨
To trigger a binding between the key generated from IKEv2 and the O/TWAMP shared secret key, the Modes field in the Server Greeting Message (Figure 2) must support key derivation as discussed in Section 5.1 🎯. Support for deriving the shared key from the IKEv2 SA is indicated by setting IKEv2Derived (see Section 7) 🚩. So when this method is used, the Modes value extension MUST be supported 💅.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Unused (12 octets) |
| |
|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Modes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Challenge (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Salt (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Count (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MBZ (12 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 2: Server Greeting Format
The choice of this set of Modes values causes no backwards-compatibility problems for existing O/TWAMP clients 🥰. Robust legacy Control-Client implementations would simply ignore the fact that the IKEv2Derived Modes bit in the Server Greeting is set 🙈. On the flip side, a Control-Client that implements this method can tell when the O/TWAMP Server it contacted doesn't support this specification 🕵️. If the Server supports other Modes, as one could assume, the Control-Client then decides which Mode to use and indicates it as per [RFC4656] and [RFC5357] 📋. A Control-Client implementing this method that decides not to use IKEv2 derivation can simply behave as a client that is purely compatible with [RFC4656] and [RFC5357] 💜.
5.3. Set-Up-Response Update 🎀
okay so this is where the Set-Up-Response message gets its glow-up 💅✨ When an O/TWAMP Control-Client implementing this method gets a Server Greeting that shows support for Mode IKEv2Derived, it SHOULD reply to the O/TWAMP Server with a Set-Up-Response that says so 🫶 For example, a compatible O/TWAMP Control-Client picking the authenticated mode with IKEv2 shared secret key derivation should set the Mode bits as per Section 7 🦋
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| KeyID (80 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Token (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Client-IV (12 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Set-Up-Response MessageThe Security Parameter Index (SPI), as described in [RFC4301] and [RFC7296], uniquely identifies the SA. If the Control-Client supports shared secret key derivation for the IKEv2 SA, it will choose the corresponding Mode value and carry SPIi and SPIr in the KeyID field. SPIi and SPIr MUST be included in the KeyID field of the Set-Up-Response Message to indicate the IKEv2 SA from which the O/TWAMP shared secret key was derived. The length of SPI is 8 octets. Therefore, the first 8 octets of the KeyID field MUST carry SPIi, and the second 8 octets MUST carry SPIr. The remaining bits of the KeyID field MUST be set to zero. 🌸
An O/TWAMP Server implementation MUST obtain the SPIi and SPIr from the first 16 octets and ignore the remaining octets of the KeyID field. Then, the Control-Client and the Server can derive the shared secret key based on the Mode value and SPI. If the O/TWAMP Server cannot find the IKEv2 SA corresponding to the SPIi and SPIr received, it MUST log the event for operational management purposes. In addition, the O/TWAMP Server SHOULD set the Accept field of the Server-Start message to the value 6 to indicate that the Server is not willing to conduct further transactions in this O/TWAMP-Control session since it cannot find the corresponding IKEv2 SA. 🙈
5.4. O/TWAMP over an IPsec Tunnel 🧚
The IPsec Authentication Header (AH) [RFC4302] and Encapsulating Security Payload (ESP) [RFC4303] provide confidentiality and data integrity to IP datagrams. An IPsec tunnel can be used to provide the protection needed for O/TWAMP Control and Test packets, even if the peers choose the unauthenticated mode of operation. In order to ensure authenticity and security, O/TWAMP packets between two IKEv2 systems SHOULD be configured to use the corresponding IPsec tunnel running over an external network even when using the O/TWAMP unauthenticated mode. 💜
6. Security Considerations 💀
okay bestie, this part is SERIOUS 😭 As the shared secret key is derived from the IKEv2 SA, the key derivation algorithm strength and limitations are as per [RFC7296]. The strength of a key derived from a Diffie-Hellman exchange using any of the groups defined here depends on the inherent strength of the group, the size of the exponent used, and the entropy provided by the random number generator employed. The strength of all keys and implementation vulnerabilities, particularly denial-of-service (DoS) attacks are as defined in [RFC7296]. Please take this seriously, no cap 🔥
7. IANA Considerations 🌈
So the authors and reviewers noticed something during production: the TWAMP-Modes registry should describe a field of single bit position flags, rather than the existing registry construction with assignment of integer values. ngl that's a very smart catch 👑 Also, the Semantics Definition column seemed to have spurious info in it. The registry has been reformatted to simplify future assignments, so here are the contents of the TWAMP-Modes registry:
Bit|Description |Semantics |Reference
Pos| |Definition |
---|------------------------------------------|------------|---------
0 Unauthenticated Section 3.1 [RFC4656]
1 Authenticated Section 3.1 [RFC4656]
2 Encrypted Section 3.1 [RFC4656]
3 Unauth. TEST protocol, Encrypted CONTROL Section 3.1 [RFC5618]
4 Individual Session Control [RFC5938]
5 Reflect Octets Capability [RFC6038]
6 Symmetrical Size Sender Test Packet Format [RFC6038]
Figure 4: TWAMP ModesHere's the new description and registry management stuff 🍓
Registry Specification: TWAMP-Modes are specified in TWAMP Server Greeting messages and Set-Up-Response messages consistent with Section 3.1 of [RFC5357]. Modes are indicated by setting single bits in the 32-bit Modes field.
Registry Management: Because the "TWAMP-Modes" are based on only 32 bit positions with each position conveying a unique feature, and because TWAMP is an IETF protocol, this registry must be updated only by "IETF Review" as specified in [RFC5226]. IANA SHOULD allocate monotonically increasing bit positions when requested.
Experimental Numbers: No experimental bit positions are currently assigned in the Modes registry, as indicated in the initial contents above.
Also, per this document, a new entry has been added to the TWAMP-Modes registry 🎉
Bit|Description |Semantics |Reference
Pos| |Definition |
---|------------------------------------------|------------|---------
7 IKEv2Derived Mode Capability Section 5 RFC 7717
Figure 5: TWAMP IKEv2-Derived Mode CapabilityFor the new OWAMP-Modes registry, see the IANA Considerations in [RFC7718]. ✨
8. References 📚
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
Zekauskas, "A One-way Active Measurement Protocol (OWAMP)",
RFC 4656, DOI 10.17487/RFC4656, September 2006,
<http://www.rfc-editor.org/info/rfc4656>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
RFC 5357, DOI 10.17487/RFC5357, October 2008,
<http://www.rfc-editor.org/info/rfc5357>.
[RFC5618] Morton, A. and K. Hedayat, "Mixed Security Mode for the
Two-Way Active Measurement Protocol (TWAMP)", RFC 5618,
DOI 10.17487/RFC5618, August 2009,
<http://www.rfc-editor.org/info/rfc5618>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)",
STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014,
<http://www.rfc-editor.org/info/rfc7296>.
[RFC7718] Morton, A., "Registries for the One-Way Active Measurement
Protocol (OWAMP)", RFC 7718, DOI 10.17487/RFC7718,
December 2015, <http://www.rfc-editor.org/info/rfc7718>.8.2. Informative References
[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography
Specification Version 2.0", RFC 2898,
DOI 10.17487/RFC2898, September 2000,
<http://www.rfc-editor.org/info/rfc2898>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005,
<http://www.rfc-editor.org/info/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<http://www.rfc-editor.org/info/rfc4303>.
[RFC5706] Harrington, D., "Guidelines for Considering Operations and
Management of New Protocols and Protocol Extensions",
RFC 5706, DOI 10.17487/RFC5706, November 2009,
<http://www.rfc-editor.org/info/rfc5706>.
[RFC5938] Morton, A. and M. Chiba, "Individual Session Control
Feature for the Two-Way Active Measurement Protocol (TWAMP)",
RFC 5938, DOI 10.17487/RFC5938, August 2010,
<http://www.rfc-editor.org/info/rfc5938>.
[RFC6023] Nir, Y., Tschofenig, H., Deng, H., and R. Singh, "A
Childless Initiation of the Internet Key Exchange Version 2
(IKEv2) Security Association (SA)", RFC 6023,
DOI 10.17487/RFC6023, October 2010,
<http://www.rfc-editor.org/info/rfc6023>.
[RFC6038] Morton, A. and L. Ciavattone, "Two-Way Active Measurement
Protocol (TWAMP) Reflect Octets and Symmetrical Size
Features", RFC 6038, DOI 10.17487/RFC6038, October 2010,
<http://www.rfc-editor.org/info/rfc6038>.Acknowledgements 🫶
We thank Eric Chen, Yaakov Stein, Brian Trammell, Emily Bi, John Mattsson, Steve Baillargeon, Spencer Dawkins, Tero Kivinen, Fred Baker, Meral Shirazipour, Hannes Tschofenig, Ben Campbell, Stephen Farrell, Brian Haberman, and Barry Leiba for their reviews, comments, and text suggestions. 💖
Al Morton deserves a special mention for his thorough reviews and text contributions to this document as well as the constructive discussions over several IPPM meetings. he really carried the whole thing 🌈👑
Authors' Addresses 🦋
Kostas Pentikousis (editor) EICT GmbH EUREF-Campus Haus 13 Torgauer Strasse 12-15 10829 Berlin Germany
Email: k.pentikousis@eict.de
Emma Zhang Huawei Technologies Huawei Building, No.3, Rd. XinXi Haidian District, Beijing 100095 China
Email: emma.zhanglijia@huawei.com
Yang Cui Huawei Technologies Otemachi First Square 1-5-1 Otemachi Chiyoda-ku, Tokyo 100-0004 Japan
Email: cuiyang@huawei.com
📦 where this page comes from
- ietf: rfc7717 2015-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms