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

[Joachim Fabini <[e-mail]>]

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.

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?
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.
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.

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.

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.

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://tools.ietf.org/html/draft-ietf-ippm-capacity-metric-method-02
>> <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://www.ietf.org/mailman/listinfo/ippm
> 
> 
> _______________________________________________
> ippm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ippm
>