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

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

Hi Rüdiger, 

Many thanks for your review and comments!
Please see replies below, [acm]

Al

> -----Original Message-----
> From: [e-mail] <[e-mail]>
> Sent: Thursday, October 21, 2021 5:54 AM
> To: MORTON JR., AL <[e-mail]>
> Cc: [e-mail]
> Subject: AW: [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?
[acm] 
Yes, that's a typo it is 7497.

> From numbers I guessed:
> https://urldefense.com/v3/__https://www.rfc-
> editor.org/rfc/rfc7497.html*section-2__;Iw!!BhdT!y6i-
> TyjWraBDT2trFoyuIFq4w_HAiM69YBGudRqV6CYCfy0IwpDrcJsftMK9$
[acm] 
right!
> 
> I started with a minor issue, as it points to RFC7497. The latter RFC contains
> the following statement:
> https://urldefense.com/v3/__https://www.rfc-
> editor.org/rfc/rfc7497.html*section-7__;Iw!!BhdT!y6i-
> TyjWraBDT2trFoyuIFq4w_HAiM69YBGudRqV6CYCfy0IwpDrcJC4OWUG$
> "Current IETF standardized test protocols (... [RFC5357 - TWAMP]..) do not
> possess the asymmetric size generation capability with two-way testing."
[acm] 
Right, we have a different problem with TWAMP and others, described below.
> 
> 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.
[acm] 
No problem, I thought about this before writing this draft. It comes down to these four points (which I will add in the Intro):

   Although there are several test protocol already available for
   support and manage active measurements, this protocol is a major
   departure from their operation:

   1.  UDP transport is used for all setup, test activation, and control
       messages, and for results feedback (not TCP), simplifying
       operations.

   2.  TWAMP and STAMP use the philosophy that one host is a Session-
       Reflector, sending test packets every time they receive a test
       packet.  This protocol supports a one-way test with periodic
       status messages returned to the sender.

   3.  OWAMP supports one-way testing with results Fetch at the end of
       the test session.  This protocol supports a one-way test and requires
       periodic status messages returned to the sender to support the
       load adjustment search algorithm.

   4.  The security features of OWAMP and TWAMP have been described as
       "unusual", to the point that IESG approved their use while also
       asking that these methods not be used again.  Further, the *WAMP
       approach to security is over 15 years old at this time.

I concluded that any attempt to enhance OWAMP or others would be time wasted. We have a unique use-case here.

thanks,
Al

> 
> Regards,
> 
> Ruediger
> 
> -----Ursprüngliche Nachricht-----
> Von: ippm <[e-mail]> Im Auftrag von MORTON JR., AL
> Gesendet: Mittwoch, 20. Oktober 2021 00:32
> An: IETF IPPM WG <[e-mail]>
> 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://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-
> morton-ippm-capacity-metric-protocol-01.txt__;!!BhdT!y6i-
> TyjWraBDT2trFoyuIFq4w_HAiM69YBGudRqV6CYCfy0IwpDrcGmC1X4M$
> 
>    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
> [e-mail]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ippm__;!!Bhd
> T!y6i-TyjWraBDT2trFoyuIFq4w_HAiM69YBGudRqV6CYCfy0IwpDrcPzob7Gi$