errata logo graphic

Found 10 records.

Status: Verified (4)

RFC5357, "A Two-Way Active Measurement Protocol (TWAMP)", October 2008

Source of RFC: ippm (tsv)

Errata ID: 1587

Status: Verified
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2008-11-05
Verifier Name: Lars Eggert
Date Verified: 2009-05-14

Section 3.5, pg.10 says:

<< last paragraph of 3.5 >>

   When the requested Receiver Port is not available (e.g., port in
   use), the Server at the Session-Reflector MAY suggest an alternate
   and available port for this session in the Port field.  The Session-
   Sender either accepts the alternate port, or composes a new Session-
|  Request message with suitable parameters.  Otherwise, the Server at
   vvvvvvvvvvvvvvvvvv                                    !!!!!!!!!!^^^
|  the Control-Client uses the Accept field to convey other forms of
|  session rejection or failure and MUST NOT suggest an alternate port;
                               ^
   in this case, the Port field MUST be set to zero.

It should say:

   When the requested Receiver Port is not available (e.g., port in
   use), the Server at the Session-Reflector MAY suggest an alternate
   and available port for this session in the Port field.  The Session-
   Sender either accepts the alternate port, or composes a new Session-
|  Request message with suitable parameters.  Otherwise, the Server uses
                                                                   ^
|  the Accept field to convey other forms of session rejection or
|  failure to the Control-Client and MUST NOT suggest an alternate port;
          ^^^^^^^^^^^^^^^^^^^^^^^
   in this case, the Port field MUST be set to zero.

Notes:

The original description does not match the architectural model depicted
in the figure in Section 1.2 (page 4), where the Server and the
Control-Client are distinct entities, and the TWAMP-Control messages
flow between these parties.

The proposed corrected text aims to clarify the roles.


Errata ID: 1589

Status: Verified
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2008-11-05
Verifier Name: Lars Eggert
Date Verified: 2009-05-14

Section 4.2.1, pg.16 says:

<<  headline for figure on page 16  >>

|  For authenticated and encrypted modes:

It should say:

|  Plaintext format for authenticated and encrypted modes:
   ^^^^^^^^^^^^^^^^^^

Notes:

The original headline is misleading; it does *not* show the general
on-the-wire format, which is partially hidden by encryption.

Thus, the headline should be amended to avoid confusion.


Errata ID: 1590

Status: Verified
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2008-11-05
Verifier Name: Lars Eggert
Date Verified: 2009-05-14

Section 4.2.1, pg.17 says:

<<  second paragraph on page 17  >>
   Sequence Number is the sequence number of the test packet according
|  to its transmit order.  It starts with zero and is incremented by one
|  for each subsequent packet.  The Sequence Number generated by the
   Session-Reflector is independent from the sequence number of the
   arriving packets.

It should say:

   Sequence Number is the sequence number of the test packet according
|  to its transmit order within the TWAMP test session.  It starts with
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|  zero and is incremented by one for each subsequent packet in the
   vvvvvvv                                                  ^^^^^^^^
|  session.  The Sequence Number generated by the Session-Reflector is
   independent from the sequence number of the arriving packets.

Notes:

In the original text, it remains unclear whether this sequence number
is maintained per session, per Session-Sender, or per Session-Reflector.

Appendix I, in the 3rd text paragraph on page 23, seems to give
a hint that the Session-Reflector generated sequence numbers might
have been intended to be generated independently per *session*.

Since similar behavior is not present in OWAMP, it ugently needs to
be specified in RFC 5357 to further interoperable implementations.

The corrected text proposed aims at cure this deficiency via a change
with minimal footprint.


Errata ID: 1593

Status: Verified
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2008-11-05
Verifier Name: Lars Eggert
Date Verified: 2009-05-14

Section 8.1 and 8.2 says:

<<  Section 8.1, on top of page 22 >>

   IANA has created a TWAMP-Control Command Number registry.  TWAMP-
|  Control commands are specified by the first octet in OWAMP-Control
                                     !!!!!!!!!!!!!!!
   messages as shown in Section 3.5 of [RFC4656], and modified by this
|  document.  Thus, this registry may contain sixteen possible values.
                                              ^^^^^^^

It should say:

   IANA has created a TWAMP-Control Command Number registry.  TWAMP-
   Control commands are specified by the first octet in OWAMP-Control
   messages as shown in Section 3.5 of [RFC4656], and modified by this
|  document.  Thus, this registry may contain 256 possible values.
                                              ^^^

Notes:

Dependent second instance of the issue:

According to the quoted snippet from Section 8.1, Section 8.2 again
uses "may only contain sixteen values", which should be corrrected
in the same manner.


Rationale:

Apparently, "the first octet" will allow *256* possible values, not 16.
Therefore, without an explanation of why only 16 values are allowed,
this restriction does not make sense.

In to the lack of an explanation for the restriction, the RFC text
and the IANA registry should be changed, replacing "sixteen" by "256"
throughout.

Alternatively, a clarifying note would have to be supplied, in order
to justify the restriction.


Hint: Errata Note entered on request of the responsible AD before
resolution with the authors.


Status: Reported (1)

RFC5357, "A Two-Way Active Measurement Protocol (TWAMP)", October 2008

Source of RFC: ippm (tsv)

Errata ID: 3511

Status: Reported
Type: Editorial

Reported By: Steve Baillargeon
Date Reported: 2013-03-08

Section Appendix says:

              controller                              responder
          +-----------------+                   +-------------------+
          |     Server      |<----------------->|                   |
          | Control-Client  |                   | Session-Reflector |
          | Session-Sender  |<--TWAMP-Test----->|                   |
          +-----------------+                   +-------------------+

   This example provides a simple architecture for responders where
   their role will be to simply act as light test points in the network.
   The controller establishes the test session with the Server through
   non-standard means.  After the session is established, the controller
   transmits test packets to the responder.  The responder follows the
   Session-Reflector behavior of TWAMP as described in section 4.2 with
   the following exceptions.

   In the case of TWAMP Light, the Session-Reflector does not
   necessarily have knowledge of the session state.  IF the Session-
   Reflector does not have knowledge of the session state, THEN the
   Session-Reflector MUST copy the Sequence Number of the received
   packet to the Sequence Number field of the reflected packet.  The
   controller receives the reflected test packets and collects two-way
   metrics.  This architecture allows for collection of two-way metrics.

It should say:

              controller                              responder
          +-----------------+                   +-------------------+
          |     Server      |                   |                   |
          | Control-Client  |                   | Session-Reflector |
          | Session-Sender  |<--TWAMP-Test----->|                   |
          +-----------------+                   +-------------------+

   This example provides a simple architecture for responders where
   their role will be to simply act as light test points in the network.
   The controller establishes the test session with the Server through
   non-standard means.  After the session is established, the controller
   transmits test packets to the responder. Other examples are also
   possible. For instance, the responder may include a light Server
   responsible to instantiate the test session states based on the
   received test packets. The responder follows the Session-Reflector
   behavior of TWAMP as described in section 4.2 with the following
   exceptions.

   In the case of TWAMP Light, the Session-Reflector does not
   necessarily have knowledge of the session state.  IF the Session-
   Reflector does not have knowledge of the session state, THEN the
   Session-Reflector MUST copy the Sequence Number of the received
   packet to the Sequence Number field of the reflected packet.  The
   controller receives the reflected test packets and collects two-way
   metrics. This architecture allows for collection of two-way metrics.
   Otherwise IF the Session- Reflector has knowledge of the session
   state (using inspection of the received test packets for instance),
   THEN the Session-Reflector MUST generate it is own sequence number
   for each reflected packet.  The controller receives the reflected
   test packets and collects two-way and one-way metrics.  This
   alternative allows for collection of two-way and one-way metrics with
   TWAMP Light.

Notes:

Many readers of the appendix don't understand the meaning of informative and try to interpret the TWAMP light description as a specification. To correct this problem, it is recommended to add a few more lines explaning other TWAMP light architectures are possible. The original text describes a single TWAMP light architecture and this is misleading.


Status: Held for Document Update (5)

RFC5357, "A Two-Way Active Measurement Protocol (TWAMP)", October 2008

Source of RFC: ippm (tsv)

Errata ID: 1591

Status: Held for Document Update
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2008-11-05
Held for Document Update by: Lars Eggert

Section 6, pg.20 says:

<<  second paragraph of the section  >>

                                                             [...].  The
   Count field provides an opportunity for a denial-of-service (DOS)
   attack because it is 32 bits long.  If an attacking system set the
|  maximum value in Count (2**32), [...]

It should say:

                                                             [...].  The
   Count field provides an opportunity for a denial-of-service (DOS)
   attack because it is 32 bits long.  If an attacking system set the
|  maximum value in Count (2**32-1), [...]

Notes:

In the second paragraph of Section 6, near the bottom of page 20,
the maximum value given is too large. In the OWAMP specification,
I could not find any indication of a bias added to the Count value,
and thus the (hypothetical) range for Count is 0 .. 2**32-1 .

Thus, the RFC text needs to be corrected.


Errata ID: 1594

Status: Held for Document Update
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2008-11-05
Held for Document Update by: Lars Eggert

Section 3.8,1st para says:

                                vvvvvvvvvvvvvvvvv
                                                        [...].  The
|  message is terminated with a single block HMAC to complete the Stop-
   Sessions command.  [...]

It should say:

<<  either:  >>

                                                        [...].  The
|  message is terminated with a single-block HMAC to complete the Stop-
   Sessions command.  [...]

<<  or:  >>

                                       vvvvvvvvvv
                                                        [...].  The
|  message is terminated with a single HMAC block to complete the Stop-
   Sessions command.  [...]

Notes:

In any way this is problematic because the term "block" has not been
introduced into the RFC text. (That's also a problem for 4.2.1!)

Even in the restricted context of SHA (FIPS PUB 180-2/3) and HMAC
(FIPS PUB 197), the term "block" does not uniquely identify a
specific number of octets.
For SHA-1, SHA-224, and SHA-256, the block size is 512 bits,
for SHA-384 and SHA-512 it is 1024 bits.

But OWAMP uses a truncated version of HMAC-SHA-1 with a 128-bit MAC,
(officially denoted as HMAC-SHA-1-128), and apparently that is carried
over to TWAMP without mention in the RFCs.

It remains unclear from the text what precisely was intended to say.


Hint: Errata Note entered on request of the responsible AD before
resolution with the authors.


Errata ID: 1586

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2008-11-05
Held for Document Update by: Lars Eggert

Section 2, pg.5 says:

<< first bullet >>

                                                    vv
|  -  The Control-Client initiates a TCP connection on TWAMP's well-
      known port, and the Server (its role now established) responds
      with its Greeting message, indicating the security/integrity
      mode(s) it is willing to support.

It should say:

                                                    vv
|  -  The Control-Client initiates a TCP connection to TWAMP's well-
      known port, and the Server (its role now established) responds
      with its Greeting message, indicating the security/integrity
      mode(s) it is willing to support.

Notes:

The "on" is misleading or ambiguous; such verbiage commonly is used
to denote the *source* port used to send a packet, but from the
context (and in particular the first paragraph of Section 3.1)
it seems likely that you mean the *destination* port number here.

The corrected text aims to disambiguate/clarify/correct this.


Errata ID: 1588

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2008-11-05
Held for Document Update by: Lars Eggert

Section 4 says:

|                                 [...].  As with OWAMP-test protocol
   [RFC4656], there are three modes: unauthenticated, authenticated, and
   encrypted.

It should say:

|                                 [...].  As with the OWAMP-test
   protocol [RFC4656], there are three modes: unauthenticated,
   authenticated, and encrypted.

Notes:

Missing article.


Errata ID: 1592

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2008-11-05
Held for Document Update by: Lars Eggert

Section 8, pg. 21 says:

<<  near the bottom of page 21 >>

   #               863-872    Unassigned

Notes:

The indicated line should be deleted; it is confusing, as it
contains information on the state of the IANA registry at the
time of publication of the RFC, which is totally uncorrelated
to the matter of the RFC.


Report New Errata