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

From: "MORTON JR., AL" <[email-masked]>
Date: Tue, 19 Oct 2021 22:31:53 +0000

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)

---

From: Lincoln Lavoie <[email-masked]>
Date: Wed, 20 Oct 2021 15:52:41 -0400

Hello Al (and everyone),

I give a quick read through and have some comments and questions on the
current draft.

Section 3, Phase Item 1: It’s not clear if the expectation is for alignment
of the mentioned items, i.e. both the client and server must support jumbo
datagrams, or for a mismatch the connection is rejected. Put another way,
is this a negotiation phase, where options are mutually agreed between
client and server?  This is more clear in the setup section below, in terms
of an “AND” type requirement.

Section 3, Phase Item 2: The set up of firewall rules.  It is unclear if
this is a requirement or informative, such that linkage between the client
implementation and a device's firewall might be required. Similarly,
careful security considerations should be taken here, akin to duration of
those “openings”  Should a comment be added to Item 4 about closing of
firewall rules, etc.  I'm thinking about this separately then the opening
of a socket / network port and the creation of the actual firewall rule
allowing access to that port.

In section 7.1, is the watchdog timer updated each time a test PDU is
received, or each time a test PDU or status message is received.  In the
case of downstream testing, for example, the server is sending down test
PDUs and receiving upstream status information from the client. If the
client or its connection were to die, the server should be able to detect
this, from a lack of upstream status messages.  It is not clear if / how
this is accomplished only at the receiver of test PDUs.

For the Setup Command Response Codes in Section 5, these seem to be
indicated as an ENUM type parameter, but as an example, what if there were
multiple conditions to be indicated to the client.  Could these be made
into “flags” such that multiple could be set.  The consequence would be
limiting the maximum number within the 8-bit size (which is already
exceeded).

Currently none of the status messages are protected against bit errors
(i.e. no checksum or similar).  Would there be benefit in adding that level
of protection to the control channel?  This would protect against a bit
flip that could cause "misalignment" between what the client / server are
"doing."

Also within the Section 5 Setup Command I’m guessing the authDigest of the
setup request message is intended as a sort of “shared password” the valid
clients would use to identify themselves. Would it make sense to mention,
as an informative comment it might be worth setting more unique credentials
per client via an out of band mechanism, like TR-069, assuming tests are
being directed by someone like a service provider?  I know security is a
much larger topic, but discouraging any type of shared credential is always
good practice in my opinion.

Please let me know if there are any other ways I can help out, great start
on the protocol!

Cheers,
Lincoln

On Tue, Oct 19, 2021 at 6:32 PM MORTON JR., AL <[email-masked]> wrote:

> 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).
>
> 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.
>
> [0]
> https://datatracker.ietf.org/doc/html/draft-morton-ippm-capacity-metric-protocol-01.txt
>
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm
>

-- 
*Lincoln Lavoie*
Principal Engineer, Broadband Technologies
21 Madbury Rd., Ste. 100, Durham, NH 03824
[email-masked]
https://www.iol.unh.edu
+1-603-674-2755 (m)
<https://www.iol.unh.edu>

---

From: can desem <[email-masked]>
Date: Thu, 21 Oct 2021 18:29:02 +1100

Hi Al, IPPM group,

I believe this will potentially be a really useful tool for measuring
speeds, especially if we can incorporate it in network terminating devices
such as customer gateways etc.

With regards the various options for the modes of operation, I think
encrypting the payload will add additional cpu load without adding much
benefit even though it may be valuable to defeat compression on links.
Instead, having an option to randomize the payload may be less process
intensive and achieve the same goal.

Another suggestion that would be extremely useful, if this measurement tool
were to be employed in a gateway like device, would be to take into
consideration the existing traffic that may be present while running such a
test. For example, monitoring the total traffic (which could be as simple
as counting the bytes on a WAN interface on a gateway) as the test is run
and including this as part of the measurement process would result in more
accurate measurements of the line speed. This could be added as an option
in the protocol which can be used when required in the described scenario.

Regards,
Can Desem

---

From: <[email-masked]>
Date: Thu, 21 Oct 2021 09:54:01 +0000

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 <[email-masked]> Im Auftrag von MORTON JR., AL
Gesendet: Mittwoch, 20. Oktober 2021 00:32
An: IETF IPPM WG <[email-masked]>
Betreff: [ippm] Questions on draft-morton-ippm-capacity-metric-protocol-01

Hi IPPM,

thanks!
Al 

 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)

---

From: "MORTON JR., AL" <[email-masked]>
Date: Thu, 21 Oct 2021 20:26:10 +0000

Hi Lincoln,

Thanks very much for your review! You’ve raised some good questions and identified areas to improve the draft.

I’ll reply point-by-point below, [acm]. I’ve left a few items for more discussion (haven’t implemented changes yet).
Al

From: Lincoln Lavoie <[email-masked]>
Sent: Wednesday, October 20, 2021 3:53 PM
To: IETF IPPM WG <[email-masked]>
Cc: MORTON JR., AL <[email-masked]>
Subject: Re: [ippm] Questions on draft-morton-ippm-capacity-metric-protocol-01

Hello Al (and everyone),

I give a quick read through and have some comments and questions on the current draft.

Section 3, Phase Item 1: It’s not clear if the expectation is for alignment of the mentioned items, i.e. both the client and server must support jumbo datagrams, or for a mismatch the connection is rejected.

[acm]
thanks, I’ll write clearer text to replace #1, and disentangle the client and server operation in the first sentence below (not yet modified).
1.  Setup Request and Response Exchange: client and server confirm
       matching protocol versions, authentication mode, and jumbo
       datagram support, or reject the connection.
BTW, all three of these configuration settings have to match, or the server sends the reject reply.

Put another way, is this a negotiation phase, where options are mutually agreed between client and server?  This is more clear in the setup section below, in terms of an “AND” type requirement.
[acm]
At this beginning Setup Exchange, there is no negotiation possible in the current protocol.
But assuming we expand the number of security modes (beyond the binary “authentication or unauthenticated” modes), the Setup Exchange could become more complicated, or be preceded by a new exchange to secure the communications.

Section 3, Phase Item 2: The set up of firewall rules.  It is unclear if this is a requirement or informative, such that linkage between the client implementation and a device's firewall might be required. Similarly, careful security considerations should be taken here, akin to duration of those “openings”
[acm]
This is an informative overview of the details in later sections that follow, and requirements will appear in the later sections. (I need to add this text in front of the list in Section 3).

This is the current text in question:
   2.  Test Activation Request and Response: ...  Note that the
       Test Activation exchange has opened any firewalls and network
       address/port translators for the test connection and the traffic
       that follows.

To answer your question, the client assumes that the co-located firewall will open the bi-directional address and port combinations in response to a client’s packet sent into the network, and subsequently close that combination after an idle time-out determined by the firewall. We didn’t imagine explicit control of the firewall, but nothing stops a management system from exerting its control.

Section 3, Phase Item 4: Should a comment be added to Item 4 about closing of firewall rules, etc.  I'm thinking about this separately then the opening of a socket / network port and the creation of the actual firewall rule allowing access to that port.
[acm]
ok, we could say that we don’t control the Firewall, and it is assumed to delete the state for the test communication after traffic stops (in phases 2 and 4).

In section 7.1, is the watchdog timer updated each time a test PDU is received, or each time a test PDU or status message is received.  In the case of downstream testing, for example, the server is sending down test PDUs and receiving upstream status information from the client. If the client or its connection were to die, the server should be able to detect this, from a lack of upstream status messages.  It is not clear if / how this is accomplished only at the receiver of test PDUs.
[acm]
In the current draft, I described the time-outs on the Test Setup, Test Activation, and Test Stream reception.
Specifically in 7.1:

   The watchdog timer at the receiver SHALL be reset each time a test

   PDU is received.
but I need to add the symmetrical time-out for Status PDUs in 7,2 (at least I don’t see it in the draft).
However, we have the symmetrical watchdog timers in the running code, and are ensuring all the needed timers and time-outs appear in TR-471 Issue 2, RFC 9097-to-be, TR-181, etc.

For the Setup Command Response Codes in Section 5, these seem to be indicated as an ENUM type parameter, but as an example, what if there were multiple conditions to be indicated to the client.  Could these be made into “flags” such that multiple could be set.  The consequence would be limiting the maximum number within the 8-bit size (which is already exceeded).
[acm]

Command Response Codes

Control Header Setup Request Code CHSR_CRSP_NONE     0 = None

Control Header Setup Request Code CHSR_CRSP_ACKOK    1 = Acknowledgement

Control Header Setup Request Code CHSR_CRSP_BADVER   2 = Bad Protocol Version

Control Header Setup Request Code CHSR_CRSP_BADJS    3 = Invalid Jumbo datagram option

Control Header Setup Request Code CHSR_CRSP_AUTHNC   4 = Unexpected Authentication in Setup Request

Control Header Setup Request Code CHSR_CRSP_AUTHREQ  5 = Authentication missing in Setup Request

Control Header Setup Request Code CHSR_CRSP_AUTHINV  6 = Invalid authentication method

Control Header Setup Request Code CHSR_CRSP_AUTHFAIL 7 = Authentication failure

Control Header Setup Request Code CHSR_CRSP_AUTHTIME 8 = Authentication time is invalid in Setup Request
Yes, it’s a good point How does the protocol handle the multiple error case explicitly (I’m not sure that we don’t, but more needs to be said, or convert to flags (except that we ran out of 8 bits already, as you point-out!).

I’m leaving this as an open issue for more discussion.

Currently none of the status messages are protected against bit errors (i.e. no checksum or similar).  Would there be benefit in adding that level of protection to the control channel?  This would protect against a bit flip that could cause "misalignment" between what the client / server are "doing."
[acm]
Possibly, the Status PDU could benefit.  The feedback status messages convey critical measurements from, OR the Sending Rate Structure to, the client. Maybe we add a stronger protection at this point in time, to ensure these messages are not spoofed by an on-path attack (Attack in the middle).

I’m leaving this as an open issue for more discussion.

Also within the Section 5 Setup Command I’m guessing the authDigest of the setup request message is intended as a sort of “shared password” the valid clients would use to identify themselves. Would it make sense to mention, as an informative comment it might be worth setting more unique credentials per client via an out of band mechanism, like TR-069, assuming tests are being directed by someone like a service provider?  I know security is a much larger topic, but discouraging any type of shared credential is always good practice in my opinion.
[acm]
Yes, shared password was a feature for the beginning open-source implementation. We didn’t want to put up a protocol with absolutely zero authentication, and Len added this last Summer before the first OB-UDPST Release.
We can make more extensive changes when addressing the question of Security modes and methods, and TR-069 is surely a good OOB example.

I’m leaving this as an open issue for more discussion, which will be subsumed by determining new Security Modes and how to implement them (Section 10).

Please let me know if there are any other ways I can help out, great start on the protocol!
[acm]
Will do, and Thanks again!  Look for an updated draft on Oct 25 at the submission deadline.

Cheers,
Lincoln

On Tue, Oct 19, 2021 at 6:32 PM MORTON JR., AL <[email-masked]<mailto:[email-masked]>> wrote:
Hi IPPM,

thanks!
Al

[0] https://datatracker.ietf.org/doc/html/draft-morton-ippm-capacity-metric-protocol-01.txt<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-morton-ippm-capacity-metric-protocol-01.txt__;!!BhdT!3tvhVp5KCcOOLuqFn3oe5hJS357FIVTqatfgkYHDgtdbpoX9VJk8xOFO-hbV$>

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

_______________________________________________
ippm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ippm<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ippm__;!!BhdT!3tvhVp5KCcOOLuqFn3oe5hJS357FIVTqatfgkYHDgtdbpoX9VJk8xIAIxb4s$>

--
Lincoln Lavoie
Principal Engineer, Broadband Technologies
21 Madbury Rd., Ste. 100, Durham, NH 03824
[email-masked]<mailto:[email-masked]>
https://www.iol.unh.edu<https://urldefense.com/v3/__https:/www.iol.unh.edu__;!!BhdT!3tvhVp5KCcOOLuqFn3oe5hJS357FIVTqatfgkYHDgtdbpoX9VJk8xBaQGOnn$>
+1-603-674-2755 (m)
[https://docs.google.com/uc?export=download&id=1j_iI6anwrnbQWNpTyuvukMLSNJJ8_8QU&revid=0B_0ujwABDnFZTmJiR3EzK0d1VjFKTjQvMENBWVM0QnA4ajhjPQ]<https://urldefense.com/v3/__https:/www.iol.unh.edu__;!!BhdT!3tvhVp5KCcOOLuqFn3oe5hJS357FIVTqatfgkYHDgtdbpoX9VJk8xBaQGOnn$>

---

From: "MORTON JR., AL" <[email-masked]>
Date: Thu, 21 Oct 2021 22:12:58 +0000

Hi Can,

Thanks for joining the discussion here, and for sharing your review with good ideas!

I’ll reply to each major point and suggestion below, [acm], and work with Len to see how we might add these features to the protocol.

Al

From: can desem <[email-masked]>
Sent: Thursday, October 21, 2021 3:29 AM
To: MORTON JR., AL <[email-masked]>
Cc: IETF IPPM WG <[email-masked]>
Subject: Re: [ippm] Questions on draft-morton-ippm-capacity-metric-protocol-01

Hi Al, IPPM group,

I believe this will potentially be a really useful tool for measuring speeds, especially if we can incorporate it in network terminating devices such as customer gateways etc.
[acm]
Thanks!
We have had some success on this front, with customer premises equipment and small/inexpensive hosts. The running code has an option to help with older hardware, clocks that are slow by today’s standards, etc.

With regards the various options for the modes of operation, I think encrypting the payload will add additional cpu load without adding much benefit even though it may be valuable to defeat compression on links.
[acm]
Agreed, there is a tension between the security benefits and the ability of some network terminating devices to operate at full line rate. The simple approach of encrypting everything might reduce the universe of hardware support of measurements at 1 Gbps, for example.

Instead, having an option to randomize the payload may be less process intensive and achieve the same goal.
[acm]
Yes, that seems like a good option to have available when link compression is present. Thanks!  We could have several options in addition to pseudo-random payload content. I’ll add this as a To Do in the next draft.

Another suggestion that would be extremely useful, if this measurement tool were to be employed in a gateway like device, would be to take into consideration the existing traffic that may be present while running such a test. For example, monitoring the total traffic (which could be as simple as counting the bytes on a WAN interface on a gateway) as the test is run and including this as part of the measurement process would result in more accurate measurements of the line speed. This could be added as an option in the protocol which can be used when required in the described scenario.
[acm]
Yes, ideally the Maximum IP-Layer Capacity measurement would be made without competing traffic, having a way to count the competing traffic goes a long way to explaining measurement results when additional traffic is present. We still need to fill the pipe to measure the max, and normal applications don’t tend to do that. You and Len and I have been running some tests to investigate the feasibility of this feature – so far so good...  This is also on the To Do list.

Regards,
Can Desem
[acm]
Again, many thanks, Can!

---

From: "MORTON JR., AL" <[email-masked]>
Date: Fri, 22 Oct 2021 23:23:14 +0000

Hi Rüdiger, 

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

Al

> -----Original Message-----
> From: [email-masked] <[email-masked]>
> Sent: Thursday, October 21, 2021 5:54 AM
> Cc: [email-masked]
> 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:
> 
[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!
> 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

> 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).
> 
> 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
> [0] https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-
> morton-ippm-capacity-metric-protocol-01.txt__;!!BhdT!y6i-
> TyjWraBDT2trFoyuIFq4w_HAiM69YBGudRqV6CYCfy0IwpDrcGmC1X4M$
> 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ippm__;!!Bhd
> T!y6i-TyjWraBDT2trFoyuIFq4w_HAiM69YBGudRqV6CYCfy0IwpDrcPzob7Gi$

---

From: <[email-masked]>
Date: Mon, 25 Oct 2021 05:29:46 +0000

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 <[email-masked]> 
Gesendet: Samstag, 23. Oktober 2021 01:23
An: Geib, Rüdiger <[email-masked]>
Cc: [email-masked]
Betreff: RE: [ippm] Questions on draft-morton-ippm-capacity-metric-protocol-01

Hi Rüdiger, 

Al

> 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:
> 
[acm]

[acm]
right!
> "Current IETF standardized test protocols (... [RFC5357 - TWAMP]..) do 
> not possess the asymmetric size generation capability with two-way testing."
[acm]
> 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]

thanks,
Al

> Betreff: [ippm] Questions on 
> draft-morton-ippm-capacity-metric-protocol-01
> 
> Hi IPPM,
> 
> designed to help measure the Maximum IP-Layer Capacity Metric (which 
> will be published as an RFC shortly).
> 
> 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.
> 
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draf
> t-
>  A. Un-authenticated mode (for all phases) AND  B. OPTIONAL 
> Authenticated set- up only
>  C. Encrypted setup and test-activation (currently using OpenSSL 
> Library, so KISS, but may be too slow for test
> packets)
> 
>  F. Encrypted test packets (maybe also valuable to defeat compression 
> on
> links)
>

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 25 Oct 2021 12:12:13 -0700

Hi Al,
while evaluating the suitability of STAMP, have you considered using a new
STAMP extension to query the Session-Reflector? In RFC 8792 there are
several examples of using STAMP extension to retrieve information fro the
Session-Reflector. Do you think that could be a viable option for the IP
Maximum Capacity test?

Regards,
Greg

On Fri, Oct 22, 2021 at 4:23 PM MORTON JR., AL <[email-masked]> wrote:

> measurement
> > I started with a minor issue, as it points to RFC7497. The latter RFC
> contains
> > the following statement:
> not
> rather
> No problem, I thought about this before writing this draft. It comes down
> to these four points (which I will add in the Intro):
>
> designed
> > We are asking folks to take a look at the draft, because we are fairly
> sure
> > you will have some questions!
> >
> operation,
> > 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-