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

Hi Al,

thanks, the arguments you've added make sense to me and I think the text is helpful for readers not accustomed with *WAMP protocols.

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: MORTON JR., AL <acmorton@att.com> 
Gesendet: Samstag, 23. Oktober 2021 01:23
An: Geib, Rüdiger <Ruediger.Geib@telekom.de>
Cc: ippm@ietf.org
Betreff: RE: [ippm] Questions on draft-morton-ippm-capacity-metric-protocol-01

Hi Rüdiger, 

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

Al

> -----Original Message-----
> From: Ruediger.Geib@telekom.de <Ruediger.Geib@telekom.de>
> Sent: Thursday, October 21, 2021 5:54 AM
> To: MORTON JR., AL <acmorton@att.com>
> Cc: ippm@ietf.org
> 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 <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://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draf
> t-
> 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
> ippm@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ippm
> __;!!Bhd 
> T!y6i-TyjWraBDT2trFoyuIFq4w_HAiM69YBGudRqV6CYCfy0IwpDrcPzob7Gi$