Slashdot Mirror

Please look at this tzdist internet draft which is close to becoming an RFC. The tzdist protocol can communicate the list of leap seconds along with the list of time zones.

I will never understand why the 'evil bit' wasn't set on their systems.

> I've seen software writers follow RFC and ONLY RFC for communications protocols [...] anything not explicitly expected per the newest standard of RFC will cause the daemon to crash hard.

Then they aren't really following the RFCs, especially not the robustness principle, stated in RFC1122, a.k.a. Postel's Law.

Throw the book at them. All of the RFCs. Hardbound.

I'm glad to see IPv6 adoption growing, and that one of my home ISPs now provides IPv6 that the router I have connected to it autoconfigures without too much digging, but some of your points aren't meaningful to a "non-technical end user", and some aren't a clear benefit of only IPv6...

• - All protocols work over IPv6, unlike the breakage on IPv4. What's a "protocol"?
• - IPv6 "just works" without user setup, great autoconfiguration. Same could be said for IPv4 (plus UPnP, etc.) configured by DHCP behind a typical NAT device. And I've had to do a lot of tinkering to get IPv6 to work, although it's getting better.
• - As many public IP addresses as you want for devices on IPv6. What's a "public IP address"?
• - Safer because network security is built into IPv6, not optional. Not true. You can still run cleartext protocols (including telnet, plain HTTP, etc.) over IPv6. Some IPv6 RFCs may mention IPsec, but you can run IPsec over IPv4 or IPv6 about equally well.
• - Add IPv6 to see the whole Internet, not just the IPv4 part. Which is nonexistent right now, except for URLs used by the JavaScript in "Test your IPv6" pages. (There may be large private IPv6 networks out there, as well, but you can't see those just by "adding" IPv6.)
• - New quality of service features for stutter-free video or gaming. You mean DSCP, which is also defined for IPv4?
• - Faster networking for a better all-round user experience. Possibly. For applications like Skype or player-to-player gaming, in situations where both users had a NAT device without UPnP or other traversal support, the service provider's server will no longer be a potential bottleneck, and RTT should be reduced. For BitTorrent, users would already have been using NAT traversal or port-mapping, so no real change. For the all the client/server stuff, maybe a router could be designed with a faster fast-path for IPv6, but are such devices in wide use yet? Or will they be within the next 10 or even 15 years?

I assume you're kidding but, regardless, for anyone who reads this and asks the same question, there is no source. It's a protocol and there are many HTTP stacks that can use it but you cannot actually compile HTTP. There never has been source to compile and there never will be. It's not a program.

The protocol is open and anyone can write a HTTP communications stack. For more information on the protocol, read the RFC 1945, RFC 6265, RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234 and RFC 7235.

I assume you're kidding but, regardless, for anyone who reads this and asks the same question, there is no source. It's a protocol and there are many HTTP stacks that can use it but you cannot actually compile HTTP. There never has been source to compile and there never will be. It's not a program.

The protocol is open and anyone can write a HTTP communications stack. For more information on the protocol, read the RFC 1945, RFC 6265, RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234 and RFC 7235.

I assume you're kidding but, regardless, for anyone who reads this and asks the same question, there is no source. It's a protocol and there are many HTTP stacks that can use it but you cannot actually compile HTTP. There never has been source to compile and there never will be. It's not a program.

The protocol is open and anyone can write a HTTP communications stack. For more information on the protocol, read the RFC 1945, RFC 6265, RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234 and RFC 7235.

I assume you're kidding but, regardless, for anyone who reads this and asks the same question, there is no source. It's a protocol and there are many HTTP stacks that can use it but you cannot actually compile HTTP. There never has been source to compile and there never will be. It's not a program.

The protocol is open and anyone can write a HTTP communications stack. For more information on the protocol, read the RFC 1945, RFC 6265, RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234 and RFC 7235.

I assume you're kidding but, regardless, for anyone who reads this and asks the same question, there is no source. It's a protocol and there are many HTTP stacks that can use it but you cannot actually compile HTTP. There never has been source to compile and there never will be. It's not a program.

The protocol is open and anyone can write a HTTP communications stack. For more information on the protocol, read the RFC 1945, RFC 6265, RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234 and RFC 7235.

I assume you're kidding but, regardless, for anyone who reads this and asks the same question, there is no source. It's a protocol and there are many HTTP stacks that can use it but you cannot actually compile HTTP. There never has been source to compile and there never will be. It's not a program.

The protocol is open and anyone can write a HTTP communications stack. For more information on the protocol, read the RFC 1945, RFC 6265, RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234 and RFC 7235.

I assume you're kidding but, regardless, for anyone who reads this and asks the same question, there is no source. It's a protocol and there are many HTTP stacks that can use it but you cannot actually compile HTTP. There never has been source to compile and there never will be. It's not a program.

The protocol is open and anyone can write a HTTP communications stack. For more information on the protocol, read the RFC 1945, RFC 6265, RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234 and RFC 7235.

I assume you're kidding but, regardless, for anyone who reads this and asks the same question, there is no source. It's a protocol and there are many HTTP stacks that can use it but you cannot actually compile HTTP. There never has been source to compile and there never will be. It's not a program.

The protocol is open and anyone can write a HTTP communications stack. For more information on the protocol, read the RFC 1945, RFC 6265, RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234 and RFC 7235.

TCP/IP is the name of the protocol suite that includes UDP. UDP is a subset of TCP/IP. TCP is a subset of TCP/IP. UDP/IP doesn't exist.

There's no UDP in TCP -- UDP is a completely different (and much simpler) protocol.

Here's the UDP RFC:

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

One possible UDP/IP interface would return the whole internet datagram
including all of the internet header in response to a receive operation.

Both UDP and TCP are transport layer protocols built on top of the IP Network Layer, you can have UDP without TCP, and TCP without UDP. They don't even require IP, you could build them on top of a different network layer.

Only if it's HTCPCP compliant.

When it's your job to catch bad guys, everyone starts looking like a bad guy. And then after a while you think that only bad guys use encryption, because good people don't have anything to hide. Soon you think it's okay to read everyone's personal communications without a warrant "for the greater good."

He probably also thinks the evil bit is an excellent idea.

Bad guys have to set the evil bit; the software checks whether or not it's set. Really people, we've thought this through.

Relevant RFC

You know, it's been years since I actually read that. The basic concept is funny, obviously, but the author took it much further. I'd forgotten such gems as:

Because NAT [RFC3022] boxes modify packets, they SHOULD set the evil bit on such packets.

Indeed, NAT boxes really should mark all their packets as evil, because NAT is evil.

Oh, I also quite enjoy:

In networks protected by firewalls, it is axiomatic that all attackers are on the outside of the firewall. Therefore, hosts inside the firewall MUST NOT set the evil bit on any packets.

Oh, obviously. If you have a firewall, every host inside the firewall is perfectly safe. BWAHAHA...

Bad guys have to set the evil bit; the software checks whether or not it's set. Really people, we've thought this through.

Relevant RFC

But Post Office (RFC1939) was superseded by IMAP (RFC3501).

But Post Office (RFC1939) was superseded by IMAP (RFC3501).

Every cloud service should have a checkbox asking the user [x] are you a terrorist, and deny them access if so. Solved.

They should also make sure to implement RFC 3514, too.

RTP/RTSP (RCFCs http://www.ietf.org/rfc/rfc1889.txt 1889 and https://tools.ietf.org/html/rfc2326 2326, respectively) have been around since the 1990s, while youtube didn't come around until this century.

RTP/RTSP (RCFCs http://www.ietf.org/rfc/rfc1889.txt 1889 and https://tools.ietf.org/html/rfc2326 2326, respectively) have been around since the 1990s, while youtube didn't come around until this century.

This is why: https://tools.ietf.org/html/rf...

Stanford Linear Accelerator Center? Small Liberal Arts College? You mean "stateless autoconfiguration", but it took until November 2010 for RFC 6106: Router Advertisement Options for DNS Configuration to bring DNS into Neighbor Discovery.

The BjÃntegaard metric is used to calculate the bitrate saving achieved by the test
encoders, based on the PSNR scores.

The problem with a lot of these studies is that the metrics don't always work that well. For example, look at the image comparison on pages 26, 27 and 28 in the NetVC presentation. The first codec on page 27 has a better PSNR score than Daala on page 28, yet to me the image compressed by Daala looks better and has more detail.

Daala's not ready yet but it's been proposed as the basis for the NetVC implementation. NetVC will probably end up being Daala merged with other contributions.

It could simply be that a few companies want to get more money from H.265.

I think it's this. The companies involved weren't satisfied with the licensing terms the MPEG LA had decided on so they formed a competing pool.

Whatever their motivations, it's exactly these licensing complications that make it clear that the best way forward for video on the Web is to develop a high quality, royalty-free codec that everyone will implement. A video codec that gets standardized through the Internet Engineering Task Force is more likely to the implemented by the likes of Apple and Microsoft than codecs developed internally at Google. NetVC aims to achieve that.

It could simply be that a few companies want to get more money from H.265.

I think it's this. The companies involved weren't satisfied with the licensing terms the MPEG LA had decided on so they formed a competing pool.

Whatever their motivations, it's exactly these licensing complications that make it clear that the best way forward for video on the Web is to develop a high quality, royalty-free codec that everyone will implement. A video codec that gets standardized through the Internet Engineering Task Force is more likely to the implemented by the likes of Apple and Microsoft than codecs developed internally at Google. NetVC aims to achieve that.

I can't find any info about NAK in IPv6, but this has been solved for over a decade in IPv4. https://www.ietf.org/rfc/rfc3514.txt

Daala is shaping up to be excellent as well, but its biggest competition may be VPx in the long run

It may be less competition and more coopetition. The NetVC working group has started in the IETF. Daala has been submitted to the standardization process. Maybe VP10 will be as well and maybe the result is ideas from both become the final version of NetVC, similarly to how the Opus audio codec is a combination of CELT from Xiph and SILK from Skype and standardized as IETF RFC 6726

Daala is shaping up to be excellent as well, but its biggest competition may be VPx in the long run

It may be less competition and more coopetition. The NetVC working group has started in the IETF. Daala has been submitted to the standardization process. Maybe VP10 will be as well and maybe the result is ideas from both become the final version of NetVC, similarly to how the Opus audio codec is a combination of CELT from Xiph and SILK from Skype and standardized as IETF RFC 6726

You mean like DANE?

The flaws in RC4 have been known about for a long time but were thought irrelevant in the scheme of SSL/TLS to the point where RC4 was the preferred cipher suit only a few years ago as it was one of the few that were able to mitigate the BEAST attack. So the GP's comment that there's no surprise since RC4 has been known to be weak for a decade isn't quite the full story.

It was only in 2013 where RC4 became strictly taboo for use in SSL/TLS with the exposure of new exploitable vulnerabilities on top of the several previous weaknesses identified, and last month RFC7465 effectively banned the cipher's use in TLS.

You could just check yourself
http://tools.ietf.org/html/rfc...
http://tools.ietf.org/html/rfc...

You could just check yourself
http://tools.ietf.org/html/rfc...
http://tools.ietf.org/html/rfc...

We're talking at cross-purposes.

Possible, but I see you are factually wrong.

My view is that we shouldn't be identifying files manually AT ALL.

No one in the whole thread is advising identifying files manually. Different people are proposing file names, extensions, content etc. all non-manually / automatically / programmatically / transparently to the end user.

They should be part of the meta-data, as already is whenever you download a file. Just because it ends in .docx doesn't mean it's sent to you as application/microsoftworddocument (or whatever it is) by your browser. In fact, you can break stuff easily that way if you don't populate your webserver with proper mimetypes

And I never said putting this information in file name is a good strategy, so why you litter your post with such irrelevant content is beyond me. This is why I read but am not addressing more than half of this post of yours too.

In fact, you can break stuff easily that way if you don't populate your webserver with proper mimetypes.

I got it. You are among the proponents of evil bit. I agree information security is trivial once we get all the evil people to set this evil bit. Real life is not so simple - web servers areone of the least trustworthy elements in a typical user's computing life.

But from that point on, we don't NEED to ever identify a file again

In RFC 3514 world, yes. In real life, this "metadata" will need to be edited, or distrusted. So we do need to identify a file. In the face of this imperfect world, there are certain difficulties. Whether it is a perl script or a jpeg image can best be figured out from looking at file content.

NOT from file name.
NOT from metadata set by untrustworthy people.

What is sad is that OpenSSL disabled the EXPORT1024 ciphersuites in 2006. If you don't know what these are, in year 1999 the US government raised the limit to 56-bit encryption and 1024-bit RSA. They were described in https://tools.ietf.org/html/dr... . And for the record it was in year 2000 that the restrictions was removed for "retail" software.

I think .dev should be like example.com: not able to register so DEVELOPERS (re: NOT GOOGLE) can use like, [mydomain].dev to develop, and not have to create wonky local host names.

RFC 2606 reserves 4 TLDs for this purpose: .test .example .invalid .localhost

I've always used .test for domains for QA/test deployments. It also reserves the example.* second level domain name across all TLDs.

I think there are some other reserved TLDs, including ".xy" and some 63-character name that was something like "sixtythreecharacterdomainnamefortestingpurposes" , but I can't find the RFC. Anyone?

That was the fault of Cogent, not Comcast, under their peering arrangement not exchanging data symmetrically. That had nothing to do with Net Neutrality and everything to do with Netflix taking 1/3rd of Internet traffic on top of bad routing.

Netflix was not uniquely targeted. The proposed FCC rules would have done jack.

http://tools.ietf.org/html/rfc... may also be of interest.

What?

Read it and learn:

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

.
      SPDY ... showed worse average performance than HTTPS
      when packet loss was 1% (average gain 0.9). This effect was more
      pronounced in the large RTT cases as compared to the small RTT. This
      result points to a weakness in the way that SPDY utilizes TCP. With
      a typical HTTPS download of a web page, the browser will open a large
      number of simultaneous TCP connections. In this case, a random
      packet loss will cause the one affected connection to temporarily
      reduce its congestion window (and hence the effective data rate), but
      the other connections will be unaffected, and in fact may be able to
      opportunistically make use of the bandwidth made available by the
      affected connection. The result for HTTPS is that random packet loss
      has only a minor impact on page download time. In the case of SPDY,
      the number of parallel TCP connections is dramatically reduced (by as
      much as a factor of six), so that random packet loss has a much
      bigger impact on the overall throughput.

...but I have no doubt you will go on mindlessly parroting anything and everything Google says.

What? POST is the non-idempotent one. See the table in http://tools.ietf.org/html/rfc..., section 8.1.3

PGP has brought incredible value to people, and thus its inventor should be rewarded properly.

However, this person is not the inventor of PGP, Phil Zimmermann is. Koch just wrote an open source program that complies with the OpenPGP RFC. This is certainly valuable and I do think that the community receives sufficient benefit from this program to support it financially, but Koch isn't an inventor, he is a programmer that implemented a public standard.

which is how hosts rock for local resolution from RAM

OK, so a malware comes along and contacts a different C&C hostname every second 99.999% of them NXDOMAIN but one day the operator registers the right domain and that last request is the one that tells your computer to wipe its drive. You can defeat that, right? Krebs cracks the bot and comes up with the hash function to turn time -> hostname so you calculate all the hostnames for the next year and add 31536000 x 253-character hostnames to your hosts file (plus a space plus a zero plus a cr plus a lf, that comes out to 257 bytes per hostname) and now your file is 8104752000 bytes larger (~8GB).

The math is done.

P.S.=> YOU can't seem to grasp that once I have a hostname blocked in hosts

And you can't seem to grasp that with 253 characters a domain can contain somewhere around 10^350 hostnames. ".adserver.com" is 13 characters so that gives 1-240 characters a-z0-9-. to make as many hostnames as the ad company wants... except they don't have to do any work. They configure their domain server with "*.adserver.com", and they are done.

But hey, you know what? That's OK. You can keep on blocking google adwords and shitty botnets that don't use a timer to create a new C&C hostname every second. I've got nothing against that. Go forth and be happy!

All I'm offering is the truth. The rabbit hole goes deeper and the red pill will take you there. If you refuse to go deeper, take the blue pill and believe whatever you want.

IAX2

IAX was developed by the open source community for the
      Asterisk Private Branch Exchange (PBX) and is targeted primarily at
      Voice over Internet Protocol (VoIP) call control, but it can be used
      with streaming video or any other type of multimedia.

      IAX is an "all in one" protocol for handling multimedia in IP
      networks. It combines both control and media services in the same
      protocol. In addition, IAX uses a single UDP data stream on a static
      port greatly simplifying Network Address Translation (NAT) gateway
      traversal, eliminating the need for other protocols to work around
      NAT, and simplifying network and firewall management. IAX employs a
      compact encoding that decreases bandwidth usage and is well suited
      for Internet telephony service. In addition, its open nature permits
      new payload type additions needed to support additional services.

Effort has been underway for quite some time - by folks such as Vint Cerf, no less - to facilitate Internet over long delays. Surprisingly, there has been terrestrial (or aquatic) applications in the research as well, for example solar-powered sensor networks that can only transmit during daylight hours.

There's a nice overview architecture draft from 2003, especially interesting bits are in the routing section (12.3-12.4), see https://tools.ietf.org/html/dr... - the eventually published RFC https://tools.ietf.org/html/rf... has nowhere such interesting figures about routing between Earth and Mars :)

Anyway, the underlying arch is relying on putting a "bundle layer" between applications and transport, a layer 5 if you will - and the bundling will attempt to hide the long latencies. Naturally, for interactive applications this won't work, but for everything else why not...There are some implementations at http://www.dtnrg.org/wiki/Code.

Effort has been underway for quite some time - by folks such as Vint Cerf, no less - to facilitate Internet over long delays. Surprisingly, there has been terrestrial (or aquatic) applications in the research as well, for example solar-powered sensor networks that can only transmit during daylight hours.

There's a nice overview architecture draft from 2003, especially interesting bits are in the routing section (12.3-12.4), see https://tools.ietf.org/html/dr... - the eventually published RFC https://tools.ietf.org/html/rf... has nowhere such interesting figures about routing between Earth and Mars :)

Anyway, the underlying arch is relying on putting a "bundle layer" between applications and transport, a layer 5 if you will - and the bundling will attempt to hide the long latencies. Naturally, for interactive applications this won't work, but for everything else why not...There are some implementations at http://www.dtnrg.org/wiki/Code.

John Postel wisely said:

In general, an implementation should be conservative in its sending behavior, and liberal in its receiving behavior.

The same is true in human discussion. It is (generally) good to limit what you say to what will be acceptable (not overly offend) others, but at the same time accept that people may say things that you do not like. Being gratuitously rude about others and taking offence at trivia is the best way of starting fights.

That is not to say that there are people & ideas that do not deserve to have fun poked at, especially those that are intolerant of views other than their own or are hypocritical — this is the area that satirical magasines work in ... readers need to understand that and be more tolerant than they might do to others.

I completely disagree with the pope claiming that religious ideas need special protection. They do not. Their effects on huge numbers of people means that their ideas should be strongly tested, not above criticism. But: given his position, there is little else that he can say.

The biggest issue that's hit ntpd in the last year was the ease with which you could use the 'monlist' command for amplification attacks. This too was easily solved with a configuration change and in any event did not compromise the integrity of the servers running ntpd. It's symbolic of a larger problem that has hit other protocols (DNS) and which will never go entirely away until network operators get off their lazy asses and implement the recommendations of BCP38

IMO failure to implement BCP38 is no excuse for protocols to not sufficiently deal with the Internet as it exists today. Solution for DNS is the same solution previously applied to TCP to mitigate SYN exhaustion attacks.

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

All remaining deployed protocols susceptible to cheesy amplification attacks can and should be fixed regardless of status of BCP38. None of it is rocket science.

imo, when you go for that last nanosecond of accuracy as the highest priority

That's kind of the whole point of a timeserver. If you're just running a typical client that doesn't need precision there are a multitude of SNTP implementations that you can use, including the one built into Windows. If you're running something that demands precision or wish to share your time with others (random plug: NTP Pool) you're going to need a little bit more accuracy than that.

and lower the priority of writing secure software to the point where it is no longer a priority, then you have ntp.

ntpd has been around since the 80s. Contrast it against other system daemons that have been around that long (sendmail) and you'll see that it has a solid security record. The recent "exploits" only impacted a small subset of servers that were using the cryptographic functionality of ntpd, which is primarily used for remote management and peering relationships and was a non-issue for the lion's share of configurations. Configurations to work around the issues were released immediately and a patch to solve them entirely was available within days. What more do you want? This was all discussed on the NTP Pool mailing lists and the consensus was "meh." I'm not aware of any NTP server that has been compromised because of these exploits.

The biggest issue that's hit ntpd in the last year was the ease with which you could use the 'monlist' command for amplification attacks. This too was easily solved with a configuration change and in any event did not compromise the integrity of the servers running ntpd. It's symbolic of a larger problem that has hit other protocols (DNS) and which will never go entirely away until network operators get off their lazy asses and implement the recommendations of BCP38.

The Tao of IETF still mentions:
"We reject kings, presidents and voting. We believe in rough consensus and running code"
http://www.ietf.org/tao.html

Maybe it's just me, but might it apply here ?

Before the httpbis working group started looking at proposals for HTTP/2.0 SPDY was already implemented and deployed in the field by mutliple browser vendors, library builders for servers and several large websites. A bunch of research documents was written. And a protocol specification document draft existed. SPDY wasn't created in the open perse, but it was iterated with the help the community.

So the IETF WG let people suggest proposals:
http://trac.tools.ietf.org/wg/...

And then they voted.

SPDY got selected.

Also the SPDY draft was used as a basis for writing the new HTTP/2.0 draft.

Is anyone surprised ?

There might fundamental parts of the protocol which might have turned out differently if they would have gone through a open collaborative process.

But at first glace it doesn't look that bad.

I can see the appeal of rubberstamping what already exists.