draft-ietf-ippm-ipsec-08.txt   draft-ietf-ippm-ipsec-09.txt 
IPPM WG K. Pentikousis, Ed. IPPM WG K. Pentikousis, Ed.
Internet-Draft EICT Internet-Draft EICT
Intended status: Standards Track E. Zhang Intended status: Standards Track E. Zhang
Expires: July 30, 2015 Y. Cui Expires: August 15, 2015 Y. Cui
Huawei Technologies Huawei Technologies
January 26, 2015 February 11, 2015
IKEv2-based Shared Secret Key for O/TWAMP IKEv2-based Shared Secret Key for O/TWAMP
draft-ietf-ippm-ipsec-08 draft-ietf-ippm-ipsec-09
Abstract Abstract
The O/TWAMP security mechanism requires that both the client and The One-way Active Measurement Protocol (OWAMP) and Two-Way Active
server endpoints possess a shared secret. Since the currently- Measurement Protocol (TWAMP) security mechanism require that both the
standardized O/TWAMP security mechanism only supports a pre-shared client and server endpoints possess a shared secret. Since the
key mode, large scale deployment of O/TWAMP is hindered currently-standardized O/TWAMP security mechanism only supports a
significantly. At the same time, recent trends point to wider IKEv2 pre-shared key mode, large scale deployment of O/TWAMP is hindered
deployment which, in turn, calls for mechanisms and methods that significantly. At the same time, recent trends point to wider
enable tunnel end-users, as well as operators, to measure one-way and Internet Key Exchange Protocol Version 2 (IKEv2) deployment which, in
two- way network performance in a standardized manner. This document turn, calls for mechanisms and methods that enable tunnel end-users,
describes the use of keys derived from an IKEv2 SA as the shared key as well as operators, to measure one-way and two- way network
in O/TWAMP. If the shared key can be derived from the IKEv2 SA, O/ performance in a standardized manner. This document describes the
TWAMP can support certificate-based key exchange, which would allow use of keys derived from an IKEv2 security association (SA) as the
for more operational flexibility and efficiency. The key derivation shared key in O/TWAMP. If the shared key can be derived from the
presented in this document can also facilitate automatic key IKEv2 SA, O/TWAMP can support certificate-based key exchange, which
management. would allow for more operational flexibility and efficiency. The key
derivation presented in this document can also facilitate automatic
key management.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 30, 2015. This Internet-Draft will expire on August 15, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 26 skipping to change at page 2, line 26
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Scope and Applicability . . . . . . . . . . . . . . . . . . . 4 3. Scope and Applicability . . . . . . . . . . . . . . . . . . . 4
4. O/TWAMP Security . . . . . . . . . . . . . . . . . . . . . . 4 4. O/TWAMP Security . . . . . . . . . . . . . . . . . . . . . . 4
4.1. O/TWAMP-Control Security . . . . . . . . . . . . . . . . 4 4.1. O/TWAMP-Control Security . . . . . . . . . . . . . . . . 5
4.2. O/TWAMP-Test Security . . . . . . . . . . . . . . . . . . 6 4.2. O/TWAMP-Test Security . . . . . . . . . . . . . . . . . . 6
4.3. O/TWAMP Security Root . . . . . . . . . . . . . . . . . . 7 4.3. O/TWAMP Security Root . . . . . . . . . . . . . . . . . . 7
5. O/TWAMP for IPsec Networks . . . . . . . . . . . . . . . . . 7 5. O/TWAMP for IPsec Networks . . . . . . . . . . . . . . . . . 7
5.1. Shared Key Derivation . . . . . . . . . . . . . . . . . . 7 5.1. Shared Key Derivation . . . . . . . . . . . . . . . . . . 7
5.2. Server Greeting Message Update . . . . . . . . . . . . . 8 5.2. Server Greeting Message Update . . . . . . . . . . . . . 8
5.3. Set-Up-Response Update . . . . . . . . . . . . . . . . . 9 5.3. Set-Up-Response Update . . . . . . . . . . . . . . . . . 10
5.4. O/TWAMP over an IPsec tunnel . . . . . . . . . . . . . . 11 5.4. O/TWAMP over an IPsec tunnel . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
The One-way Active Measurement Protocol (OWAMP) [RFC4656] and the The One-way Active Measurement Protocol (OWAMP) [RFC4656] and the
Two-Way Active Measurement Protocol (TWAMP) [RFC5357] can be used to Two-Way Active Measurement Protocol (TWAMP) [RFC5357] can be used to
measure network performance parameters such as latency, bandwidth, measure network performance parameters such as latency, bandwidth,
skipping to change at page 3, line 15 skipping to change at page 3, line 15
altering the measurement results. altering the measurement results.
The currently-standardized O/TWAMP security mechanism [RFC4656] The currently-standardized O/TWAMP security mechanism [RFC4656]
[RFC5357] requires that endpoints (i.e. both the client and the [RFC5357] requires that endpoints (i.e. both the client and the
server) possess a shared secret. In today's network deployments, server) possess a shared secret. In today's network deployments,
however, the use of pre-shared keys is far from optimal. For however, the use of pre-shared keys is far from optimal. For
example, in wireless infrastructure networks, certain network example, in wireless infrastructure networks, certain network
elements, which can be seen as the two endpoints from an O/TWAMP elements, which can be seen as the two endpoints from an O/TWAMP
perspective, support certificate-based security. For instance, perspective, support certificate-based security. For instance,
consider the case in which one wants to measure IP performance consider the case in which one wants to measure IP performance
between an eNB and SeGW. Both eNB and SeGW are 3GPP/LTE nodes and between a E-UTRAN Evolved Node B (eNB) and Security Gateway (SeGW).
support certificate mode and IKEv2. Since the currently standardized Both eNB and SeGW are 3GPP Long Term Evolution (LTE) nodes and
O/TWAMP security mechanism only supports the pre-shared key mode, support certificate mode and the Internet Key Exchange Protocol
large scale deployment of O/TWAMP is hindered significantly. Version 2 (IKEv2). Since the currently standardized O/TWAMP security
Furthermore, deployment and management of "shared secrets" for mechanism only supports pre-shared key mode, large scale deployment
massive equipment installation consumes a tremendous amount of effort of O/TWAMP is hindered significantly. Furthermore, deployment and
and is prone to human error. management of "shared secrets" for massive equipment installation
consumes a tremendous amount of effort and is prone to human error.
With IKEv2 widely used, employing keys derived from IKEv2 SA as With IKEv2 widely used, employing keys derived from IKEv2 security
shared key can be considered as a viable alternative. In mobile association (SA) as shared key can be considered as a viable
telecommunication networks, the deployment rate of IPsec exceeds 95% alternative. In mobile telecommunication networks, the deployment
with respect to the LTE serving network. In older-technology rate of IPsec exceeds 95% with respect to the LTE serving network.
cellular networks, such as UMTS and GSM, IPsec use penetration is In older-technology cellular networks, such as UMTS and GSM, IPsec
lower, but still quite significant. If the shared key can be derived use penetration is lower, but still quite significant. If the shared
from the IKEv2 SA, O/TWAMP can support cert-based key exchange and key can be derived from the IKEv2 SA, O/TWAMP can support cert-based
practically increase flexibility and efficiency. The use of IKEv2 key exchange and practically increase operational flexibility and
also makes it easier to extend automatic key management. In general, efficiency. The use of IKEv2 also makes it easier to extend
O/TWAMP measurement packets can be transmitted inside the IPsec automatic key management. In general, O/TWAMP measurement packets
tunnel, as it occurs with typical user traffic, or transmitted can be transmitted inside the IPsec tunnel, as it occurs with typical
outside the IPsec tunnel. This may depend on the operator's policy user traffic, or transmitted outside the IPsec tunnel. This may
and is orthogonal to the mechanism described in this document. depend on the operator's policy and is orthogonal to the mechanism
described in this document.
When IPsec is deployed, protecting O/TWAMP traffic in unauthenticated When IPsec is deployed, protecting O/TWAMP traffic in unauthenticated
mode using IPsec is one option. Another option is to protect O/TWAMP mode using IPsec is one option. Another option is to protect O/TWAMP
traffic using O/TWAMP layer security established using the PSK traffic using O/TWAMP layer security established using the PSK
derived from IKEv2 but bypassing the IPsec tunnel. Protecting derived from IKEv2 but bypassing the IPsec tunnel. Protecting
unauthenticated O/TWAMP control and/or test traffic via AH or ESP unauthenticated O/TWAMP control and/or test traffic via
cannot provide various security options, e.g. it cannot authenticate Authentication Header (AH) [RFC4302] or Encapsulating Security
part of a O/TWAMP packet as mentioned in [RFC4656]. For measuring Payload (ESP) [RFC4303] cannot provide various security options,
latency, the timestamp is carried in O/TWAMP traffic. The sender has e.g. it cannot authenticate part of a O/TWAMP packet as mentioned in
to fetch the timestamp, encrypt it, and send it. In this case, the [RFC4656]. For measuring latency, timestamp is carried in O/TWAMP
middle step can be skipped, potentially improving accuracy as the traffic. The sender has to fetch the timestamp, encrypt it, and send
sequence number can be encrypted and authenticated before the it. In this case, the middle step can be skipped, potentially
timestamp is fetched. It is the same case for the receiver since it improving accuracy as the sequence number can be encrypted and
can obtain the timestamp by skipping the decryption step. In such authenticated before the timestamp is fetched. It is the same case
cases, protecting O/TWAMP traffic using O/TWAMP layer security but for the receiver since it can obtain the timestamp by skipping the
bypassing the IPsec tunnel has its advantages. decryption step. In such cases, protecting O/TWAMP traffic using O/
TWAMP layer security but bypassing IPsec tunnel has its advantages.
This document specifies a method for enabling network measurements This document specifies a method for enabling network measurements
between a TWAMP client and a TWAMP server which both support IPsec. between a TWAMP client and a TWAMP server, as discussed in Section 3.
In short, the shared key used for securing TWAMP traffic is derived In short, the shared key used for securing TWAMP traffic is derived
using IKEv2 [RFC7296]. This method SHOULD be used when O/TWAMP using IKEv2 [RFC7296]. From an operations and management perspective
traffic is bypassing IPsec protection and is running over an external [RFC5706], the mechanism described in this document requires that
network exactly between two IKEv2 systems. both the TWAMP client and server support IPsec. This method SHOULD
be used when O/TWAMP traffic is bypassing IPsec protection and is
running over an external network exactly between two IKEv2 systems.
After clarifying the terminology and scope in the subsequent After clarifying the terminology and scope in the subsequent
sections, the remainder of this document is organized as follows. sections, the remainder of this document is organized as follows.
Section 4 summarizes O/TWAMP protocol operation with respect to Section 4 summarizes O/TWAMP protocol operation with respect to
security. Section 5 presents the method for binding TWAMP and IKEv2 security. Section 5 presents the method for binding TWAMP and IKEv2
for network measurements between the client and the server which both for network measurements between the client and the server which both
support IKEv2. Finally, Section 6 discusses the security support IKEv2. Finally, Section 6 discusses the security
considerations arising from the proposed mechanisms. considerations arising from the proposed mechanisms.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Scope and Applicability 3. Scope and Applicability
This document reserves from the TWAMP-Modes registry the Mode value This document reserves from the TWAMP-Modes registry the Mode value
IKEv2Derived which is equal to 128 (i.e. bit set in position 7) [NOTE IKEv2Derived which is equal to 128 (i.e. bit set in position 7) and
to IANA: remove before allocation and final publication] and MUST be MUST be used by TWAMP implementations compatible with this
used by TWAMP implementations compatible with this specification. specification.
Although the control procedures described in this document are Although the control procedures described in this document are
applicable to OWAMP per se, the lack of an established IANA registry applicable to OWAMP per se, the lack of an established IANA registry
for OWAMP Mode values technically prevents us from extending OWAMP for OWAMP Mode values technically prevents us from extending OWAMP
Mode values. Therefore, independent OWAMP implementations SHOULD be Mode values. Therefore, independent OWAMP implementations SHOULD be
checked for full compatibility with respect to the use of this Mode checked for full compatibility with respect to the use of this Mode
value. Until an IANA registry for OWAMP Mode values is established, value. Until an IANA registry for OWAMP Mode values is established,
the use this feature in OWAMP implementations MUST be arranged the use this feature in OWAMP implementations MUST be arranged
privately among consenting OWAMP users. privately among consenting OWAMP users.
skipping to change at page 5, line 28 skipping to change at page 5, line 35
parameters are negotiated during the control connection parameters are negotiated during the control connection
establishment. establishment.
Figure 1 illustrates the initiation stage of the O/TWAMP-Control Figure 1 illustrates the initiation stage of the O/TWAMP-Control
protocol between a client and the server. In short, the client opens protocol between a client and the server. In short, the client opens
a TCP connection to the server in order to be able to send O/TWAMP- a TCP connection to the server in order to be able to send O/TWAMP-
Control commands. The server responds with a Server Greeting, which Control commands. The server responds with a Server Greeting, which
contains the Modes, Challenge, Salt, Count, and MBZ fields (see contains the Modes, Challenge, Salt, Count, and MBZ fields (see
Section 3.1 of [RFC4656]). If the client-preferred mode is Section 3.1 of [RFC4656]). If the client-preferred mode is
available, the client responds with a Set-Up- Response message, available, the client responds with a Set-Up- Response message,
wherein the selected Mode, as well as the KeyID, Token and Client IV wherein the selected Mode, as well as the KeyID, Token and Client
are included. The Token is the concatenation of a 16-octet initialization vector (IV) are included. The Token is the
Challenge, a 16-octet AES Session-key used for encryption, and a concatenation of a 16-octet Challenge, a 16-octet AES Session-key
32-octet HMAC-SHA1 Session-key used for authentication. The Token is used for encryption, and a 32-octet HMAC-SHA1 Session-key used for
encrypted using AES-CBC. authentication. The Token is encrypted using AES-CBC.
+--------+ +--------+ +--------+ +--------+
| Client | | Server | | Client | | Server |
+--------+ +--------+ +--------+ +--------+
| | | |
|<---- TCP Connection ----->| |<---- TCP Connection ----->|
| | | |
|<---- Greeting message ----| |<---- Greeting message ----|
| | | |
|----- Set-Up-Response ---->| |----- Set-Up-Response ---->|
skipping to change at page 9, line 11 skipping to change at page 9, line 39
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Server Greeting format Figure 2: Server Greeting format
The Modes field in Figure 2 will need to allow for support of key The Modes field in Figure 2 will need to allow for support of key
derivation as discussed in Section 5.1. As such, the Modes value derivation as discussed in Section 5.1. As such, the Modes value
extension MUST be supported by implementations compatible with this extension MUST be supported by implementations compatible with this
document, indicating support for deriving the shared key from the document, indicating support for deriving the shared key from the
IKEv2 SA. The new Modes value indicating support for this IKEv2 SA. The new Modes value indicating support for this
specification is IKEv2Derived and is equal to 128 (i.e. bit set in specification is IKEv2Derived and is equal to 128 (i.e. bit set in
position 7) [NOTE to IANA: remove before allocation and final position 7). Clearly, an implementation compatible with this
publication]. Clearly, an implementation compatible with this
specification MUST support the authenticated, encrypted and mixed specification MUST support the authenticated, encrypted and mixed
modes as per [RFC4656][RFC5357][RFC5618]. modes as per [RFC4656][RFC5357][RFC5618].
The choice of this set of Modes values poses no backwards The choice of this set of Modes values poses no backwards
compatibility problems to existing O/TWAMP clients. Robust legacy compatibility problems to existing O/TWAMP clients. Robust legacy
client implementations would disregard the fact that the IKEv2Derived client implementations would disregard the fact that the IKEv2Derived
Modes bit in the Server Greeting is set. On the other hand, a client Modes bit in the Server Greeting is set. On the other hand, a client
compatible with this specification can easily identify that the O/ compatible with this specification can easily identify that the O/
TWAMP server contacted does not support this specification. If the TWAMP server contacted does not support this specification. If the
server supports other Modes, as one could assume, the client would server supports other Modes, as one could assume, the client would
skipping to change at page 9, line 36 skipping to change at page 10, line 15
purely [RFC4656]/[RFC5357] compatible client. purely [RFC4656]/[RFC5357] compatible client.
5.3. Set-Up-Response Update 5.3. Set-Up-Response Update
The Set-Up-Response Message should be updated as in Figure 3. When a The Set-Up-Response Message should be updated as in Figure 3. When a
O/TWAMP client compatible with this specification receives a Server O/TWAMP client compatible with this specification receives a Server
Greeting indicating support for Mode IKEv2Derived it SHOULD reply to Greeting indicating support for Mode IKEv2Derived it SHOULD reply to
the O/TWAMP server with a Set-Up response that indicates so. For the O/TWAMP server with a Set-Up response that indicates so. For
example, a compatible O/TWAMP client choosing the authenticated mode example, a compatible O/TWAMP client choosing the authenticated mode
with IKEv2 shared secret key derivation should set Mode to 130, i.e. with IKEv2 shared secret key derivation should set Mode to 130, i.e.
set the bits in positions 1 and 7 (TBD IANA) to one. set the bits in positions 1 and 7 to one.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mode | | Mode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Key ID (80 octets) | | Key ID (80 octets) |
| | | |
| | | |
skipping to change at page 10, line 33 skipping to change at page 10, line 45
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Set-Up-Response Message Figure 3: Set-Up-Response Message
The Security Parameter Index (SPI)(see [RFC4301] [RFC7296]) can The Security Parameter Index (SPI)(see [RFC4301] [RFC7296]) can
uniquely identify the Security Association (SA). If the client uniquely identify the Security Association (SA). If the client
supports the derivation of shared secret key from IKEv2 SA, it will supports the derivation of shared secret key from IKEv2 SA, it will
choose the corresponding mode value and carry SPIi and SPIr in the choose the corresponding mode value and carry SPIi and SPIr in the
Key ID field. SPIi and SPIr MUST be included in the Key ID field of Key ID field. SPIi and SPIr MUST be included in the Key ID field of
Set-Up-Response Message to indicate the IKEv2 SA from which the O/ Set-Up-Response Message to indicate the IKEv2 SA from which the O/
TWAMP shared secret key derived from. The length of SPI is 4 octets. TWAMP shared secret key derived from. The length of SPI is 8 octets.
Therefore, the first 4 octets of Key ID field MUST carry SPIi and the Therefore, the first 8 octets of Key ID field MUST carry SPIi and the
second 4 octets MUST carry SPIr. The remaining bits of the Key ID second 8 octets MUST carry SPIr. The remaining bits of the Key ID
field MUST set to zero. field MUST set to zero.
A O/TWAMP server which supports the specification of this document, A O/TWAMP server which supports the specification of this document,
MUST obtain the SPIi and SPIr from the first 8 octets and ignore the MUST obtain the SPIi and SPIr from the first 16 octets and ignore the
remaining octets of the Key ID field. Then, the client and the remaining octets of the Key ID field. Then, the client and the
server can derive the shared secret key based on the mode value and 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 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 the SPIi and SPIr received, it MUST log the event for operational
management purposes. In addition, the O/TWAMP server SHOULD set the management purposes. In addition, the O/TWAMP server SHOULD set the
Accept field of the Server-Start message to the value 6 to indicate Accept field of the Server-Start message to the value 6 to indicate
that server is not willing to conduct further transactions in this O/ that server is not willing to conduct further transactions in this O/
TWAMP-Control session since it can not find the corresponding IKEv2 TWAMP-Control session since it can not find the corresponding IKEv2
SA. SA.
5.4. O/TWAMP over an IPsec tunnel 5.4. O/TWAMP over an IPsec tunnel
IPsec AH [RFC4302] and ESP [RFC4303] provide confidentiality and IPsec Authentication Header (AH) [RFC4302] and Encapsulating Security
data integrity to IP datagrams. Thus an IPsec tunnel can be used to Payload (ESP) [RFC4303] provide confidentiality and data integrity to
provide the protection needed for O/TWAMP Control and Test packets, IP datagrams. An IPsec tunnel can be used to provide the protection
even if the peers choose the unauthenticated mode of operation. If needed for O/TWAMP Control and Test packets, even if the peers choose
the two endpoints are already connected through an IPSec tunnel it is the unauthenticated mode of operation. In order to ensure
RECOMMENDED that the O/TWAMP measurement packets are forwarded over authenticity and security, the IPsec tunnel SHOULD be configured to
the IPSec tunnel if the peers choose the unauthenticated mode in include O/TWAMP measurement packets even when using the
order to ensure authenticity and security. unauthenticated mode.
6. Security Considerations 6. Security Considerations
As the shared secret key is derived from the IKEv2 SA, the key As the shared secret key is derived from the IKEv2 SA, the key
derivation algorithm strength and limitations are as per [RFC7296]. derivation algorithm strength and limitations are as per [RFC7296].
The strength of a key derived from a Diffie-Hellman exchange using The strength of a key derived from a Diffie-Hellman exchange using
any of the groups defined here depends on the inherent strength of 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 group, the size of the exponent used, and the entropy provided by
the random number generator employed. The strength of all keys and the random number generator employed. The strength of all keys and
implementation vulnerabilities, particularly Denial of Service (DoS) implementation vulnerabilities, particularly Denial of Service (DoS)
attacks are as defined in [RFC7296]. attacks are as defined in [RFC7296].
As a more general note, the IPPM community may want to revisit the
arguments listed in [RFC4656], Sec. 6.6. Other widely-used Internet
security mechanisms, such as TLS and DTLS, may also be considered for
future use over and above of what is already specified in [RFC4656]
[RFC5357].
7. IANA Considerations 7. IANA Considerations
IANA is requested to allocate the IKEv2Derived Mode bit that is equal IANA is requested to allocate the IKEv2Derived Mode bit that is equal
to 128 (i.e. bit set in position 7) in the TWAMP-Modes registry. The to 128 (i.e. bit set in position 7) in the TWAMP-Modes registry. The
TWAMP-Modes registry should be augmented as follows: TWAMP-Modes registry should be augmented as follows:
Value Description Semantics Definition Value Description Semantics Definition
-------------------------------------------------------- --------------------------------------------------------
128 IKEv2 Derived This memo, Section 5.2 128 IKEv2 Derived This memo, Section 5.2
Mode Capability new bit position 7 Mode Capability new bit position 7
Figure 4: IKEv2 Modes Capability Figure 4: IKEv2 Modes Capability
8. Acknowledgments 8. Acknowledgments
We thank Eric Chen, Yaakov Stein, Brian Trammell, Emily Bi, John We thank Eric Chen, Yaakov Stein, Brian Trammell, Emily Bi, John
Mattsson, and Steve Baillargeon for their comments and text Mattsson, Steve Baillargeon, Spencer Dawkins, Tero Kivinen, Fred
suggestions. We also thank Spencer Dawkins for his AD evaluation of Baker, Meral Shirazipour, and Hannes Tschofenig for their reviews,
this document. comments and text suggestions.
Al Morton deserves a special mention for his thorough reviews and Al Morton deserves a special mention for his thorough reviews and
text contributions to this document as well as the constructive text contributions to this document as well as the constructive
discussions over several IPPM meetings. discussions over several IPPM meetings.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 12, line 46 skipping to change at page 13, line 5
(IKEv2)", STD 79, RFC 7296, October 2014. (IKEv2)", STD 79, RFC 7296, October 2014.
9.2. Informative References 9.2. Informative References
[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography
Specification Version 2.0", RFC 2898, September 2000. Specification Version 2.0", RFC 2898, September 2000.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC5706] Harrington, D., "Guidelines for Considering Operations and
Management of New Protocols and Protocol Extensions", RFC
5706, November 2009.
[RFC6023] Nir, Y., Tschofenig, H., Deng, H., and R. Singh, "A [RFC6023] Nir, Y., Tschofenig, H., Deng, H., and R. Singh, "A
Childless Initiation of the Internet Key Exchange Version Childless Initiation of the Internet Key Exchange Version
2 (IKEv2) Security Association (SA)", RFC 6023, October 2 (IKEv2) Security Association (SA)", RFC 6023, October
2010. 2010.
Authors' Addresses Authors' Addresses
Kostas Pentikousis (editor) Kostas Pentikousis (editor)
EICT GmbH EICT GmbH
EUREF-Campus Haus 13 EUREF-Campus Haus 13
 End of changes. 23 change blocks. 
88 lines changed or deleted 92 lines changed or added

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