--- 1/draft-ietf-ippm-ipsec-06.txt 2014-12-27 12:14:53.121251279 -0800 +++ 2/draft-ietf-ippm-ipsec-07.txt 2014-12-27 12:14:53.153252059 -0800 @@ -1,20 +1,20 @@ IPPM WG K. Pentikousis, Ed. Internet-Draft EICT Intended status: Standards Track E. Zhang -Expires: May 14, 2015 Y. Cui +Expires: June 30, 2015 Y. Cui Huawei Technologies - November 10, 2014 + December 27, 2014 IKEv2-based Shared Secret Key for O/TWAMP - draft-ietf-ippm-ipsec-06 + draft-ietf-ippm-ipsec-07 Abstract The O/TWAMP security mechanism requires that both the client and server endpoints possess a shared secret. Since the currently- standardized O/TWAMP security mechanism only supports a pre-shared key mode, large scale deployment of O/TWAMP is hindered significantly. At the same time, recent trends point to wider IKEv2 deployment which, in turn, calls for mechanisms and methods that enable tunnel end-users, as well as operators, to measure one-way and @@ -34,21 +34,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2014 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 @@ -57,35 +57,35 @@ 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Scope and Applicability . . . . . . . . . . . . . . . . . . . 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.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.3. Set-Up-Response Update . . . . . . . . . . . . . . . . . 10 5.4. O/TWAMP over an IPsec tunnel . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 - 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 - 9.2. Informative References . . . . . . . . . . . . . . . . . 12 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 + 9.2. Informative References . . . . . . . . . . . . . . . . . 13 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction The One-way Active Measurement Protocol (OWAMP) [RFC4656] and the Two-Way Active Measurement Protocol (TWAMP) [RFC5357] can be used to measure network performance parameters, such as latency, bandwidth, and packet loss by sending probe packets and monitoring their experience in the network. In order to guarantee the accuracy of network measurement results, security aspects must be considered. Otherwise, attacks may occur and the authenticity of the measurement @@ -156,22 +156,24 @@ 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 and Applicability This document specifies a method for enabling network measurements between a TWAMP client and a TWAMP server which both support IPsec. In short, the shared key used for securing TWAMP traffic is derived using IKEv2 [RFC7296]. This document reserves from the TWAMP-Modes - registry the Mode value IANA.TBA.TWAMP.IKEv2Derived which MUST be - 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 applicable to OWAMP per se, the lack of an established IANA registry for OWAMP Mode values technically prevents us from extending OWAMP Mode values. Therefore, independent OWAMP implementations SHOULD be checked for full compatibility with respect to the use of this Mode value. Until an IANA registry for OWAMP Mode values is established, the use this feature in OWAMP implementations MUST be arranged privately among consenting OWAMP users. @@ -372,47 +375,47 @@ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Server Greeting format 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 extension MUST be supported by implementations compatible with this document, indicating support for deriving the shared key from the IKEv2 SA. The new Modes value indicating support for this - specification is IANA.TBA.TWAMP.IKEv2Derived (note to IANA: 128 is - preferred, i.e. bit in position 7). Clearly, an implementation - compatible with this specification MUST support the authenticated, - encrypted and mixed modes as per [RFC4656][RFC5357][RFC5618]. + specification is IKEv2Derived and is equal to 128 (i.e. bit set in + position 7) [NOTE to IANA: remove before allocation and final + publication]. Clearly, an implementation compatible with this + 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 compatibility problems to existing O/TWAMP clients. Robust legacy - client implementations would disregard the fact that the - IANA.TBA.TWAMP.IKEv2Derived Modes bit in the Server Greeting is set. - On the other hand, a client compatible with this specification can - easily identify that the O/TWAMP server contacted does not support - this specification. If the server supports other Modes, as one could - assume, the client would then decide which Mode to use and indicate - such accordingly as per [RFC4656][RFC5357]. A client compatible with - this specification which decides not to employ IKEv2 derivation, can - simply behave as a purely [RFC4656]/[RFC5357] compatible client. + client implementations would disregard the fact that the IKEv2Derived + Modes bit in the Server Greeting is set. On the other hand, a client + compatible with this specification can easily identify that the O/ + TWAMP server contacted does not support this specification. If the + server supports other Modes, as one could assume, the client would + then decide which Mode to use and indicate such accordingly as per + [RFC4656][RFC5357]. A client compatible with this specification + which decides not to employ IKEv2 derivation, can simply behave as a + purely [RFC4656]/[RFC5357] compatible client. 5.3. Set-Up-Response Update The Set-Up-Response Message should be updated as in Figure 3. When a O/TWAMP client compatible with this specification receives a Server - Greeting indicating support for Mode IANA.TBA.TWAMP.IKEv2Derived it - SHOULD reply to the O/TWAMP server with a Set-Up response that - indicates so. For example, a compatible O/TWAMP client choosing the - authenticated mode 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. + Greeting indicating support for Mode IKEv2Derived it SHOULD reply to + the O/TWAMP server with a Set-Up response that indicates so. For + example, a compatible O/TWAMP client choosing the authenticated mode + 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. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Key ID (80 octets) | | | | | @@ -475,22 +478,30 @@ 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 - IANA is requested to allocate the IANA.TBA.TWAMP.IKEv2Derived Modes - value in the TWAMP-Modes registry. + 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 + 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 We thank Eric Chen, Yaakov Stein, Brian Trammell, Emily Bi, John Mattsson, and Steve Baillargeon for their 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. @@ -541,21 +554,21 @@ EICT GmbH EUREF-Campus Haus 13 Torgauer Strasse 12-15 10829 Berlin Germany Email: k.pentikousis@eict.de Emma Zhang Huawei Technologies - Huawei Building, Q20, No.156, Rd. BeiQing + Huawei Building, No.3, Rd. XinXi Haidian District , Beijing 100095 P. R. China Email: emma.zhanglijia@huawei.com Yang Cui Huawei Technologies Otemachi First Square 1-5-1 Otemachi Chiyoda-ku, Tokyo 100-0004 Japan