A Two-Way Active Measurement Protocol (TWAMP)
draft-ietf-ippm-twamp-09

[Ballot discuss]
This document mentions 'UTF-8' without a reference.  Please add a
reference to STD 63 (RFC3629).

RFC 4656 uses a shared secret in the form of a passphrase with no
mention of what charset is used to encode that passphrase.  That's
likely to cause interoperability problems for non-US-ASCII passphrases
and this specification inherits that problem.  Some resolutions that
would address the interoperability problem:
1. the passphrase must be US-ASCII.
2. the passphrase is UTF-8 as described in RFC 5198
3. the passphrase is UTF-8 with SASLprep (RFC 4013)

[Ballot comment]
The use of UTF-8 for KeyID is sufficiently narrow that it's unlikely to
create interoperability issues, but a reference to RFC 5198 would reduce
the chances of problem.  Without some canoncialization, it's possible to
have a KeyID most people can't type but it's unlikely people will actually
do that in practice.

[Ballot comment]
Section 1.2, Logical Model, implies that Session-Sender's definition is unchanged from that
in OWAMP.    Doesn't the Session-Sender need to be the entity that "is capable of returning
the results of a test session" since the Server no longer fills that role?  If that is true, I believe
Session-Sender should be added to the list with its expanded role.

It strikes me as a little odd that the first block of a message is encrypted in "authenticated only
mode".  It would be helpful if the security considerations shed some light on this architectural
decision.  (I realize that this is a carryover from 4656, but I didn't find a rationale there either.)

Upon review, the use of CBC with an IV of zero seems to be secure in the context of this
protocol.  However, generation of an IV in addition to the key material doesn't seem to be
an insurmountable problem.  I am curious why the designers of OWAMP chose this path...

[Ballot discuss]
The protocol relies on PKCS #5 to generate keys from shared secrets (passwords).  The document
recommends using 1024 as the iteration counter but provides a 32-bit field to convey the
iteration counter.  At the extreme, this provides an opportunity for a a DOS attack; generating
a key using 2**32 iterations could stall a system for a significant amount of time.  The
security considerations should strongly recommend configuration controls to permit rejecting
requests that specify overly large iteration counters.

TWAMP Light has SHOULDs for supporting authenticated and encrypted mode, but doesn't
include a TWAMP control session.  However, deriving the keys *requires* a TWAMP-Control
Session key.  How does the key derivation work in the absence of a TWAMP control session
key?  Further specification is needed here!

[Ballot comment]
I find the introduction to this document quite confusing.  I would
  me much happier with an introduction that tells the reader about
  the shortcomings of the current ICMP Echo-based solution and how
  the addition of a timestamp by the reflector is an improvement.

  Please define "MBZ".  Suresh Krishnan suggested the following:
  >
  > The bits marked MBZ MUST be set to zero by senders and MUST be
  > ignored by receivers.

  Suresh Krishnan suggested that Section 3.8 set the number of
  sessions field to 0 since there are no session description records
  that follow.

[Ballot comment]
Section 4.2.1:

(with the implication that the later two modes will
  not fit in a single ATM cell)

Is this comment at all relevant as there will be an IP and UDP header on the packet also, making the smallest packet size become 28+41?

Or is the intention to allow the format to be used with other encapsulations then IP/UDP? Then I would expect a clearer description of this fact and recommendation on what is necessary for that usage.

[Ballot comment]
Section 1.2, Logical Model, implies that Session-Sender's definition is unchanged from that
in OWAMP.    Doesn't the Session-Sender need to be the entity that "is capable of returning
the results of a test session" since the Server no longer fills that role?  If that is true, I believe
Session-Sender should be added to the list with its expanded role.

[Ballot comment]
Section 1.2, Logical Model, implies that Session-Sender's definition is unchanged from that
in OWAMP.    Doesn't the Session-Sender need to be the entity that "is capable of returning
the results of a test session" since the Server no longer fills that role?  If that is true, I believe
Session-Sender should be added to teh list with its expanded role.

IANA Last Call comments:

Action #1:
Upon approval of this document, the IANA will make the following
assignments in the "port numbers" registry at
http://www.iana.org/assignments/port-numbers

twamp-control TBD/tcp TWAMP-Control
twamp-control TBD/udp TWAMP-Control
# [RFC-ippm-twamp-08]

Note: if it is still possible to do so when the document is approved,
IANA will assign port number 862.

Action #2:
Upon approval of this document, the IANA will create the following
registry at http://www.iana.org/assignments/TBD

Registry Name: Two Way Active Measurement Protocol (TWAMP)
Control Number
Reference: [RFC-ietf-ippm-twamp-08.txt]
Registration Procedure: IETF Consensus

Registry:
Value Description Semantics Definition Reference
0 Reserved [RFC-ietf-ippm-twamp-08.txt]
1 Forbidden [RFC-ietf-ippm-twamp-08.txt]
2 Start-Sessions RFC4656, Section 3.7 [RFC4656]
3 Stop-Sessions RFC4656, Section 3.8 [RFC4656]
4 Reserved [RFC-ietf-ippm-twamp-08.txt]
5 Request-TW-Session this document, Section 3.5  [RFC-ietf-ippm-twamp-08.txt]
6 Experimentation undefined, see Section 8.3. [RFC-ietf-ippm-twamp-08.txt]
7-15 Unassigned

We understand the above to be the only IANA Actions for this
document.

(1.a) Who is the Document Shepherd for this document? Has the Document Shepherd
personally reviewed this version of the document and, in particular, does he or
she believe this version is ready for forwarding to the IESG for publication?

Henk Uijterwaal, henk@ripe.net. Yes, I have personally reviewed this document
throughout its life and believe that it is now ready for publication.

(1.b) Has the document had adequate review both from key WG members and from key
non-WG members? Does the Document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

The document has been reviewed by at least 8 WG members (the ones mentioned
section 7), but there have been more comments from folks on the list about
this document. The reviews appear to be thorough, as they touched on many
details in the document.


(1.c) Does the Document Shepherd have concerns that the document needs more
review from a particular or broader perspective, e.g., security, operational
complexity, someone familiar with AAA, internationalization or XML?

No. This document is closely related to the OWAMP protocol (RFC 4656).
Operational and security issues are similar and were discussed extensively
during the development of that document. No new issues came up during
the development of TWAMP.

(1.d) Does the Document Shepherd have any specific concerns or issues with
this document that the Responsible Area Director and/or the IESG should be aware of?

No

(1.e) 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?

A large fraction of the WG understands the document and agrees with it.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent?

No

(1.g) Has the Document Shepherd personally verified that the document
satisfies all ID nits?

The id-nits tool notices a few things but a review by a carbon based
processor showed that these are bugs in the tool, not the document.

(1.h) Has the document split its references into normative and informative?

Yes

Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear state?

No


(1.i) Has the Document Shepherd verified that the
document IANA consideration section exists and is consistent with the body of
the document?

Yes

If the document specifies protocol extensions, are reservations
requested in appropriate IANA registries? Are the IANA registries clearly
identified? If the document creates a new registry, does it define the proposed
initial contents of the registry and an allocation procedure for future
registrations? Does it suggest a reasonable name for the new registry? See
[RFC2434]. If the document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG can appoint the
needed Expert during the IESG Evaluation?

This is the case.


(1.j)

N/A.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document Announcement Write-Up?



Technical Summary

The One-way Active Measurement Protocol [RFC4656] (OWAMP) provides
a common protocol for measuring one-way metrics between network
devices. OWAMP can be used bi-directionally to measure one-way
metrics in both directions between two network elements. However,
it does not accommodate round-trip or two-way measurements. This
memo specifies a Two-way Active Measurement Protocol (TWAMP), based
on the OWAMP, that adds two-way or round-trip measurement
capabilities. The TWAMP measurement architecture is usually
comprised of two hosts with specific roles, and this allows for
some protocol simplifications, making it an attractive alternative
in some circumstances.

Working Group Summary

The working group has supported the document through the last
few revisions, and it has been uncontroversial.

Document Quality
The document has been given thorough review by the group over its
revisions, the key reviewers are listed in the acknowledgements section.

Personnel
Document Shepherd: Henk Uijterwaal
Responsible Area Director: Lars Eggert