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

[[e-mail]]

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]<mailto:[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]<mailto:[e-mail]>>
Sent: Dienstag, 2. Juli 2024 17:52
To: Geib, Rüdiger <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; tpauly=[e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[e-mail]>>
Gesendet: Dienstag, 24. Juni 2025 23:27
An: The IESG <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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<http://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]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>