Slashdot Mirror

No, no, it's obviously talking about the new IPoV technology. Sorta like rfc1149, but louder.

I think you misinterperted the title. It really means that Linux IP consists of variations in air pressure.

IP and air, then surely you'd need something like RFC 1149

I knew they were onto something when CPIP was announced. Now we just need to find enough pigeons...

As a software programmer who has written IPv6 enabled applications what I'd really like to see is a similar report of the kernel support for IPv6 in addition to common applications, and for multiple operating systems.

For instance I took advantage of the superior multicasting capability of IPv6, but when porting to different Unixes I found varying level of support. Some just didn't do it, while others were missing some important APIs which made it easier. And some just have messed up C header files rather than faulting the kernel. IPv6 is supposed to have a whole new set of APIs which allow your application to do things like enumerate the various network adapters (important to know when multicasting). Name resolution is also done differently, and with more sane APIs.

The IETF IPv6 Working Group has been busy developing a lot of standards, and for the developer the two most important are RFC2553 for the basic sockets API, and RFC3542 for advanced sockets API. But many Unix vendors aren't up to the latest standard and still implement the older RFC's 2133 and 2292 respectively.

Oh, and on the applications side, many network administrative tools are missing from their list. What about netfilter (aka, iptables and iptables6), or tcpdump, nc, ping/ping6, or X Window? Also what about language support for those languages which have "super" libraries. Python's support for IPv6 is getting pretty strong, but I've found Java's support to be superficial (it only exposes say 10% of IPv6 functionality). Not to complain too much though, this as list is the most complete I've seen so far.

As a software programmer who has written IPv6 enabled applications what I'd really like to see is a similar report of the kernel support for IPv6 in addition to common applications, and for multiple operating systems.

For instance I took advantage of the superior multicasting capability of IPv6, but when porting to different Unixes I found varying level of support. Some just didn't do it, while others were missing some important APIs which made it easier. And some just have messed up C header files rather than faulting the kernel. IPv6 is supposed to have a whole new set of APIs which allow your application to do things like enumerate the various network adapters (important to know when multicasting). Name resolution is also done differently, and with more sane APIs.

The IETF IPv6 Working Group has been busy developing a lot of standards, and for the developer the two most important are RFC2553 for the basic sockets API, and RFC3542 for advanced sockets API. But many Unix vendors aren't up to the latest standard and still implement the older RFC's 2133 and 2292 respectively.

Oh, and on the applications side, many network administrative tools are missing from their list. What about netfilter (aka, iptables and iptables6), or tcpdump, nc, ping/ping6, or X Window? Also what about language support for those languages which have "super" libraries. Python's support for IPv6 is getting pretty strong, but I've found Java's support to be superficial (it only exposes say 10% of IPv6 functionality). Not to complain too much though, this as list is the most complete I've seen so far.

As a software programmer who has written IPv6 enabled applications what I'd really like to see is a similar report of the kernel support for IPv6 in addition to common applications, and for multiple operating systems.

For instance I took advantage of the superior multicasting capability of IPv6, but when porting to different Unixes I found varying level of support. Some just didn't do it, while others were missing some important APIs which made it easier. And some just have messed up C header files rather than faulting the kernel. IPv6 is supposed to have a whole new set of APIs which allow your application to do things like enumerate the various network adapters (important to know when multicasting). Name resolution is also done differently, and with more sane APIs.

The IETF IPv6 Working Group has been busy developing a lot of standards, and for the developer the two most important are RFC2553 for the basic sockets API, and RFC3542 for advanced sockets API. But many Unix vendors aren't up to the latest standard and still implement the older RFC's 2133 and 2292 respectively.

Oh, and on the applications side, many network administrative tools are missing from their list. What about netfilter (aka, iptables and iptables6), or tcpdump, nc, ping/ping6, or X Window? Also what about language support for those languages which have "super" libraries. Python's support for IPv6 is getting pretty strong, but I've found Java's support to be superficial (it only exposes say 10% of IPv6 functionality). Not to complain too much though, this as list is the most complete I've seen so far.

The part where the OS gets involved is when it uses the same mechanism to associate documents with their application as they do interpreted code with their interpreter.

MIME has a Content-Type mechanism to describe data. In the original MIME specification the authors stated

The "application" Content-Type is to be used for data which do not fit in any of the other categories, and particularly for data to be processed by mail-based uses of application programs. This is information which must be processed by an application before it is viewable or usable to a user. Expected uses for Content-Type application include mail- based file transfer, spreadsheets, data for mail-based scheduling systems, and languages for "active" (computational) email. (The latter, in particular, can pose security problems which should be understood by implementors, and are considered in detail in the discussion of the application/PostScript content-type.)

Security considerations: This type is intended for the transmission of data to be interpreted by locally-installed programs. If used, for example, to transmit executable binary programs or programs in general-purpose interpreted languages, such as LISP programs or shell scripts, severe security problems could result. In general, authors of mail-reading agents are cautioned against giving their systems the power to execute mail-based application data without carefully considering the security implications. While it is certainly possible to define safe application formats and even safe interpreters for unsafe formats, each interpreter should be evaluated separately for possible security problems.

Just because the designers of outlook essentially ignored the data description features of MIME didn't mean they had to ignore the warnings of the dangers of executable content. There is no reason why a mail reader should associate a .sh file, or an application/x-shell-script file with a general purpose interpreter, and the people who invented MIME knew this and warned about it.

There is no good reason for a mail program to run hand executable content off to the OS or an interpreter.

I think one of the largest problems with shared calendars have been that there's no standard for it. CAP seems to address that problem. It's still a draft of course, but I'd assume it won't change at least radically anymore.

All the more reason for verification that an e-mail actually did originate from the address specified. I think half the solution is in this proposal, but I think the other half is validation of the sending address as follows:

1. The sending server would generate a CONTENT KEY based on the contents of a specific message, including the subject, date, from, to, and CC fields, as well as the body. The algorithm to generate this key would be public in nature.
2. A PRIVATE KEY would be used in conjunction with the CONTENT KEY to generate a VERIFICATION KEY.
3. The VERIFICATION KEY would be added to the e-mail, which would then be sent.
4. The receiving server would use the same algorithm above to generate another CONTENT KEY for the received message.
5. The CONTENT KEY plus the VERIFICATION KEY would be sent to the sending server for verification.
6. The sending server would use its PRIVATE KEY with the CONTENT KEY from the receiving server and compare the results to the VERIFICATION KEY.

A. If the receiving server was not updated with the verification capability, it would pass the message through as is done today, for backwards compatibility.
B. If the sending server was not updated, the VERIFICATION KEY would obviously not be present, and the receiving server would pass the message through as is done today, for backwards compatibility (note that the number of non-updated servers will diminish over time, eventually leaving only "spoofable" servers, which could easily be blocked in a more manageable way via the RBL).
C. If the sending server indicates that the message is verified, the message passes through.
D. If the sending server indicates that the message is NOT verified, the message is BOUNCED (I think it is important to actually bounce the message in order to generate additional traffic at the sending server and further encourage open relays to be updated, and to discourage protected e-mail addresses from being added to further SPAM address lists).

Xesdeeni

Well, technically it isn't breaking the spec, just bending it really far.

No, it is actually breaking the spec. You (and Mark) are referring to an unofficial Note produced by a member of the W3C. A quote from that document:

This document is a Note made available by the World Wide Web Consortium (W3C) for your information. Publication of this Note by W3C indicates no endorsement by W3C or the W3C Team, or any W3C Members.

I am referring to RFC 2854. This RFC provides the list of document types that may be sent as text/html. It includes XHTML 1.0, but not any other type of XHTML. In particular, even some forms of XHTML 1.0 are unsuitable for being labelled as text/html.

First I heard of it was from Landon Noll and Mel Pleasant. It is noted in brief as one of the techniques in this plan to end spam (though their plan, which did include the triplets, is not laid out in full there.)

It is a worthwhile technique for a little while, and if spammers were rational, would be worthwhile for some time to come. But spammers are not rational, and already this technique is not as useful as would be hoped.

Do a Google Search for Tempfailing especially in ASRG to see statistics etc.

Oh yeah, you must mean RFC1149

OGG is a container format, it can contain as many Vorbis, MP3, AAC, WMA or PCM WAVE channels as you like. http://www.ietf.org/rfc/rfc3534.txt

Why not just turn on the 'evil' bit for these connections?

Then simply enable a filter to drop those packets during off hours or peak usage.

And people thought that was a joke!

Tried this earlier as anonymous, but it sank, so here it is with a name attached...

It's the mobile ad-hoc networking IETF group doing just what he's talking about. And as everybody would probably expect, QoS is the biggest obstacle.

Try this:

It's the mobile ad-hoc networking IETF group doing just what you're talking about. And as everybody would probably expect, QoS is the biggest obstacle.

"It's illegal to be 'evil'"
So just set the evil bit to 0 and they'll never suspect a thing >:-]

And now the so-called Master Penmen are upset that their little hobby will be archived next to the hurricane oil lamp and the carrier pidgeon.

At least carrier pigeons still have some uses...

Sure, you can even have Internet over Carrier Pigeon, just don't expect it to perform very well! Much more interesting is Shortwave Radio over the Internet.

When I played around w/ Packet Radio there were a lot of problems, collisions, weak transmitters come and go, the retries and lag time is tremendous - the buzz at the time was: don't expect to be able to d/l PacMan video games using Packet! Whats the max packet baud rate these days? 9600? On HF it's even lower.

At work I can ping a remote site and get a response in about 70 milliseconds, going thru about 20 routers. Packet radio can't touch that.

Look into PSK31, it's an interesting active mode these days for point-to-point qso's, an HF chat room if you will.

In a related issue, what's up with email address portability? Isn't it annoying that when your ISP goes out of business, you need to change email addresses? It's really the same problem.

My guess is that the typical Slashdotter can see what a pain it would be to have email address portability. Telephone number portability is just as bad. Not that you can't do it, but it's really hard and expensive. Every phone call becomes a database dip. Consider the size and speed of that distributed database.

Would you believe that they're trying to go at it the other way around? Mapping "names" (consisting only of numbers) to phone numbers. The benefit is that the phone numbers are already a globally unique addressing system.

Or at least, that's my trivial understanding of enum.

but you could still use IP Over Carrier Pigeon . . .

I believe this is HSTCP.
For more info, you can also take a look at:
Web100 and Net100.
It basically amounts to improving the AIMD algorithm and changing the way slow start works as well. Also, whoever said it before that this will not help your DSL connection is correct. It is meant to help high speed long RTT paths. And it does so -- quite well.

But... (drum roll)

what is wrong with HSTCP (High Speed TCP) of which seems to have been much better thought out, is on its way to being an IETF draft (do a google search for HSTCP) and seems to work both for the average normal user and the power user. There is also another TCP varient called Scalable TCP which also seems to have quite a bit of theory behind it!

RFC 3514

Looks like this this

SCTP is a reliable transport protocol operating on top of a connectionless packet network such as IP. It offers the following services to its users:

-- acknowledged error-free non-duplicated transfer of user data,
-- data fragmentation to conform to discovered path MTU size,
-- sequenced delivery of user messages within multiple streams,
with an option for order-of-arrival delivery of individual user
messages,
-- optional bundling of multiple user messages into a single SCTP
packet, and
-- network-level fault tolerance through supporting of multi-
homing at either or both ends of an association.

The design of SCTP includes appropriate congestion avoidance behavior
and resistance to flooding and masquerade attacks.

Thats what TCP does, just in a passive fashion. The sender queues all sent packets for resend, (on a delay) and packets are deleted from the queue when an acknowledgement for a range of packets is recived from the remote computer.

If you're curious: RFC 793

I haven't yet spotted any cryptographic "reviews" of this yet, but it certainly looks like an appealing platform to work with.

Appealing or not, but according to the document bundled with source distribution their key exchange takes 8 messages to complete. SSL does it with 4 packets (with multiple messages per packet), IKE - with 3 (in aggressive mode).

They also seem to impose extra load on CPU with unneccessary crypto operations (step 1 and 2), derive keys in funky way, do not provide (or do not document) rekeying mechanisms, do not provide a replay protection, etc, etc.

With all due respect, this stuff needs a major facelift and a cleanup.

Oh you mean... this?

Are these guys supposed to be actually implementing anything or just doing research? The entanglement of the IRFT and (one of their sponsors) the IEFT in the stories make it unclear, but the group's charter make it clear that they have to define a lot of terms first.

The article is full of quotes from the chair, Paul Judge, and none from any other members. Take a look at the mailing list archive and decide for yourself.

One of the tools, Reverse MX, is expected to be in place in several months. It would allow the receiving mail server to query a domain to determine if the sending server is allowed to send on its behalf.

According to the linked draft, this is supposed to be a "protection against e-mail fraud, especially spam". No mention is made of legitimate uses that are also killed.

When I travel abroad, I send e-mail with my own home e-mail address as the sender through the foreign ISP's SMTP server (and collect mail with POP3 from my home ISP as usual). This has several advantages such as not needing another e-mail account and still being able to post to mailing lists. This plan will lump that in with "fraud" and make it impossible. With whitelisting on private e-mail becoming more and more common, this will be even more of an issue.

If the spammers do not make e-mail as we know it unusable, trust clueless antispammers to do that job more thoroughly.

(Another sign of their cluelessness in that draft is their statement that "spam is not yet exactly defined". The definition is, and always has been, unsolicited bulk e-mail. You can't get more exact than that.)

RFC 3268 describes the way you should use the Advanced Encryption Standard with SSL/TLS.

My experiences weren't at all like the ones described in the article, even though we certainly weren't codifying existing practice. No one threatened to leave and join a rival standards effort, even though AES over TLS is important for government contracts. Most of the argument was about the minutiae of the protocol. For example there was a long discussion about the padding type and cipher mode of operation.

The problem I had was that the process is horribly slow. There are a few people in the IETF who have a lot of work to do, and you tend to find yourself sitting in a queue for a long time.

That said, I think it was a very worthwhile thing to do. If we hadn't done AES through the IETF, no one could have interoperated. It wouldn't be a case of then codifying existing practice a few years on because it simply wouldn't work. The different TLS implementations need to use the same ciphersuite numbers for example. Much better to sort that out on an IETF mailing list than try to cobble something together in a series of bilateral discussions.

RFC 3268 describes the way you should use the Advanced Encryption Standard with SSL/TLS.

My experiences weren't at all like the ones described in the article, even though we certainly weren't codifying existing practice. No one threatened to leave and join a rival standards effort, even though AES over TLS is important for government contracts. Most of the argument was about the minutiae of the protocol. For example there was a long discussion about the padding type and cipher mode of operation.

The problem I had was that the process is horribly slow. There are a few people in the IETF who have a lot of work to do, and you tend to find yourself sitting in a queue for a long time.

That said, I think it was a very worthwhile thing to do. If we hadn't done AES through the IETF, no one could have interoperated. It wouldn't be a case of then codifying existing practice a few years on because it simply wouldn't work. The different TLS implementations need to use the same ciphersuite numbers for example. Much better to sort that out on an IETF mailing list than try to cobble something together in a series of bilateral discussions.

• Chandler, and
• ProChange

Ahh, the upgrade to RFC 1149 is here at last.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.

The TCP initial sequence numbers were not intended as a security mechanism. Even back then they wouldn't have been dumb enough to use a 32-bit number for security. You mention "randomly generated" numbers as is they were part of the spec, but the word "random" doesn't even appear in the RFC. No stacks (AFAIK) randomized these numbers back then. They used the trivially predictable 64K rule as these numbers were intended for reliability not security.

It is true that this reliability feature makes spoofing slightly more difficult, and that many stacks have been enhanced (mostly in the last 5 years) to make these numbers less predictable. But to call this "the fundamental security mechanism for TCP" and declare this as challenge-response prior art from 1981 is misleading.

All that being said, I wholeheartedly agree that this patent is bogus and that you are right to be looking for any creative examples of prior art you can find! But this just does not cut it.

GET / HTTP/1.1
...
Keep-Alive: 300
Connection: keep-alive

Challenge-Response is the fundamental security mechanism for TCP, the reliable communication protocol used for everything from the web to SMTP itself. During the three way handshake between client and server, each sends the other a randomly generated 32 bit number, and each refuses to communicate unless that number is successfully returned intact. If either the client or the server fakes its identity, it will fail to receive the required value -- one of four billion -- and will thus be unable to complete the handshake.

At least, that's the thinking. Perfect security this ain't, but please -- the spec for TCP came out in 1981. TCP's security technique entirely encapsulates challenge-response systems for SMTP -- the same mitigation of false addresses through an inability to respond, the same caching of credentials once a response is received (you can think of a "trusted address" as a permanently open socket, with all the management headaches that implies!), etc.

In short, this is nothing new. But of course, we already knew that :-)

Yours Truly,

Dan "I Do Way Too Much Stuff With TCP" Kaminsky
DoxPara Research
http://www.doxpara.com

to implementing power over TCP/IP.
Read the RFC Here.

[RFC3533] The Ogg Encapsulation Format Version 0, Silvia Pfeiffer, May 2003.
[RFC3534] The application/ogg Media Type, Linus Walleij, May 2003.

[RFC3533] The Ogg Encapsulation Format Version 0, Silvia Pfeiffer, May 2003.
[RFC3534] The application/ogg Media Type, Linus Walleij, May 2003.

[RFC3533] The Ogg Encapsulation Format Version 0, Silvia Pfeiffer, May 2003.
[RFC3534] The application/ogg Media Type, Linus Walleij, May 2003.

[RFC3533] The Ogg Encapsulation Format Version 0, Silvia Pfeiffer, May 2003.
[RFC3534] The application/ogg Media Type, Linus Walleij, May 2003.

On a side note, there has also been a second RFC (RFC 3534) published regarding the application/ogg media type.

RFC 3533 over RFC 1149! (perfect for those multi-year John Cage tunes)

Screw that...it needs RFC3514 support so that Britney/NSuck/etc. OGGs can be marked appropriately. With RFC3514 support in routers and such, maybe you'd see much less of that crap clogging the Internet.

I refuse to support Ogg until its streaming component adequately supports the Evil Bit. Slashdot has given this so-called "Evil Bit" RFC a little lip service in the past, but I think it's high time we brought it out into the open.

The actual lookup isn't patented, it's just automatic lookups that are patented. This would be prior art if the actual lookup process was patented.

If the courts knew anything about computers, they would see structured programming as prior art for this. But, of course, something can be a new "invention" if a certain subcase is added. So, I should be able to patent "repetitive functions by a computing device used to search a file sharing network" and donate it to the RIAA to keep automated scripts from downloading from Kazaa.

The proper name for this technology is "IP over Avian Carriers" and it is defined in RFC 1149.

--zawada