The world in which IPv6 was a good design

Suprising to see a recommendation for QUIC by someone who seems to ackowledge djb's contributions and incredible attention to detail. http://apenwarr.ca/log/?m=201103#28

Correct me if wrong, but QUIC was inspired by djb's CurveCP?

Would you rather have djb implement your trusted UDP congestion-controlled overlay or a company with 70,000+ employees who are paid from the sale of online ads?

@hashbreaker Apr 15 CurveCP's zero-padding (curvecp.org/messages.html) was designed years before ringroadbug.com, explicitly to stop that type of attack.

http://ringroadbug.com

Ring-Road

Leaking Sensitive Data in Security Protocols

What is Ring-Road?

The Ring-Road Bug is a serious vulnerability in security protocols [e.g, QUIC but not CurveCP] that leaks the length of passwords allowing attackers to bypass user authentication. The Internet Engineering Task Force for HTTP/2 led by Google is working to create a patch to protect security protocols vulnerable to Ring-Road.

Researchers a part of Purdue University identified a major security issue with Google's QUIC protocol (Quick UDP Internet Connections, pronounced quick).

MQTT, CoAP, SRTP

Not as long as every preexisting application on your computer validates IP addresses and tells you that colons are not valid in IPs and domains.

I think it may be worse than a lost packet, though. If the destination host is truly gone from that network, the nearest router might reply that no such computer exists, causing the socket to be disconnected. (It's been awhile since I've studied TCP/IP; I'm not sure what the exact correct reply would be...)

Perhaps this could be mitigated by adding a timeout that keeps sockets alive for awhile in case the destination shows up somewhere else.

BTW, the best read in networking is "The Elements of Networking Style" by Mike Padlipsky.

https://en.wikipedia.org/wiki/Michael_A._Padlipsky

It's hard to find a copy of that book but oh, man, if you know the stack and you lived through the ISO/OSI proposals, it's so so good.

I got lucky and read that book after I had ported Lachman's streams based networking stack into the ETA-10 and SCO's Unix. I didn't know what I was doing but I had to get the job done, I was just dealing with shorts that weren't 16 bits, stuff like that. So I was a grunt thrashing around. At some point I wanted to know more about I was doing, I still have a notebook where I wrote down every packet format, all the IP stuff, TCP stuff, UDP stuff, ARP stuff, etc. Shout out to Masscomp because I was a sys admin on their machines in college and they had a great intro to networking that formed the basis of my limited understanding of networking.

It was Padlipsky's book that brought the whole thing into focus. I dunno if you guys have had that clarity problem, I had it again when I went to Sun and was working on the kernel, had no idea what I was doing, thrashed about, and slowly, slowly, the architecture of what Sun had done came into focus. It was amazing to me when I got it. It took a lot of time just looking, reading the code, trying to see the picture. Padlipsky's book made me get networking long before I came to Sun, I was a n00b at everything and he made me get it. And it was funny as heck.

"Do you want protocols that look nice or work nice?"

"If you know what you are doing 3 layers are enough, if you don't 7 aren't"

His book was full of that stuff and it made you get the stack. If you are into the network stack, and especially if you are trying to figure it out, get that book.

In fact, if you contact me and say "that's me but I'm broke", I'll see if I can find a copy on ebay or some place and send it to you.

That book rocks.