Re: [ippm] Questions on draft-morton-ippm-capacity-metric-protocol-01

Hi Al,

A standardized protocol to request a standardized access bandwidth measurement is a generic requirement and I appreciate your initiative. As a person not personally implementing software, some high level comments on the doc only:

2.  Scope, Goals, and Applicability, last sentence: 

   "The primary application of the protocol described here is the same as
   in Section 2 of [RFC7479] where:"

That's a mis-quote, isn't it? You target another RFC, don't you?
>From numbers I guessed:	
https://www.rfc-editor.org/rfc/rfc7497.html#section-2

I started with a minor issue, as it points to RFC7497. The latter RFC contains the following statement:
https://www.rfc-editor.org/rfc/rfc7497.html#section-7
"Current IETF standardized test protocols (... [RFC5357 - TWAMP]..) do not possess the asymmetric size generation capability with two-way testing."

Adding a brief section to draft-morton-ippm-capacity-metric-protocol discussing why e.g. TWAMP (or a simplified version) isn't applied or rather enhanced for the measurement protocol may be useful. If existing IETF IPPM measurement control protocols don't offer any benefits justifying their adaption for a capacity-metric-protocol, the section will be brief. If there's pro and con, what's worth adding functionality to TWAMP and what's the "cost" (in terms of work and changes) may be worth some words. Should inclusion of a capacity-metric-protocol to TWAMP be worth a thought, a few words on required features and changes (a sketch on what to add) may be useful. I'm not a TWAMP expert, I excuse if my comment doesn't apply.

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: ippm <ippm-bounces@ietf.org> Im Auftrag von MORTON JR., AL
Gesendet: Mittwoch, 20. Oktober 2021 00:32
An: IETF IPPM WG <ippm@ietf.org>
Betreff: [ippm] Questions on draft-morton-ippm-capacity-metric-protocol-01

Hi IPPM,

Len Ciavattone and I am looking for some feedback on our protocol [0] designed to help measure the Maximum IP-Layer Capacity Metric (which will be published as an RFC shortly).

We are asking folks to take a look at the draft, because we are fairly sure you will have some questions!

One area where we know more development is required is the Modes of operation, which essentially describes how the different aspects/exchanges of the protocol will be made secure. This is pretty-much a green-field in our specification, so suggestions are very welcome.  Section 10 currently describes the different modes that we imagined to be useful (A through F below), but practical aspects of any proposed solution might indicate modes that should be combined, split-up, or new modes.

So, please give the draft and/or the list below a look, and let us know what you think.

thanks!
Al 

[0] https://datatracker.ietf.org/doc/html/draft-morton-ippm-capacity-metric-protocol-01.txt

   3.  Client-server authentication and integrity protection for
       feedback messages conveying measurements is RECOMMENDED.  To
       accomodate different host limitations and testing circumstances,
       different modes of operation are recommended:

 A. Un-authenticated mode (for all phases) AND  B. OPTIONAL Authenticated set-up only
SHA-256 HMAC time-window verification (5 min time stamp verification) (could add silent failure option)

     -=-=-=-=-=-=-=-=-=-

 C. Encrypted setup and test-activation
(currently using OpenSSL Library, so KISS, but may be too slow for test packets)

     -=-=-=-=--=- Old/low-power host performance impacts -=-=-=-=-=-=-

 D. Encrypted feedback messages

 E. Integrity protection for test packets SHA-256 HMAC

 F. Encrypted test packets (maybe also valuable to defeat compression on links)

_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm