[ippm] Re: Paul Wouters' Discuss on draft-ietf-ippm-capacity-protocol-20: (with DISCUSS and COMMENT)

[Paul Wouters <[e-mail]>]

I thought I answered this but I don't see any set appointment.

Can do we do this for the Wednesday slot you proposed? 9am EST 4pm CET ?

Paul

On Fri, Aug 8, 2025 at 7:25 AM <[e-mail]> wrote:

> Hi Paul,
>
>
>
> the approach taken is a performance measurement protocol with added
> security features. The latter should find consent of the sec area.
>
>
>
> Part of our design:
>
>    - One UDP port
>    - One PDU type which is neither encrypted nor authenticated (it
>    carries load with no information)
>
>
>
> Ok, where to go from there?
>
>
>
>    - The authors, IPPM WG and OPS Area chairs prefer this work to reach
>    RFC state.
>    - No complete re-design of the protocol
>    - Is there a way for sec area
>    * to add security features, Authentication at least, to a
>    communication as sketched above (one port, one unauthenticated PDU type)?
>    * if that can’t be done for encryption, does a solution without
>    encryption have consent of the sec area?
>    * If that also can’t be done for Authentication, is that finding IESG
>    consent (the authors would be disappointed, Authentication is required)?
>
>
>
> The security approach taken so far doesn’t find consent of the sec area
> (the authors don’t discuss the points you raise – we are no security
> experts). Is the sec area willing to provide the authors guidance on how to
> progress this protocol at this stage without a complete redesign?
>
> If a complete protocol redesign is the only option to add security
> features finding sec area consent, I’d suggest OPS area and SEC area to
> jointly specify a framework how to design performance measurement protocols
> with added security features (this order of priority – I don’t want exclude
> a secure protocol with added performance measurement features in general,
> if measurement precision isn’t impacted by the secure protocol). Hoping to
> get a blueprint for that motivated us to contact the sec area in 2022. That
> latter is a worst case, we hope to avoid. We’d still have to figure out,
> what to do if there’s no other option.
>
>
>
> Please let me know, if further details on the protocol were helpful for
> the sec design.
>
>
>
> Med is available for a conf call too. Would UTC 14.00-15.00 Monday to
> Thursday, that’s 9.00-10.00 EST and 16.00-17.00 CEST be suitable? If yes,
> please let me know, if you prefer a particular day. Otherwise, please
> change.
>
>
>
> Regards,
>
>
>
> Ruediger
>
>
>
> *Von:* Paul Wouters <[e-mail]>
> *Gesendet:* Donnerstag, 7. August 2025 19:44
> *An:* Geib, Rüdiger <[e-mail]>; Deb Cooley <
> [e-mail]>
> *Cc:* [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> *Betreff:* Re: [ippm] Paul Wouters' Discuss on
> draft-ietf-ippm-capacity-protocol-20: (with DISCUSS and COMMENT)
>
>
>
> On Thu, Aug 7, 2025 at 8:09 AM <[e-mail]> wrote:
>
>
>
> Hi Ruediger,
>
>
>
> I am sorry the process has been long and frustrating so far. But there is
> still a lot of things that are not clear to us as SEC ADs.
>
> I am also seeing different emails bringing up new things, which
> complicates things as well.
>
>
>
> Hi Paul
>
> Thanks for your review. We'd like to focus on the DISCUSS raised by you by
> this exchange.
>
> You are asking, "Why is this protocol not using DTLS for its security
> features?"
>
> Authors:
>
> To our understanding, using DTLS for its security features requires the
> protocol to open two UDP ports:
> - one for the secure DTLS signaled PDUs
> - one for the Load PDUs which aren't protected.
>
>
>
> This is the first time I hear of the requirement of running encrypted and
> unencrypted streams over the same port.
>
>
>
> As far as we can see, this would require a re-design of the protocol. The
> protocol by now has reached IESG. First time, the authors have contacted
> security area and asked for guidance was 2022:
> https://mailarchive.ietf.org/arch/msg/ippm/LQxG-144USqSlwTHCZvFtW9wA08/
>
>
>
> Reading through that thread, some of the issues that are bubbling up now
> were not clear to me (or Roman?) at the time.
>
> Note that a SecDir reviewer is also just one person with an opinion - it
> does not constitute a Security Area approval.
>
>
>
> Note that the above thread also states that data is "generated", leaving
> me confused as to why that needs to be encrypted or
>
> protected?
>
>
>
> Authors: We've made progress and tried to follow guidance of Brian Weiss
> on security. He asked us to present our approach to an appropriate security
> WG in 2024, when you were involved again (I post the header only, didn't
> pass lists):
>
> -------
> From: Paul Wouters <[e-mail]>
> Sent: Dienstag, 2. Juli 2024 17:52
> To: Geib, Rüdiger <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; tpauly=[e-mail];
> [e-mail]
> Re: Request for a presentation slot in SAAG and CFRG, respectively
>
> we try to discourage presenting the same thing in two different meetings.
> it seems the CFRG slot would be a better fit ?
>
>
>
> It seemed based on the PDF attached at the time, you were writing your own
> encryption protocol. This is why I suggested to
>
> get feedback from CFRG. Based on
> https://datatracker.ietf.org/meeting/120/materials/minutes-120-cfrg-202407252000-00
> you did
>
> get feedback but it got down deep to the crypto level. Did any followups
> happen on the CFRG mailing list?
>
>
>
>  To me again this seems to suggest this protocol is not the place to
> invent its own cryptography. And again if this is generated
>
> synthetic data, I am still confused why it needs to be encrypted.
>
>
>
> Authors: We accept, that there are other security approaches. We looked
> for, received and followed early and ongoing guidance by the security area
> on one of these. The encryption approach pursued so far still isn't
> consented by the security area. The authors are not interested in a
> complete re-design of the protocol. Then how to make progress?
>
>
>
> I do not know how you can make progress. From a security point of view,
> specifying new protocols with the CBC cryptographic primitive
>
> is just not viable. Runing low level openssl crypto library calls as a
> protocol to security people is just unspeakable. It is just not done.
>
> Which is why we recommend DTLS. There was some confusion about that not
> being able to detect packet drops or duplications, but that
>
> got resolved during IETF-123 when I sent a message with an example of how
> an SCTP RFC required using DTLS with replay protection disabled.
>
>
>
> Now you raise a new problem of not wanting to redesign things on two
> ports. There is no security protocol that allows you to mix encrypted
>
> packets with cleartext packets in a single data stream.
>
>
>
> - wait for the security area to improve the security approach taken so far
> so that it can be implemented and finds consent by the security area?
>
>
>
> I do not think you should "wait for the security area to improve". Our
> objections are very fundamental cryptography concerns. For example,
>
> TLS 1.3 has disallowed all CBC algorithms and only allows AEAD algorithms.
>
>
>
> - drop encryption and just operate authentication?
>
>
>
> I think I still don't understand what the encryption of generated
> synthetic data is supposed to protect, so I cannot answer this question.
>
> I also do not understand what you mean with "authentication". Without
> encryption, what does authenticaction mean? It cannot be a few
>
> packet authentication exchange, followed by a stream of unencrypted data
> as the data would not be integrity protected either. And if you
>
> plan to integrity protect the data, you would run into similar issues as
> when you are encrypting the data. You would need to negotiate
>
> securely an integrity key that can be used for something like an HMAC
> style verification of data, but how would that work with mixing
>
> integrity protected data and unprotected data in the same stream?
>
>
>
> - in both cases, we'd ask you for a reference pointing to a load
> performance measurement protocol which operates by DTLS (either by a single
> UDP port only or using two UDP ports, one for signaling and one for
> measurement).
>    If that's not feasible, we are happy to add text on such an improvement
> and ask you to provide it.
>
>
>
> Please talk to your WG chairs and AD. The Security ADs are not the ones
> that can be tasked to secure every protocol the IETF comes up with.
>
>
>
> An important constraint of a load measurement protocol: load measurement
> PDUs must be large. They mostly do not transport content or any kind of
> higher layer information - mostly bytes to create load and be dropped by
> the receiver. These packets are not encrypted, as in addition to inducing
> measurement errors / impacting precision of timestamps, encryption of
> meaningless information protects no protocol or communication, but induces
> processing requirements. Low end devices likely are not able to support
> such a protocol.
>
>
>
> I still do not understand why you are trying to encrypt these data streams
> of randomly generated data.
>
>
>
> Med suggested to have a conf-call, if this helps progressing issues. He's
> about to leave office for three weeks and I personally try to avoid Friday
> conf calls (I'm available until 11.00 UTC).
>
> Please suggest a way to proceed.
>
>
>
> I am available in various time slots in the next few weeks during EST
> business hours.
>
>
>
> Paul
>
>
>
>
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Paul Wouters via Datatracker <[e-mail]>
> Gesendet: Dienstag, 24. Juni 2025 23:27
> An: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]
> Betreff: [ippm] Paul Wouters' Discuss on
> draft-ietf-ippm-capacity-protocol-20: (with DISCUSS and COMMENT)
>
> <snip>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> The main point of my DISCUSS is around the protocols authentication and
> encryption.
> It is a homegrown protocol, very restricted in cryptographic options, no
> ephemeral
> key exchange and unsafe use of PSK. Why is this protocol not using DTLS
> for its
> security features instead of inventing its own using low level openssl
> functions
> as a security protocol ?
>
> All of the Cryptogrpahic issues would go away, if you just optionally
> allow to use DTLS 1.2
> or later.
>
> [Authors]: Duplicate Packets is one of the performance metrics captured.
> Earlier draft versions contained text: "The <DTLS> replay protection would
> remove duplicated packets and prevent transparent measurement of this
> impairment."
>
> ---------------------
>
> 1) secure hash algorithm
>
> The document claims a number of times that low power devices are an
> important use
> case. If so, AES-CMAC (RFC4494) would be more appropriate than HMAC-SHA256
>
>
> -------------------
>
> 2) using the KDF
>
>         The KDF SHALL use the following parameters:
>         [...]
>
> It should more clearly specify thow these parameters are used. One likely
> method
> is concatenation in the order of the listed parameters, but if so, it
> should
> clearly state this, eg  KDF(Kin || Label || Context || r) and it should
> specify
> how to deal with input that is larger in size than the input of the KDF.
>
>         The authUnixTime field serves as a nonce
>
> This KDF use is not safe against writing a brute force engine of captured
> traffic where the only unknown is the PreSharedKey. I think this could be
> cracked in realtime using something like https://hashcat.net/hashcat/ for
> every PSK under 16 characters. As PSK is "out of scope", it seriously runs
> the risk of going in the clear in email or a phone call with a low entropy
> phrase.
>
> -----------------
>
> 3) auth and enc key generation
>
> Why are the authenticaion and encryption keys of a different
> length/strength ?
> This would make the resulting strength the least of the two, eg 128bit.
> It only costs 1 HMAC-SHA2 operation more (4 instead of 3) to get 256bit
> keys
> for both. Or, you could use AES-CCM / AES-GCM and use an AEAD when
> encryption
> is needed which requires 256bit (or you can pick/choose 128bit)
>
> Which brings me to another point, at this point CBC should really not be
> deployed for new protocols anymore. Please use AES-CCM or AES-GCM.
> Especially
> if low power devices are being targeted, using AES-CBC-SHA256 is far more
> expensive (and less secure) compared to AES-CCM/AES-GCM (and SHA256).
> Of course, this does require safe handling of the counters.
>
> -----------------
>
> 4) encryption streams
>
> How are different streams using encryption? Same key? How is uniqueness in
> IV
> ensured? Or when switching to CCM/GCM, how are counters not re-used?
>
> ----------------
>
> 5) random
>
>         The sender SHALL populate the initVector field with a
>         cryptographically random 16-octet Initialization Vector (IV),
>
> On low power devices, getting a good random source is not always easy
> either. This would be easier if one were to use an AEAD as well, and
> use the authUnixTime as a nonce with a proper counter instead of a
> random IV. For AES-CBC you would have to use an explicit IV (eg send
> it over the wire) to allow decrypting out of order packets (eg see
> RFC3602) which means generating randomness per packet. With AEAD
> you only need to guarantee uniqueness, not unpredictability (aka random).
>
> ---------------
>
> I also would think the protocol should not hardcode AES-CBC-SHA256, but
> use a registry similar to AlgID.
>
> ---------------
>
>        AUTHMODE_3:    Optional Encrypted mode
>
> You want to say: Optional Encrypted plus Authenticated Control and Data
> phase mode.
>
> ---------------
>
>      Authentication and encryption methods and requirements steadily
> evolve.
>      Alternate encryption and/or authentication modes provide for algorithm
>      agility by defining a new Mode, whose support is indicated by an
> assigning
>      a suitable "Test Setup PDU Authentication Mode Registry" value (see
> Section 11.3.4 ).
>
> But this registry only has different modes of using authentication or
> encryption. All the
> actual values for these (HMAC-SHA256 and AES-CBC) are hardcoded and
> implicit, so when one
> in the future would add something else (eg encryption with AES-CMAC and
> AES-CTR) the current
> naming does not work at all for this registry.
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
> Titel says:
>
>         Test Protocol for One-way IP Capacity Measurement
>
> Abstract says:
>
>         This document defines the UDP Speed Test Protocol for conducting
>         RFC 9097 and other related measurements.
>
> The Introduction says:
>
>         This document specifies the UDP Speed Test Protocol (UDPSTP)
>
> Can these terms be made consistent?
>
> [Authors] Title, CHANGE : UDP Speed Test Protocol for One-way IP Capacity
> Measurement
> We'd like to keep One-way IP Capacity Measurement in the Title, as 9097
> specifies the latter. UDP Speed Test doesn't appear in 9097, however.
>
> -------------------
>
> I am skeptical of the value of speed meassurements for anything using
> specific ports,
> as it is allows the network to treat these differently from "regular"
> traffic. Eg we
> commonly see "speedtest.net" outperforming reality. I see it can still be
> useful in
> labs (but then I question the authentication/encryption parts being
> neccessary at all)
>
> [Authors]: Taking a consumer point of view, your analysis may be right in
> some cases (at least). The protocol has seen deployment by one large
> network provider for diagnostic purposes and it is preferred to TCP Speed
> Test by some diagnosis tools in wireless environments.
>
> ------------------
>
>        Test Setup Request and Response: If a server instance is
>         identified with a host name that resolves to both IPv4/IPv6
>         addresses, it is recommended to use the first address returned
>         in the name resolution response - regardless, whether it's IPv4
>         or IPv6. Thus, the decision on the preferred IP address family
>         is left to the DNS operator.
>
> I don't understand this part. If the application sends out a query for AAAA
> before A, or A before AAAA, that will make a difference that is not "left
> to
> the DNS operator" at all. There is currently no way to ask for A + AAAA
> within
> the same DNS packet, but once it does (there are efforts on their way) then
> both would arrive at the same time in the same answer.
>
> [Authors] Could you suggest text to be added? Should it say, that only a
> single record (e.g. A or AAAA) should be queried?
>
> ------------------
>
>         The encrypted portion of each PDU SHALL contain the padding
> required
>
> I believe you mean "the cleartext to be encrypted shall be padded to ...."
> ?
>
> [Authors] Thanks, CHANGE: " The PDU's cleartext to be encrypted SHALL be
> padded to..."
>
>
>
> _______________________________________________
> ippm mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>