draft-ietf-ippm-ipsec-07.txt   draft-ietf-ippm-ipsec-08.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: June 30, 2015 Y. Cui Expires: July 30, 2015 Y. Cui
Huawei Technologies Huawei Technologies
December 27, 2014 January 26, 2015
IKEv2-based Shared Secret Key for O/TWAMP IKEv2-based Shared Secret Key for O/TWAMP
draft-ietf-ippm-ipsec-07 draft-ietf-ippm-ipsec-08
Abstract Abstract
The O/TWAMP security mechanism requires that both the client and The O/TWAMP security mechanism requires that both the client and
server endpoints possess a shared secret. Since the currently- server endpoints possess a shared secret. Since the currently-
standardized O/TWAMP security mechanism only supports a pre-shared standardized O/TWAMP security mechanism only supports a pre-shared
key mode, large scale deployment of O/TWAMP is hindered key mode, large scale deployment of O/TWAMP is hindered
significantly. At the same time, recent trends point to wider IKEv2 significantly. At the same time, recent trends point to wider IKEv2
deployment which, in turn, calls for mechanisms and methods that deployment which, in turn, calls for mechanisms and methods that
enable tunnel end-users, as well as operators, to measure one-way and enable tunnel end-users, as well as operators, to measure one-way and
two-way network performance in a standardized manner. This document two- way network performance in a standardized manner. This document
discusses the use of keys derived from an IKEv2 SA as the shared key describes the use of keys derived from an IKEv2 SA as the shared key
in O/TWAMP. If the shared key can be derived from the IKEv2 SA, O/ in O/TWAMP. If the shared key can be derived from the IKEv2 SA, O/
TWAMP can support certificate-based key exchange, which would allow TWAMP can support certificate-based key exchange, which would allow
for more operational flexibility and efficiency. The key derivation for more operational flexibility and efficiency. The key derivation
presented in this document can also facilitate automatic key presented in this document can also facilitate automatic key
management. 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.
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 June 30, 2015. This Internet-Draft will expire on July 30, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . 5 4.1. O/TWAMP-Control Security . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . . 10 5.3. Set-Up-Response Update . . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 13 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,
and packet loss by sending probe packets and monitoring their and packet loss by sending probe packets and monitoring their
experience in the network. In order to guarantee the accuracy of experience in the network. In order to guarantee the accuracy of
network measurement results, security aspects must be considered. network measurement results, security aspects must be considered.
Otherwise, attacks may occur and the authenticity of the measurement Otherwise, attacks may occur and the authenticity of the measurement
results may be violated. For example, if no protection is provided, results may be violated. For example, if no protection is provided,
an adversary in the middle may modify packet timestamps, thus an adversary in the middle may modify packet timestamps, thus
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 an eNB and SeGW. Both eNB and SeGW are 3GPP/LTE nodes and
support certificate mode and IKEv2. Since the currently standardized support certificate mode and IKEv2. Since the currently standardized
O/TWAMP security mechanism only supports pre-shared key mode, large O/TWAMP security mechanism only supports the pre-shared key mode,
scale deployment of O/TWAMP is hindered significantly. Furthermore, large scale deployment of O/TWAMP is hindered significantly.
deployment and management of "shared secrets" for massive equipment Furthermore, deployment and management of "shared secrets" for
installation consumes a tremendous amount of effort and is prone to massive equipment installation consumes a tremendous amount of effort
human error. 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 SA as
shared key can be considered as a viable alternative. In mobile shared key can be considered as a viable alternative. In mobile
telecommunication networks, the deployment rate of IPsec exceeds 95% telecommunication networks, the deployment rate of IPsec exceeds 95%
with respect to the LTE serving network. In older-technology with respect to the LTE serving network. In older-technology
cellular networks, such as UMTS and GSM, IPsec use penetration is cellular networks, such as UMTS and GSM, IPsec use penetration is
lower, but still quite significant. If the shared key can be derived lower, but still quite significant. If the shared key can be derived
from the IKEv2 SA, O/TWAMP can support cert-based key exchange and from the IKEv2 SA, O/TWAMP can support cert-based key exchange and
make it more flexible in practice and more efficient. The use of practically increase flexibility and efficiency. The use of IKEv2
IKEv2 also makes it easier to extend automatic key management. In also makes it easier to extend automatic key management. In general,
general, O/TWAMP measurement packets can be transmitted inside the O/TWAMP measurement packets can be transmitted inside the IPsec
IPsec tunnel, as it occurs with typical user traffic, or transmitted tunnel, as it occurs with typical user traffic, or transmitted
outside the IPsec tunnel. This may depend on the operator's policy outside the IPsec tunnel. This may depend on the operator's policy
and is orthogonal to the mechanism described in this document. 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 AH or ESP
cannot provide various security options, e.g. it cannot authenticate cannot provide various security options, e.g. it cannot authenticate
part of a O/TWAMP packet as mentioned in [RFC4656]. For measuring part of a O/TWAMP packet as mentioned in [RFC4656]. For measuring
latency, timestamp is carried in O/TWAMP traffic. The sender has to latency, the timestamp is carried in O/TWAMP traffic. The sender has
fetch the timestamp, encrypt it, and send it. In this case, the to fetch the timestamp, encrypt it, and send it. In this case, the
middle step can be skipped, potentially improving accuracy as the middle step can be skipped, potentially improving accuracy as the
sequence number can be encrypted and authenticated before the sequence number can be encrypted and authenticated before the
timestamp is fetched. It is the same case for the receiver since it timestamp is fetched. It is the same case for the receiver since it
can obtain the timestamp by skipping the decryption step. In such can obtain the timestamp by skipping the decryption step. In such
cases, protecting O/TWAMP traffic using O/TWAMP layer security but cases, protecting O/TWAMP traffic using O/TWAMP layer security but
bypassing IPsec tunnel has its advantages. This document describes bypassing the IPsec tunnel has its advantages.
how to derive the shared secret key from the IKEv2 SA and employ the
security service at the O/TWAMP layer. This method SHOULD be used This document specifies a method for enabling network measurements
when O/TWAMP traffic is bypassing IPsec protection and is running between a TWAMP client and a TWAMP server which both support IPsec.
over an external network exactly between two IKEv2 systems. In short, the shared key used for securing TWAMP traffic is derived
using IKEv2 [RFC7296]. 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 specifies a method for enabling network measurements This document reserves from the TWAMP-Modes registry the Mode value
between a TWAMP client and a TWAMP server which both support IPsec. IKEv2Derived which is equal to 128 (i.e. bit set in position 7) [NOTE
In short, the shared key used for securing TWAMP traffic is derived to IANA: remove before allocation and final publication] and MUST be
using IKEv2 [RFC7296]. This document reserves from the TWAMP-Modes used by TWAMP implementations compatible with this specification.
registry the Mode value IKEv2Derived which is equal to 128 (i.e. bit
set in position 7) [NOTE to IANA: remove before allocation and final
publication] and MUST be used by TWAMP implementations compatible
with this 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 8, line 5 skipping to change at page 7, line 38
key MUST be derived from the IKEv2 Security Association (SA). Note key MUST be derived from the IKEv2 Security Association (SA). Note
that we explicitly opt to derive the shared secret key from the IKEv2 that we explicitly opt to derive the shared secret key from the IKEv2
SA, rather than the child SA, since the use case whereby an IKEv2 SA SA, rather than the child SA, since the use case whereby an IKEv2 SA
can be created without generating any child SA is possible [RFC6023]. can be created without generating any child SA is possible [RFC6023].
When the shared secret key is derived from the IKEv2 SA, SK_d must be 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]. generated first. SK_d MUST be computed as per [RFC7296].
The shared secret key MUST be generated as follows: The shared secret key MUST be generated as follows:
Shared secret key = PRF( SK_d, "IPPM" ) Shared secret key = prf( SK_d, "IPPM" )
Wherein the string "IPPM" comprises four ASCII characters and prf is Wherein the string "IPPM" comprises four ASCII characters and "prf"
a pseudorandom function. It is recommended that the shared secret is a pseudorandom function. It is recommended that the shared secret
key is derived in the IPsec layer. This way, the IPsec keying key is derived in the IPsec layer. This way, the IPsec keying
material is not exposed to the O/TWAMP client. Note, however, that material is not exposed to the O/TWAMP client. Note, however, that
the interaction between the O/TWAMP and IPsec layers is host-internal the interaction between the O/TWAMP and IPsec layers is host-internal
and implementation-specific. Therefore, this is clearly outside the and implementation-specific. Therefore, this is clearly outside the
scope of this document, which focuses on the interaction between the scope of this document, which focuses on the interaction between the
O/TWAMP client and server. That said, one possible way could be the O/TWAMP client and server. That said, one possible way could be the
following: at the client side, the IPSec layer can perform a lookup following: at the client side, the IPSec layer can perform a lookup
in the Security Association Database (SAD) using the IP address of in the Security Association Database (SAD) using the IP address of
the server and thus match the corresponding IKEv2 SA. At the server the server and thus match the corresponding IKEv2 SA. At the server
side, the IPSec layer can look up the corresponding IKEv2 SA by using side, the IPSec layer can look up the corresponding IKEv2 SA by using
skipping to change at page 8, line 37 skipping to change at page 8, line 21
Again, although both alternatives are feasible, they are in fact Again, although both alternatives are feasible, they are in fact
implementation-specific. implementation-specific.
If rekeying for the IKEv2 SA or deletion of the IKEv2 SA occurs, the If rekeying for the IKEv2 SA or deletion of the IKEv2 SA occurs, the
corresponding shared secret key generated from the SA can continue to corresponding shared secret key generated from the SA can continue to
be used until the O/TWAMP session terminates. be used until the O/TWAMP session terminates.
5.2. Server Greeting Message Update 5.2. Server Greeting Message Update
To achieve a binding association between the key generated from IKEv2 To achieve a binding association between the key generated from IKEv2
and the O/TWAMP shared secret key, Server Greeting Message should be and the O/TWAMP shared secret key, Server Greeting Message should
updated as in Figure 2. include these extensions, as in Figure 2.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Unused (12 octets) | | Unused (12 octets) |
| | | |
|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Modes | | Modes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 12, line 16 skipping to change at page 11, line 50
-------------------------------------------------------- --------------------------------------------------------
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, and Steve Baillargeon for their comments and text
suggestions. suggestions. We also thank Spencer Dawkins for his AD evaluation of
this document.
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
 End of changes. 21 change blocks. 
43 lines changed or deleted 43 lines changed or added

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