Slashdot Mirror

this IETF statement smells a little too much like the kind of letter a telco sends when it's rais^W giving you a discount. the fact that the IETF isn't requiring a unique identifier isn't very comforting: they could just as easily recommend - which goes a long way - that no packets carry a persistent identifier other than an IP address. let vendors and sysadmins build in optional peristent IDs for those who want them or situations where they're needed.

the vast majority of traffic on the net involves this statement's second category, "less trusted targets," and that proportion will only grow over time, to the point where implicitly trusted traffic is a barely expressible nanopercentage. if in fact the IETF is interested in articulating a structure that will reflect those plain facts, then they should skip this kind of condescending "explanation," with it's "there's two situations" stuff, and base their analysis on the actual directions in which the net is developing.

IPv6 offers a chance to develop a protocol that will allow the net to develop into a field for truly open, random, and free social engagement - or to become a tool for systematic surveillance by those in a position to do so. and note well: encouraging persistent, unique IDs will put a lot of people in a position to do so.

we'll see what the IETF decides on this - and on the question of whether "the IETF [should] develop new protocols or modify existing protocols to support mechanisms whose primary purpose is to support wiretapping or other law enforcement activities."

There has been some concern over the use of thw ':' character in the text representation of IPv6 addresses - this could break some programs parsing addresses or especially URLs.

There is an internet draft which proposes the following native format:

instead of "ABCD:EF01::2345:10.9.8.7" use "ABCD-EF01--2345-10.9.8.7.ipv6" which contains only characters valid on a domain name and marks the with a pseudo-TLD of ".ipv6"


----

Perhaps some of the posters here who have reasoned comments to contribute to this discussion might consider joining the IETF.

Turn up to a meeting (4 per year), or subscribe to one of the mailing lists and start posting useful comments to the ongoing discussion. That's it, you are a member just by participation.

Unfortunately for the conspiracy theorists, there are no initiation ceremonies, and no cabalistic membership application procedure. Sorry guys, you will just need to go back to tracking down the Illuminati!

Some people would say that you have to join a magic "inner circle" of the IETF before your voice counts. I'm going to let the Slashdot readers in on a huge secret here - if your contributions generally are on topic and contain way more signal than noise, the "inner circle" will be glad to have you!

Having attended an IETF meeting, I can vouch for the attendees in general being highly intelligent, professional engineers, with good ethical and moral standards. If they don't agree with a proposed standard, you will not have to wait for the reasoned arguments against the standard to come flooding in.

Personally, I applaud the IESG for encouraging early debate on wiretap issues. To ignore these issues would run the risk of being caught out by new legislation, followed by hasty implementation of a poorly planned set of technologies designed to appease the governments such that the Internet is allowed to continue to operate in a useful fashion.

IESG / IETF did not pull these issues out of thin air - these are real issues and can/must not be ignored. I wonder how many of the people posting negative comments about the IETF have actually bothered to look at the web site: http://www.ietf.org/

The mailing list is public. You can subscribe here and read the archives here. This, IMHO, is good. The existing posts on the list are, for the most part, high quality, constructive and thoughtful. One would hope that this being posted to Slashdot doesn't change that.

The mailing list is public. You can subscribe here and read the archives here. This, IMHO, is good. The existing posts on the list are, for the most part, high quality, constructive and thoughtful. One would hope that this being posted to Slashdot doesn't change that.

2.3. Possible Approaches

One way to avoid some of the problems discussed above would be to use DHCP for obtaining addresses. With DHCP, the DHCP server could arrange to hand out addresses that change over time.

Another approach, one compatible with the stateless address autoconfiguration architecture would be to change the interface id portion of an address over time. For example, upon each system restart, select a new interface identifier different from the ones used previously. Changing the interface identifier makes it more difficult to look at the IP addresses in independent transactions and identify which ones actually correspond to the same node.

In order to make it difficult to make educated guesses as to whether two different interface identifiers belong to the same node, the algorithm for generating alternate identifiers must include input that has an unpredictable component from the perspective of the outside entity's collecting information. Picking identifiers from a pseudorandom sequence suffices, so long as the specific sequence cannot be determined by an outsider examining just the identifiers that appear in addresses. This document proposes the use of an MD5 hash, using a per-interface "key" that varies from one interface to another. Specifically, we use the interface identifier generated using the normal procedure [ADDRARCH] as the key.

There are, however, ample other opportunities for other aspects of interoperability that generally have merit.

• Data formats

  Many UNIX applications have traditionally used data formats as a mechanism for interoperability. Many applications know how to read things like mail and news spools, which provides interoperability.

  GNOME and KDE both make fairly extensive use of XML, which may, with some cooperation on DTDs, provide opportunities to interoperate in a cooperative manner.

• Protocols

  One of the traditional strengths of UNIX has been the use of common sorts of protocols. The IETF has been involved in defining common protocols for things like news and mail that allow diverse mail and news servers/clients to interoperate. And just look at how many web server implementations there are out there...

  GNOME and KDE both include CORBA implementations that represent a well-defined, intentionally-interoperable way of defining protocols for client/server applications.

  The use of this approach requires splitting applications into "client/front end" portions, which may be GUI-specific, and "server side" portions, which should be designed to be altogether independent of the GUI.

In effect, people should be doing design efforts to build useful "services" that are entirely GUI-independent; that will provide code that will be usable with both GNOME and KDE.

...at least if you use a non-ethernet addressing scheme for those bottom 64 bits and get a full 128-bit space. I once wondered about whether nanotech would present problems for 128-bit addressing and did some back-of-the-envelope calculations to examine the issue. A little math to satisfy one's "what-if geek" tendencies:

earth's surface area = 5.099*10^11 m2
earth's land area = 1.4835*10^11 m2

That's surface area, but we live in a volumetric space; let's define that space as 1 km high above/below earth's land-mass(part of that 1km being underground, part being in the air.) Thus the volume of human space above/below land is 1.48*10^14 m3. With 10^6 cubic centimeters per cubic meter, and approximately 10^23 atoms per cubic centimeter, we get 1.48*10^43 atoms in our human-habitable slab of space on earth.

Now, how many IP addresses for that space? Well, 2^128 = 3.4*10^38th.

Ergo we have enough IP addresses for nanotech devices of 43,600 atoms each, in a human-habitable volume completely covering the land-mass of Earth and extending to fill a volume of space above and below the earth's surface for a full 1 km. Sure, you might get nanodevices smaller than that, but would they be independent enough and sensing/generating enough information to communicate via IP?

Well, if that isn't a problem for 128-bits, what is? Let's check a few other test cases that your friendly sci-fi reader might imagine...

Well, that was just land-mass. What if we filled the sea with nanodevices, would that exhaust it?
The sea is 11km deep at worst, 3.8km on average. Water surface area is little over double land. Thus water basically requires a factor of 10x more devices. Given that you probably won't have more than 10% of the volume of any space being nanodevices (and this would seem to remain an extreme upper bound), this probably isn't an issue.

So what about interplanetary colonization? Still not too much of an issue for this solar system (ignoring the latency issues.) At least the first few planets (Mars/Venus/Mercury) which only add a factor of 3-4x expansion once 100% colonized form due to the roughly similar size of available nanodevice space on those planets as earth. True, a colonized Jupiter might pose problems down the line...

And if you used nanoprobes to fill/convert entire atmospheric systems, you end up covering a lot more volume (99% of earths' atmosphere fills approx 8.6*10^19 m3 by my calculations, five orders of magnitude more space than our 1 km slab.) Of course, any nanodevice design on that scale would probably use its own non-IP protocol.

Ah, but what other assumptions could be misleading us? For example, what is the efficiency of the 128-bit name space? Can we really use all those addresses? Well, I admit, I'm less an expert on this. The issue that Ethernet MACs will typically be your bottom 64-bits definitely chews up a lot of space, but if Ethernet doesn't make sense for nanodevices, we'll probably be using something else, or our self-assembling nanoprobes will build and configure themselves so that they share 1 higher-level IP but under the covers each have an colony-wide (not globally) unique ethernet address. How efficiently allocated is the rest of that (non-Ethernet) space? Well, I think CIDR-like tweaks can squeeze a fair amount out.

Still, even in the case where 128-bits isn't quite enough(!), I suspect reverting to NAT-type approaches in IPv6 will be workable. Certainly inter-stellar communications which will be limited to a relatively small number of transmitters will scale up with NATs for quite a while, assuming photon-based communications. ;-)

So I suspect the 128-bit addressing scheme of IPv6 will last us at least another 200 years, not just "decades" as the IPv6 committee conservatively claims.

Of course, they probably know more weaknesses in that timeframe than I. Pretty hard to extrapolate out that far. For example, will the 4-bit header for IP version numbers be sufficient? Only 255 (8bit) hops? Who knows? Maybe IPv6's optional extension headers will even let us kludge around those issues.

Still, I think 128-bit IPv6 addressing will last us through nanotech and intra-planetary travel. Perhaps it will even last as long as our 4-digit field Y2K fixes!

--LP ;-)

Here's a link to IETF's IAB document called The Case For IPv6. Section 2.2 spells the design goals out pretty clearly.

I realize you were just repeating bad info, so nothing personal.

This is something a of no-brainer, but you can find out a great deal about IPv6 by checking out

http://www.ipv6.org/

If you just want a in-depth understanding of why you should use IPv6 instead of Ipv4 take a look at

http://www.ie tf.org/internet-drafts/draft-ietf-iab-case-for-ipv 6-04.txt

Why physical layer security? This isn't physical layer security. The poster who though it was was wrong. If you want to adhere to strict OSI layer definitions -- well, you're out of touch with modern networking reality, but if you do -- then this is a Link Layer security.

Uhm, what is that comment about? If you go by the standards you're out of touch with modern networking? How is the OSI model obsolete?

Firstly, this isn't an official draft of an IETF working group - anyone can submit a draft, even if it's this lousy. (Working group drafts are of the form draft-ietf-working_group_name-*)

Secondly, IPv6 isn't really that complex, especially considering this proposal isn't exactly simple (would it really be easier to roll this out instead?!). An excellent starting point is the Internet Architecture Board Case for IPv6. You can also get some good information and links at the IPv6 Imformation Page. I have to say I don't like the way this guy slates IPv6 without explanation, maybe he needs to read up a bit more on the subject.

Finally, although one day we may run out of IPv4 addressing, that's not the immediate addressing problem - the problem is of uneven distribution of addresses. While the USA might be alright, where every corporation who could shout "Me Too!" got a class A, there are other places in the world who are very short on addresses. I've heard it said that Madagascar has just 200 global IPv4 addresses! A whole country run through NAT! *Shudder* (I reserve the right for this to be an urban legend ;)

Anway, there's loads of other really neat stuff in IPv6 aside from extending the address space to keep us all happy....

As well as 172.16.0.0 through 172.31.255.255. This is all defined in RFC 1918.

One big reason for the subnet mask is routing. Let's pretend we're the routing code in the IP stack. A packet is handed to us, and we look at the destination address. We compare that destination with our routing table, looking for the closest match. For example, if the routing table looks like (edited for something like clarity):

$ netstat -nr
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
192.168.1.2 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0

Consider a packet with the address 127.0.0.1. We bitwise "and" it with the network mask from the first route (255.0.0.0), and get 127.0.0.0. This is a match, so we send the packet to the loopback interface, "lo", which in all probability won't cause any traffic on the wire connected to my box.

For 192.168.1.50, we'd go down the list, looking for a match, until we got to the third rule. Applying the network mask, we get 192.168.1.0, which matches the destination for this route. We'll send the packet to the ethernet address, and do an ARP to resolve it's ethernet address, which we need to send a packet on the local network.

Note that the last line, 0.0.0.0 (mask 0.0.0.0), matches everything. This is the default route. The IP address you see here is the router that we want to make the next hop routing decision for us.

One big reason for the subnet mask is routing. Let's pretend we're the routing code in the IP stack. A packet is handed to us, and we look at the destination address. We compare that destination with our routing table, looking for the closest match. For example, if the routing table looks like (edited for something like clarity):

$ netstat -nr
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
192.168.1.2 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0

Consider a packet with the address 127.0.0.1. We bitwise "and" it with the network mask from the first route (255.0.0.0), and get 127.0.0.0. This is a match, so we send the packet to the loopback interface, "lo", which in all probability won't cause any traffic on the wire connected to my box.

For 192.168.1.50, we'd go down the list, looking for a match, until we got to the third rule. Applying the network mask, we get 192.168.1.0, which matches the destination for this route. We'll send the packet to the ethernet address, and do an ARP to resolve it's ethernet address, which we need to send a packet on the local network.

Note that the last line, 0.0.0.0 (mask 0.0.0.0), matches everything. This is the default route. The IP address you see here is the router that we want to make the next hop routing decision for us.

For those that want to know more about private network numbers, see RFC 1918.

Classless Inter-Domain Routing. Check out RFC 1519

You're right, the netmask is not transmitted in the datagram. I've tried very hard to include the diagram from RFC 791 here but Slashdot does not allow me to do so in a legible way :-(

See p.10 of the RFC for the table.

Erik

Has it ever occurred to you that God might be a committee?

"If you're trying to implement this, I think that PAM (pluggable authentication modules) is the way to go."

Correct.

"You would need to write a wrapper for getpwent and friends and link all the programs on your system against it..."

Not necessarily - if you are using libc6 (ie., GNU libc 2.0 or 2.1) then you already have Sun Solaris-style NSS (Name Service Switch) which already provides the necessary "wrappers" for getpwent and friends in the standard C library; all you (the admin) needs to provide is a backend lookup library/module that will query against the nominated database.

The "modern" version of NIS/NIS+ is to do all this through LDAP - have a PAM module that performs authenticated binds against an LDAP directory (for authentication) and an NSS module that does all the get*ent lookups against the LDAP directory (for ls and friends).

Works a treat - absolutely no need for any users in /etc/passwd or /etc/shadow.

Check out:

• IETF RFC 2307
• NSS LDAP Module
• PAM LDAP Module

There are some other schema efforts underway (incl. The Open Group and the DMTF), though the above is the only one to so far "deliver" (for want of a better word) for UNIX and UNIX-like (POSIX) environments.

AOL's closing it's protocol? Switch protocols:

http://www.ietf.org/html.charters/impp-charter.htm l

Don't like that one, try this:
Jabber

The draft for this is located at:
http://www. ietf.org/internet-drafts/draft-ietf-nat-rsip-proto col-01.txt. Pretty interesting read as it looks like it has loads of potential. I can't wait to try out an implementation of this!

Bryan R.

I guess it depends on whether we're going for a survey of important documents (think executive summary) or an in depth catalog of every minutae that shaped the Internet, directly or indirectly.

This probably hinges on who the intended audience is. If it's for ourselves (geeks), then anything but the deep catalog will probably bore us. If it's for everyone else (non-geeks). Then anything more comprehensive than a survey of the topic will be overwhelming. I'm not implying that non-geeks are stupid, but who else but a geek would care about each individual Internet protocol? Perhaps we should do both.

For a survey level collection of important Internet documents, I'd suggest that RFC1 [ 1] is the single most important RFC, simply because it started it all. RFC2555 [ 2], a.k.a. "30 years of RFCs" would be a usefull citation for giving context to RFC1.

For in an in depth catalog, covering all relevant RFCs, the large majority (if not all) of the the work has already been done. You simply need to link to, or include the index of RFCs that form the Internet standards, RFC2500 [ 3].

Tim

[ 1] RFC 0001 Host Software

[ 2] RFC 2555 30 Years of RFCs

[ 3] RFC 2500 Internet Official Protocol Standards

I guess it depends on whether we're going for a survey of important documents (think executive summary) or an in depth catalog of every minutae that shaped the Internet, directly or indirectly.

This probably hinges on who the intended audience is. If it's for ourselves (geeks), then anything but the deep catalog will probably bore us. If it's for everyone else (non-geeks). Then anything more comprehensive than a survey of the topic will be overwhelming. I'm not implying that non-geeks are stupid, but who else but a geek would care about each individual Internet protocol? Perhaps we should do both.

For a survey level collection of important Internet documents, I'd suggest that RFC1 [ 1] is the single most important RFC, simply because it started it all. RFC2555 [ 2], a.k.a. "30 years of RFCs" would be a usefull citation for giving context to RFC1.

For in an in depth catalog, covering all relevant RFCs, the large majority (if not all) of the the work has already been done. You simply need to link to, or include the index of RFCs that form the Internet standards, RFC2500 [ 3].

Tim

[ 1] RFC 0001 Host Software

[ 2] RFC 2555 30 Years of RFCs

[ 3] RFC 2500 Internet Official Protocol Standards

I'm currently working on a project where we might be using Michael Schechter's FrameCal running on a bank's intranet and need to sync with Outlook. Post a message if you are interested in this direction.
/g

PS. Development is not approved yet.
PPS. Have not studied these RFCs ( here is RFC2445), but at first glance it appears that RFC2445 is not XML-based and therefore I am not very interested.

o Anycast address is not distinguishable from non-anycast, unicast addresses.
o Anycast address can be assigned to multiple interfaces of multiple nodes.
o Anycast address MUST NOT be assigned to an IPv6 host. It can be assigned to an IPv6 router only.
o Anycast address MUST NOT be used in source address field in IPv6 header.

therefore no tcp to them! forget the web example... here are some specs

Go get some knowledge about IPv6 addresses, just click below and suck it in and enjoy.

ftp://ftp.ietf.org/rfc/rfc2373.txt

It would be cool if IPv6 were modified in a DNS kind of way. Instead of 128-bit numbers, I would much prefer the option of something like:

[country].[region].[industry].[specialty].[company ].[division].[department].[machine/user]

Actually, the scheme itself takes 3 bits, toplevel registries (such as InterNIC) gets 13 bits, lower-level registries (the chain of ISPs below the top down to the site) gets 32 bits to share. Additionally, each sites get 16 bits (or more if it is given some of the ISP bits) of its own --- a whole class B net in IPv4 --- which it can subnet to its heart's content.

Implementing the given proposal in this addressing scheme is left as an exercise to the reader.

The ICANN is on probation. So long as they seem to be making progress towards breaking the NSI monopoly, they will be tolerated by the IETF, however if the ICANN goes rogue, there are still technical mechanisms available to reign both them and NSI in again.

The major problem is that Jon Postel died at the worst possible moment, when his vigilance was/is most required.

NSI is fighting for its life, and its officers know that. Their "service" has been so poor over the term that they've had the InterNIC contract that the minute there is viable competition, it is likely that most registrants will switch providers, and NSI will dry up and blow away (but not before the Securities & Exchange Commission gets ahold of them and prosecutes the corporate officers for fraud; they claimed that they owned ".com" in their prospectus. They do not).

We live in interesting times.

Every computer company, whether hardware vendor or software vendor, plays the "customer lock-in" game. The object is to foster customer dependence on technology that only one company can deliver, and then take the customers to the proverbial cleaners because the customer has no alternatives.

Open standards for computer networking protocols, and for file formats, serve to mitigate or prevent customer lock-in, and this is why more open standards are a good thing, rather than a bad thing. Unfortunately, it appears that this seemingly obvious truth is lost on the majority of Information Systems (IS) professionals in the business world.

Open standards of this type are the central message of the Internet. The Internet Engineering Task Force (IETF) requires demonstrated "interoperability", i.e. disparate computers and software successfully communicating, as the primary requirement for any standard specification to be advanced in their process.

Imagine this scenario: you're the Chief Information Officer (CIO) of a major corporation. You, in order to promote the efficient flow of information through the company, issue an edict to the effect that Microsoft Word (or WordPerfect, or whatever) shall be the standard software package for producing and exchanging documents throughout the company.

While this should work fine provided that there is a version of that software for every computer in your enterprise - an iffy proposition these days; there are two unhappy outcomes from this kind of "standard":

1. It is very difficult for a single software package to fully meet the needs and working styles of every person or group in a medium or large company, aside from the issue of finding a version of that single software for every computer your enterprise owns & operates.

   Some people and departments will be very unhappy with your order, and will likely defy it, by using a different and probably incompatible software package that better fits their department's business needs. This will cause problems when they try to exchange documents.

2. You've just locked your company's document destiny to this one software vendor, and they can bleed you dry if they so choose. Or, worse, if they go out of business, you're stuck.

What's worse is that converting from one document format to another is usually difficult because of semantic information loss - different document representations have different assumptions, and it's usually not possible to cleanly translate from one set to another. This is the "lock-in." In strict terms, the software vendor can't charge you more than it could cost you to convert your documents to another format, but who has that particular price at his fingertips at any given moment?

Now, let's change the scenario a bit: instread of standardizing on a particular word processing software package, you order that all documents shall be in a standard file format, e.g. SGML with a particular DTD.

In this world, your company makes it clear to all software vendors that this is your chosen corporate document standard and that if they wish your business, their software must implement appropriate interpretation and manipulation of that file format.

This puts those software vendors into competition with each other for your business; presumably the one who can produce the best results with the most pleasant and efficient user interface will win your dollars.

This also gives the various different groups inside your company the freedom to pick the software that best suits their working style, so long as it produces the standard document file format. Everybody wins.

If we take this scenario further - you contact your fellow CIO's in other companies and promote this idea, then even more people and organizations win. Just by doing the right kind of standard.

This is precisely what the Internet is about: standards for networking protocols, for E-mail & messaging, for file transfer, for remote access, and file formats like HTML. The Universities and Research Institutions that initially designed the Internet had exactly this result in mind: no one vendor in control, all competing on a level playing field for the business, with the best results for the customers.

Of course, the big companies will fight this kind of initiative because it requires them to compete harder - they can't rest on their laurels. Small companies will welcome this kind of initiative, because it gives them a foot-in-the-door with potentially big accounts, for (relative to their size) lots of money.

Some vendors will counter with "standards" of their own. Of these, some will be honest attempts to extend an existing public standard in a useful way, and some will be an attempt to stymie the process. The things to watch out for are:

1. no published specification (or an insufficiently published specification that cannot be independently implemented for lack of particular details).

2. onerous license or patent restrictions.

3. No alternative vendors of software for that "standard."

All of these end in customer lock-in to a proprietary "standard" - a situation which is not to the customer's benefit in the long run.

Open, public standards for file formats, and computer networking protocols are the right thing for everybody.

Another essay on this issue can be found at the Best Viewed With Any Browser campaign site.

This article is at http://www.clock.org/~fair/opinion/open-standards. html

There are at least three independent implementations of IPv6: Sun's, INRIA, and... hell. can't remember offhand.

If you're interested in more info on IPv6, check out Sun's site, and the IETF ipng working group info page

Internet Transparency

It's a pretty good read. Anyway, ARIN should be offering IPv6 addresses the 17th (next Monday) unless politics and policy get in the way. The registration folks are testing my code today. :)

Make sure your ISP is ready! And don't settle for a /128!

Shane Kerr
Software Engineer
ARIN

Scheduling a meeting can involve enough give-and-take between N people that it really needs some sort of messaging, and not to use mail for that is just silly. Of course there's always iCalendar, the IETF draft standard that I believe Netscape and others implement.

I don't believe there is a free implementation, but the specs are there, so anyone can have a stab at it (hope they do). There are several commercial implementations of the client.
--

OpenBSD IPsec has been unofficially ported to FreeBSD, but if you want a better integration and compliance with the latest specs you'd better run OpenBSD directly. I really wonder why /. masses are so ignorant of something that the IETF designs in the public view and that OpenBSD implements for so long.

While I agree with alot of the comments concerning the question over real criminality and how microsoft definatitly has a certian amount of due negligence. This post is probably the most interesting.

A class action suit should be filed against Microsoft for it's negligent behavior in not creating preventitive measures by the people and corporations impacted by this virus.

The fundimental question is really what sort of ietf standard could be applied to prevent this from happening again?
The forced re-entry of password check when sending out Userid (eg. non root) messages with over 5 to 10 recepients?
One of the major problems is that this type of mail type virus has not been considered by any of the rfc and ietf drafters.. It is a new 'concept', pardon the pun.

I don't think virus prevention of this kind is the realm of the IETF, it is the realm of application writers. Now, the IETF should make sure that all protocols are secure, which will help... for example, right now it is possible to spoof the From: address(the field is added on the client side... it's not easy to hide all traces of the fact it was spoofed, but for a non-technical user, it isn't necessary) or intercept email and add an attachment containing a virus to it. So, I could pretend I was someone you trust, and send you a virus.

But, there already is an RFC on how to prevent this - RFC2311 - S/MIME Version 2 Message Specification All email readers and writers should start supporting this(hopefully in reasonably secure ways such that you can verify any automatically generated email before letting it get signed!), so that sometime soon we even have the reasonable option of not accepting any email without a verified digital signature. (Imagine the possibilities for eliminating/filtering SPAM! Delete or filter into a separate folder all mail received from someone who isn't in your key ring and doesn't have a key verified by one of your friends!)

The outcome of various ideas to eliminate this type of attack mean that every major mail distribution system must be reconfigured. All clients would have to make allowances for the change in standards as well. - While this is not a big issue for open source, the effects of a major revamp of closed source applications is huge.

This is not true. No change in the mail distribution system is necessary to prevent this type of virus. Merely changes on the clients to prevent a script received via email from automatically emailing people. Note that Java already has protections against such things, whereas Visual Basic does not. Also changes to implement S/MIME so as to verify who sent the email, so that you know whether or not the mail was received from a trusted individual. (Note: This won't help unless scripts are also prevented from sending signed mail!)

While I agree with alot of the comments concerning the question over real criminality and how microsoft definatitly has a certian amount of due negligence. This post is probably the most interesting.

A class action suit should be filed against Microsoft for it's negligent behavior in not creating preventitive measures by the people and corporations impacted by this virus.

The fundimental question is really what sort of ietf standard could be applied to prevent this from happening again?
The forced re-entry of password check when sending out Userid (eg. non root) messages with over 5 to 10 recepients?
One of the major problems is that this type of mail type virus has not been considered by any of the rfc and ietf drafters.. It is a new 'concept', pardon the pun.

I don't think virus prevention of this kind is the realm of the IETF, it is the realm of application writers. Now, the IETF should make sure that all protocols are secure, which will help... for example, right now it is possible to spoof the From: address(the field is added on the client side... it's not easy to hide all traces of the fact it was spoofed, but for a non-technical user, it isn't necessary) or intercept email and add an attachment containing a virus to it. So, I could pretend I was someone you trust, and send you a virus.

But, there already is an RFC on how to prevent this - RFC2311 - S/MIME Version 2 Message Specification All email readers and writers should start supporting this(hopefully in reasonably secure ways such that you can verify any automatically generated email before letting it get signed!), so that sometime soon we even have the reasonable option of not accepting any email without a verified digital signature. (Imagine the possibilities for eliminating/filtering SPAM! Delete or filter into a separate folder all mail received from someone who isn't in your key ring and doesn't have a key verified by one of your friends!)

The outcome of various ideas to eliminate this type of attack mean that every major mail distribution system must be reconfigured. All clients would have to make allowances for the change in standards as well. - While this is not a big issue for open source, the effects of a major revamp of closed source applications is huge.

This is not true. No change in the mail distribution system is necessary to prevent this type of virus. Merely changes on the clients to prevent a script received via email from automatically emailing people. Note that Java already has protections against such things, whereas Visual Basic does not. Also changes to implement S/MIME so as to verify who sent the email, so that you know whether or not the mail was received from a trusted individual. (Note: This won't help unless scripts are also prevented from sending signed mail!)

While I agree with alot of the comments concerning the question over real criminality and how microsoft definatitly has a certian amount of due negligence. This post is probably the most interesting.

A class action suit should be filed against Microsoft for it's negligent behavior in not creating preventitive measures by the people and corporations impacted by this virus.

The fundimental question is really what sort of ietf standard could be applied to prevent this from happening again?
The forced re-entry of password check when sending out Userid (eg. non root) messages with over 5 to 10 recepients?
One of the major problems is that this type of mail type virus has not been considered by any of the rfc and ietf drafters.. It is a new 'concept', pardon the pun.

I don't think virus prevention of this kind is the realm of the IETF, it is the realm of application writers. Now, the IETF should make sure that all protocols are secure, which will help... for example, right now it is possible to spoof the From: address(the field is added on the client side... it's not easy to hide all traces of the fact it was spoofed, but for a non-technical user, it isn't necessary) or intercept email and add an attachment containing a virus to it. So, I could pretend I was someone you trust, and send you a virus.

But, there already is an RFC on how to prevent this - RFC2311 - S/MIME Version 2 Message Specification All email readers and writers should start supporting this(hopefully in reasonably secure ways such that you can verify any automatically generated email before letting it get signed!), so that sometime soon we even have the reasonable option of not accepting any email without a verified digital signature. (Imagine the possibilities for eliminating/filtering SPAM! Delete or filter into a separate folder all mail received from someone who isn't in your key ring and doesn't have a key verified by one of your friends!)

The outcome of various ideas to eliminate this type of attack mean that every major mail distribution system must be reconfigured. All clients would have to make allowances for the change in standards as well. - While this is not a big issue for open source, the effects of a major revamp of closed source applications is huge.

This is not true. No change in the mail distribution system is necessary to prevent this type of virus. Merely changes on the clients to prevent a script received via email from automatically emailing people. Note that Java already has protections against such things, whereas Visual Basic does not. Also changes to implement S/MIME so as to verify who sent the email, so that you know whether or not the mail was received from a trusted individual. (Note: This won't help unless scripts are also prevented from sending signed mail!)

Yes, it would be useful for the government to be involved (along with industry) in setting standards for important infrastructure stuff like operating systems and network protocols. But it is possible to create and maintain such standards without government control.

IMHO, the IETF is a prime example of what can be done when people from government and industry and academia all work together on an equal footing.
--
Michael Dillon - E-mail: michael@memra.com

This is precisely why NSI had to announce that they owned the data; otherwise, the Prospectus for their public stock offering was a lie (it also claimed this), and thus NSI would be guilty of fraud.

The Securities & Exchange Commission which regulates the financial markets takes a very dim view of such things. Potentially, the officers and directors of NSI could be held criminally liable, and face prison time in addition to stiff fines.

Personally, I look forward to seeing those bastards strung up by their toes. The most enraging thing about this whole affair is NSI's rank incompetence in operating a key piece of Internet infrastructure, which has threatened the stability of the Internet as a whole.

Where ICANN is concerned, I'm willing to play "wait & see"; the most worrisome thing about them is that they also appear to be vying for some kind of control. They need to understand that they merely perform a service and administration function at the pleasure of the IETF, and not the other way around as they have been claiming.

• www.counterpane.com , Bruce Schneier's company, which hosts a lot of info on e.g. blowfish and the newer twofish cipher. (Twofish is an AES candidate)
• NIST is working towards the Advanced Encryption Standard (AES), which is to take over DES' role as the US-government recommended shared key block cipher.
• www.gnupg.org , the GNU Privacy Guard, a free alternative to PGP. (Currently rapidly approaching version 1.0)
• Lsh ( http://www.lysator.liu.se/~nisse/lsh/.) is a GPL-ed implementation of the SSH2 protocols.

I don't know of any Open Source initiatives around this, but the standard you want to be looking at is PKIX-CMP. Check out the IETF draft.

There are also a lot of links to good white papers and other references at the Entrust Technologies resources page.