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

[[e-mail]]

Hi Al,



Thanks for clarifications, I agree to your proposals.



Yes, if a test running for 10 sec at line-speed can reliably only be invoked willingly by the party having to cope with the congested link, then an emergency-stop likely isn't required.



Regards,



Ruediger









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



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]><mailto:&lt;[e-mail]&gt;> On Behalf Of [e-mail]<mailto:[e-mail]>

Sent: Tuesday, December 7, 2021 3:01 AM

To: marcus.ihlar=[e-mail]<mailto:marcus.ihlar=[e-mail]>

Cc: [e-mail]<mailto:[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]<mailto:[e-mail]%3cmailto:[e-mail]>> Im Auftrag von Marcus Ihlar

Gesendet: Montag, 6. Dezember 2021 16:53

An: [e-mail]<mailto:[e-mail]<mailto:[e-mail]%3cmailto:[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/rfc9097/%3Chttps:/urldefense.com/v3/__https:/datatracker.ietf.org/doc/rfc9097/__;!!BhdT!0XFagPVddMPqLtUl1ej6zNK69Ogn2sgujZ23jLU92MHMnHJnppFGox6tI3-r$%3E>)$>;)



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/draft-morton-ippm-capacity-metric-protocol/%3Chttps:/urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-morton-ippm-capacity-metric-protocol/__;!!BhdT!0XFagPVddMPqLtUl1ej6zNK69Ogn2sgujZ23jLU92MHMnHJnppFGoww_Z_IZ$%3E>

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$><https://datatracker.ietf.org/doc/html/draft-morton-ippm-capacity-metric-protocol-02%3Chttps:/urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-morton-ippm-capacity-metric-protocol-02__;!!BhdT!0XFagPVddMPqLtUl1ej6zNK69Ogn2sgujZ23jLU92MHMnHJnppFGo-rAHSKU$%3E>



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