Slashdot Mirror

It seems IPv6 will be in use soon; so why tinker with DNS requests on IPv4?

Of course the extension supports IPv6. You'd have to be pretty dense to propose a new standard that doesn't.
http://tools.ietf.org/html/draft-vandergaast-edns-client-ip-00

Also, does anybody know how GEO locating an IP will be done on IPv6 (at least down to country level) ?

IPv6 geolocation will be done the exact same way as IPv4 geolocation: wild guesses and black magic.

Just implement RFC 3514 http://tools.ietf.org/html/rfc3514

Actually, rethinking global addressing schemes is on the table for many next-gen Internet projects I've spoken to researchers about. The reason is that router-table growth is not adequately handled in IPv6, nor is the meaning of an IP address very clear in the current Internet. These are major issues. Have a look at Jerome Saltzer's work on naming and addressing. If you want the short version, have a look here.

Once we get IPv6 everywhere, most ISPs will simply assign each user a fixed subnet, since that is so much easier and more efficient than keeping track of dynamic assignements.

Not necessarily. Unless the user explicitly asks for a routable /48 or /56, I'll bet most ISPs just give each user a /64 and have them autoconfigure, in which case there's always the Privacy Extensions for Stateless Address Autoconfiguration option.

". . .especially garbage ones that people without a lot of brains have been using for LANs in violation of the spec for years."

Which spec are you referring to? The IETF RFC1918 *specifically designates* 10.0.0.0/8 as reserved for use in private networks. Silly network admins, using the addresses *designated* by IANA/IETF as being used FOR THAT PURPOSE.

So much for all the people who thought that NAT was going to make IPv6 unnecessary - now that 10.0.0.0/8 has been allocated, that only leaves 2 more private address blocks which people can use for NAT, and when those are gone, NAT will break (or, more accurately, the people who get allocated the blocks everyone else is using as private address blocks will discover no one else on the Internet can actually contact their hosts - I sure wouldn't want one of those addresses as my 'global' address).

The IPv6 spec reserves space for the entire IPv4 network, making translation between the two a snap. Any modern OS less than 5 years old has IPv6 built in, including conversion between v4 and v6.

Ok, cool. Here's a scenario. You're on the machine you're using, right now. I'm on mine - and let's be generous, I'll run any OS you pick for me. I only have IPv6 connectivity. I want to view your website, send you an email, and chat with you over jabber. What do I need to do? Is there anything that I need you to do first?

Private addressing with NAT doesn't even need to change if you don't want to bother with it, just change your gateway IP's from v4 to v6 and there you go, bandaid applied until you actually truly need to upgrade everything.

Here's another scenario. Very similar to the above. I'm on my machine, whichever OS you pick, it's on private v4, and it's behind the NAT-PT you describe. (That transition mechanism in Network Address Translation-Protocol Translation.) Let's assume I already have a working, non-buggy NAT-PT implementation on my provider's DSL router. It's translating all my v4 packets into v6. How do I view your website?

You're right that, technically, we know how to solve all these problems. But we are a very, very long way from being able to deliver products that will work, and will interoperate with the existing network that's there.

NAT between v4 and v6 has been deprecated.

I see you haven't been following the IETF lately. Although some people are promoting flavors of dual-stack, NAT64 is back on the table. http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful-08

Yah, you can cut the rate of bad connections down by about 50%+ if you force the sending host to follow the RFCs.

- Incorrectly formatted HELO/EHLO greeting? 5xx Doesn't catch too many connections as the other end would have to massively screw up in order to trigger the invalid HELO rule.

- Giving a HELO/EHLO that is not a FQDN (fully qualified domain name)? 5xx Many botnets don't follow the FQDN rule and will give a randomly generated HELO name. I've never had a false-positive with checks like this.

- Giving a HELO/EHLO that does not resolve via DNS (see RFC 5321, section 2.3.5 where it talks about this issue in the 1st bullet point)? 5xx or 4xx if there was a DNSFAIL issue

- SPF record says "-all" for the MAIL FROM or HELO lookup and it fails to pass SPF? 5xx (At which point, you're simply following the instructions of the sender. If the record says "-all", they WANT you to reject non-conforming mail.)

- HELO/EHLO which purport to be from your own system? 5xx Know your servers, know who is allowed to put your domain into the HELO/EHLO and boot the pretenders. Easily done in Postfix with a few simple rules.

Most of those are standard checks in Postfix and will greatly reduce the amount of spam that you have to analyze in a more in-depth manner. Which results in a huge CPU/bandwidth savings if you can tell them to bugger off before the DATA command is issued.

I prefer to save block lists for the spam scoring system as there are too many false positives (and sometimes abuses of power) in the DNSBLs. Far safer to score rather then block - although Spamhaus' Zen list is extremely good.

DNSSEC still has some serious problems. EG, in our preliminary analysis, a shockingly large number of Netalyzr users are behind DNS resolvers that can't handle fragmented traffic. Yet a large number are behind resolvers that do request DNSSEC data.

Since DNSSEC replies are often large (and can easily be over the 1500B response limit), turning on DNSSEC could very well mysteriously slow down DNS by causing large timeouts as the UDP reply fails to arrive and the DNS resolver, after a long timeout, then resorts to a TCP connection, even when the signatures are not validated, simply because there are a lot of resolvers that request DNSSEC but actually can't handle large replies.

http://www.ops.ietf.org/lists/namedroppers/namedroppers.2009/msg01513.html

Re-defined entrenched URL standards (you cannot specify username/password in an Internet Explorer URL but this is a legal standard form of URL)?

HTTP URLs never supported username and password in the URL, according to the actual standards. RFC 1738 was the original URL specification. Section 3.1 said that some schemes supported username (and/or password) in the URL, giving the example of ftp urls. However, http was not one of the schemes supporting usernames or passwords, as you can see from the syntax description in section 3.3. None of the followup RFCs added user or password support to http URLs. In fact, RFC2396 noted in section 3.2.2 that the feature was not recommended even when it was supported. RFC3986 then deprecated the feature, even for ftp URLs. So user and password in http URLs was a non-standard feature Microsoft should never have implemented in the first place, and they were right to remove it. As far as I know, the only URL scheme which still officially supports username and password without deprecation is telnet, presumably on the grounds that anyone still using telnet doesn't care about the username and password being hacked anyway.

Re-defined entrenched URL standards (you cannot specify username/password in an Internet Explorer URL but this is a legal standard form of URL)?

HTTP URLs never supported username and password in the URL, according to the actual standards. RFC 1738 was the original URL specification. Section 3.1 said that some schemes supported username (and/or password) in the URL, giving the example of ftp urls. However, http was not one of the schemes supporting usernames or passwords, as you can see from the syntax description in section 3.3. None of the followup RFCs added user or password support to http URLs. In fact, RFC2396 noted in section 3.2.2 that the feature was not recommended even when it was supported. RFC3986 then deprecated the feature, even for ftp URLs. So user and password in http URLs was a non-standard feature Microsoft should never have implemented in the first place, and they were right to remove it. As far as I know, the only URL scheme which still officially supports username and password without deprecation is telnet, presumably on the grounds that anyone still using telnet doesn't care about the username and password being hacked anyway.

Thus, these guys are setting most of the major network standards, as well as implementing them.

I can't imagine how you manage to live your life without SMTP.

Why would he have to? SMTP over TLS is becoming quite common now. Gmail supports it and has for some time. Many other email providers also support it, although Yahoo and Hotmail do not.

Not always the case anymore. Web browsers and servers have implemented persistent connections (keep-alive) for a while. It's in the RFC.

You're both right, but the GP is righter. Yes, persistant connections have been around since 1999. But it still DOES starts the encrypted request all over again.

It is persistent, but it is also stateless. Makes sense when you think about it.

Not always the case anymore. Web browsers and servers have implemented persistent connections (keep-alive) for a while. It's in the RFC.

That's already been thought of. As an ISP, you don't get to just make up whatever rules you want to determine how many IPs you can assign, beyond a certain point, you have to apply RFC 2050, per the name resource policies:

Because it is.

In actuality, need is defined as the minimum number of IP addresses that will be required within a certain period of time in the future, according to Network Engineering plans that get submitted to ISPs (LIRs and RIRs) in order to apply for IPs; efficient utilization means utilizing 80% of the IPs to address internet hosts. IPs that will be required in the near future are needed and part of the justification.

Currently 25% immediate utilization is required after 6 months, 50% required after 1 year.

All existing IP allocations must be 80% utilized.

ARIN NRPM, 4.2.3.1. Efficient utilization ISPs are required to apply a utilization efficiency criterion in providing address space to their customers.

ARIN NRPM, 4.2.3.6 Reassignment to multihomed downstream customers: Under normal circumstances an ISP is required to determine the prefix size of their reassignment to a downstream customer according to the guidelines set forth in RFC 2050.
Specifically, a downstream customer justifies their reassignment by demonstrating they have an immediate requirement for 25% of the IP addresses being assigned, and that they have a plan to utilize 50% of their assignment within one year of its receipt.

4.2.3.3. Contiguous blocks: if a customer moves to another service provider or otherwise terminates a contract with an ISP, it is recommended that the customer return the network addresses to the ISP and renumber into the new provider's address space. The original ISP should allow sufficient time for the renumbering process to be completed before requiring the address space to be returned.

RFC 2050.

That's already been thought of. As an ISP, you don't get to just make up whatever rules you want to determine how many IPs you can assign, beyond a certain point, you have to apply RFC 2050, per the name resource policies:

Because it is.

In actuality, need is defined as the minimum number of IP addresses that will be required within a certain period of time in the future, according to Network Engineering plans that get submitted to ISPs (LIRs and RIRs) in order to apply for IPs; efficient utilization means utilizing 80% of the IPs to address internet hosts. IPs that will be required in the near future are needed and part of the justification.

Currently 25% immediate utilization is required after 6 months, 50% required after 1 year.

All existing IP allocations must be 80% utilized.

ARIN NRPM, 4.2.3.1. Efficient utilization ISPs are required to apply a utilization efficiency criterion in providing address space to their customers.

ARIN NRPM, 4.2.3.6 Reassignment to multihomed downstream customers: Under normal circumstances an ISP is required to determine the prefix size of their reassignment to a downstream customer according to the guidelines set forth in RFC 2050.
Specifically, a downstream customer justifies their reassignment by demonstrating they have an immediate requirement for 25% of the IP addresses being assigned, and that they have a plan to utilize 50% of their assignment within one year of its receipt.

4.2.3.3. Contiguous blocks: if a customer moves to another service provider or otherwise terminates a contract with an ISP, it is recommended that the customer return the network addresses to the ISP and renumber into the new provider's address space. The original ISP should allow sufficient time for the renumbering process to be completed before requiring the address space to be returned.

RFC 2050.

[...] the occasional twit who forgot that email is a *text* medium

A view commonly expressed by the occasional fossil who forgot that email stopped being a text-only medium almost two decades ago.

What? Of all the proposals that came out of the ROAD/IPng process the SIPP proposal -- which is what IPv6 is -- was the most minimal change.

It consisted of: 128-bit addresses with minimal class/AFI semantic, elimination of the header checksum and IP fragmentation, a useful clean-up of MTU issues, elimination of the option field (replaced with header extensions), an attempt to make existing higher-order optional configuration systems mandatory (multicast, stateless autoconfiguration, and network layer security -- all of which were defined to use essentially the same mechanisms as IPv4 was already using), and that's essentially it.

Oh wait, "ttl" was renamed to "hop limit" and the timer-based decrement requirement formally expunged.

"Most of it completely unnecessary" -> address length was considered necessary, the other features were certainly useful if not strictly necessary. The timer-based decrement of ttl had already been abandoned because of implementation complexity and the reality that queues as long as a full second became exceptionally rare in the early 1990s, so this change just codified existing practice. The unnecessary stuff was the optional->mandatory featureset and the changes to the options processing; the first divides into "ignored" and "already in place in practice anyway" and the second was aimed at a fastpath/slowpath router architecture where the fastpath was used for optionless packets (i.e., most packets), which was popular at the time. It also added room for expansion of the semantics encoded into a packet header.

Things that were not done: any meaningful change to IP hop-by-hop longest-match routing (for unicast/anycast), any separation of the overloading of network layer address and host identifier, any meaningful change to multicast forwarding or routing, anything more than a "gigantic address space makes collision less likely" approach to address collision avoidance, any consideration at all of address ephemerality, any support for interoperation within a heterogeneous catenet (i.e., dual stack was inevitable from day 1, which killed rapid widescale deployment, because v6-only hosts could not talk to v4-only hosts without complicated application layer gatewaying and so forth),

Consider the other proposals:

http://tools.ietf.org/html/rfc1752#section-7

CATNIP would have created an extensible "superheader" which would allow for a heterogeneous catenet, preserving most semantics among the differently-protocoled internetworks concatenated together; the "superheader" could be used natively. Superheaders grow "upwards" so if new semantics were required in parts of the global big-I Internet -- to support multimetric routing, for example -- that would be straightforward to do "in the middle" involving one or more networks (ISPs, corporates, whatever; it does not have to be the backbones). Modern NATs evolved out of (or at least very strongly informed by) CATNIP; even IPv6/IPv4 translation is being explored, which is a very CATNIP-esque idea. In particular, CATNIP did not require hosts to talk CATNIP, or change themselves at all. No dual-stack.

TUBA would have used an OSI profile and take advantage of the work already done for OSI. There was a substantial overlap of people involved in OSI and Internet routing work at the time, and pooling resources seemed like a good idea for people working on e.g. DECNET phase IV (and IS-IS) and the future of EGP/BGP protocols. OSI was also mandated by the US federal government (they recently did this for IPv6 too) so router vendors could move the packets around with existing routing systems reasonably well. CLNP as a packet format had some attractive features, and the addresses were extensible and "automatically" (a) split into network-routing-part and host-identity-part and (b) the network-routing-part had level-hierarchy specified already. TUBA would also have been dual-stack. On the other hand, TUBA *may* have been able to inh

Besides: if you really want, you can NAT IPv6. IPv6 has private address blocks just like IPv4.

Honestly, NATing might be useful just to avoid network renumbering if you're not big enough to get an AS number.

It's not *that* evil, because with IPv6, we'll have enough public addresses to make a one-to-one NAT scheme feasible, which will allow incoming connections to work transparently.

I propose to use JSON in all ajax-style applications instead of XML.

I can agree for that particular use case.

It's superior in nearly every way.

Depends on the usage. See below.

You'd be surprised how many ready-made parsers there are at json.org.

So, how do I pick the best one (or at least the "good enough" one) to use? The one that I can trust to be fully compliant, and that will be kept maintained and ported to new language/framework versions? Let's say, I need one for C++.

That's not necessarily true...

You misunderstand me. What I meant is that there are kinds of XML documents in which tags take up the minority of the content, and the majority is text. XHTML is a classic example; DocBook is another one. Essentially any scenario in which the basis is text, and the tags are markup on that text. Your SCORM example (that brings back some very unpleasant memories, by the way - I had to deal with this cursed thing) is about as far from it as it can get.

Now, for text markup, you can still represent it as JSON (after all, it's still a tree) - but just imagine how messy even a simple XHTML example would look that way.

Oh, by the way - JSON sample code in your post isn't actually JSON. In particular, you need to quote all keys, i.e. rather than:

      identifier: "resource1"

you have to write:

      "identifier": "resource1"

The only unquoted JSON identifiers are literals "true", "false", and "null". See RFC 4627 for reference (though the grammar on http://json.org/ also covers this).

RFC1123 is a standard, STD 3 is currently RFC1123. RFC2821 is currently not a standard of any kind. Check the listing in the RFC Index next time.

1123 Requirements for Internet Hosts - Application and Support. R. Braden, Ed.. October 1989. (Format: TXT=245503 bytes) (Updates RFC0822) (Updated by RFC1349, RFC2181, RFC5321) (Also STD0003) (Status: STANDARD)

2821 Simple Mail Transfer Protocol. J. Klensin, Ed.. April 2001. (Format: TXT=192504 bytes) (Obsoletes RFC0821, RFC0974, RFC1869, STD0010) (Obsoleted by RFC5321) (Updated by RFC5336) (Status: PROPOSED STANDARD)

0821 Simple Mail Transfer Protocol. J. Postel. August 1982. (Format: TXT=124482 bytes) (Obsoletes RFC0788) (Obsoleted by RFC2821) (Also STD0010) (Status: STANDARD)

We run a multi-step system.

First off, your mail server has to follow RFCs regarding HELOs. That means it has to be a valid HELO name, has to be a FQDN, and it has to map back to an address in a public DNS A/MX record. (We do *not* check beyond that as per the RFCs due to mail servers often being multi-homed and the IP address in the DNS record frequently won't match the IP address of the server that's talking to us.)

The HELO checks are cheap and will block 10-20% of inbound connections. Make sure you have a quick and easy way to whitelist servers which are improperly configured. You'll have to whitelist a few dozen during the first 2-3 months, then it will trickle down to about 1 per month.

Then I'd recommend blocking on a very very good DNSBL (like Spamhaus Zen). We personally choose not to.

After that, SPF checks and A/V filtering *during* SMTP time so that you can 5xx reject and not have to quarantine or deal with creating backscatter bounce messages. If you block using the Zen DNSBL, then you probably won't see many inbound viruses. But it's good to have A/V filtering at this point on inbound anyway. About 61% of our inbound messages have SPF rules that can be checked, and 33% of those get blocked at SMTP time due to "-all" failures.

At this point, we're dealing with maybe 40-50% of the original mail volume that was hitting our server. So now we feed it into a spam filtering system (we use SpamAsassin with amavisd-new). If you use Amavis, setup a 'soft' whitelist where you subtract 2 points for domains that you commonly do business with and subtract 5 points for specific email addresses which tend to score high.

We tag at 5.0 (adding a '[SPAM]' to the start of the subject line along with headers) and we quarantine at 9.0. The quarantine is simply done by moving the message into the user's Junk filter on the IMAP server using server-side Sieve filters. If the user wants to check their junk folder, they can either use webmail (which talks to the server via IMAP) or if they're already using an IMAP mail client, they can simply look in the subscribed Junk folder right in their mail client.

To give you an idea of numbers. Without the HELO checks and SPF checks, I would personally be getting about 6x more spam then I did before we implemented SA. We were killing off 83% of all spam just with HELO and a DNSBL check. With SA in the picture, I only see maybe 1/10th of what's left make it into my inbox. So we're keeping about 98% of all spam from hitting the user's inbox.

I could probably push that to 99%, but the risk of false positives would go up too much.

Also, what networks do you have the right to set up a resolver for? Comcast isn't technically "intercepting" anything -- these are requests going directly to their nameservers, that they then decide what to do with.

I have the right to setup and run my home network as I see fit.
If I choose to use DNS 4.2.2.2, or to stay on topic, if I choose to use Google DNS at 8.8.8.8, then that is my choice.

When I send a DNS request to 8.8.8.8 and comcast redirects that request to their DNS servers which reply as you say, how comcast chooses.

By me specifically NOT using comcast DNS and choosing 8.8.8.8, then by comcast blocking that packet and returning a response from their own name servers and spoofing the source 8.8.8.8 so it appears Google responded, they are intercepting DNS traffic (which qualifies as a part of 'anything')

$ host www.example.com 4.2.2.2
Server: 4.2.2.2
Address: 4.2.2.2#53

Non-authoritative answer:
Name: www.example.com
Address: 208.68.139.38

Comcast even submitted their broken DNS hijacking methods as an official protocol update to the Internet Engineering Task Force

http://tools.ietf.org/html/draft-livingood-dns-redirect-00

So when comcast admits to hijacking DNS, and has submitted the technical methods they use to do this to become an official standard, "some guy on slashdot" saying comcast is not intercepting anything carries little weight...

The claims look quite similar to compressed RTP, which is used to shorten IP/UDP/RTP headers for VoIP calls from 40 bytes to 2 and has been an RFC since 1999. For that matter, this patent could describe MPLS as well.

RFC 2323 May be what he is talking about. (Was going to RTFA but sleep sounds like a better choice for me)

As for my RFC reading, i only read the April 1 ones, they seem to be the best for on the can reading :)

This is possibly the best post that has ever been made at /.

I have been wanting the ability to mask HTTP REFERRER [sic sic] since practically Day One of getting on the WWW [and certainly since the first time I ever put a sniffer on the network stack and saw all the personal information that was being given away to God-only-knows whom].

It's hard to believe that it's taken us almost two decades to be able to surmount the single most egregious mistake that Tim Berners-Lee made in designing [or mis-designing] the web.

You forgot to do something to filter out those pages with the Evil Bit set (see RFC 3514).

I wondered how this will be addressed and the numerous "it will be fixed, don't worry" posts were not really helpful. TFA was and linked to "a TLS extension to cryptographically tie renegotiations to the TLS connections they are being performed over, thus preventing this attack" draft.

Actually most routers don't have a fully recursive server - they have a "proxy" (or "forwarder").

See my RFC 5625 for more details, and some explanation for why the router even has this feature. The short answer is that it's so that the router can give a consistent DHCP OFFER before it knows what the upstream DNS servers are. See also slides I presented at the IETF DNSOP working group last week: http://tools.ietf.org/agenda/76/slides/dnsop-5.ppt

If the proxy is open on the WAN port then it'll forward all queries to the ISP's real recursive servers, and that's where the recursion happens. It may look as if the router's DNS proxy is recursive, but in most cases it isn't.

The DNS query results from the ISP will go back up the DSL / cable line back to the router, which will then send then back down the line to the (probably spoofed) source IP address of the original request.

Actually most routers don't have a fully recursive server - they have a "proxy" (or "forwarder").

See my RFC 5625 for more details, and some explanation for why the router even has this feature. The short answer is that it's so that the router can give a consistent DHCP OFFER before it knows what the upstream DNS servers are. See also slides I presented at the IETF DNSOP working group last week: http://tools.ietf.org/agenda/76/slides/dnsop-5.ppt

If the proxy is open on the WAN port then it'll forward all queries to the ISP's real recursive servers, and that's where the recursion happens. It may look as if the router's DNS proxy is recursive, but in most cases it isn't.

The DNS query results from the ISP will go back up the DSL / cable line back to the router, which will then send then back down the line to the (probably spoofed) source IP address of the original request.

The problem is that even the cookie spec says that conforming servers have to obtain informed consent before any use of cookies. This includes disclosing how any 3rd party is using the data. So, unless your rating service is willing to disclose, both to you and the end user, exactly how they collect, analyse, store, forward, archive, and sell the data, your web site isn't in conformance with the spec.

RFC 2965 for cookies says the Europeans are 100% right.

6. PRIVACY

Informed consent should guide the design of systems that use cookies.
A user should be able to find out how a web site plans to use
information in a cookie and should be able to choose whether or not
those policies are acceptable. Both the user agent and the origin
server must assist informed consent.

Quite simply, people have a right to expect that web sites and their operators conform to the RFCs. Privacy is a huge problem, and it's only going to get worse.

And considering what is at stake, the decision to use one rating service over another is unlikely to be based on their technical method of tracking.

Bot traffic is a huge problem, as are pay-to-click scams. Unfortunately, tracking via cookies is an extremely naive way of trying to ferret out either of these problems. Ultimately, if you're suspicious and want to build up a case, you have to go back to the server logs anyway ... unless you on occasion insert a "survey" like the following into the data stream:

Click Subcontractor Performance Survey

We are evaluating the cost/performance of our pay-to-click program. Please choose one of the following options.
[_] I am getting less than 5 cents for every link I click.
[_] I am getting between 5 and 10 cents for every link I click.
[_] I am getting more than 10 cents for every link I click.
[_] I am not being paid when I click on a link.

And for those following along - yes, this actually catches people who are participating in pay-to-click scams - especially if you add a captcha to it to make it look more like you're not just trying to catch the low-hanging morons^fruit. Randomize the order, include hidden values, and you'll even catch some bots.

Feel free to cite me how to use third party tracking without cookies without giving up user security by sending everything in the URI.

Guess what - cookies don't just reside on your machine. They're transmitted with every page request, same as all the POST and GET data. And because even some programmers don't think for two seconds and realize this, they think that cookies are somehow "more secure".

They're no more secure (actually, they're less secure) than POST data. Think about it - POST data has the advantage of not persisting on the host machine between uses, so it's actually more secure than a cookie.

As for 3rd party tracking, there are plenty of ways. Go buy a good book on javascript.

And before you say "they can turn javascript off", that same criticism applies to cookies.

Look, I don't want to be harsh, but the article is uninformed fud, and the european law only codifies what RFC 2965 already mandates.

6. PRIVACY

Informed consent should guide the design of systems that use cookies.
A user should be able to find out how a web site plans to use
information in a cookie and should be able to choose whether or not
those policies are acceptable. Both the user agent and the origin
server must assist informed consent.

So, what's so bad about informed consent? Even the RFC says that both the server and the user agent must enforce this. In other words, you can't just set ANY cookies w/o first getting informed consent, or letting the user choose to opt in/out, or your site doesn't conform to the RFC - it's broken.

Bravo to the Europeans for finally forcing "web designers" to get their act into shape.

Actually, the cookie spec says that web sites have to do what the Europeans propose:

6. PRIVACY

Informed consent should guide the design of systems that use cookies.
A user should be able to find out how a web site plans to use
information in a cookie and should be able to choose whether or not
those policies are acceptable. Both the user agent and the origin
server must assist informed consent.

Note the wording: "Both the user agent and the original server must assist informed consent."

Its not optional (it says "must", not "may"), and it's not something that the web server can simply delegate to the user agent (browser). If your web site doesn't do this, your site is broken according to the RFC. the Europeans want to bring web sites into conformity with the spec. How is that a bad thing?

First, the cookie spec is in complete agreement with the European law:

6. PRIVACY
Informed consent should guide the design of systems that use cookies.
A user should be able to find out how a web site plans to use
information in a cookie and should be able to choose whether or not
those policies are acceptable. Both the user agent and the origin
server must assist informed consent.

Now as for your:

Session or server-side variables may also be used for this, but that's more work for the web designer, who usually is up to his neck trying to support different versions of IE misbehavior.

So the real problem, like always, is Microsoft :-)

The real problem is that cookies have really been abused by "web designers." Real programmers don't like them for several reasons:

1. We're mostly privacy nuts. We know how data can be misused because we've seen it happen up close and dirty too many times;
2. The spec makes it clear that there is a very low bound as to the number of cookies that conforming browsers need to support - see section 5.3 - 300 cookies total, 4k per cookie, 20 cookies per site.

   Applications should use as few and as small cookies as possible, and
   they should cope gracefully with the loss of a cookie.

   5.3.1 Denial of Service Attacks User agents MAY choose to set an
   upper bound on the number of cookies to be stored from a given host
   or domain name or on the size of the cookie information. Otherwise a
   malicious server could attempt to flood a user agent with many
   cookies, or large cookies, on successive responses, which would force
   out cookies the user agent had received from other servers. However,
   the minima specified above SHOULD still be supported.

   But as I note at the bottom, it's not just a security issue - it's also a performance issue. (and this ignores the fact that certain versions of IE fail to meet the minimum of 4k per cookie, failing at 2083 bytes, while some other browsers stupidly allow over 100k per cookie as a "feature".

3. Cookies leak information
4. Cookies can be turned off, so depending on them is, by definition bad programming
5. Poor performance over time. We're seeing slowdowns in browsers because of the enormous number of cookies that are stored. Like your browser cache, your cookie cache takes time to read in, parse out, and search, so your browser does slow down over its' lifetime, in part, because of scads of cookies.

First, the cookie spec is in complete agreement with the European law:

6. PRIVACY
Informed consent should guide the design of systems that use cookies.
A user should be able to find out how a web site plans to use
information in a cookie and should be able to choose whether or not
those policies are acceptable. Both the user agent and the origin
server must assist informed consent.

Now as for your:

Session or server-side variables may also be used for this, but that's more work for the web designer, who usually is up to his neck trying to support different versions of IE misbehavior.

So the real problem, like always, is Microsoft :-)

The real problem is that cookies have really been abused by "web designers." Real programmers don't like them for several reasons:

1. We're mostly privacy nuts. We know how data can be misused because we've seen it happen up close and dirty too many times;
2. The spec makes it clear that there is a very low bound as to the number of cookies that conforming browsers need to support - see section 5.3 - 300 cookies total, 4k per cookie, 20 cookies per site.

   Applications should use as few and as small cookies as possible, and
   they should cope gracefully with the loss of a cookie.

   5.3.1 Denial of Service Attacks User agents MAY choose to set an
   upper bound on the number of cookies to be stored from a given host
   or domain name or on the size of the cookie information. Otherwise a
   malicious server could attempt to flood a user agent with many
   cookies, or large cookies, on successive responses, which would force
   out cookies the user agent had received from other servers. However,
   the minima specified above SHOULD still be supported.

   But as I note at the bottom, it's not just a security issue - it's also a performance issue. (and this ignores the fact that certain versions of IE fail to meet the minimum of 4k per cookie, failing at 2083 bytes, while some other browsers stupidly allow over 100k per cookie as a "feature".

3. Cookies leak information
4. Cookies can be turned off, so depending on them is, by definition bad programming
5. Poor performance over time. We're seeing slowdowns in browsers because of the enormous number of cookies that are stored. Like your browser cache, your cookie cache takes time to read in, parse out, and search, so your browser does slow down over its' lifetime, in part, because of scads of cookies.

You are 100% incorrect.

I would think even mere insertion of a USB device into a computer could lead to all sorts of problems

The mere insertion of a USB device has its problems. First, you have to differentiate. Say, on a WinXPsp2 machine, a USB device has no working autostart mechanism. You can circumvent that, e.g. by using those "U3" devices that emulate a CD drive (Autostart is working fine with CD drives if you didn't disable autorun at all) or like the Conficker worm does, by displaying an "open folder" icon that will result in the action of calling a program. But by default, the recent MS OSses do not allow autorun via USB Sticks.

Now, that having said, there still are some problems with the mere insertion of an USB device. The one I know of is that typically Windows makes a "bing" noise, when an USB stick is inserted. This means, that the Windows "USB insertion bing noise".wav is getting read and thus the "read" timestamp of that file gets modified. This results in the fact that after plugging in an USB stick, the forensic analysist might not be able to determine, when an USB stick has been plugged into that machine the last time prior to the said USB stick having been plugged into it. This might be especially of concern if you want to find out how a certain piece of malware entered a PC which happened to be via a USB stick exactly the last time an USB stick was plugged into the foreniscally examined PC.

So, let's go on...

that's why they image the drives through special "read-only" adaptors (apparently harder with SATA nowadays) and then analyse the image.

Well, yes, sort of. Cloning images of drives with "read-only" adaptors is done for post mortem analysis. I mean the following:

If the investigator is called to a site with an already unplugged device, this is the usual procedure - that way it is ensured, that no evidence is altered in any way.

However, the situation is completely different, when the investigator is faced with a live system. Because there, you have a huge amount of information that will get destroyed by unplugging the system. In former times, investigators where taught to unplug the system and then to clone the drive with a write-blocker, like you said. But this removes volatile evidence like:

• registers, cache

• routing table, arp cache, process table, kernel statistics, etc.

• memory

• temporary file systems

See RFC 3227 - Guidelines for Evidence Collection and Archiving for more. So, when encountering a live system, switching it off and cloning the disk with a write-blocker is so much more problematic in terms of destroying evidence than plugging in a foreniscally sound USB thumb drive, than it gets.

You see, the consequences of plugging in an foreniscally sound device - and plugging it in will have some consequences and ultimately result in the destruction of some evidence - can be reproduced and thus can be tolerated in court without problems. NOT plugging in that device will lead to much much greater destruction of evidence.

Why speculate based on the FCC filings? The entire scheme is described right here: http://tools.ietf.org/html/draft-livingood-woundy-congestion-mgmt

I am still surprised that a better protocol for proximity favored peer connections wasn't developed for BitTorrent and other P2P systems to maximize performance by connecting to peers on the same or close-by networks.

It is actually being developed, in the IETF ALTO working group. And BitTorrent Inc. is actually an active contributor of the current draft.

I am still surprised that a better protocol for proximity favored peer connections wasn't developed for BitTorrent and other P2P systems to maximize performance by connecting to peers on the same or close-by networks.

It is actually being developed, in the IETF ALTO working group. And BitTorrent Inc. is actually an active contributor of the current draft.

TFA is badly written and factually inaccurate.

All that is actually going on here is that icann is allowing use of IDN (which is already in use at lower levels of the heirachy) in the root. The standards for IDN already specify exactly how the names are encoded.

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

Well, yes, there is a way! Any router can make that decision! I hope you haven't forgotten about RFC 3514?

Someone already tried IPv7 in 1993.

If we are gonna skip numbers, why "6"?, sounds like the devil's work to me. They even use "hex" numbers in the dot notation... (which is 8 groups of 4 hex digits... so why not IPv8?)

8 looks too much like 6. We'll have to bring back IPv9 instead.

This is precisely why I think that the whole concept of an ISP is fundamentally flawed. Your Internet connection shouldn't be dependant on a company, government, or any other entity. Instead, we should build a mesh of wireless devices, where your computer communicates with nearby ones, they communicate with those further away, and so on all the way to the other side of the world. To solve the issues with latency, we could still have large publicly owned backbone wires serving the function of highways; but your actual connection would be provided by everyone near you.

This kind of systen would make it utterly impossible to cut anyone off the Net, and if implemented properly, would also make communications pretty much untracable. However, I'm afraid that it's already too late: now that powers that be know the threat networking presents them, they'll look at any such development like a hawk. Perhaps small and cheap "insect robots" could be used to get the base mesh going?

Well, this is the idea behind the http://www.funkfeuer.at/ city-wide network in Vienna, and part of the motivation between the MANET work in the IETF http://www.ietf.org/dyn/wg/charter/manet-charter.html.

I'm sorry, but I don't grok how a router can tell an IP packet has an illicit payload.

Then perhaps you need to read RFC 3514 a little more closely.

We already have a mechanism for that.

It's called RFC 795.
http://tools.ietf.org/html/rfc795

Why stop there?

Perhaps it is just for the IPv6 spec with the 6 crossed out and 7 in its place after all.

There alredy is a IPv7:
http://tools.ietf.org/html/draft-iab-ipversion7-00

From the charter:

The Multipath TCP (MPTCP) working group develops mechanisms that add the capability of simultaneously using multiple paths to a regular TCP session. The primary output of the group will be the protocol extensions needed to deploy MPTCP, and adaptations to congestion control to safely support multipath resource sharing.