Two-Way Active Measurement Protocol (TWAMP) Data Model

Note: This ballot was opened for revision 10 and is now closed.

Spencer Dawkins Yes

Ignas Bagdonas (was Discuss) No Objection

Comment (2018-06-26 for -11)
No email
send info
Thank you for addressing DISCUSS comments.

Deborah Brungard No Objection

Ben Campbell No Objection

Comment (2018-06-19 for -11)
No email
send info


The security consideration lists a couple of examples of writeable nodes that might be vulnerable. I'd like to see an actual list of nodes thought to be vulnerable, along with a sentence or two describing the risks for each.

Are there no nodes that are privacy (or otherwise) sensitive when just readable?


- Title/abstract: It seems like there's a bit more than a data model here; there some normative behavior as well.

- first bullet: s/ "identical with " / "identical to "
- third bullet: "such as" and "for example" are redundant.

Alissa Cooper No Objection

Comment (2018-06-21 for -11)
No email
send info
I support Adam's DISCUSS.

Section 1.1: I'm surprised to see the two references to the long-expired NFVRG drafts. If a reference to describe virtualized infrastructure using orchestration is really needed (I'm not convinced that it is), I would assume a better reference exists from outside the IETF/IRTF.

Section 5.2:

"Encrypted mode 'makes it impossible to alter
              timestamps undetectably.' See also Section 4 of RFC 7717
              and Section 6 of RFC 4656."

"Encrypted mode 'makes it impossible to alter
              timestamps undetectably' [Section 6 of RFC 4656]. See also Section 4 of RFC 7717."
Process comment more for the AD: the YANG doctors reviewed a version of this more than a year ago. Is that typical or would they normally review again during IETF LC?

Benjamin Kaduk No Objection

Comment (2018-06-18 for -11)
No email
send info
Perhaps I am confused and/or misreading things, but the descriptions
of the control-client and session-reflector include discussion of
'sid' session identifiers as if they were always used, but the mode
bitmap includes a separate bit for negotiation of
'individual-session-control' for session identifier usage.  Is there
some conflict between this mandatory/negotiable distinction, or are
they actually talking about different things?

Comments below in document order, but please pay special note to the
(potential) need for global uniqueness of key-ids, the PBKDF2
iteration count, and the list of sensitive nodes to call out in the
security considerations.

Section 3.1

   o  Authentication and encryption attributes such as KeyID, Token and
      the Client Initialization Vector (Client-IV); see also the last
      paragraph of Section 6 in OWAMP [RFC4656] and Randomness
      Requirements for Security [RFC4086].

I'm confused about what the RFC4656 reference is intended to call
out -- the reliance on AES to be resistant to chosen plaintext, or
the randomly generated challenge from the server, or the existential

   o  Information pertaining to the test packet stream, such as the test
      starting time, which performance metric is to be used Registry for
      Performance Metrics [I-D.ietf-ippm-metric-registry], or whether
      the test should be repeated.

Is there something missing before or around "Registry for
Performance Metrics"?  The current text is hard to read.

Section 3.4

   Each Session-Reflector is associated with zero or more TWAMP-Test
   sessions.  For each test session, the REFWAIT timeout parameter which
   determines whether to discontinue the session if no packets have been
   received (TWAMP [RFC5357], Section 4.2) can be configured.

nit: I think this would be easier to read if "which
determines...received" was offset by commas or parentheses.

   Read-only access to other data model parameters, such as the Sender
   IP address is foreseen.  Each test session can be uniquely identified
   by the 4-tuple mentioned in Section 3.2.

Nit: comma after "Sender IP address".

Section 4.1

   [...] Specifically, mode-preference-chain lists the
   mode and its corresponding priority, expressed as a 16-bit unsigned
   integer, where zero is the highest priority and subsequent integers
   increase by one.

I thought I remembered some discussion about this text being unclear
and removing "and subsequent integers increase by one" being
proposed.  But I don't see that discussion in an obvious place, so
maybe it was on a different document.

   Note that the list of preferred Modes may set bit position
   combinations when necessary, such as when referring to the extended

Maybe "may set multiple bits independently" would be more clear? 
But it seems that some bit combinations don't make any sense, like
unauthenticated+authenticated -- is there need for more expository
text here?

   [...] The secret-key is the shared secret, a sequence
   of octets of arbitrary length whose interpretation is unspecified.
   The key-id and secret-key encoding SHOULD follow Section 9.4 of YANG
   [RFC7950]. [...]

Section 9.4 of YANG is for (printable) strings, but the secret-key
is binary -- should this get a Section 9.8 reference as well?
I'm also not sure that leaving it as "arbitrary length"
is great -- if we're using it to derive 16-byte AES keys and 32-byte
HMAC-SHA1 keys, we could at least say "SHOULD contain at least 128
bits of entropy".

Section 4.2

   [...] The Server, being prepared to conduct
   sessions with more than one Control-Client, uses KeyIDs to choose the
   appropriate secret-key; a Control-Client would typically have
   different secret keys for different Servers. key-id tells the Server
   which shared-secret the Control-Client wishes to use for
   authentication or encryption.

Does this imply a global uniqueness requirement for key-ids?  If so,
that should be called out more clearly.

Section 4.3

                            | name                      |
                            | ctrl-connection-name {ro} |
                            | fill-mode                 |
                            | number-of-packets         |
                            | state {ro}                |
                            | sent-packets         {ro} |
                            | rcv-packets          {ro} |
                            | last-sent-seq        {ro} |
                            | last-rcv-seq         {ro} |

nit: should the "{ro}" on "state" be right-aligned with the others?

Is there any privacy concern about exposing the parent-connection

Section 5.2

In the 'count' leaf, a default value of 10 (corresponding to an
iteration count of 2^10 == 1024 for PBKDF2) is described.  This
seems quite low for a PBKDF2 iteration count, by modern standards.
In "normal" cryptographic protocols we would generally be using a
default closer to 32768 == 2^15 (which I see is the default *max*
count value, and there is additional discussion of the issue in the
leaf description for that leaf).  Perhaps one could make an argument
that this is just for test setups and the keys and data exchanged
are "not very valuable", but there is always risk of key sharing
across protocols, and my preference is to present the strong
defaults and give users the option to reduce where appropriate.
What are the authors' thoughts here?

Section 7

There are probably more nodes that can get called out as
particularly vulnerable, such as the count and max-count nodes that
can cause a long time to be spent on PBKDF2 iterations, the dscp
markings, the mode bitmask, etc.

Appendix A

The <secret-key> elements appear to be using base64-encoded values.
Where is it specified that such encoding is used for the binary
values?  (I assume this is just my ignorance of a generic standard,
so please enlighten me!)

Am I reading it right that the <count>30</count> means 2^30 (one
billion) PBKDF2 iterations?  Has this actually been run in practice?
It seems like it would be painfully slow.

Suresh Krishnan No Objection

Comment (2018-06-20 for -11)
No email
send info
It would be good if the yang model can be updated to refer to the NTPv4 specification (RFC5905) for the timestamps. It is currently referring to the obsolete NTPv3 specification (RFC1305 which is not listed in the references section) to describe the timestamp format.

Mirja Kühlewind No Objection

Comment (2018-06-18 for -11)
No email
send info
High level question: How does this YANG model relate to the lmap YANG model (rfc8194)?

Alexey Melnikov No Objection

Comment (2018-06-18 for -11)
No email
send info
         bit unauth-test-encrpyt-control {

I think you probably mean "encrypt" above

           position 3;
             "When using the Mixed Security Mode, the TWAMP-Test
              protocol follows the Unauthenticated mode and the
              TWAMP-Control protocol the Encrypted mode.";
             "RFC 5618: Mixed Security Mode for the Two-Way Active
              Measurement Protocol (TWAMP)";

On pages 25-26:

     grouping key-management {
       list key-chain {
         key key-id;
         leaf key-id {
           type string {
             length 1..80;
             "KeyID used for a TWAMP-Control connection. As per
              Section 3.1 of RFC 4656, KeyID is 'a UTF-8 string, up to
              80 octets in length' and is used to select which 'shared

This makes me slightly uncomfortable about possibility of truncating a UTF-8 encoding of some Unicode characters, but this probably doesn't matter in reality. Are these likely to be used for display?

              shared secret the [Control-Client] wishes to use to
              authenticate or encrypt'.";

Eric Rescorla No Objection

Comment (2018-06-19 for -11)
No email
send info
Rich version of this review at:

S 6.1.
>      Figure 8 shows a configuration example for a Control-Client with
>      client/admin-state enabled.  In a real implementation following
>      Figure 2 this would permit the initiation of TWAMP-Control
>      connections and TWAMP-Test sessions.
>      [note: '\' line wrapping is for formatting only]

Most of these examples do not contain any line wrapping.

S 7.
>        </twamp>
>      </data>
>   7.  Security Considerations
>      The YANG module specified in Section 5 this document defines a schema

Some words about the threat model would be appreciated here. Is the
assumption that the two sender and the reflector are owned by whoever
runs the network and therefore they are not mounting an attack? If
not, what is the model?

Alvaro Retana No Objection

Adam Roach (was Discuss) No Objection

Comment (2018-07-02)
No email
send info
Thanks for addressing my discuss and comments

Martin Vigoureux No Objection