And unfortunately, like #ietf119, #ietf120 is a pepsi venue again

Members of the @intarchboard the Internet Engineering Steering Group, the IETF Administration LLC Board of Directors, and the IETF Trust were announced just before the recent #IETF119 meeting, where several of the groups met in-person for the first time: https://www.ietf.org/blog/nomcom-announcement-2024/

Weekend Reads

* DNS at IETF 119 https://www.potaroo.net/ispcol/2024-03/dns119.html
* DNS HTTPS RR ecosystem https://arxiv.org/abs/2403.15672
* US cyber force proposal https://www.fdd.org/analysis/2024/03/25/united-states-cyber-force/
* Port forwarding service risks https://arxiv.org/abs/2403.16060
* US DHS incident reporting proposal https://public-inspection.federalregister.gov/2024-06526.pdf

#US #DHS #CyberForce #DNS #IETF119 #PFS

Do you enjoy ISPs dictating what quality you should watch your videos at? Then you might want to read my latest blogpost about the SCONEPRO BoF meeting at #IETF119 https://tarakiyee.com/sconepro-with-network-jam-and-clotted-streams/ #TrafficShaping #InternetStandards

📢#IETF119 video of the @irtf RASP meeting is now available with 1) LLMs for RFCs, 2) psycholinguistics analysis of IETF mail lists, 3) standards tracking, and 4) a debate about the (growing) challenge of RFC publication 👉 https://www.youtube.com/watch?v=atC6XLnvKZ8 🧵(1/6)

The Internet Last Week

* IETF meeting 119
https://www.ietf.org/how/meetings/119/
* DataDock Strasbourg water leak outage
https://status.plusserver.com/incidents/s6lzkwsc3tbj
https://www.server4you.com/
https://status.racknerd.com/incident/1848
* Redis licensing change
https://redis.com/blog/redis-adopts-dual-source-available-licensing/
https://redict.io/posts/2024-03-22-redict-is-an-independent-fork/
* Threads joins the fediverse
https://engineering.fb.com/2024/03/21/networking-traffic/threads-has-entered-the-fediverse/

#IETF119 #DataDock #Redis #Threads

And this is the end of #IETF119, you may now drink beers and cuddle koalas.

#Brisbane

Also, proposal to make #DNSSEC configuration easier. The difficulty is how to do it easier for the good guys without makeing it also easier for an attacker.

#IETF119

Analysis of existing CDS/CDNSKEY records in the wild. They are sometimes broken, sometimes in funny ways (authortative name servers not returning the samed CDS...)

Why would a domain in .com publish a CDS (.com does not handle CDS) and a broken one (does not match the keys)?

#DNS #DNSSEC #IETF119

Not all #DNS data were created equal. A project for a new ranking of DNS data credibility.Top: DNSSEC-signed data. Bottom: glue.

#IETF119

Possible change in the process for crypto recommendations (the current one is too slow).
The proposal will require more RFCs, but smaller.
(PQ algorithms are ready to pounce.)

#IETF119 #DNS

Discussion post-BoF about the DELEG (or DD) project, "the most significant change in the #DNS since DNSSEC"

#braceYourself #IETF119

OK, now, we talk about using CBOR in BGP messages and signing them with PQ algorithms.

#ThatEscalatedQuickly #IETF119

Protocol design: what is the difference between a good feature and a bad feature?

A good feature is something I want. A bad feature is something you want.

#IETF119

"I don't say it is impossible, just that it is harder than changing the engines of the plane during the flight."

#IETF119

There is a BGPsec, signing the AS all along the path. But it is not widely deployed (cryptography is hard).

#IETF119

As everyone one (and his dog) knows, BGP has a security issue: how to be sure the peer announcing a route is right?

Your neighbor may lie!

But improving the security requires a way to know the truth: can AS X announce prefix Y? This can be very hard to tell.

#IETF119

You can add new attributes to carry between BGP routers, with interesting possibilities and some possibilities of (imperfect) control over their propagation.

And a problem may appear in routers downsream (since routers may have forwarded incorrect messages). Remember "attribute 99".

Because BGP is stateful, things you send to a peer may be remembered, may be for ever.

#IETF119

And BGP is *the* backbone of the Internet. If it breaks, everything breaks. Hence the sensitivity of BGP people with respect to new proposals.

Some even suggest to *stop* adding things to BGP.

(Is BGP Turing-complete? Can you do arbitrary computations with a set of BGP routers?)

#IETF119

BGP carries routes (obviously) but also VPN config, firewall rules ("a terrifying way to blow up your network"), link state, etc.

Unlike the DNS, which uses the camel metaphor, BGP people use the "dump truck" metaphor: too many things on BGP.

#IETF119