RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 13 records.

Status: Verified (6)

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

Note: This RFC has been updated by RFC 5618, RFC 5938, RFC 6038, RFC 7717, RFC 7750, RFC 8545

Source of RFC: ippm (ops)

Errata ID: 1587
Status: Verified
Type: Technical
Publication Format(s) : TEXT

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
Publication Format(s) : TEXT

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
Publication Format(s) : TEXT

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
Publication Format(s) : TEXT

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.

Errata ID: 5045
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Xiao Min
Date Reported: 2017-06-21
Verifier Name: Mirja Kühlewind
Date Verified: 2020-03-04

Section 4.2.1 says:

   The minimum data segment length of TWAMP-Test packets in
   unauthenticated mode is 41 octets, and 104 octets in both
   authenticated mode and encrypted modes.

It should say:

   The minimum data segment length of TWAMP-Test packets in
   unauthenticated mode is 41 octets, and 112 octets in both
   authenticated mode and encrypted modes.

Notes:

In authenticated/encrypted mode, the minimum data segment length should be 112 octets, instead of 104 octets.

Errata ID: 5046
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Xiao Min
Date Reported: 2017-06-21
Verifier Name: Mirja Kühlewind
Date Verified: 2018-11-28

Section 4.1.2 says:

   each direction of transmission (this is usually desirable).  To
   compensate for the Reflector's larger test packet format, the Sender
   appends at least 27 octets of padding in unauthenticated mode, and at
   least 56 octets in authenticated and encrypted modes.

It should say:

   each direction of transmission (this is usually desirable).  To
   compensate for the Reflector's larger test packet format, the Sender
   appends at least 27 octets of padding in unauthenticated mode, and at
   least 64 octets in authenticated and encrypted modes.

Notes:

In authenticated/encrypted mode, the minimum data segment length of TWAMP-Test and OWAMP-Test packets is 112 octets and 48 octets respectively, so the Sender should append at least 64 octets, instead of 56 octets.

Status: Held for Document Update (6)

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

Note: This RFC has been updated by RFC 5618, RFC 5938, RFC 6038, RFC 7717, RFC 7750, RFC 8545

Source of RFC: ippm (ops)

Errata ID: 1591
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

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
Publication Format(s) : TEXT

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: 4429
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Steve Baillargeon
Date Reported: 2015-07-27
Held for Document Update by: Spencer Dawkins
Date Held: 2016-07-04

Section Appendix 1 says:

Section Appendix says: 
              controller                              responder
          +-----------------+                   +-------------------+
          |     Server      |<----------------->|                   |
          | Control-Client  |                   | Session-Reflector |
          | Session-Sender  |<--TWAMP-Test----->|                   |
          +-----------------+                   +-------------------+

It should say:

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


Notes:

The top arrow is not identified and misleading. It should be removed.

2015-07-29: RFC Editor changed the Type to Technical.

2016-07-04 Spencer chatted about this with Al Morton.

Al said -

> As I'm likely the last reachable author of TWAMP:
>
> In http://tools.ietf.org/html/rfc5357#section-1.2
> the Logical Model of TWAMP, the communications link
> between the Server and the Session-Reflector is indicated,
> but also undescribed. This communication is necessary for
> controlling state in the Session-Reflector, to start and
> stop sessions (which resets sequence renumbering in the
> Session-Reflector), for example.
>
> Also, section 1.2 says:
> "Unlabeled links in the figure are unspecified by
> this document and may be proprietary protocols."
>
> Like the Figure at the bottom of Page 4 in sec 1.2,
> the TWAMP-Light Figure is a re-formulation of the roles
> in the Logical Model, moving the Server alongside the
> Control-Client. The need for Server <-> Session-Reflector
> communications still exists for the case of TWAMP-Light
> operating *with* session state.

In previous discussions, Brian Trammell had suggested that unlabeled arrows should be marked "protocol unspecified" or "see section 1.2" here to clear up the confusion.

Spencer will leave this for the working group to consider if the document is updated.

Errata ID: 1586
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

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
Publication Format(s) : TEXT

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
Publication Format(s) : TEXT

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.

Status: Rejected (1)

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

Note: This RFC has been updated by RFC 5618, RFC 5938, RFC 6038, RFC 7717, RFC 7750, RFC 8545

Source of RFC: ippm (ops)

Errata ID: 3511
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT

Reported By: Steve Baillargeon
Date Reported: 2013-03-08
Rejected by: Martin Stiemerling
Date Rejected: 2015-07-16

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.
--VERIFIER NOTES--
Erratas are not meant to be used to expand existing text beyond textual clarifications.

Report New Errata



Advanced Search