> > 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 < [email protected]> 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 <[email protected]> > Sent: Wednesday, September 10, 2025 20:07 > To: North American Network Operators Group <[email protected]> > Cc: [email protected] > 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 < > [email protected]> 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 <[email protected]> > >Sent: Wednesday, September 10, 2025 8:25 AM > >To: Tom Beecher <[email protected]>; North American Network Operators > >Group <[email protected]> > >Cc: Vasilenko Eduard <[email protected]> > >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 <[email protected]> > >Sent: Wednesday, September 10, 2025 15:28 > >To: North American Network Operators Group <[email protected]> > >Cc: Saku Ytti <[email protected]>; Vasilenko Eduard > ><[email protected]> > >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 < > [email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> > >Sent: Wednesday, September 10, 2025 13:11 > >To: North American Network Operators Group > ><[email protected]<mailto:[email protected]>> > >Cc: Vasilenko Eduard > ><[email protected]<mailto:[email protected]>> > >Subject: Re: MD5 is slow > > > >On Wed, 10 Sept 2025 at 13:01, Vasilenko Eduard via NANOG < > [email protected]<mailto:[email protected]>> 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/[email protected]/message/5E2 > >2LVBXJI4WQUE6CQUOCJ7GJB4XQ5ZL/ > >_______________________________________________ > >NANOG mailing list > >https://lists.nanog.org/archives/list/[email protected]/message/Q7R > >J7HFDGPW3D45PJGWSX5GJ5H3BLSV3/ > >_______________________________________________ > >NANOG mailing list > >https://lists.nanog.org/archives/list/[email protected]/message/ZVG > >RMCGRF4OZN2UKUAYITCSMG6SXYPTL/ > _______________________________________________ > NANOG mailing list > > https://lists.nanog.org/archives/list/[email protected]/message/UYFO4NJY2TSASMTHHSE3HUK7PNHDJHPD/ > _______________________________________________ > NANOG mailing list > > https://lists.nanog.org/archives/list/[email protected]/message/EGMXOLSPSIYB7F3O576C4Q3DBIR27MDS/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/LWEZHBMLZJIS6V4DYKQWWPSVQLQUCWEC/
