Subject: [ippm] [IANA #805766] Last Call: <draft-ietf-ippm-ipsec-08.txt> (IKEv2-based Shared Secret Key for O/TWAMP) to Proposed Standard

From: "Pearl Liang via RT" <[email-masked]>
Date: Tue, 03 Feb 2015 16:55:41 +0000

(BEGIN IANA LAST CALL COMMENTS)

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-ippm-ipsec-08.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA has some questions about the IANA action requested by this draft.

We received the following comments/questions from the IANA's reviewer:

IANA understands that, upon approval of this document, there is a single action which must be completed.

In the TWAMP-Modes subregistry of the Two-way Active Measurement Protocol (TWAMP) Parameters registry located at:

https://www.iana.org/assignments/twamp-parameters/

a single new value is to be registered as follows:

Value: TBD
Description: IKEv2Derived Mode Capability
Semantics definition: Section 5.2, bit position 7
Reference: [ RFC-to-be ]

IANA understands that value 128 is being requested.

Question: A place holder 'TBD' is used in section 5.3:

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 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.

Q1. Have the authors decided to use value 128 as documented in the IANA 
Considerations (IC) section?

Q2. Section 5.3 said "set the bits in positions 1 and 7".  However, the IC 
mentions only position 7.  Are the authors requesting another value for 
position 1 for the place holder TBD?

IANA understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.  

Please note that IANA cannot reserve specific values. However, early allocation is available for some types of registrations. For more information, please see RFC 7120. 

Thanks,

Pearl Liang
ICANN

(END IANA LAST CALL COMMENTS)

On Mon Jan 26 15:26:36 2015, [email-masked] wrote:
> 
> The IESG has received a request from the IP Performance Metrics WG (ippm)
> to consider the following document:
> - 'IKEv2-based Shared Secret Key for O/TWAMP'
>   <draft-ietf-ippm-ipsec-08.txt> as Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2015-02-09. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> 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
>    two- way network performance in a standardized manner.  This document
>    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/
>    TWAMP can support certificate-based key exchange, which would allow
>    for more operational flexibility and efficiency.  The key derivation
>    presented in this document can also facilitate automatic key
>    management.
> 
> 
> 
> 
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-ippm-ipsec/
> 
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-ippm-ipsec/ballot/
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
>

---

From: Kostas Pentikousis <[email-masked]>
Date: Wed, 11 Feb 2015 17:54:40 +0100

Dear Pearl,

| We received the following comments/questions from the IANA's reviewer:
| 
| IANA understands that, upon approval of this document, there is a single
| action which must be completed.
| 
| In the TWAMP-Modes subregistry of the Two-way Active Measurement Protocol
| (TWAMP) Parameters registry located at:
| 
| https://www.iana.org/assignments/twamp-parameters/
| 
| a single new value is to be registered as follows:
| 
| Value: TBD
| Description: IKEv2Derived Mode Capability Semantics definition: Section 5.2,
| bit position 7
| Reference: [ RFC-to-be ]
|
| IANA understands that value 128 is being requested.

Correct. The new version (-09) does not include any text markers/placeholders for IANA.

| 
| Question: A place holder 'TBD' is used in section 5.3:
| 
| 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 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.
| 
| Q1. Have the authors decided to use value 128 as documented in the IANA
| Considerations (IC) section?

Yes.

| 
| Q2. Section 5.3 said "set the bits in positions 1 and 7".  However, the IC
| mentions only position 7.  Are the authors requesting another value for
| position 1 for the place holder TBD?

TBD was binding to "7" only, and has been removed in the latest version (-09)

| 
| IANA understands that this is the only action required to be completed upon
| approval of this document.

Correct. 

Many thanks and best regards,

Kostas