Re: [ippm] WGLC for draft-ietf-ippm-capacity-metric-method

["MORTON, ALFRED C (AL)" <[e-mail]>]

Hi Joachim,

Thanks for your comments!  Please see [acm] replies below.

Al, for the co-authors

> -----Original Message-----
> From: ippm [mailto:[e-mail]] On Behalf Of Joachim Fabini
> Sent: Monday, August 31, 2020 10:33 AM
> To: Tommy Pauly <tpauly=[e-mail]>; IETF IPPM WG
> ([e-mail]) <[e-mail]>
> Cc: MORTON, ALFRED C (AL) <[e-mail]>
> Subject: Re: [ippm] WGLC for draft-ietf-ippm-capacity-metric-method
> 
> All,
> 
> as a follow-up some nits that I noticed while reading through the
> capacity draft:
> 
> 1. Newly added security considerations: my expectation is that UDP-based
> capacity measurements can be potentially more harmful and more difficult
> to protect against when compared to TCP-based ones, in particular when
> considering (D)DoS. First, there is no state involved at transport layer
> that an attacker may need to track/establish and no flow/congestion
> control involved. Second, firewalls and other stateful protection
> devices can easily identify a missing 3-way handshake for TCP and block
> subsequent (unsolicited, harmful) measurement packets sent by an
> attacker. But there's no such option for UDP, meaning that the
> application layer must handle this case.
> If an attacker misuses the packet pattern of UDP capacity measurements
> and directs these measurements to an open UDP port of the
> destination/target, then middlebox and firewall protections may fail and
> consider the traffic to be a legitimate one.
> The authors may consider adding some details and guidelines on these
> aspects to the security section.
[acm] 
Yes, Len Ciavattone and I have added a new list item 2, which is based on the udpst "running code" (after setting-up the measurement architecture with some new text in Section 8):

2. A REQUIRED user client-initiated setup handshake between cooperating hosts allows firewalls to control inbound unsolicited UDP which either go to a control port [expected and w/authentication] or to ephemeral ports that are only created as needed. Firewalls protecting each host can both continue to do their job normally.
> 
> 2. A potential architectural/wording issue (disclaimer: I just skimmed
> over the draft and may have ommitted some relevant statements, will
> hopefully find some more time during the next weeks to review it more
> thoroughly): in the beginning the unidirectionality of the capacity
> measurement was not obvious to me. Perhaps add it to the draft title to
> make this explicit?
[acm] 
I see the ambiguity now, too.  Besides the fixes for Ignacio's comments, I added "One-way" to the title and the formal metric names.

> In particular the discussion about round-trip delay (RTD) and round-trip
> loss (RTL) created this impression and, infact, may also be misleading
> wrt inferences about the capacity measurement results.
[acm] 
Here, we make have an architectural requirement that sending rate is controlled using feedback messages from the receiver, and this is the source of round-trip delay measurements (the most reliable from a time-accuracy perspective).

Also, I made a mistake representing the Loss measurements. They are One-way, like the Capacity measurement, and are a key measurement in the feedback messages. This is now clarified.

> I assume that the correct capacity measurement depends on the forward
> path only, but a lossy reverse path may increase the RTL. This may
> introduce some artificial bias and impression that the measurement limit
> is reached, while infact the forward link is still under-utilized. So
> I'm wondering if Round-trip delay/loss is acceptable or one-way-loss is
> needed and more accurate.
[acm] 
You are right, of course!  The udpst "running code" uses one-way loss (only) and allows the use of one-way delay variation (when sender and receiver clocks are stable)
> 
> But, as written in the disclaimer: it's a potential issue that needs
> some more time and deeper analysis. Hope to find some time to go more
> into details later on.
[acm] 
Len Ciavattone and I have evaluated many different measurement feedback combinations. So far, RTD and OWL (one-way loss) are both sufficient and reliable.

> 
> Overall I find the concept of UDP-based capacity measurement to be a
> compelling mechanism that can help to overcome some of the downsides of
> TCP-based bulk transfer capacities. Thanks to the authors for their
> contribution.
[acm] 
Thanks for your continuing contributions to this work, Joachim! You engaged in many discussions last year, and you sent two very important comments/catches again this time. Much appreciated!

> 
> regards
> Joachim
> 
> On 29/08/2020 00:34, Tommy Pauly wrote:
> > Hi IPPM,
> >
> > A reminder that our WGLC is ending next week for
> > draft-ietf-ippm-capacity-metric-method. Please take a moment to review
> > the document!
> >
> > Thanks,
> > Tommy
> >
> >> On Aug 14, 2020, at 2:31 PM, MORTON, ALFRED C (AL)
> >> <[e-mail] <mailto:[e-mail]>> wrote:
> >>
> >> Thanks Tommy and Ian!
> >>
> >> While updating a few references this week, I noticed that the 02 draft
> >> had no Security Considerations Section.  That won’t do!
> >>
> >> The co-authors came together and supplied new text for the Section in
> >> version 03, posted minutes ago. Please consider version 03 of the
> >> draft during WGLC.  Thank you IPPM.
> >>
> >> For the co-authors,
> >> Al
> >>
> >>
> >> *From:* ippm [mailto:ippm-bounces@ietf..org] *On Behalf Of *Tommy Pauly
> >> *Sent:* Friday, August 14, 2020 5:21 PM
> >> *To:* IETF IPPM WG ([e-mail] <mailto:[e-mail]>)
> >> <[e-mail] <mailto:[e-mail]>>
> >> *Subject:* [ippm] WGLC for draft-ietf-ippm-capacity-metric-method
> >>
> >> Hello IPPM,
> >>
> >> As discussed at IETF 108, draft-ietf-ippm-capacity-metric-method is
> >> stable, and the group felt it is ready for Working Group Last Call.
> >>
> >> The latest version can be found
> >> here: https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__tools.ietf.org_html_draft-2Dietf-2Dippm-2Dcapacity-2Dmetric-2Dmethod-
> 2D02&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=F25iaEsqjGDFSCDyqTAzktARRKvhs
> CcpmJ0w_4nhAEA&s=lcASpR1GwpzDKv3GRJhRZMLY_CPvEf6m7InH8POWY0k&e=
> >> <https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__tools.ietf.org_html_draft-2Dietf-2Dippm-2Dcapacity-2Dmetric-2Dmethod-
> 2D02&d=DwMFAg&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=SIvlMcMEEzV1Wv8tA8hftr1Fvi38_
> c2R6bgbotceIsU&s=WEcaTbukpUJlfOGrn8Lbw-jjrpTxRsPst6bsHPjjExE&e=>
> >>
> >> The last call will end on *Wednesday, September 2*. Please reply
> >> to [e-mail] <mailto:[e-mail]> with your reviews and
> >> comments, and indicate if you think the document is ready to progress!
> >>
> >> Best,
> >> Tommy & Ian
> >> _______________________________________________
> >> ippm mailing list
> >> [e-mail] <mailto:[e-mail]>
> >> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_ippm&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=F25iaEsqjGDFSCDyqTAzktARRKvhs
> CcpmJ0w_4nhAEA&s=9N8ZNy8TlO27Uuxnqq_iP8HKY5mkWISE0Y9V-j0JMe8&e=
> >
> >
> > _______________________________________________
> > ippm mailing list
> > [e-mail]
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_ippm&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=F25iaEsqjGDFSCDyqTAzktARRKvhs
> CcpmJ0w_4nhAEA&s=9N8ZNy8TlO27Uuxnqq_iP8HKY5mkWISE0Y9V-j0JMe8&e=
> >
> 
> _______________________________________________
> ippm mailing list
> [e-mail]
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_ippm&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=F25iaEsqjGDFSCDyqTAzktARRKvhs
> CcpmJ0w_4nhAEA&s=9N8ZNy8TlO27Uuxnqq_iP8HKY5mkWISE0Y9V-j0JMe8&e=