RE: MD5 is slow

[Vasilenko Eduard via NANOG <nanog () lists nanog org>]

Hi Tom,
I do not want to discuss “why in 1st place” for 2 reasons:

  1.  It is not related to the previous discussion
  2.  I mostly agree with you: it is not a good idea to squeeze everything possible from something; the network is 
becoming fragile after such an exercise (I have seen it many times).
But people are doing it! For my 30 years in networking, I have seen these “sub-second” discussions and other “IGP speed 
optimizations” many times. For example:
convergence-time.dvi<https://www.cs.princeton.edu/courses/archive/fall10/cos561/papers/IGPconverge05.pdf>
RFC 9681 - IS-IS Fast Flooding<https://datatracker.ietf.org/doc/rfc9681/>
Like we or not.
I remember that it was possible to achieve something like 600ms. The article above claims even less (3x better for 
small scale network).
30ms (over 5 hops) could be 5% which is visible.
But it would be no 30ms, I have failed with my assumption based on the academic document, Jay Acuna has proved it to 
me. It would be 2.5ms (over 5 hops) even for SHA-3, - I do not believe it is relevant.
We could park this discussion. MD5 is fast enough not to create a latency problem (and additionally not to protect 
anything because of this).
Eduard
From: Tom Beecher <beecher () beecher cc>
Sent: Thursday, September 11, 2025 19:25
To: North American Network Operators Group <nanog () lists nanog org>
Cc: Vasilenko Eduard <vasilenko.eduard () huawei com>
Subject: Re: MD5 is slow

I would prefer the same explanation, but in relation to ISIS or OSPF.

I addressed this previously.

IS-IS and OSPF both have delays so that SPF isn't constantly running if a given network is unstable. Take for example 
an IS-IS network on a Juniper. By default :

- For a point to point interface, R1 transmits CSNPs every 5000ms.
- R2 receives CSNP, and updates its LSDB.
- LSDB change =  topology change. R2 starts a 200ms timer before running SPF.
- If additional CSNPs are received such that R2 runs SPF 3 times in succession. ( 600ms ) , R2 starts a holddown timer, 
preventing any additional SPF runs for the next 5000ms.

If you changed values to their platform minimums :
- csnp tx interval : 1000ms
- spf delay : 50ms

So your BEST case is still 1050ms + 1/2 link RTT.  ( These would probably be really bad to use in a real network too. )

Does this make it clear why even a couple theoretical extra ms of processing time is not a concern?

On Thu, Sep 11, 2025 at 2:05 AM Vasilenko Eduard via NANOG <nanog () lists nanog org<mailto:nanog () lists nanog org>> 
wrote:
Because the BGP is not relevant (event propagation time is not important, not to the ms level),
I would prefer the same explanation, but in relation to ISIS or OSPF. Yes, it is called MAC.
Example configuration is explained, for  example, here: 
https://netquirks.co.uk/wp-content/uploads/2023/03/is-is-md5-authentication.pdf
Eduard
-----Original Message-----
From: nanog--- via NANOG <nanog () lists nanog org<mailto:nanog () lists nanog org>>
Sent: Wednesday, September 10, 2025 20:07
To: North American Network Operators Group <nanog () lists nanog org<mailto:nanog () lists nanog org>>
Cc: nanog () immibis com<mailto:nanog () immibis com>
Subject: RE: MD5 is slow

The MD5 option of BGP (or TCP more generally, but only BGP really uses it) combines each TCP packet with a password 
that's configured the same on both sides of the connection, then hashes the combination, and transmits it in the 
packet. The receiver does the same calculation, and if the receiver's calculated hash doesn't match the one in the 
packet, it ignores the packet.

This procedure is more specifically called a "message authentication code" or MAC and the password is actually a "key" 
for the MAC.



On 10 September 2025 15:53:17 CEST, Nicholas Warren via NANOG <nanog () lists nanog org<mailto:nanog () lists nanog 
org>> wrote:
> Can someone with experience in list discussions tell me what's happening right now? Why are passwords and secrets 
> being associated with hashing?
>
> Operationally, I'm getting from this that spoofing IGP packets is a popular pastime.
>
> Nich
>
> -----Original Message-----
> From: Vasilenko Eduard via NANOG <nanog () lists nanog org<mailto:nanog () lists nanog org>>
> Sent: Wednesday, September 10, 2025 8:25 AM
> To: Tom Beecher <beecher () beecher cc<mailto:beecher () beecher cc>>; North American Network Operators
> Group <nanog () lists nanog org<mailto:nanog () lists nanog org>>
> Cc: Vasilenko Eduard <vasilenko.eduard () huawei com<mailto:vasilenko.eduard () huawei com>>
> Subject: RE: MD5 is slow
>
> BGP would never be fast, because it could be a DDoS attack vector by itself (push expensive BGP to run very often on 
> the alien domain).
>
> Many people did tuning of the IGP to achieve “sub-second”.
> Some number of ms * a few hops * 2 => it is something like 1/5 of the “sub-second”.
> If it is not important, why do people do something like this RFC 9681 -
> IS-IS Fast Flooding<https://datatracker.ietf.org/doc/html/rfc9681>
>
> Symmetric encryption may be used only for authentication. But it is better to encrypt the whole header if symmetric 
> encryption is available.
> Eduard
> From: Tom Beecher <beecher () beecher cc<mailto:beecher () beecher cc>>
> Sent: Wednesday, September 10, 2025 15:28
> To: North American Network Operators Group <nanog () lists nanog org<mailto:nanog () lists nanog org>>
> Cc: Saku Ytti <saku () ytti fi<mailto:saku () ytti fi>>; Vasilenko Eduard
> <vasilenko.eduard () huawei com<mailto:vasilenko.eduard () huawei com>>
> Subject: Re: MD5 is slow
>
> It is the reason why symmetric encryption is much stronger for this use case. Hence, symmetric encryption does not 
> need to be slow.
>
> Symmetric encryption is faster when the data size in question is large.
> The delta between symmetric and asymmetric is negligible at the data
> sizes in scope for networking protocols. (Also hashes in protocols
> aren't being used for ENCRYPTION, they're being used for
> AUTHENTICATION. )
>
> Also, even if we assert the 5ms per hash calculation is accurate ( although to be clear I agree it is not ), it is 
> STILL basically a no-op.  ISIS and OSPF implementations have spf-delay timers ( different by vendor ) to prevent 
> constant calculation churn during instability.  BGP UPDATES received have to process through Adj-Rib-In , then go into 
> Loc-Rib, then go into main RIB with all other protocol routes, then you have to bestpath THAT to get the FIB , which 
> then gets turned around and transmitted as appropriate.
>
> Hash calculations , even if hypothetically repeated at each step ( which they are not ) , are a negligible part of the 
> convergence delay, at any scale.
>
> On Wed, Sep 10, 2025 at 7:13 AM Vasilenko Eduard via NANOG <nanog () lists nanog org<mailto:nanog () lists nanog 
> org><mailto:nanog () lists nanog org<mailto:nanog () lists nanog org>>> wrote:
> Hi Ytti,
> It looks like you are trying to teach me what is "salt". Salt + password greatly increases the challenge for the 
> attacker: it is not possible to map a hash to a password just from the database (in 1 step).
>
> For the attacker in the networking protocol case, the "salt" is always visible (these are additional fields from 
> packet headers).
> The attacker could still try different passwords from the database. But it would need many steps; every step is 
> effectively the same processing as on the legitimate host (headers + password).
> If we assume that on some platform (GPU?), the performance would be very fast (10B/sec), then all typical passwords 
> would be tried in seconds.
> It is not acceptable. Hash must be slow! (if used for signature,
> because hash for load balancing or routing tables have no such problem
> - they need only good randomness)
>
> For symmetric encryption, the "salt" is the internal state of the encryption engine (initialization vector?) - it is 
> not visible and changed/preserved between packets.
> It is the reason why symmetric encryption is much stronger for this use case. Hence, symmetric encryption does not 
> need to be slow.
> Ed/
> -----Original Message-----
> From: Saku Ytti <saku () ytti fi<mailto:saku () ytti fi><mailto:saku () ytti fi<mailto:saku () ytti fi>>>
> Sent: Wednesday, September 10, 2025 13:11
> To: North American Network Operators Group
> <nanog () lists nanog org<mailto:nanog () lists nanog org><mailto:nanog () lists nanog org<mailto:nanog () lists nanog 
> org>>>
> Cc: Vasilenko Eduard
> <vasilenko.eduard () huawei com<mailto:vasilenko.eduard () huawei com><mailto:vasilenko.eduard () huawei 
> com<mailto:vasilenko.eduard () huawei com>>>
> Subject: Re: MD5 is slow
>
> On Wed, 10 Sept 2025 at 13:01, Vasilenko Eduard via NANOG <nanog () lists nanog org<mailto:nanog () lists nanog 
> org><mailto:nanog () lists nanog org<mailto:nanog () lists nanog org>>> wrote:
>
> > IMHO: Then it was bad design. The source text is visible if a hash is used for the signature. Only the password is 
> > not known.
>
> Please make a serious attempt in trying to understand how applications are different.
>
> Try to understand why unix passwords benefit from slow hash. You only have the password hash as output, any input that 
> provides same hash, is equivalent. So any collision you find, you have exactly the same problem and serious problem.
>
> MD5 or SHA in BGP, ISIS, OSPF are not like this. There isn't even necessarily guarantee that useful collisions exist, 
> as you may not have enough bits that can have arbitrary value while keeping PDU valid and conducive towards your 
> attack vector.
>
> Most collisions would be garbage, where PDU is rejected. Therefore even if we assume we could cause MD5, SHA 
> collisions, it wouldn't still matter.
>
> You have good rationale in wanting slow hash, but you struggle to understand why not all applications are about 
> hashing 8byte secrets.
> --
>  ++ytti
> _______________________________________________
> NANOG mailing list
> https://lists.nanog.org/archives/list/nanog () lists nanog org/message/5E2
> 2LVBXJI4WQUE6CQUOCJ7GJB4XQ5ZL/
> _______________________________________________
> NANOG mailing list
> https://lists.nanog.org/archives/list/nanog () lists nanog org/message/Q7R
> J7HFDGPW3D45PJGWSX5GJ5H3BLSV3/
> _______________________________________________
> NANOG mailing list
> https://lists.nanog.org/archives/list/nanog () lists nanog org/message/ZVG
> RMCGRF4OZN2UKUAYITCSMG6SXYPTL/
_______________________________________________
NANOG mailing list
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/UYFO4NJY2TSASMTHHSE3HUK7PNHDJHPD/
_______________________________________________
NANOG mailing list
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/EGMXOLSPSIYB7F3O576C4Q3DBIR27MDS/
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/DUPI3YTZ4WJHPPDDDGYKRZWD4BEAGIUO/