Slashdot Mirror

An anonymous reader writes: Researchers have discovered that improperly configured TFTP servers can be easily abused to carry out reflection DDoS attacks that can sometimes have an amplification factor of 60, one of the highest such values. There are currently around 600,000 TFTP servers exposed online, presenting a huge attack surface for DDoS malware developers. Other protocols recently discovered as susceptible to reflection DDoS attacks include DNSSEC, NetBIOS, and some of the BitTorrent protocols.

An anonymous reader writes with news that the IETF has adopted a policy of designing new protocols taking into account the need to mitigate pervasive monitoring of all traffic. From the article: "...RFC 7258, also known as BCP 188 (where BCP stands for 'Best Common Practice'); it represents Internet Engineering Task Force consensus on the fact that many powerful well-funded entities feel it is appropriate to monitor people's use of the Net, without telling those people. The consensus is: This monitoring is an attack and designers of Internet protocols must work to mitigate it."

higuita writes "With faster technologies showing up everyday, people need to prepare in advance the problems of faster-than-light communication. The main problem is that packages will arrive to the destination before they are sent, forcing a huge redesign of most protocols. Read here the first draft RFC. Any network expert is free to help fine tune this draft."

kdawson writes "Software developer and blogger Ben Strong did a little exploring to find out how Google achieves its admirably fast load times. What he discovered is that Google, and to a much greater extent Microsoft, are cheating on the 'slow-start' requirement of RFC-3390. His research indicates that discussion of this practice on the Net is at an early, and somewhat theoretical, stage. Strong concludes with this question: 'What should I do in my app (and what should you do in yours)? Join the arms race or sit on the sidelines and let Google have all the page-load glory?'"

An anonymous reader writes "A new RFC has been published this morning to significantly speed the deployment of IPv6. With IPv6 over Social Network (IPoSN), '[e]very user is a router with at least one loopback interface,' and 'Every friend or connection between users will be used as a point-to-point link.' It is noted that latency on the network can be very high, though."

PoesRaven writes "An A. Farrel has put out a Request For Comments paper on a new routing protocol with profound implications for the internet, the usability of the TCP/IP protocol, and the security of the net's youngest users. From the RFC: "It has often been the case that morality has not been given proper consideration in the design and specification of protocols produced within the Routing Area. This has led to a decline in the moral values within the Internet and attempts to retrofit a suitable moral code to implemented and deployed protocols has been shown to be sub-optimal." Interesting, but seems to raise some serious privacy questions.

solidox writes "There is a new RFC discussing the Omniscience Protocol. It proposes that every computer be installed with an OP Client which would allow law enforcement ('Good guys.') and copyright holders (RIAA, MPAA) to remotely destroy the computer of any user who has been involved in copyright infringement ('evil-doer'). The client will be completely undetectable and unremovable by even the most skilled hacker. It also must be able to report to the server at any time. 'The OP must be able to communicate through uncooperative firewalls, NATs, and when the computer is disconnected from the Internet.' So if your computer randomly blows up in the next while, you can put the blame on this."

Stanislav Shalunov writes "Jean-Luc Cooke posted a Usenet article describing a distributed webpage-based effort (Chinese Lottery) to find a collision in the MD5 function. All you need to do to participate in the effort is visit the URL that loads the code. The author comments: 'What is interesting about this approach - when we reach final release stage - is that any website that adds this small snippet of code to their pages will have their visitors working on the problem for the duration of their visit to the site'."

Steve Loughran writes "It's been pretty quiet in public on the SiteFinder front, but it does not mean that VeriSign are accepting defeat. On October 15, the ICANN Security and Stability committee met to discuss it, as can be seen from the long transcript. The new item from this is a VeriSign review of Site Finder, which is very interesting." Loughran further analyzes the Verisign presentation, below.

Some key points:

1. English-only responses only merits a 'moderate' response. I am sure the rest of the world thinks their language is only 'moderately' important.
2. A lot of problems are viewed as minor, fixable with 'user education' or 'application patch'. I wonder if DNS patches were the application VeriSign expected us to patch?
3. Apparently most spam doesnt forge sender domains; only 3-5%. So checking domain validity doesn't help much as an effective spam filter. A SpamAssassin representative commented that there are so few invalid domains in their corpus is that they get filtered earlier, so this data may be bogus.
4. An acknowledged troublespot could be automated HTTP programs getting confused by the new responses, but they hadn't heard of that, and using HTTP over port 80 in this way by automated tool is discouraged according to BCP 56 .
5. User studies liked it, but since the core finding was "there's more functionality than you get with a 404 so it's helpful for me", the study may have been flawed. Site Finder did nothing for 404 pages, only for unknown hosts.
6. Most of the problems with services such as SMTP relate to misconfigured systems, and these did not show up with the small scale tests VeriSign tried.

After the presentation, the transcript shows some good feedback from the audience -ripping into the end user survey, for example, and trying to understand the relationship with other registrars. It is notable that the only two user groups considered are (a) registrars and (b) end users. The wants and needs of people who implement networked applications or support them are neglected because we are seemingly invisible.

I myself am most offended by the "we shouldn't be automating access over port 80" comment. Hello? VeriSign? What do you think Web Services are?

While Site Finder was up, I tested how SOAP stacks handled misconfigured addresses: the results are published on xml.com. Both SOAP stacks tested choked on the 302 response, giving errors to the clients that are nowhere near user intelligible. So VeriSign are making things harder, despite their apparent obliviousness or denials. I shall be sharing my data with VeriSign, and encourage anyone else to do the same."

dousette asks: "In reading over one of the RFC's governing the SMTP protocol, and other RFC's as well, it's interesting to note that you see some big names and big companies from time to time. With all the loopholes in the current SMTP specification, is it possible for the Slashdot collective to come up with another one? Would it stand a chance in making it into a standard, or do they just listen to Cisco, AT&T, etc? I realize that a lot of people have a lot of ideas how things should be done (and they haven't been shy about posting them to Slashdot), but has anyone tried to write the RFC for a replacement protocol? As a side note (where I won't be shy about posting how things should be done), if there were a replacement trusted protocol, one could have mail received via that protocol bypass spam filtering, id checking, or whatever checks might be in place (saving processor cycles, etc). The regular checks could still be done on other mail received via the 'older' SMTP protocol. If more and more ISP's make use of this, SMTP could be gradually phased out... or if you are one for a sudden cut-over, just cut to the new one at the same time as the IPv6 upgrade!"

Logic writes "The Ogg bitstream format (used by Ogg Vorbis) has been enshrined in RFC 3533, "The Ogg Encapsulation Format Version 0", for all you folks who won't look at something unless it has an RFC attached to it."

An anonymous reader writes "The company recently published a proposal that describes how it plans to embed 'lawful interception' capability into its products. Among the highlights: Eavesdropping 'must be undetectable,' and multiple police agencies conducting simultaneous wiretaps must not learn of one another. If an Internet provider uses encryption to preserve its customers' privacy and has access to the encryption keys, it must turn over the intercepted communications to police in a descrambled form." See our earlier story and the RFC for background.

cf_33073 writes "Scary stuff for the privacy advocates out there. Your Internet telephone conversations may soon be tapped by the government. Anyone else concerned about these intercepts being hacked? Full text of the RFC Is available (mirror)"

pldms writes "Safari Beta 2 is available via Software Update or from the Safari page. This is build 73, for those who've had 'exclusive' access to previous development versions since beta 1 ;-) The blurb: 'Safari Beta 2 introduces tabbed browsing to conveniently see and switch between multiple web pages in a single window, and AutoFill to instantly fill out web forms and password fields. This update also features increased standards compatibility and improved application stability.'" I had to set Lax Certificate Checks in the Debug menu to use it with Slashdot ... and its secure cookie check is still quite broken (either saves secure cookies without the secure flag, or sends out secure cookies to insecure sites, which would violate RFC 2965 where it says "no less than the same level of security").

J0e 1337 wrote in to tell us about a recent development in the TCP/IP header RFC. He says "According to the just-released RFC, conveniently labeled number 3514 for easy rememberance, a new bit will be added to enhance security. This new evil bit will make it possible to route based on the evil status of any given packet. It's about TIme!!" You might want to read A Related Slashdot Story in order to more fully understand the scope of this exciting new RFC.

An anonymous reader writes "New security measures are being suggested (see RFC 3514) for the IPv4 header. The measures include a bit that can be set and unset according to whether the packet is secure or not. Due to the important security implications, anyone coding client/server internet applications might want to take a look."

Absolut Ralts notes that " RFC 3514 is now available. It provides for an additional so called 'Evil Bit' that can be used to determine the nature of the TCP/IP packet. This should vastly simplify networking and internet security, and prevent the beepers of tired sysadmins from going off and interfering with Warcraft III!"

Nashirak writes "This is new RFC that introduces new security measures into IPv4 header. The measures include an "evil bit" that can be set an unset according to wether the packet is evil or not."

RFC 3514 was just released, with a new bit definition for use in the headers of IP packets. Because there are important security implications, anyone coding internet services (on either the client or server end) should probably take a look.

kousik writes "rfc3098 is out with the title "How to Advertise Responsibly Using E-Mail and Newsgroups or - how NOT to $$$$$ MAKE ENEMIES FAST! $$$$$"." This is a well written piece, and actually is worth reading for anyone doing advertising online. Unfortunately the people who need to understand it will never read it. And the most evil of spammers won't care because (here's the shocker) Spam Works. As long as people respond to unsolicited spam, it'll keep coming.

Crossfire writes: "IP over Avian Carrier (RFC1149) was just a joke, right? It would seem not. The Bergen Linux Users Group has made it a reality! It would also seem that Alan Cox was present for the event too, given by the photos on the page." This is just excellent. Kudos to everyone involved.

Anonymvs Cowardvs writes "Well, it looks like after their 20-year reign, RFCs 821 (SMTP) and 822 (mail message format) are history. The replacements, RFCs 2821 and 2822 are available now (2822 was just released). Apparently they reserved the numbers, no cosmic coincidence here."(Read on for more.)

"It's weird. Both 821 and 822 looooong predate my time on the Internet, and you sort of get used to them being as if written in stone. Doesn't look like the changes were too radical -- mostly just catching them up to current practice -- but that's a lot of text that I haven't got through yet and there's surely some gotchas in there. Does your mail client or server (or netnews client, since they use the message format) comply?

And this is the first time that Jon Postel's name has seemed conspicuously absent to me..."

Anonymvs Cowardvs writes "Well, it looks like after their 20-year reign, RFCs 821 (SMTP) and 822 (mail message format) are history. The replacements, RFCs 2821 and 2822 are available now (2822 was just released). Apparently they reserved the numbers, no cosmic coincidence here."(Read on for more.)

"It's weird. Both 821 and 822 looooong predate my time on the Internet, and you sort of get used to them being as if written in stone. Doesn't look like the changes were too radical -- mostly just catching them up to current practice -- but that's a lot of text that I haven't got through yet and there's surely some gotchas in there. Does your mail client or server (or netnews client, since they use the message format) comply?

And this is the first time that Jon Postel's name has seemed conspicuously absent to me..."

Anonymvs Cowardvs writes "Well, it looks like after their 20-year reign, RFCs 821 (SMTP) and 822 (mail message format) are history. The replacements, RFCs 2821 and 2822 are available now (2822 was just released). Apparently they reserved the numbers, no cosmic coincidence here."(Read on for more.)

"It's weird. Both 821 and 822 looooong predate my time on the Internet, and you sort of get used to them being as if written in stone. Doesn't look like the changes were too radical -- mostly just catching them up to current practice -- but that's a lot of text that I haven't got through yet and there's surely some gotchas in there. Does your mail client or server (or netnews client, since they use the message format) comply?

And this is the first time that Jon Postel's name has seemed conspicuously absent to me..."

Anonymvs Cowardvs writes "Well, it looks like after their 20-year reign, RFCs 821 (SMTP) and 822 (mail message format) are history. The replacements, RFCs 2821 and 2822 are available now (2822 was just released). Apparently they reserved the numbers, no cosmic coincidence here."(Read on for more.)

"It's weird. Both 821 and 822 looooong predate my time on the Internet, and you sort of get used to them being as if written in stone. Doesn't look like the changes were too radical -- mostly just catching them up to current practice -- but that's a lot of text that I haven't got through yet and there's surely some gotchas in there. Does your mail client or server (or netnews client, since they use the message format) comply?

And this is the first time that Jon Postel's name has seemed conspicuously absent to me..."

Time for an etoy.com news roundup. The Etoy artists are still operating under a ridiculous injunction that bars them from operating a website at their domain. NSI caved to what they perceived as a court order and put the entire domain on hold, so email is blocked too. And Monday's meeting with the judge turned out to be merely a status conference which, according to Etoy's lawyer, "took all of 45 seconds." Nothing was decided, and the injunction remains in effect. But there's good news about the trademark. Click to read more.

The status conference was scheduled for 8:30 AM on the Monday after Christmas weekend, and Etoy's lawyer wasn't able to attend. Essentially it was the judge checking in with eToys' lawyers; the next meeting is scheduled for Jan.10, but that will probably also be just a status conference.

Here's the good news. According to Etoy's lawyer, one of eToys' major claims to trademarked ownership of "etoy" has been shot down.

eToys had purchased the trademark "ETOYS" from Etna Toys, a New York importer which had secured the mark for itself in 1990. In this way, the company which hadn't formed a website until 1997 could claim that it owned a trademark older than the art group which had been operating on the web since 1995.

Fortunately for Etoy, the Trademark Office decided that "ETOYS" was too generic to be trademarked, and invalidated it. According to this decision, prefixing "e" to the generic term "toys" is not enough to make it trademarkable. This decision may yet be overturned, but it's looking more promising by the day.

Meanwhile, Wired reports that John Perry Barlow and Douglas Rushkoff have joined the etoy crisis advisory board. Barlow calls this domain name dispute "the battle of Bull Run." He's got a point - NSI has taken a highly unusual action based solely on the bullying of a legal firm and a single clueless judge. If that matters more than the time-tested rules of the internet, we're all in trouble. Barlow says that Jon Postel, who worked so hard to establish those rules, would be in tears.

TBTF points out that eToys' stock has been plummeting since Dec.1 and asks why. Since that story, it has continued to fall. Some think this has something to do with their bullying Etoy; others disagree; there are some good comments in the Take It Offline forum that TBTF started.

Etoy's supporters' website at toywar.com promises "TOYWAR.com 1.0 will leave the etoy.BETA-LABS in a few days" but it's been saying that for weeks.

Finally, Etoy's friends at RTMark have taken it upon themselves to wage a game against eToys. The point is apparently to drive their stock price to zero. To me, this sounds about as fun as Quake over a 1200 baud modem, but maybe I'm just too bourgeois.

r3drun sent us pictures of the first production empeg (the Linux based car MP3 player). Tom Porter hooked us up with interesting essay by Neal Stephenson that is pretty interesting. Worth a read. emad sent us a link to a Vote for your favorite RFC page. Cracked me up: You vote by number. wall sent us what appears to be the new SGI Logo. Next, I've been waiting for an excuse to link Space Ghost for awhile, and Visoblast sent one that I think us amusing as hell: Naked Pictures of Keith Richards do not affect wildlife. I'm probably only posting it because I listened to Some Girls and Beggers Banquet today. In other music news, RedOregon sent us amusing parody lyrics, Welcome to Berkeley California (you can guess the tune) And finally, GiMP wrote in to say that someone created the Slashdot dance. Hemos has never looked lovelier.