IKEv2-Derived Shared Secret Key for the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)
draft-ietf-ippm-ipsec-11

[Ballot discuss]

(1) Are O/TWAMP vulnerable to reflection attacks with this scheme?
If so that's not good. Sorry that I didn't manage to figure
that out in the time available but I'm hoping you can just
tell me the answer quickly:-) If it's not vulnerable, that's
great though it might be worth making that clearer. If it is,
then that seems like a bad plan about which we ought chat.
The usual solution would be to derive different keys for each
direction of use, and just say to use those appropriately.
And even if O/TWAMP are thusly vulnerable with a PSK, it'd be
fine, and quite possible to fix that here now we're doing
better key mgmt.

(2) Is it clear what to do if a key needs to be derived for
O/TWAMP whilst re-keying is in progress for the IKE SA?
(Hannes' review made me wonder, and I don't recall if
the text on this is quite clear enough to not allow for a
case where the two sides end up with different values
derived from the DH share.)

[Ballot discuss]

Are O/TWAMP vulnerable to reflection attacks with this scheme?
If so that's not good. Sorry that I didn't manage to figure
that out in the time available but I'm hoping you can just
tell me the answer quickly:-) If it's not vulnerable, that's
great though it might be worth making that clearer. If it is,
then that seems like a bad plan about which we ought chat.
The usual solution would be to derive different keys for each
direction of use, and just say to use those appropriately.
And even if O/TWAMP are thusly vulnerable with a PSK, it'd be
fine, and quite possible to fix that here now we're doing
better key mgmt.

[Ballot comment]

Since you're touching on the key managment code, I'd have
loved to see you also update the O/TWAMP crypto itself to e.g.
use an AEAD cipher rather than AES-CBC. Did the WG consider
that? (I assume it's too late now, but I'm not clear from the
write-up if this is implemented or not, so I guess there's a
small chance that the WG may want to update more than just the
key mgmt.)

[Ballot discuss]
In the last paragraph, the text indicates that if the IKEv2 SA is rekeyed or deleted, O/TWAMP can continue to use the same shared secret. The language seems to make such a continuance optional. Does that cause an interoperability problem if the endpoints don't agree on the strategy?

If so, this may need a 2119 MUST (or possibly SHOULD).

[Ballot comment]
Section 1, paragraph 4:

This paragraph casts the decision whether to send O/TWAMP inside or outside of an IPSec tunnel as a question of how you want to secure the O/TWAMP packets. It seems to me that this is really more a matter of what you want to measure, given that the tunneled data and non-tunneled data may have different performance capabilities.

Sentence starting with "In this case...": The antecedent of "this" is unclear.

Section 1, 2nd to last paragraph:

I assume the last sentence means that IKEv2 derived keys SHOULD be used instead of shared secrets when otherwise using IKEv2. That seems to add a normative requirement to OWAMP and TWAMP in general, in which case this doc should be listed as updating those.

Section 3:

I agree with Brian's DISCUSS.

Section 4.1:

Please expand HMAC on first mention.

Section 5.1:

"SK_d MUST be computed as per [ref]" :That doesn't need 2119 language.

"string "IPPM" comprises four ASCII characters ": This is oddly constructed. Is this intended to observe that IPPM has 4 letters?

Section 5.2, paragraph after Figure 2: "Clearly, an implementation .... MUST ..."

It is not as clear to me. Why does the use of IKEv2 create a stronger requirement to support all 3 protection modes?

Section 5.3:, first paragraph:

"The Set-Up-Response Message should be updated": Do you mean to say it _is_ updated?

Paragraph after figure 3:

s/ "can uniquely identify" / "uniquely identifies"

5.4, last sentence:

The sentence is confusing. Do you mean to say that O/TWAMP SHOULD be configured to use the tunnel?

[Ballot comment]
General: the "implementations compatible with this specification" stuff is really awkward and unnecessary.  It would be better if it were changed to "implementations of this method" (and similar phrasing, such as "clients implementing this method") throughout the document.  But this is non-blocking, and there's no reason to discuss it.  I urge you to consider the change, but please do with that urging as you think best.

-- Section 3 --

  This document reserves from the TWAMP-Modes registry the Mode value
  IKEv2Derived which is equal to 128 (i.e. bit set in position 7) and
  MUST be used by TWAMP implementations compatible with this
  specification.

Pete Resnick has left the IESG in body only, but not in spirit.
I think what you mean here is that you signal that you're using this method by setting IKEv2Derived.  Is that correct?  Assuming so, this would be more clearly and simply said in a way such as this (definitely without any 2119 words, which aren't appropriate for that):

NEW
  TWAMP implementations signal the use of this method by setting
  IKEv2Derived (see Section 7).
END

Please leave the details of the registry, and which bit was assigned, to the IANA Considerations section, where that stuff belongs.  The reference to Section 7 makes it easy to find.

-- Section 5.2 --
As in Section 3, it's better just to refer to IKEv2Derived, and not to talk about the registration details here.  So:

OLD
  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 IKEv2Derived and is equal to 128 (i.e. bit set in
  position 7).  Clearly, an implementation compatible with this
  specification MUST support the authenticated, encrypted and mixed
  modes as per [RFC4656][RFC5357][RFC5618].
NEW
  The Modes field in Figure 2 will need to allow for support of key
  derivation as discussed in Section 5.1.  Therefore, when this
  method is used, the Modes value extension MUST be supported.
  Support for deriving the shared key from the IKEv2 SA is indicated
  by setting IKEv2Derived (see Section 7).  The authenticated,
  encrypted and mixed modes (see [RFC4656][RFC5357][RFC5618]) MUST
  also be supported.
END

[Ballot discuss]
I hope this is a short discussion and I can change my ballot to a Yes...

The applicability section says "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."

Is there an issue with this document creating that registry?  Or, if separation is needed, a companion document spun quickly to create this registry?  The functionality specified here seems quite applicable to OWAMP and requiring private agreements to use it seems sub-optimal.

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.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (IKEv2-based Shared Secret Key for O/TWAMP) to Proposed Standard


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'
  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
ietf@ietf.org mailing lists by 2015-02-09. Exceptionally, comments may be
sent to iesg@ietf.org 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.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

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

Working Group Summary

The document was discussed extensively within the IPPM WG, and has gone through two WGLCs. There was no significant controversy during the discussion of the document -- the main points of discussion had to do with the details of how to implement the binding between O/TWAMP and IPsec and whether the packet format used needed to be backward-compatible with non-IPsec O/TWAMP. The document has consensus to go forward.

Document Quality

As the document "glues" O/TWAMP to IPsec, it required review from both communities The document has had less comment from the IPsec WG than from the IPPM WG, but comments from IPsec were addressed.

Personnel

  Brian Trammell is the document shepherd. Spencer Dawkins is the responsible AD.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document shepherd has been reviewing the document and following discussion and changes since its adoption as a WG item, and believes the document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

IPPM reviews on the O/TWAMP side of the document are more than adequate. More review from IPsec would have been nice (we had one in-depth review, and the reviewer there also expressed concern that more IPsec review would be useful), but were not forthcoming.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

See (4) above.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

I have no concerns about WG consensus.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No nits.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No formal review criteria.

(13) Have all references within this document been identified as
either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

The IANA considerations section requests the allocation of a new bit in the TWAMP-modes registry.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No new registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

No formal language content.