Slashdot Mirror

Ehh...

First of all, this isn't new. Hell, it's in the RFC. In fact, the RFC specifically details and recommends protecting against it in several places.

This is an implementation problem, not really anything to do with OAuth 2.0 or OpenID-Connect. Authorization servers are supposed to match the redirect_uri against valid values that are registered by the client. This is inconvenient for redirecting users back to the right page, so some popular providers decided to match based on prefix or domain, instead. And some websites on the internet have open redirects (hard to believe, i know). If the client website's security is _really_ lousy^H^H^H^H^H lax, its OAuth2 callback module might also not validate the response URI when it gets the access code, and may even not strip the access code from the URI parameters when redirecting.

The service providers are supposed to require clients to register a full redirection callback. The clients can keep track of whatever page people are on with the state parameter. But those same clients, with that same terrible security, will probably get that wrong, too.

So, it's entirely a known problem, and what it boils down to is this: You can recommend best practices, but you can't fix stupid. That's why Google and Facebook are shrugging it off.

That said, if they performed some meager sanitization, it could go a long way to improve the situation.

Ehh...

First of all, this isn't new. Hell, it's in the RFC. In fact, the RFC specifically details and recommends protecting against it in several places.

This is an implementation problem, not really anything to do with OAuth 2.0 or OpenID-Connect. Authorization servers are supposed to match the redirect_uri against valid values that are registered by the client. This is inconvenient for redirecting users back to the right page, so some popular providers decided to match based on prefix or domain, instead. And some websites on the internet have open redirects (hard to believe, i know). If the client website's security is _really_ lousy^H^H^H^H^H lax, its OAuth2 callback module might also not validate the response URI when it gets the access code, and may even not strip the access code from the URI parameters when redirecting.

The service providers are supposed to require clients to register a full redirection callback. The clients can keep track of whatever page people are on with the state parameter. But those same clients, with that same terrible security, will probably get that wrong, too.

So, it's entirely a known problem, and what it boils down to is this: You can recommend best practices, but you can't fix stupid. That's why Google and Facebook are shrugging it off.

That said, if they performed some meager sanitization, it could go a long way to improve the situation.

Ehh...

First of all, this isn't new. Hell, it's in the RFC. In fact, the RFC specifically details and recommends protecting against it in several places.

This is an implementation problem, not really anything to do with OAuth 2.0 or OpenID-Connect. Authorization servers are supposed to match the redirect_uri against valid values that are registered by the client. This is inconvenient for redirecting users back to the right page, so some popular providers decided to match based on prefix or domain, instead. And some websites on the internet have open redirects (hard to believe, i know). If the client website's security is _really_ lousy^H^H^H^H^H lax, its OAuth2 callback module might also not validate the response URI when it gets the access code, and may even not strip the access code from the URI parameters when redirecting.

The service providers are supposed to require clients to register a full redirection callback. The clients can keep track of whatever page people are on with the state parameter. But those same clients, with that same terrible security, will probably get that wrong, too.

So, it's entirely a known problem, and what it boils down to is this: You can recommend best practices, but you can't fix stupid. That's why Google and Facebook are shrugging it off.

That said, if they performed some meager sanitization, it could go a long way to improve the situation.

From http://tools.ietf.org/id/draft...
"5. Header Syntax

      The Do Not Track HTTP header, "DNT", must take one of two values: "1"
      ("opt out") or "0" ("opt in"). All other values are reserved. ...
6.3. Default

      A user agent MAY adopt NO-EXPRESSED-PREFERENCE or OPT-OUT by default.
      It MUST NOT transmit OPT-IN without explicit user consent."

The standard explicitly allows opt-out as a default

The NSA has been heavily promoting ECC.

>So start using ECC and give the NSA the finger

I don't want to give the NSA the finger, or rather that's not my primary job. I do want to develop secure products regardless of the NSA, that make it into that hands of many people, who then enjoy secure computing without having to get involved in the fight. The NSA is a great help in some ways and an undermining force in other ways. As professionals we have to deal with that reality. Delivering secure solutions in mass market products is not just a technical problem. It involves politics, risk management and paranoid lawyers. ECC wins on the technical bit and screws the pooch on the other three. I'm not going to let those issues get in the way.

Saving a few bits on the stored key is not a good tradeoff with having to deal with all the people who don't have the technical knowledge to know what's right or wrong with ECC, but they've sure heard lots of FUD before.

Lots of algorithms are adequate. The challenge these days battling complexity in communication and computing standards that lead to vulnerable implementations.

I would be relegated to communicating via smoke signal.

http://tools.ietf.org/html/rfc...
http://slashdot.org/story/03/0...
There are other options; smokers don't have a monopoly on information transfer.

224/4 is multicast. 240/4 could be made available. https://tools.ietf.org/html/dr...

Many compilers precalculate arithmetic expressions consisting of constants, replacing them at compile-time with the result value constant.

I believe the different constants can be deduced from Section 4 of the original RFC proposing the TLS hearbeat message:

4. Heartbeat Request and Response Messages

The Heartbeat protocol messages consist of their type and an
arbitrary payload and padding.

struct {
HeartbeatMessageType type;
uint16 payload_length;
opaque payload[HeartbeatMessage.payload_length];
opaque padding[padding_length];
} HeartbeatMessage;

The total length of a HeartbeatMessage MUST NOT exceed 2^14 or
max_fragment_length when negotiated as defined in [RFC6066].

type: The message type, either heartbeat_request or
heartbeat_response.

payload_length: The length of the payload.

payload: The payload consists of arbitrary content.

padding: The padding is random content that MUST be ignored by the
receiver. The length of a HeartbeatMessage is TLSPlaintext.length
for TLS and DTLSPlaintext.length for DTLS. Furthermore, the
length of the type field is 1 byte, and the length of the
payload_length is 2. Therefore, the padding_length is
TLSPlaintext.length - payload_length - 3 for TLS and
DTLSPlaintext.length - payload_length - 3 for DTLS. The
padding_length MUST be at least 16.

HeartbeatMessageType is a single-byte enumeration (documented in Section 3) and the payload_length is a uint16 (two bytes)... and the packet always requires 16 bytes of padding, so that's the 1, the 2, and the 16.

If this was a conspiracy, intentional coding would be required for exploit. Given that, I find it difficult to accept that an agency intentionally first complicated the spec by including a length field (which *could* be checked, in the name of security, for protocol robustness rather than local memory ops); then hen perverted a particular implementation in a manner that looks exceedingly garden variety. Easier to never have the length field in the first place

http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=4817504
"Submitted by: Robin Seggelmann "

https://tools.ietf.org/html/rfc6520
"R. Seggelmann" (main author)

Easier if you're both the one making the spec, and the one implementing it... You're in a position of being trusted ("he is the RFC author, he knows what he's doing best, and it's a public spec recognized by the IETF, he's a big guy"). Plus obviously the more cruft, the easier to hide things...

I know this is redundant but this is funny:

Seggelmann told the Sydney Morning Herald. 'In one of the new features, unfortunately, I missed validating a variable containing a length.'

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

Internet Engineering Task Force (IETF)
Request for Comments: 6520
Category: Standards Track
ISSN: 2070-1721

R. Seggelmann, M. Tuexen: Muenster Univ. of Appl. Sciences
M. Williams: GWhiz Arts & Sciences
February 2012

Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension ...

If the payload_length of a received HeartbeatMessage is too large, the received HeartbeatMessage MUST be discarded silently.

Can't even implement an RFC he wrote himself. Nice one.

If your job is to process a formally defined struct, you are not going to review the struct in an attempt to change the standard.

The developer who wrote this code also wrote the spec, as part of his PhD research. To me the more worrying aspect of this whole affair is that OpenSSL accepted into the trunk an extension which at the time hadn't even reached "Proposed standard" status (and still doesn't seem to have progressed beyond it).

The added feature implemented a performance optimization.

Let's not miss the opportunity to point a finger of blame at the RFC, which says " to make the extension as versatile as possible, an arbitrary payload and a random padding is preferred, ". https://tools.ietf.org/html/rf... Arbitrary payload and a random padding for a heartbeat instead of a specified sequence of bits? This is very suspicious.

There really ought to be a better way to handle this.

RFC822 has been obsoleted at least twice now. The current standard (RFC5322) says this about the origination headers:

The originator fields indicate the mailbox(es) of the source of the message. The "From:" field specifies the author(s) of the message, that is, the mailbox(es) of the person(s) or system(s) responsible for the writing of the message. The "Sender:" field specifies the mailbox of the agent responsible for the actual transmission of the message.

In other words, any mailing list that rewrites the From header field is wrong. It is also wrong for it to rewrite the Sender field, since the mailing list is not the "agent" responsible for the actual transmission of the message. It is only a transport agent, not an initiator. In the contextual history of RFC*22, the Sender is the person (secretary, e.g.) who sent the message when that person is not the author.

And, additionally: "In all cases, the 'From:' field SHOULD NOT contain any mailbox that does not belong to the author(s) of the message." While that's only a SHOULD not, it is still relevant and shows the intent of that header.

I've found the room full of horse droppings. I'm sure there's a pony around here somewhere. I'll let you ride him when I find him.

Really legit mailing lists should be rewriting the sender headers to reflect that the mail has been redelivered by the mailing list, the only difficulty this would cause is when users try to reply directly to messages rather than forwarding their replies to the list itself.

There really ought to be a better way to handle this.

And it really should be implemented properly everywhere. Oh, and I want a pony too.

Rather than get all aggro, I will state that I have tried to find a concrete answer to this question ("is OpenSSH vulnerable/impacted by this?"), and I still cannot. So before someone say "shut the fuck up when you don't know what you're talking about" to me, I'll provide the data (and references) I do have:

* OpenSSH links to the libcrypto.so shared library which is absolutely OpenSSL on most systems: ldd /usr/sbin/sshd followed by strings /whatever/path/libcrypto.so.X (you'll find OpenSSL references in there). Truth: because OpenSSH links to a cryptographic library that's part of OpenSSL doesn't mean it's necessarily using the code that's bugged (see below poster's sig and note function names are DTLS-related (keep reading)), but it also doesn't mean it isn't. When was the last time you ran truss/strace with all flags (for children, all syscalls, fd I/O, etc.) and looked at it closely?

* SSH, as a protocol, is not SSL (but keep reading): http://www.comforte.com/solutions/tls-vs-ssh/ and http://stackoverflow.com/questions/723152/difference-between-ssh-and-ssl (see replies to primary thumbs-up'd answer)

* However, SSH does rely on at least some part of TLS, the one that's known is X.509 (a form of PKI) (but keep reading): http://www.snailbook.com/faq/ssl.auto.html

* ...but then things like this seem to imply the OpenSSH folks don't use X.509 at all and that you have to run a special OpenSSH build for this to work: http://security.stackexchange.com/questions/30396/how-to-set-up-openssh-to-use-x509-pki-for-authentication

* ...but then you find things like this which are open-ended and seem to imply otherwise (and the link mentioned on that blog, by the way, is also worth skimming/reading to see what's being done): http://trueg.wordpress.com/2012/09/06/use-an-x-509-certificate-for-ssh-login/

* The "heartbleed" bug, which refers to RFC 6520, pertains to TLS: http://www.snailbook.com/faq/ssl.auto.html (yes same link)

* There are repeated/continual news references to "use of X.509" (which could apply to either SSH or SSL from the above references) in every single news announcement. I shouldn't need to link them all.

There is nothing even remotely definitive on either the OpenSSL or OpenSSH mailing list, and that's a bit shocking if you ask me. Therefore, to me, the OP's question is quite valid.

Does the answer to his/her question change the severity of the situation? Yes it does. Yes you should still upgrade OpenSSL, but what some of us senior system administrators are trying to figure out is whether or not we need to inform every employee that they need to generate new SSH keys. I think everyone at this point is aware webservers (ex. nginx, Apache, etc.) doing SSL need to have OpenSSL upgraded + the daemons restarted + keys re-generated + re-signed, but the concern here is whether or not any part of OpenSSH's function calls into the OpenSSL crypto library rely on anything related to RFC 6520.

My opinion: the reason nobody has definitive answer with references (and I hope this Slashdot post induces such) is because there's a serious disconnect between using security-focused software (end-users, SAs, companies using security software, etc.), the writing of cryptographic algorithms (cryptologists), and ac

GnuPG implements RFC4880. See also the OpenPGP alliance. GnuTLS implements SSL, TLS and DTLS. See also OpenSSL and PolarSSL.

Your userland software may or may not link against GnuTLS. It's probably more likely to link against OpenSSL.

It's important to understand the mechanisms involved with software that provides facilities for securing information both locally and in transit to others. It's nearly as important to do a bit of research on said mechanisms before engaging in discussions on them.

You could also set up some kind of DMZ where you use a router with firewalling capabilities between broadband and your home network. This gives you some security now while you are still experimenting. Also it is a good idea to not trust your router and set up your own firewall in addition to it. Beyond that you may also protect us from your experiments that way.

You can also try to scan/hack your internal firewall with tools like nmap to see how it is holding up. Here is a list of a few links:
http://www.ietf.org/rfc/rfc791...
http://www.netfilter.org/index...
http://nmap.org/
http://www.wireshark.org/

Also there is user friendly in case you have been missing it so far, http://ars.userfriendly.org/ca...

I think Mozilla needs to be cleaned of moles and it seems "Eric Rescorla" is one of them, and look where he is active:

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

-- snip from reuters story -- .. Information Assurance Directorate, and an outside expert named Eric Rescorla.

Rescorla, who has advocated greater encryption of all Web traffic, works for Mozilla, maker of the Firefox web browser. He and Mozilla declined to comment. Salter did not respond to requests for comment.
-- snip --

So... mobile apps aren't a real-world scenario? You know, where cert pinning is used *all the time* because the same developer provides both client and server? You know, the entire context of this discussion?

Do you even *try* and think before posting bullshit on the Internet?

By the way, it is entirely possible to implement public key TOFU in browsers. It's called HTTP Public Key Pinning. Chrome is already supporting it, I believe. It could also be achieved through browser extension/plugin pretty easily.

Not drones, pidgeons. http://tools.ietf.org/html/rfc...

Looks like all their doing is storing an encryption key on a separate hardware component and offloading all operations requiring said key to hardware. Isn't this what TPM already does? Why reinvent the wheel?

See also
http://tools.ietf.org/html/dra...

"our only method of communicating to the outside world is over their network"

Do you live in the middle ages? If convicts can get cellphones into prison, I'm sure you have access to one. Also there is always ip over semaphore.

http://tools.ietf.org/html/rfc...

https://www.ietf.org/rfc/rfc42...

Cryptographically they are just as secure as each other (why you need the libraries from OpenSSL for OpenSSH), but it's the implementation that suffers.

I wish ICANN would finally give us some real "reserved" internal TLDs, but we do have a few we can work with:
RFC 2606 https://tools.ietf.org/html/rf...
      test, example, invalid, localhost
"gTLD Applicant Guidebook", Section 2.2.1.2.1 "Reserved Names" http://newgtlds.icann.org/en/a...
      afrinic, iana-servers, nro, alac, icann,
      rfc-editor, apnic, iesg, ripe, arin, ietf,
      root-servers, aso, internic, rssac, ccnso,
      invalid, ssac, example*, irtf, test*, gac,
      istf, tld, gnso, lacnic, whois, gtld-servers,
      local, www, iab, localhost, iana, nic

Most of those aren't really suitable for internal network names except perhaps "tld" and "local" but we can't use "local" because of multicast dns... but that RFC does reference some other names we're PROBABLY safe to use:
RFC 6762 http://tools.ietf.org/html/rfc...
      intranet, internal, private, corp, home, lan

It'd be great if we could just get the alternate example domains from RFC 6762 explicitly reserved.

I wish ICANN would finally give us some real "reserved" internal TLDs, but we do have a few we can work with:
RFC 2606 https://tools.ietf.org/html/rf...
      test, example, invalid, localhost
"gTLD Applicant Guidebook", Section 2.2.1.2.1 "Reserved Names" http://newgtlds.icann.org/en/a...
      afrinic, iana-servers, nro, alac, icann,
      rfc-editor, apnic, iesg, ripe, arin, ietf,
      root-servers, aso, internic, rssac, ccnso,
      invalid, ssac, example*, irtf, test*, gac,
      istf, tld, gnso, lacnic, whois, gtld-servers,
      local, www, iab, localhost, iana, nic

Most of those aren't really suitable for internal network names except perhaps "tld" and "local" but we can't use "local" because of multicast dns... but that RFC does reference some other names we're PROBABLY safe to use:
RFC 6762 http://tools.ietf.org/html/rfc...
      intranet, internal, private, corp, home, lan

It'd be great if we could just get the alternate example domains from RFC 6762 explicitly reserved.

I'm not a video expert, but I did write an H.261 codec once.

I don't think it's practical in a VP9 decoder to save time by cutting quality. The Huffman decoding stuff all needs to be bit-exact. The DCT is pretty standard; you would just get a fast implementation of DCT and use that.

I suppose you could sleaze the mixing and filtering steps but the results would probably be so horrible that nobody would want to see it... part of how video decoding works is to refer back to previously-decoded images. The way "motion compensation" works is to say "this block is like this other block over here, but moved over by x pixels horizontally and y pixels vertically and with a few pixels updated". This means that if you sleaze the decode, it can have an effect on later frames.

(H.261 could only do motion compensation that referenced the previous frame. VP9 has 8 different reference buffers and any one frame can encode references to up to three of them! And they'd all better contain properly decoded images.)

So, my guess is that they just did a great job of tuning their code and the quality is good.

Also, the spec says that VP9 was deliberately designed to enable parallel decoding; maybe the FFMPEG implementation takes advantage of that. See section 3.2.1, "Frame-Level Parallelism".

http://tools.ietf.org/html/draft-grange-vp9-bitstream-00

This is also from the *actual* draft:

7. Privacy Considerations

Notice how it's empty? The author(s) plainly don't give two hoots about use privacy.

What proxy would you trust with your banking details? Because this spec will let them see your private conversations with third parties including banks. Weinstein is correct to be worried about this proposal. However, this is not an IETF document. The IETF isn't trying to do anything here. This is a document some people have floated in the IETF. As written, I don't see it getting traction, because it's in violation of existing IETF policy.

That's not what Netflix is doing though, it's not what anyone is doing. It's what usenet used to do back when every ISP ran a usenet server.

Netflix CDN, like every other CDN, only cache's content for the content providers under it's umbrella (typically the one's who pay). What is needed is an internet architecture with more local caches which cache content from ANY content provider. The content itself can be encrypted, and only decryptable with a key sent directly to the user form the content originator.

In fact this is the exact problem statement in RFC6707 and their is an active engineering effort to solve this problem (CDNIWG):

Content Delivery Networks (CDNs) provide numerous benefits for
      cacheable content: reduced delivery cost, improved quality of
      experience for End Users, and increased robustness of delivery. For
      these reasons, they are frequently used for large-scale content
      delivery. As a result, existing CDN Providers are scaling up their
      infrastructure, and many Network Service Providers (NSPs) are
      deploying their own CDNs. It is generally desirable that a given
      content item can be delivered to an End User regardless of that End
      User's location or attachment network. This is the motivation for
      interconnecting standalone CDNs so they can interoperate as an open
      content delivery infrastructure for the end-to-end delivery of
      content from Content Service Providers (CSPs) to End Users. However,
      no standards or open specifications currently exist to facilitate
      such CDN Interconnection.

      The goal of this document is to outline the problem area of CDN
      Interconnection for the IETF CDNI (CDN Interconnection) working
      group.

Well, there is this working group and the introductory RFC6707, which outlines pretty much the exact problem you identify, in a much calmer and more effective manner.

Well, there is this working group and the introductory RFC6707, which outlines pretty much the exact problem you identify, in a much calmer and more effective manner.

They're wrong.

Misfeatures of UPnP: A) only for IPv4/NAT gateways; B) proprietary specification; C) defined as profile of SOAP over UDP (so very wide attack surface); D) allows every client to make 3rd-party port maps by default (so very insecure by design).

Corrections in PCP A) works for IPv4/NAT and IPv6 gateways (NAT and w/o NAT); B) open IETF specification; C) defined as simple binary protocol (so very narrow attack surface); D) disallows 3rd-party port maps unless optional extension implemented (so less insecure by design).

You need something that does this if you have a firewall (whether there is NAT or not). If you have an IPv6 gateway, then see RFC 6092 section 3.4 Passive Listeners for an explanation. That RFC is referenced by CableLabs and BBF specs, so it is what you should expect to see in most provider-provisioned home gateways in the near future.

Seriously, PCP is what you need to use for this. Does this suck? Maybe. Depends on whether you think having firewalls everywhere denying all inbound traffic to passive listeners by default is a good idea. If you think that's a good idea, then PCP doesn't suck. Deal with it.

> So how do you propose that my game on a machine on NAT arranges to receive UDP through the firewall? I'm supposed to manually configure firewall rules for each game? And then change them all if my IP changes?

Ladies and gentlemen, I give you Port Control Protocol [RFC 6887].

The spec actually explicitly says that users should get (or at least be able to get) more than a /64.

Our experience some time ago building (Sun) gear for theatre display and provisioning was that the protocols were fine, but there were a lot of botches in the software supposedly implementing them (:-))

The absolute worst was in the software in the projector, but the routers of the day kept getting in our way. Being biased, we preferred to use our own servers for routing, and even there the software wasn't everything we needed. We, and several other people, started off on efforts to do routing differently, some of which now exist (crossbow, software defined networks, etc).

The same observations have returned as of last year: the "bufferbloat" investigation has exposed exactly what you report: router software over-optimized for throughput and avoidance of buffer overflow. In reality good throughput, minimal overflows and minimal delay/jitter comes from paying attention to latency. There's a discussion at http://tools.ietf.org/id/draft... which I helped a little bit with. As we speak, the bufferbloat community is working on draft RFCs for advanced queue management, the second step towards getting this fixed. There's a meeting scheduled for IETF89, March 2-7, 2014 in London.

In your specific case, your jitter buffer needs to be bigger in seconds than the ^#&$^&*@!! largest queue that builds up in the path between your source and sink, and the software in between needs to get its queue and therefor buffer use down close to one packet (or packet-train). This is measurable, by the way, and described a couple of places in the discussions at https://lists.bufferbloat.net/...

I'll claim that in principle it's easy, and in practice a pain in the ass (:-))
If it weren't being fixed, I'd have exactly the same opinion as you do!

RFC2474, which was one of the earliest standards published for differentiating traffic (thus enabling QoS/Traffic-shaping) wasn't even published until December 1998. So the technology enabling the death of "best effort" routing and thereby network "neurtrality" wasn't even properly DEFINED until almost 1999, much less available in market ready production quality switching and routing equipment. Let's not pretend spiking network neutrality was even viable in the early 80s, throughout the 90s, or even into the mid 2000s. It wasn't until the mid-2000s before QoS became viable. And lo and behold, that's about the time network neutrality became a topic of discussion.

But the reason ISPs haven't implemented prioritized traffic based on who's paying them premiums is because the ISPs have been busy maximizing profit based on the original business model while they build the infrastructure (from the actual capability of traffic shaping to identifying which/whose traffic to shape, to tying it all into billing and support systems) they'll need to do so.

Now that returns are leveling off in the old business model, and the infrastructure is in place to allow them to charge Netflix, et. al., more to carry their traffic, they will use the avenues to continue bringing in more money if allowed. It's obvious and simple, really: QoS-ing someone's traffic into oblivion unless they pay to get onto the higher priority tier will be the new normal because (a) the technology is mature enough now, and (b) mo' money, mo' money!

What I have never understood is: why has no one redesigned IPv6 in such a way as to be backwards compatible as possible with IPv4?

The key to solving IPv4 exhaustion is rooted in deeper understanding of ternary logic :)

http://tools.ietf.org/html/dra...

http://tools.ietf.org/html/dra...

Wide and easy adoption of any new technology requires backward compatibility.

Unless of course there is no other operationally viable solution.

Wide and easy adoption of any new technology requires backward compatibility. IPv6 is not even slightly backwards compatible.

When I browse to YouTube I connect via IPv6 and it works fine. When I go to that same website and I don't have IPv6 I reach it via IPv4 and it still works.

I know every v6 hater thinks there just **MUST** be some clever way to solve the pigeonhole problem or construct some magical overlay network that is better than deploying IPv6. Must have heard them all by now. Meanwhile in the real world IPv6 adoption is following exponential growth curve.

If you have one IPv4 application on the entire network, then you pretty much have to keep IPv4.

Who is saying get rid of IPv4? Just add IPv6 and call it a day.

What I have never understood is: why has no one redesigned IPv6 in such a way as to be backwards compatible as possible with IPv4?

The key to solving IPv4 exhaustion is rooted in deeper understanding of ternary logic :)

http://tools.ietf.org/html/dra...

http://tools.ietf.org/html/dra...

Wide and easy adoption of any new technology requires backward compatibility.

Unless of course there is no other operationally viable solution.

Wide and easy adoption of any new technology requires backward compatibility. IPv6 is not even slightly backwards compatible.

When I browse to YouTube I connect via IPv6 and it works fine. When I go to that same website and I don't have IPv6 I reach it via IPv4 and it still works.

I know every v6 hater thinks there just **MUST** be some clever way to solve the pigeonhole problem or construct some magical overlay network that is better than deploying IPv6. Must have heard them all by now. Meanwhile in the real world IPv6 adoption is following exponential growth curve.

If you have one IPv4 application on the entire network, then you pretty much have to keep IPv4.

Who is saying get rid of IPv4? Just add IPv6 and call it a day.

I doubt anyone cares, but this is the RFC for IP6's architecture. https://www.ietf.org/rfc/rfc35...

There is no patent-unencumbered video codec worth using.

That might be technically true... Google owns the patents on VP8. But since they've offered an irrevocable perpetual royalty free license to the entire world, it's unencumbered for all reasonable, practical purposes.

When Google open-sourced their hopeless purchase, the extent of the scam became apparent.

VP3 was open-sourced over a decade ago, and no lawsuits ever came out of that. Are you suggesting On2 only RECENTLY started stealing MPEG patents? When exactly? And let's not forget that VP9 was not developed until years after Google acquired On2, and just recently released.

What did Google do? Simple- it used its insane cash reserves to strike behind-the-scenes deals with the patent owners, paying the for right to use those patents in non-disclosure agreements.

All of H.264's patents must be worth many billions of dollars over their lifetime. If Google had paid out anything like that, it would be obvious from stock prices, SEC filings, etc., etc. Instead, Google paid a piddly little amount to MPEG-LA, and it's they who wanted the NDA to save face. MPEG-LA argued for years that they owned patents that covered VP8, yet after years only came up with a very short-list, and still most of that was found laughably irrelevant. H.264 is covered by THOUSANDS of patents, by HUNDREDS of companies. The deal Google entered into only involved 11 of those hundreds of companies, yet that was enough to get MPEG-LA to declare full stop on any harassment of VP8.

The reality:
"This agreement is not an acknowledgment that the licensed techniques read on VP8. The purpose of this agreement is meant to provide further and stronger reassurance to implementors of VP8."

http://www.ietf.org/mail-archi...

In fact, the MPEG-LA's posturing was being investigated by the DoJ as anticompetitive behavior:

http://arstechnica.com/tech-po...

Google NEVER denied its video codec purchase was a rip-off (and a bad one at that) of H264.

Yes they did. They even did so in court, and they unequivocally WON:

http://blog.webmproject.org/20...

1) Google's fake free codec uses insanely more amounts of energy to decode and display video.

This is straightforward to disprove.
An x264 developer said of the first version of libvpx decoding:

"the current implementation appears to be about 16% slower than ffmpeg's H.264 decoder"

http://x264dev.multimedia.cx/a...

But since then, numerous performance improvements have been performed:

http://x264dev.multimedia.cx/a...

2) Google's fake free codec has the tiniest fraction of hardware support than is enjoyed by H264. Every modern device decodes H264 in efficient hardware

Actually, hardware acceleration isn't a big deal. The difference between VDPAU and software decoding of 1080 video on my PC is just a few percentage points. When my phone switches from hardware to software decoding (you can force this with "Mobo Player"), the performance and power difference is very small, and goes almost completely unnoticed. Hardware acceleration mattered a lot when mobile devices ran with 35MHz CPUs, but today, it makes a very tiny difference.

For the same quality, x264 video files are less than HALF the size of videos produced for Google's fake free codec.

Back in 2010 when comparing the just introduced an

In case anybody thinks you are exaggerating: FTP was designed back in 1971. These companies are using a protocol with terrible security because it wasn't designed to be used on the public Internet - because the Internet wasn't even invented back then.

Anybody who seriously suggests FTP in this day and age needs to be told in no uncertain terms that this is an obsolete, pain in the arse protocol that should have died a long time ago.

So they had ".com" = corporations/companies, ".org" = non-profit organisation, and ".edu" for the educational research groups, ".mil" for the military", and ".net" for the companies that managed the continent wide networks built from fibre-optics and satellite communications.

.com is derived from the word "commerical" which includes but is not limited to corporations and companies.

Back in 1985 when .net was created I don't think there was "continent wide networks built from fibre-optics". .net was intended for network technology companies, ISPs (local, national and international) and infrastructure companies. Although, no restrictions were put on it's use so it has become a general purpose name.

I was at Novell at the time during which the protocol basis for the commercial Internet was being decided. Novell was attempting to swing a deal with AT&T to get them to deploy a commercial network topology based on SPX/IPX; at the same time, Microsoft was attempting to get AT&T and Sprint, and whoever else they could get on board, to deploy a commercial network based on NetBIOS/NetBEUI.

It has been some time since I worked with both IPX and NetBEUI, but AFAIK they are single-segment protocols

Correct about NetBIOS and NetBEUI/NetBIOS Frames protocol or whatever you want to call it; incorrect about IPX, which is routable and is routed. And NetBIOS (the service) can also operate atop IPX as well as operating atop TCP/UDP.

based on broadcast.

Host/service-name-to-address lookup is done in NetBIOS Frames protocol using broadcasts. That's not the only way to do it with NetBIOS-over-TCP; it might not be the only way to do it with NetBIOS-over-IPX either.

(Terry, was Microsoft talking about using NBF? That probably deserved to die, for the reasons mentioned.)

I was at Novell at the time during which the protocol basis for the commercial Internet was being decided. Novell was attempting to swing a deal with AT&T to get them to deploy a commercial network topology based on SPX/IPX; at the same time, Microsoft was attempting to get AT&T and Sprint, and whoever else they could get on board, to deploy a commercial network based on NetBIOS/NetBEUI.

It has been some time since I worked with both IPX and NetBEUI, but AFAIK they are single-segment protocols

Correct about NetBIOS and NetBEUI/NetBIOS Frames protocol or whatever you want to call it; incorrect about IPX, which is routable and is routed. And NetBIOS (the service) can also operate atop IPX as well as operating atop TCP/UDP.

based on broadcast.

Host/service-name-to-address lookup is done in NetBIOS Frames protocol using broadcasts. That's not the only way to do it with NetBIOS-over-TCP; it might not be the only way to do it with NetBIOS-over-IPX either.

(Terry, was Microsoft talking about using NBF? That probably deserved to die, for the reasons mentioned.)

For the record, I think my text search is broken; I can't find the word "verb" there anywhere. =)
http://www.ietf.org/rfc/rfc261...

Is .lan reserved yet? .local wasn't even reserved (despite people using it) when I proposed .here years ago. And now though .local is reserved (as of last year) it has a slightly different usage in practice from what I proposed so .here could still be useful.

Compare:
https://en.wikipedia.org/wiki/...
vs
http://tools.ietf.org/html/dra...

Actually, I believe I have found the answer to this question, and have done so by googling: Read the Request for Comments from the Internet Engineering Task Force, then get back to me in a couple of years. Have a nice read and hope to see you in the new job!

• RFC 5737: IPv4 Address Blocks Reserved for Documentation - 192.0.2.*, 198.51.100.*, and 203.0.113.*
• RFC 3927: Dynamic Configuration of IPv4 Link-Local Addresses - 169.254.*.*
• RFC 1918: Address Allocation for Private Internets - 10.*.*.*, 172.16.*.* thru 172.31.*.*, and 192.168.0.* thru 192.168.255.*

Including numbers greater than 255 just makes it look obviously fake.

• RFC 5737: IPv4 Address Blocks Reserved for Documentation - 192.0.2.*, 198.51.100.*, and 203.0.113.*
• RFC 3927: Dynamic Configuration of IPv4 Link-Local Addresses - 169.254.*.*
• RFC 1918: Address Allocation for Private Internets - 10.*.*.*, 172.16.*.* thru 172.31.*.*, and 192.168.0.* thru 192.168.255.*

Including numbers greater than 255 just makes it look obviously fake.