Re: [ippm] draft-morton-ippm-capacity-metric-protocol

["MORTON JR., AL" <[e-mail]>]

Hi Rüdiger, Thanks again for your comments!

We discussed some of them at our coding project meeting today.
Please see [acm] for replies.

All proposals below are implemented in the working text.

Al

############

Some comments:

Section  3.  Protocol Overview

   The client requires configuration of a test direction parameter
   (upstream or downstream test) as well as the hostname or IP address
   of the server in order to begin the setup and configuration exchanges
   with the server.

RG: The draft also mentions a sender and a receiver. Both, client and server
may act as sender and receiver. This depends on the test direction,
upstream or downstream.

Words to that appear in "9.  Method of Measurement", at the end of the doc.

[acm]
OK. Let's try this for the paragraph above:

The client requires configuration of a test direction parameter
(upstream or downstream test, where the client performs the role of
                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
sender or receiver, respectively) as well as the hostname or IP address
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
of the server in order to begin the setup and configuration exchanges
with the server.


4.  Stopping the Test: The server initiates the phase to stop the
       test by setting the STOP1 indication in load PDUs or sstatus
       feedback messages.                                  ( ^^^^)

RG: Would it be worth a thought to enable the client to terminate a test?

[acm]
This sentence in section 3 might benefit from some clarification. I added:

4. Stopping the Test: When the specified test duration has been reached, the server
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   initiates the phase to stop the test by setting the STOP1 indication in load
   PDUs or status feedback messages. The client acknowledges by setting the STOP2
   in load PDUs or status feedback messages. ...

IOW, neither the server nor the client can stop a test prematurely in normal
operation. Note that the protocol overlays the STOP indication on existing
measurement and feedback traffic. It's very simple to implement.

Alternatively, a client (or server) can stop sending traffic
(load PDUs or status feedback messages, depending on its role).
An activity timer will expire at the opposite end, and both
client and server will close the connection. The timer value
can be set to expire as quickly as needed (some may be sensitive
to the amount of load PDUs sent after a test appears to fail).


##########


5.  Setup Request and Response Exchange


The message format isn't "TLV". Is the protocol extensible (e.g. could security be adapted to future needs)?

[acm]
All the message formats/PDUs are extensible. A specific set of formats match a
protocol version number (currently 8 in the draft you reviewed).
Our goal is to make version 9 and higher backward-compatible.
We should be able to add fields to the PDUs and leave earlier parts
untouched...


##########

6.2.  Test Activation Request - server response

.....The remaining 28 octets of the Test Activation Request (normally read

RG: A bit worrying, seems to be set by the sender in the reply to a request only. See editorials...

[acm]
Here's the full context:
   If the client has requested an upstream test, the server SHALL include
   the transmission parameters from the first row of the sending rate table.

   The remaining 28 octets of the Test Activation Request (normally read
   from the first row of the sending rate table) are called the
   Sending Rate Structure, and SHALL be organized as follows:
...

So, the Test Activation Response (the new name for section 6.2)
uses the Sending Rate Structure to communicate a starting send rate
for the test, IF the client is the sender, as in an upstream test.

Perhaps we can clarify:
   If the client has requested an upstream test, the server SHALL include
   the transmission parameters from the first row of the sending rate table
   in the Sending Rate Structure (defined below).


##########


7.1.  Test Packet PDU and Roles

.... On the other hand, the test configuration MAY use a fixed sending
   rate requested by the client,

RG: contains descriptive text about the method (e.g. decision on the
sending rate). The text there certainly is correct. I wonder, whether
a reference replacing the text would be sufficient?

[acm]
Actually, I don't see anything except protocol details near the OTOH
sentence above.

We can add a second clarifying sentence in the paragraph below:
   The client MAY communicate the desired fixed rate in its activation
   request. The reasons to conduct a fixed-rate test include stable measurement
   at the maximum determined by the load adjustment (search) algorithm,
   or the desire to test at a known subscribed rate without searching.


RG:  Does the MAY here introduce a new method? If it does, would that require
to update the RFC specifying the method?

[acm]
I don't think an update is necessary. We mentioned this possibility
immediately, in RFC 9097 Section 2:

   *  If a network operator is certain of the IP-Layer Capacity to be
      validated, then testing MAY start with a fixed-rate test at the
      IP-Layer Capacity and avoid activating the load adjustment
      algorithm.

###########

10.  Security Considerations


RG: would a receiver (client and host) require an "Emergency Stop" message?

[acm]
When would the client or server send this message?

As mentioned above, either end can initiate a premature stop, and timer
expiration takes care of the test termination at the opposite end.

RG: If yes, should it require authentication in order to avoid an attacker
from unwanted test termination?

[acm]
No "Emergency Stop" message, no attack.

#########


RG: Would a three-way-handshake make sense to activate testing?
(noting that the sender in that case also must be protected against
opening of unbounded numbers of tests). A three way handshake protects
against forged test set up messages.

[acm]
The combination of Test Setup and Test Activation define a 4-way handshake.


RG: What else could be forged?
[acm] everything in the current version, except the Authentication string.


RG: Do these require authentication or at least a discussion?

    Response message feedback (indicating ramp-up/no drop where there's congestion or the other way around, congestion where there is none).
    Stop messages (unwanted termination)
    Could a host or a client be tricked into persistently acting as a sender?

[acm]
Yes, of course! We want to supply sufficient AUTH and integrity options when
needed.  That's partly why we petitioned for WG Adoption, to get an early SEC-DIR
review or two.

However:

I have begin to think that we only need 4 security modes of operation:
1. Unauthenticated (in the protocol now)
2. Password-protected test setup (in the protocol now)
3. Encrypted Test Setup exchanges
4. Run the protocol inside an encrypted tunnel

#4 will have performance implications for high capacity measurements
on small hosts (in residences, GWs, WLAN devices, etc.)

FYI -  a client cannot be tricked into persistently acting as a sender.
The command that starts the client process determines this role.


########


Editorials

[acm]
Thanks for these!  I'll get to them in a second pass...

From: ippm <[e-mail]> On Behalf Of [e-mail]
Sent: Tuesday, December 7, 2021 3:01 AM
To: marcus.ihlar=[e-mail]
Cc: [e-mail]
Subject: Re: [ippm] draft-morton-ippm-capacity-metric-protocol

Hi Marcus,

I support adoption.

Regards, Ruediger


Some comments:

Section  3.  Protocol Overview

   The client requires configuration of a test direction parameter
   (upstream or downstream test) as well as the hostname or IP address
   of the server in order to begin the setup and configuration exchanges
   with the server.

RG: The draft also mentions a sender and a receiver. Both, client and server
may act as sender and receiver. This depends on the test direction,
upstream or downstream.
Words to that appear in "9.  Method of Measurement", at the end of the doc.


4.  Stopping the Test: The server initiates the phase to stop the
       test by setting the STOP1 indication in load PDUs or sstatus
       feedback messages.                                                      ( ^^^^)

RG: Would it be worth a thought to enable the client to terminate a test?

##########

5.  Setup Request and Response Exchange

The message format isn't "TLV". Is the protocol extensible (e.g. could security be adapted to future needs)?

##########

6.2.  Test Activation Request - server response

.....The remaining 28 octets of the Test Activation Request (normally read

RG: A bit worrying, seems to be set by the sender in the reply to a request only. See editorials...

##########

7.1.  Test Packet PDU and Roles

.... On the other hand, the test configuration MAY use a fixed sending
   rate requested by the client,

RG: contains descriptive text about the method (e.g. decision on the sending rate). The text
there certainly is correct. I wonder, whether a reference replacing the text would be sufficient?

RG:  Does the MAY here introduce a new method? If it does, would that require to update the
RFC specifying the method?

###########

10.  Security Considerations

RG: would a receiver (client and host) require an "Emergency Stop" message? If yes, should it require authentication in order to avoid an attacker from unwanted test termination?

Would a three-way-handshake make sense to activate testing? (noting that the sender in that case also must be protected against opening of unbounded numbers of tests). A three way handshake protects against forged test set up messages.

What else could be forged? Do these require authentication or at least a discussion?

  *   Response message feedback (indicating ramp-up/no drop where there's congestion or the other way around, congestion where there is none).
  *   Stop messages (unwanted termination)
  *   Could a host or a client be tricked into persistently acting as a sender?
########


Editorials

6.2.  Test Activation Request - server response

...   When the server sends the Test Activation response back, it SHALL set
   the cmd Response field to:

RG: Server Test Activation Reply (or Response - please apply stringently through the text)
When the server responds by a Test Activation Reply, it...

----

   The server SHALL include all the test parameters again to make the
   client aware of any changes.

RG: The server SHALL repeat all test parameters to indicate changes to the client.

----

8.  Stopping the Test

   When the test duration timer on the server expires, it SHALL set the
   connection test action to STOP and also starts marking all outgoing
   load or status PDUs with a test action of STOP1.

RG: ...and mark all outgoing load...

----

10.  Security Considerations

A. Unathenticated mode (for all phases)

Unauthenticated
    ^^^^

Von: ippm <[e-mail]<mailto:[e-mail]>> Im Auftrag von Marcus Ihlar
Gesendet: Montag, 6. Dezember 2021 16:53
An: [e-mail]<mailto:[e-mail]>
Betreff: [ippm] draft-morton-ippm-capacity-metric-protocol

Hi IPPM,

This email starts an adoption call for draft-morton-ippm-capacity-metric-protocol, " Test Protocol for One-way IP Capacity Measurement".  This document is intended for Standards Track and defines a protocol for measuring Network Capacity metrics defined in RFC 9097 (https://datatracker.ietf.org/doc/rfc9097/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/rfc9097/__;!!BhdT!0XFagPVddMPqLtUl1ej6zNK69Ogn2sgujZ23jLU92MHMnHJnppFGox6tI3-r$>)

https://datatracker.ietf.org/doc/draft-morton-ippm-capacity-metric-protocol/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-morton-ippm-capacity-metric-protocol/__;!!BhdT!0XFagPVddMPqLtUl1ej6zNK69Ogn2sgujZ23jLU92MHMnHJnppFGoww_Z_IZ$>
https://datatracker.ietf.org/doc/html/draft-morton-ippm-capacity-metric-protocol-02<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-morton-ippm-capacity-metric-protocol-02__;!!BhdT!0XFagPVddMPqLtUl1ej6zNK69Ogn2sgujZ23jLU92MHMnHJnppFGo-rAHSKU$>

This adoption call will last until Monday, December 20. Please review the document, and reply to this email thread to indicate if you think IPPM should adopt this document.

BR,
Marcus