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

[Paul Wouters <[e-mail]>]

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]
>