Re: MD5 is slow

[Tom Beecher via NANOG <nanog () lists nanog org>]

> 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> 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>
> Sent: Wednesday, September 10, 2025 20:07
> To: North American Network Operators Group <nanog () lists nanog org>
> Cc: 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> 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>
> > Sent: Wednesday, September 10, 2025 8:25 AM
> > To: Tom Beecher <beecher () beecher cc>; North American Network Operators
> > Group <nanog () lists nanog org>
> > Cc: Vasilenko Eduard <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>
> > Sent: Wednesday, September 10, 2025 15:28
> > To: North American Network Operators Group <nanog () lists nanog org>
> > Cc: Saku Ytti <saku () ytti fi>; Vasilenko Eduard
> > <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>> 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>>
> > Sent: Wednesday, September 10, 2025 13:11
> > To: 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
> >
> > On Wed, 10 Sept 2025 at 13:01, Vasilenko Eduard via NANOG <
> 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/LWEZHBMLZJIS6V4DYKQWWPSVQLQUCWEC/