Slashdot Mirror

It's almost as if it's a play on the Dragonfly Key Exchange name that's being targetted.

...but I'm using RFC 1149.

https://tools.ietf.org/html/rfc1149/

UnknowingFool reminisced:

I Remember IANA

Me, too.

Jon's sly, gentle humor perfectly counterbalanced his unfailing integrity and courtesy. He was a superb custodian for the DNS and IP allocation databases, back when IANA was strictly a one-man-band. He also was wise enough to see the need for authority over the DNS registry to be taken out of the hands of Network Solutions, Inc.

Unfortunately, it wound up under the control of ICANN, instead - which was an improvement only in the sense that being beaten with a sock full of nickels is an improvement over being beaten with a sock full of dimes ...

(Posting as AC only so as not to undo prior upmods in this thread.)

--

Check out my novel ...

> For example, the word "conversation" in the RFC doesn't refer to two people chatting about the weather, does it?
> Or how about "bit"? It wasn't a drill bit, or a bit of money, or a bit part in a movie, was it?
> So according to your rules, they should have been capitalized.

Where, exactly, do you see "bit" and "conversation" defined in that RFC, or any contemporary RFC?

I didn't say "all caps means a technical term".
All caps means a term defined in:
1. That RFC or
2. An RFC which is referenced

For example, most RFCs reference RFC 2119, which defines SHOULD, MUST, and MAY
http://www6.ietf.org/rfc/rfc21...

So yeah those should not be capitalized per best practice, because there isn't a specific definition included which is being referenced.

Since that's the very first RFC, fifty years old, and usage RFCs like 2119 hadn't been written yet, you probably *can* find some instances where the very first RFC did not comport to modern guidelines fifty years later. Neither bit nor conversation are examples, though.

Indeed, BIT probably *is* defined in a special way for some physical interface standards, such as 100base-tx, which defines a HIGH bit as being over a certain voltage, and a LOW being below another voltage, with an undefined error band in the middle. Capitalizing BIT would have indicated that one needed to refer to a given specialized definition.

I Remember IANA

I really wish they had implemented RFC3514. Thanks, Obama.

How can we be talking about internet RFCs without mentioning the most important one?

The Infinite Monkey Protocol Suite

How else would we get the collective works of Shakespeare with an infinite supply of monkeys/typewriters/bananas?

https://tools.ietf.org/html/rf...

Send Mexicans amnesty letters over IP over avian carriers with QoS to get their votes and make them dependent on welfare, you mean? Thanks for putting the brakes on this, Trump!

Yes, there is. RFC5322 defines what constitutes an email address, amongst other things. Arguably though, all Google is going is automatically creating every single possible RFC5322 compliant alias of a given email address that you can create by inserting full stops in the bit before the @ sign and assigning them all to the same user, how they do that (almost certainly by stripping out the full stops from the LHS) isn't any concern of RFC5322. They're not actually creating any invalid email addresses or anything; just restricting the number of possible unique email addresses they can assign on their domain.

Not really. The way Caller ID was originally implemented, the Caller ID information is transmitted along with the call as a set of ultrasonic tones, therefore any caller and set their caller-id number to whatever they want. This is useful if you are calling from an office that gets routed through a local switchboard.

Some kind of standard is being worked on, but it is a hard problem to implement with the current telepohny network was it exists today

see https://datatracker.ietf.org/w...

This post is what I still love about Slashdot over Reddit and Facebook. This post exists. Unlike Reddit, Twitter, Facebook, et al. it won't get deleted. [Not sure if the list of owners has changed the policy, but I think the Scientology post through legal action was the only one. Any lurking 2-4 digit users remember?]

AC is hands down the best user on Slashdot and why I keep coming back. I've seen some amazing +5 Informative posts. Laughed at +5 Funny. And thankfully not had to ever deal with [pronoun]'s Troll posts, and most users, especially logged out lurkers, will never know. No one is ranting about Slashdot hosting what ever this rant was (I certainly didn't bother reading it). It'l get modded troll and disappear. Maybe it'll get a legendary -5 Troll from being +5 Interesting but still a Troll post.

Slashdot has persisted, because of the (IMHO) amazing moderation on Slashdot had implemented from the beginning.

• Unlike Reddit, it's not just a up/down bandwagon vote if you agree with the comment.
• Unlike Facebook, it's not a quinary 'reaction' of how I feel about the comment. 'Like, love, laugh, sad, wow, and mad' aren't even worth registering for something like this.
• Unlike Twitter, it's not a numerical count of how many people agree with it or a reply.
• Unlike the former Imzy, it's not a bunch of people trying not to offend a single person in a room of thousands.
• Unlike 4Chan.... I have no clue the appeal of 4Chan. I was in my 20s and didn't get it. Any younger millenials comment?

• Reddit is just a bunch of forums band-aided together with the same userbase. /r/The_Donald, /r/HumansBeingBros, /r/trees and /r/gonewild just all in one place.
• Facebook is just some poorly designed poll about how something makes me feel.
• Twitter is a bunch of idiots standing around shouting. With some idiots giving other idiots megaphones. And a million little side shouting matches.
• Imzy was trying to be an online kumbaya circle. I just commented about "Anonymous Coward" vs their RandomUserName method and got an earful about the 'connotation' of Coward and how it makes others feel. And that was the end of that. The attitude of every user just wanted me to never post. It appears it made others feel the same way.
• 4Chan appeared to be the online version of The Aristocrats. With everyone thinking they were Gilbert Gottfried version after the 9/11 joke.

Slashdot may have its problems and I may not always agree with its registered userbase, but Jesus, have you seen where those people

hangout online?

Whiplash, if you're serious about improving the site and want to attract a huge raft of migrants from Reddit upset over the Facebook-ization of the redesign:

• 
  
• This downtime was just unacceptable for a site targeted towards professionals like Slashdot was.
  
• Can we please use Markdown? When I wrote HTML daily in the late 90s posting here was second nature. Markdown has sort of become lingua fraqua of formats. It's short and descriptive enough.
• You don't even have to force the same front end on users. Register a new domain with a fancy TLD. Do the translation on the backend.
• Fucking Unicode.

Slashdot's killer feature is the moderation. I would pay money for a politics forum with Slashdot's moderation system. Because even at $1/month it'll keep out the most people that don't even value their opinion at that, the ones that will cling to Facebook and Twitter like those that did to MySpace and Imzy.

I'd also pay for a Usenet interface. Hire some people, RFC-5537 is 10 years old and could be improved upon. Have a lessons learned pow-wow at Slashdot and I'll lower your bandwidth bill by a significant factor.

It's been done virtually before. RfC 3514 - IETF aka the "Packet Evil Bit."

... often have difficulty distinguishing between packets that have malicious intent and those that are merely unusual. We define a security flag in the IPv4 header as a means of distinguishing the two cases.

This seems like it should be easy to defeat. Acting as a portal ought to come with some sort of detectable signature. A few extra ms, routing abnormalities?

Why would that be easy?

Transit time changes frequently. "A few extra" miliseconds would result in false-positive rates approaching 50%

Routes change frequently too. That's the point of using routing protocols. Worse, why would the route from the user's perspective change? Transparent proxies are the norm these days.

Plus "ought" is an ethical concept, not a descriptive one. The evil bit isn't implemented.

The only way one could detect this sort of attack reliably is to have enterprise-level DNSCrypt, enforce mandatory TLS on connections, ensure certs are handled before the link is compromised, never allow inferior encryption suites, ensure everything is patched, then monitor every connection for changes to any of those components.

Yes, there's a whole RFC series for Unicode labels in domain names, including advice to registrars for how to mitigate that problem. The ".com" domain itself is managed by Verisign, and they have a policy to address exactly that problem.

Chrome also supports QUIC, which requires a long-lived GUID (ie. a unique browser ID).

Cite?

I think you're referring to the Connection ID, but it is not long-lived and it is not global, i.e. not a unique browser ID. Its purpose is to enable connection migration, seamless continuation of an existing connection when the device changes IP addresses (switches LANs, goes from Wifi to cellular or vice versa, etc.). It's actually required to change on every migration, and allowed to change at almost any other point in time, so it's definitely not long-lived, even for a given connection, and is certainly not global.

Chrome also supports QUIC, which requires a long-lived GUID (ie. a unique browser ID).

Cite?

I think you're referring to the Connection ID, but it is not long-lived and it is not global, i.e. not a unique browser ID. Its purpose is to enable connection migration, seamless continuation of an existing connection when the device changes IP addresses (switches LANs, goes from Wifi to cellular or vice versa, etc.). It's actually required to change on every migration, and allowed to change at almost any other point in time, so it's definitely not long-lived, even for a given connection, and is certainly not global.

https://tools.ietf.org/html/rf...
https://tools.ietf.org/html/rf...

This protocol was assigned v8 by the IANA.

https://tools.ietf.org/html/rf...
https://tools.ietf.org/html/rf...

This protocol was assigned v8 by the IANA.

IETF is way ahead of you. Been around since 2013.

I don't differentiate you from the other bullies. Note "other". Verbal and textual abuse are never acceptable, and that includes the abuse in the post I'm referring to.

Things to do:
https://tools.ietf.org/html/rf...
http://www.faqs.org/faqs/games...
(B1 applies to all Internet posts)

Things not to do:
https://groups.google.com/foru...

I doubt you, or any other troll, will read any of this, or care even if you do. Why should you? If nothing matters and nothing exists, then netiquette just means better quality nothing.

Anything using 10/8, 172.16/12, or 192.168/16 is a "private internet" according to RFC 1918 - Address Allocation for Private Internets (1996).

A fundamental difference between QUIC and TCP or SCTP is that QUIC is a user space transport protocol, which allows rapid protocol revision without having to wait for system upgrades. To support rapid protocol revision, QUIC's connection setup goes through a negotiation process that involves determining the lowest common version supported between the two endpoints and a cryptographic handshake which incorporates TLS to provide a secure connection. This thing is an operating system, not a transport protocol. De-commoditizing of basic protocols was one of the stated means to exert control by the Microsoft of the Halloween Documents. Now the actors have changed, but it looks like the play is always the same.

There is a draft RFC that specifically addresses this question; A Comparison between SCTP and QUIC.

Among the conclusions; QUIC provides better connection latency by eliminating handshake round trips. QUIC mandates encryption for everything in all phases including the initial handshake. QUIC has better compatibility with existing infrastructure because it rides on UDP and is therefore supported by nearly all "middleboxes," whereas SCTP is not universally supported. The connection ID concept allows QUIC connections to transparently survive IP address changes and NAT rebinding.

Another rationale for QUIC over SCTP appears here: QUIC: Design Document and Specification Rationale

Again, connection latency is cited. Also, "bandwidth efficiency;" basically QUIC has less overhead than SCTP+DTLS and achieves the same result.

First, read this blog post from 2017: The world in which IPv6 was a good design. It's on the long-ish side, but you'll come out the other end somewhat smarter.

Toward the end, the author makes an off-handed reference to QUIC, a then-experimental protocol that actually solves many of the issues that IPv6 was supposed to solve. Right now, TCP connections are hard-bound to IP addresses. If your IP address changes (as is extremely likely to happen on your mobile phone), your connection is broken and you have to reconnect -- a huge pain in the ass for streaming applications and network operators trying to paper over that. QUIC's big win (assuming it wasn't lost during revisions) is that it allows your network connections to survive IP address changes, since the endpoints are identified not by an IP address/port tuple, but rather by a GUID/port tuple. Downside: You lose (some? all?) anonymity, as your GUID is long-lived.

So, no, this isn't some kluge Google chundered up last week. This has actually been under review by the IETF for a couple years.

If you don't control both end points though H.264 is now almost universal as long as you're willing to use Cisco's OpenH264 patent licensed binary or one of the many other open source decoders, which is 99.99% of the market. That was as late as 2013 though, so it's only been 5 years since missing codecs actually was an end user problem.

Here's one: Video calling between end users. This requires both sides to have an audio encoder, video encoder, audio decoder, and video decoder for the codec suite used for the call.

As for audio: Apple WebKit appears to support Opus (webrtcHacks).

As for video: Apple WebKit supports only H.264 (webrtcHacks; bug 173141) and therefore doesn't fully conform to WebRTC (RFC 7742 section 5). If one end of a WebRTC video call is an iOS device running Safari or another Apple WebKit wrapper, then the call must use H.264, and the other device must also include a licensed H.264 encoder. Does OpenH264 encode, or is it only a decoder?

P.S. VP8 in WebRTC was added to Apple WebKit 37 days ago (bug 189976), but it may take months for this fix to reach the version of Apple WebKit included with iOS.

They should be using the proper standard RFC 3514.

Clearly the world just needs to get off its butt and adopt real privacy and security.

the 'do not track' bit

It's every bit [sic] as effective as the evil bit.

Actually, no, "Google Authenticator" is just an app which implements the OATH TOTP protocol (a.k.a. RFC 6238). There are several other implementations out there, and they're pretty much all compatible.

It's possible (although I don't know if Google's app does so) for the generator application to be a purely offline app with no external access whatsoever.

It functions essentially like one of the old RSA SecurID tokens - an offline token generating 6 or 8 digit time-based id numbers.

The professional response is: Right or wrong, RFC 5011, section 6.3 uses the term 'roll'

Stopping to your level, the response is: read the RFCs before you write your next comment.

With regards to (2), the phone companies are protected by their Common Carrier status, so it's probably going to take a change to phone protocols to prevent spoofing. e.g. Change how VoIP-to-VoIP calls are made so they also send a datagram encrypted with a private key owned by the caller.

That's what the STIR and its sister protocol SHAKEN hope to implement. Unfortunately, as you pointed out, telcos are dragging their feet to roll the technologies out because they like the revenue that spammers pay (a dollar is a dollar is a dollar) and would rather save on the implementation costs.

Example.com and several others are reserved domains (RFC6761, example.com), operated by IANA for documentation purposes.

The filtering you mention conceptually resembles sslstrip, which prompted HSTS. A mail user agent (MUA) might implement an analogous countermeasure against STARTTLS stripping by warning the user if STARTTLS to a particular server stops working:

MUA connects to mail server over one network.
STARTTLS works.
MUA records this fact.
MUA connects to same mail server over a different network.
STARTTLS fails.
MUA warns user that a mail server that once supported STARTTLS no longer does and drops the connection until further notice.

There's even a draft proposal called MTA-STS for a mail server to require STARTTLS for further connections.

Or the user could configure the MUA to connect on the alternate port that uses TLS from byte one: 465 for SMTP, 993 for IMAP, or 563 for NNTP.

ISPs applying this technique filter out all incoming connections. The subscriber's modem doesn't even have a publicly routable IP address. Instead, the ISP assigns the subscriber an IP address in the reserved space 100.64.0.0/10 (as documented in RFC 6598), which is routable only within that ISP's network, and translates addresses within that range to a much smaller address space as packets enter and leave the ISP's network.

And as Bert64 wrote, Myanmar is among the countries that have so few IPv4 addresses allocated to them that all ISPs have to run home users behind NAT in order to provide service. Say you have 16,000-odd IP addresses (a /18) but 10 million customers. The pigeonhole principle means you can't put each customer on a separate IP address. At a global scale, with 7 billion people and 4.2 billion IP addresses, you can't give everyone a unique address.

Wrong; See: https://tools.ietf.org/html/rfc4941.

And IPv6 moving away from NAT has everything to do with NAT being an awful solution to the bad design of IPv4. NAT Going away is an enormous benefit for the freedom of the internet where all nodes are treated as peers.

As a result, many in the industry have held onto the virtually universally-supported HTTP Live Streaming, which is an M3U playlist with tag extensions and MPEG-2 Transport Stream container for the codecs. Even that standard developed by Apple has never become a fully ratified within the IETF, and nobody knows if the same thing will happen there either.

HTTP Live Streaming definition now lives in RFC 8216. Yes, it is informational, but it's there.

Only one Anonymous Coward mentions IRC, where away messages were written into the protocol in 1993.

Actually technically RFC 2822 says that the subject is optional... so it is really on the app side that we should have made the subject line optional (or even hidden) in the UI.

https://tools.ietf.org/html/rf...

IPv4 is non-extendable in any useful way. That RFC is about as much of a joke as https://tools.ietf.org/html/rf... Computers must look like magic to you. If someone can't get something done, they must not be waving their magic wand hard enough.

Beyond brainstorming, anyone who takes extending IPv4 seriously should not be in change of anything related to networking. It's not an ivory tower issue. It's the limitations of logic in our Universe.

Alright, let's go with that for now. The next question is: what could they possibly have done about it?

They could have banned Vint Cerf from the steering committee, great start. Then get down and seriously figure out the least painful way to extend the IPv4 address space. Too hard for Vint Cerf to comprehend, apparently. Maybe you also unless you are just being disingenuous, which is a distinct possibility.

Nobody said anything about forward compatible, do you know the difference? (I doubt it.)

there's nothing that v6 could have done to avoid i

Intellectually embarrassing claim for you to make.

Show us your RFC for IP v7, then.

IP6 Is a XX century protocol as well.

In fact IPv6 has been standardised in 2017, see https://tools.ietf.org/html/rf...
BTW, there was even IPv9 and it wasn't a Chinese joke.

Had they just fucking called we both would have been able to quickly sort out who knew what and who was going to do anything about it.

That is actually misrepresenting the problem. A call requires you to drop everything and give it your full attention. It doesn't allow for editing your answer, or asking a careful question. The upside is indeed that you can quickly go back-and-forth. But the cost is that you lose your flow and are out of it for at least another 15 minutes. If I was dug into something deep and you call me around four, I might as well go home since I won't be able to get back in for the day. That's a fairly steep but hidden cost to your two minute call you could've resolved yourself with thirty seconds thinking or a minute or two of searching for yourself.

But the root cause is muddled thinking. This is quite common, and several essays on the issue immediately spring to mind.

There is that and also depending on your job you may even be required to have everything in writing whenever talking with a client or even for interdepartmental communications. Some of it is for CYA purposes but also for dealing with those people who just won't take notes and call you again with the same question the very next day because they already forgot. If someone insists on leaving me a long-winded voicemail I'll just email them and claim that it was garbled or such and to please reply to the email with their question. In my experience the ones who try to avoid email are trying to hinder you from documenting what they said.

Had they just fucking called we both would have been able to quickly sort out who knew what and who was going to do anything about it.

That is actually misrepresenting the problem. A call requires you to drop everything and give it your full attention. It doesn't allow for editing your answer, or asking a careful question. The upside is indeed that you can quickly go back-and-forth. But the cost is that you lose your flow and are out of it for at least another 15 minutes. If I was dug into something deep and you call me around four, I might as well go home since I won't be able to get back in for the day. That's a fairly steep but hidden cost to your two minute call you could've resolved yourself with thirty seconds thinking or a minute or two of searching for yourself.

But the root cause is muddled thinking. This is quite common, and several essays on the issue immediately spring to mind.

Notice how the kids (I'm 40, but I feel much older) treat "texting" like a phone call, or worse: Half-sentences or just loose words strung along across many messages. So they're trying to suck all your attention to them over the text.

Me, I prefer messages like I used to exchange on USENET (and FidoNet's Echomail). Properly interleave-quoted, edited for brevity, to the point, easily readable. It takes quite a bit of effort to make such a thing work but if you do you can get massive content through with lots of detail and nuance.

You don' t get that with a phone call, nor with "texting". You just get lots of attentiongrabbing, and a very low signal-to-noise ratio. This seems to be par for the course for "business" these days. Even before "texting" became a thing, truth be told. Mealy-mouthed "we value your custom so we're putting you on hold" and other such bullshit, not just on the phone. It's everywhere, and besides being full of obvious lies, it's a searing insult to my intelligence.

And now it's not just phone calls and texting, but all sorts of do-overs, do-agains, me-toos, and other imitations. Whatsapp, twitter, facebook, and previously icq, msn, aol messenger, jabber, what-have-you. None of those add anything worthwhile beyond being popular for a while, they just manage to fragment your messaging archive beyond all integration.

So for anything official, I'm back to letters.

It is a regrettably well spread misconception that publication as an
      RFC provides some level of recognition. It does not, or at least not
      any more than the publication in a regular journal. In fact, each
      RFC has a status, relative to its relation with the Internet
      standardization process: Informational, Experimental, or Standards
      Track (Proposed Standard, Draft Standard, Internet Standard), or
      Historic. This status is reproduced on the first page of the RFC
      itself, and is also documented in the periodic "Internet Official
      Protocols Standards" RFC (STD 1).

https://tools.ietf.org/html/rf...

Now let’s go to the I’m a Teapot RFC:

Status of this Memo

      This memo provides information for the Internet community. It does
      not specify an Internet standard of any kind. Distribution of this
      memo is unlimited.

So basically you’re wrong as can be.

and were suddenly silenced

No, that would be the 451 error code.

If you saw the error message, you used a command line interface with a proxy server, and thus were likely tech savvy. And then chances are you'd know about the 418 error code and RFC2324. It's 20 years old now, preceding IOT by quite a bit.

It is a legitimate error code only if the device is an actual teapot and was asked to brew coffee. That is not the case in this situation, and the error code is being misused.

We fear that the PGP software stores hiddenly the password of the user in the PGP-encrypted message.

I know it is hard to trust anything in a software ecosystem where the likes of RSA Security has been implicated in a security weakening scandal, and one could almost certainly hide data within an Open-PGP message (e.g. adding a private/experimental packet), but I also know that software I use does not do this. I say this because I have done the exercise of analyzing and decrypting Open-PGP messages produced by GnuPG, and I can account for every byte of each packet with the encrypted massages I have analyzed.

But don't trust me: Look up the RFC 4880 and check for yourself. You'll need to do some work because the protocol is klunky, but it is worth doing if you are seriously concerned.

Here comes the fun police.

Time to remove all jokes from the internet.

What's next? The Teapot protocol? Avian carriers?

Here comes the fun police.

Time to remove all jokes from the internet.

What's next? The Teapot protocol? Avian carriers?