draft-ietf-ippm-ipsec-06.txt   draft-ietf-ippm-ipsec-07.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: May 14, 2015 Y. Cui Expires: June 30, 2015 Y. Cui
Huawei Technologies Huawei Technologies
November 10, 2014 December 27, 2014
IKEv2-based Shared Secret Key for O/TWAMP IKEv2-based Shared Secret Key for O/TWAMP
draft-ietf-ippm-ipsec-06 draft-ietf-ippm-ipsec-07
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
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 May 14, 2015. This Internet-Draft will expire on June 30, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 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
skipping to change at page 4, line 29 skipping to change at page 4, line 29
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 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 which both support IPsec.
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 document reserves from the TWAMP-Modes using IKEv2 [RFC7296]. This document reserves from the TWAMP-Modes
registry the Mode value IANA.TBA.TWAMP.IKEv2Derived which MUST be registry the Mode value IKEv2Derived which is equal to 128 (i.e. bit
used by TWAMP implementations compatible with this specification. 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 9, line 10 skipping to change at page 9, line 38
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 IANA.TBA.TWAMP.IKEv2Derived (note to IANA: 128 is specification is IKEv2Derived and is equal to 128 (i.e. bit set in
preferred, i.e. bit in position 7). Clearly, an implementation position 7) [NOTE to IANA: remove before allocation and final
compatible with this specification MUST support the authenticated, publication]. Clearly, an implementation compatible with this
encrypted and mixed modes as per [RFC4656][RFC5357][RFC5618]. specification MUST support the authenticated, encrypted and mixed
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 client implementations would disregard the fact that the IKEv2Derived
IANA.TBA.TWAMP.IKEv2Derived Modes bit in the Server Greeting is set. Modes bit in the Server Greeting is set. On the other hand, a client
On the other hand, a client compatible with this specification can compatible with this specification can easily identify that the O/
easily identify that the O/TWAMP server contacted does not support TWAMP server contacted does not support this specification. If the
this specification. If the server supports other Modes, as one could server supports other Modes, as one could assume, the client would
assume, the client would then decide which Mode to use and indicate then decide which Mode to use and indicate such accordingly as per
such accordingly as per [RFC4656][RFC5357]. A client compatible with [RFC4656][RFC5357]. A client compatible with this specification
this specification which decides not to employ IKEv2 derivation, can which decides not to employ IKEv2 derivation, can simply behave as a
simply behave as a 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 IANA.TBA.TWAMP.IKEv2Derived it Greeting indicating support for Mode IKEv2Derived it SHOULD reply to
SHOULD reply to the O/TWAMP server with a Set-Up response that the O/TWAMP server with a Set-Up response that indicates so. For
indicates so. For example, a compatible O/TWAMP client choosing the example, a compatible O/TWAMP client choosing the authenticated mode
authenticated mode with IKEv2 shared secret key derivation should set with IKEv2 shared secret key derivation should set Mode to 130, i.e.
Mode to 130, i.e. set the bits in positions 1 and 7 (TBD IANA) to set the bits in positions 1 and 7 (TBD IANA) to one.
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 11, line 35 skipping to change at page 11, line 44
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 As a more general note, the IPPM community may want to revisit the
arguments listed in [RFC4656], Sec. 6.6. Other widely-used Internet arguments listed in [RFC4656], Sec. 6.6. Other widely-used Internet
security mechanisms, such as TLS and DTLS, may also be considered for security mechanisms, such as TLS and DTLS, may also be considered for
future use over and above of what is already specified in [RFC4656] future use over and above of what is already specified in [RFC4656]
[RFC5357]. [RFC5357].
7. IANA Considerations 7. IANA Considerations
IANA is requested to allocate the IANA.TBA.TWAMP.IKEv2Derived Modes IANA is requested to allocate the IKEv2Derived Mode bit that is equal
value in the TWAMP-Modes registry. to 128 (i.e. bit set in position 7) in the TWAMP-Modes registry. The
TWAMP-Modes registry should be augmented as follows:
Value Description Semantics Definition
--------------------------------------------------------
128 IKEv2 Derived This memo, Section 5.2
Mode Capability new bit position 7
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.
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.
skipping to change at page 13, line 15 skipping to change at page 13, line 31
EICT GmbH EICT GmbH
EUREF-Campus Haus 13 EUREF-Campus Haus 13
Torgauer Strasse 12-15 Torgauer Strasse 12-15
10829 Berlin 10829 Berlin
Germany Germany
Email: k.pentikousis@eict.de Email: k.pentikousis@eict.de
Emma Zhang Emma Zhang
Huawei Technologies Huawei Technologies
Huawei Building, Q20, No.156, Rd. BeiQing Huawei Building, No.3, Rd. XinXi
Haidian District , Beijing 100095 Haidian District , Beijing 100095
P. R. China P. R. China
Email: emma.zhanglijia@huawei.com Email: emma.zhanglijia@huawei.com
Yang Cui Yang Cui
Huawei Technologies Huawei Technologies
Otemachi First Square 1-5-1 Otemachi Otemachi First Square 1-5-1 Otemachi
Chiyoda-ku, Tokyo 100-0004 Chiyoda-ku, Tokyo 100-0004
Japan Japan
 End of changes. 14 change blocks. 
34 lines changed or deleted 44 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/