Slashdot Mirror

There are popups, browser hijacking and unfortunate search results that could subject people to porn even though they did not actively seek it out. I remember hearing a story a few years ago of a public school teacher showing kids how to use Google and she suggested typing in "Spice Girls" and at the time one of the top results had nude photos of Geri Halliwell.

But nude photos aren't porn. Even *erotic* nude photos (which I suppose is what you're talking about) aren't porn.

Pop-ups for porn sites only happen if you go to unsavory sites in the first place, too. When was the last time you got any of those on a respectable site?

Browser hijacking? An urban myth that you swallowed hook, line and sinker. What would porn site even gain from that?

Finally, "unfortunate search results" still require you to click on them. If you search for "Gerri Halliwell", to pick up your example, and then get a link that says "nude photos of Gerri Halliwell!", you can still refuse to check it out.

The controversial .xxx domain, if it ever gets approved, would allow people and countries that do not want to see porn to have a way to ensure that they will never see it unless they intentionally go to those sites. That is assuming that porn sites agree to migrate. After all, migration would be in their best interests as a way of heading off eventual government regulation that would likely be more restrictive. They likely wouldn't lose any money since porn always sells.

The IETF disagrees with you.

http://tools.ietf.org/html/draft-vandergaast-edns-client-ip-01

Problem solved.

I'm the founder of OpenDNS (and long-time slashdot reader).

This article is not very accurate for a number of reasons. First, both my service (OpenDNS) and Google's are co-located in similar POPs to all of the major CDNs which causes this problem to be largely avoided. The author of the blog post used a tiny sample size and tested mainly from EC2 instances, neither of which helps his cause.

1) EC2 instances are BY DESIGN not co-located in the same place as major peering infrastructure because that real estate costs more. They are one or two hops away. People use EC2 for compute power, not for routing performance. So he needs to use something like Keynote or Gomez to test from home connections. If he had, he'd see it doesn't impact anything, and often improves performance, especially in the US. We don't have POPs in Asia yet, though they are coming this year, and when we do, we'll improve things for him.

2) Akamai is the only CDN where this will ever be perceptible because their deployments are so dense. They have 3000+ pops which means they will also be able to target more precisely. But this is being worked on RIGHT NOW in the IETF -- http://tools.ietf.org/html/draft-vandergaast-edns-client-ip-01

Anyways, this is really not the issue the author makes it out to be, and for the edge cases, they are being worked on.

Thanks,
David

Seems like a decent idea, though you'd also need a system for replacing failed monkeys, motivating monkeys that are slacking, etc. Fortunately, there's an RFC that covers all of this.

• FTP
• Telnet
• FTP mail (which predated SMTP)
• UUCP
• Kermit
• IBM IMS
• INGRES
• the original MUD
• MRDS

• Maybe you should just read A Brief History of the Internet which lists FTP, email, telnet, NCP, TCP, UUCP, and BITNET gateways as being developed and in production before MS-DOS was released in 1982.

  CBBS was a dial-in BBS (think web forum without the WWW, HTTP, browser, or pretense) in 1978 on CP/M.

  IBM had terminals connecting to remote servers -- a serious precursor to proper client/server -- in 1964. The first ATM -- clearly a client-server technology -- was installed in 1970. Usenet was invented in 1979. Essex MUD was in 1979. Ask the Computer History Museum about networking.

  Creeper traversed networks in 1971. Wikipedia calls it a virus, but the description they give is more of a worm. It ran on TENEX and infected systems over ARPANET.

  In 1971, RFC 189 described a method and system for submitting jobs to a mainframe from remote systems over ARAPANET and to receive the results. It includes the connections, protocols, the mapping of ASCII to EBCDIC for systems that used ASCII to not need to translate on their end, a name for the whole thing (NETRJS), and several details of implementation.

  Need any more examples?

  Why yes, yes, computer history is a hobby of mine.

• FTP
• Telnet
• FTP mail (which predated SMTP)
• UUCP
• Kermit
• IBM IMS
• INGRES
• the original MUD
• MRDS

• Maybe you should just read A Brief History of the Internet which lists FTP, email, telnet, NCP, TCP, UUCP, and BITNET gateways as being developed and in production before MS-DOS was released in 1982.

  CBBS was a dial-in BBS (think web forum without the WWW, HTTP, browser, or pretense) in 1978 on CP/M.

  IBM had terminals connecting to remote servers -- a serious precursor to proper client/server -- in 1964. The first ATM -- clearly a client-server technology -- was installed in 1970. Usenet was invented in 1979. Essex MUD was in 1979. Ask the Computer History Museum about networking.

  Creeper traversed networks in 1971. Wikipedia calls it a virus, but the description they give is more of a worm. It ran on TENEX and infected systems over ARPANET.

  In 1971, RFC 189 described a method and system for submitting jobs to a mainframe from remote systems over ARAPANET and to receive the results. It includes the connections, protocols, the mapping of ASCII to EBCDIC for systems that used ASCII to not need to translate on their end, a name for the whole thing (NETRJS), and several details of implementation.

  Need any more examples?

  Why yes, yes, computer history is a hobby of mine.

Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.

RFC2616, 15.1.3

all browsers follow this.

actually, your browser will do this for you anyway:

RFC 2616, 15.1.3:
Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.

You search for some keywords over SSL and click on a non-https link in the result page. BAM, the Referer now points to the result page, which contains the keywords you just used in its URL.

According to RFC2616 (HTTP/1.1) section 15.1.3 "Encoding Sensitive Information in URI's", "Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol."

(For those of you playing along at home: I've noticed that use of the term "weasel-word" is usually a cover for "I can't be arsed to do my homework, so I'll just parrot something I read on Wikipedia".)

I did your homework for you!

I demand an RFC

RFC 2551 is a good start.

They fail to realize that putting porn behind a TLD makes it easier to filter it out so children can't find it.

You fail to realise that it doesn't and especially not unless the filtering is done at the resolver (eg: CNAME records return A).

Now, repeat after me: "DNS is not and has never been a content labeling or classification system".

As I maintain my own DNS servers and such, I was curious how this worked. Here's what I learned with 15 minutes of research:

My first stop was to see the root.zone and I looked for these new TLDs, curious to see how they would show up in a Latin-based zone file. Ah, I spotted these odd XN-- zones and then knew what to dig into more.

Take for instance (I pasted a Unicode domain, but Slashcode won't show it) which is handled by ns[1-3].dotmasr.eg.:

$ dig ns (Unicode domain)

; > DiG 9.6.2-P1-RedHat-9.6.2-3.P1.fc12 > ns (Unicode domain) ;; QUESTION SECTION: ;.(Unicode domain) IN NS ;; ANSWER SECTION:
. 3600(Unicode domain) IN NS ns1.dotmasr.eg.
. 3600 (Unicode domain)IN NS ns2.dotmasr.eg.
. 3600(Unicode domain) IN NS ns3.dotmasr.eg.

If you look in the root.zone file, you will see that the ASCII/Latin version of this zone is really XN--WGBH1C.:
XN--WGBH1C. NS NS1.DOTMASR.EG.
XN--WGBH1C. NS NS2.DOTMASR.EG.
XN--WGBH1C. NS NS3.DOTMASR.EG.

TLD Reserved Domains has a list of the current mappings. ToASCII and ToUnicode are the methods to convert back and forth which links to RFC 3490 which has the nitty gritty details.

(meh, Slashcode doesn't support Unicode encoding, but I can see the Unicode domain name I am pasting in before I hit Preview in Firefox)

Also, the whole switching from right to left in Latin characters to left to right in some Unicode is odd when trying to edit!

You don't have an excuse like 'oh I didn't know this was a porn site!' when caught. You can't just say you were searching Large fresh melons and accidentally found such a smutty site.

Yes, you can. This was addressed ages ago, in RFC 3675.

It's really the combination two problems. 1) The particular OS is configured to prefer 6to4 connectivity to native IPv4, 2) 6to4 isn't supported well on many ISPs for various reasons, and there can also be LAN issues which make 6to4 not work well, or at all. So you could say #2 here is a problem with 6to4 implementation.

Most OSes by default (Windows, and most distros of Linuxes, and BSDs) are configured to prefer using a native IPv4 address before an IPv6 6to4 or Teredo (another automatic tunneling method) address (see RFC 3484) for connections. Apparently OS X isn't. So, when a site has both an IPv4 and an IPv6 address, OS X will prefer the IPv6 address even if the system's IPv6 connectivity is via 6to4. Since 6to4 is often slow, slow to start, or just plain doesn't work on a particular LAN/ISP depending on a plethora of reasons, you'll get timeouts and such. This is one of the reasons why services like Google have a separate domain name for IPv6 based services (ipv6.google.com), instead of just putting up both A and AAAA DNS records.

If using a 6to4 connection, YMMV depending on your LAN configuration, your ISP, routes it receives, proximity to a 6to4 relay, whether the 6to4 anycast address (192.88.99.1) your ISP sees routes to a reasonable place, etc. This is why it's so problematic. There are a lot of variables which can make it either not work at all, or affect its performance. Plus, being a tunneling scheme, performance is already degraded vs. a "native" protocol even if it worked perfectly.

6to4 works by constructing an IPv6 address in a special range reserved for it (2002::/16) which encodes your IPv4 address into the IPv6 address (i.e. if your IPv4 is 192.0.2.10, the 6to4 IPv6 prefix will be 2002:c000:20a::/48, out of which you can subnet and make /64s, etc). The traffic is then sent over a IPv4 6in4 (IPv4 protocol 41) tunnel to the "nearest" 6to4 relay which is reached via the 6to4 anycast address (unless the relay server is configured manually). Unfortunately, many ISPs have this anycast routed to a far away relay. For instance, two friends' separate cable ISPs I tested this on had the traffic routing from eastern Canada and the western USA to a relay server in Sweden!

Traffic from the IPv6 internet to the 6to4 space is routed from its source to the "closest" relay server advertising the 6to4 space in BGP. The relay extracts the IPv4 address from the 6to4 IPv6, and the IPv6 packet is encapsulated in a IPv4 6in4 tunnel packet and sent to the extracted IPv4, which should be the user's 6to4 router. This trip from the origin to the 6to4 relay can also often be a long distance, depending on the origin of the traffic, and then of course the tunnel packets have to make their way over the IPv4 internet to your 6to4 router. Obviously this can make for some pretty serious asymmetric routing which can cause its own problems.

Other problems such as 6in4 being blocked anywhere along the forward or reverse path to the user's 6to4 router will cause it to fail. Also, if the implementation isn't smart enough to know that a particular box is behind a NAT, and constructs a 6to4 IPv6 address based on the NATed address instead of the public IPv4, it will obviously fail, since the return traffic will be sent to a private IPv4 address by the relay server instead of the user's public. I don't know if OS X does this or not. And finally, most firewall/nat boxes with a single public IP shared by many computers can only support a single 6in4 (and therefor 6to4) tunnel behind them, since unless they inspect and track the tunneled IPv6 packets (plus some other implementation enhancements), there's no way it can know which inside host to send return traffic to when it deNATs them.

Note, that none of this is a basic failing of IPv6! The problems here are with implementation details of a well intentioned automatic tunneling method designed to provide IPv6 access to IPv4 only users in a "automatic" manner which doesn't

Periodically there are proposals to mandate the use of a special top level name or an IP address bit to flag "adult" or "unsafe" material or the like. This document explains why this is an ill considered idea from the legal, philosophical, and particularly, the technical points of view.

Can anyone tell me why someone wouldn't want the .xxx domain to happen? What possible downside is there to it?

RFC 3675 covers it pretty well

Yes, because this will work just as well as RFC 3514 - The Security Flag in the IPv4 Header.

Hi, Nick...

Yes, it would be better if Google were to deploy their own 6to4 relays, but when I asked their IPv6 operations people why they won't do that, their answer was basically that it would be a lot of work and it still wouldn't solve their problem. There would still be too many hosts behind 6to4 tunneling routers that are, in turn, behind firewalls that block returning protocol 41.

You should look at 6RD, which fixes all the really bad problems with 6to4 and gives service providers a proven upgrade path that doesn't force them to forklift upgrade all their IPv4-only edge router gear. We should start seeing consumer home gateway equipment and provider provisioned CPE routers that support 6RD in the not-too-distant future. Comcast is planning to use 6RD in its upcoming trials, and Google is supportive of it as well.

It would be nice if people read the standards...

FWIW, I'm pretty sure the actual problem is DNS. Specifically, he's misconfiguring things such that IPv4 DNS requests return AAAA records indicating an IPv6 address when there is no end-to-end IPv6 connectivity. A DNS server that is queried via IPv4 should only return IPv4 addresses to the querant. See also http://www.ietf.org/rfc/rfc4074.txt.

So he's basically intentionally misconfigured the DNS server, and then is complaining about IPv6 connectivity "not working" for 6over4 when he's not running dual stacks and Ipv4 bridging of IPv6 traffic on both ends (via proxies or via relay routers; see http://www.ietf.org/rfc/rfc3068.txt for details).

IPv6 will *never* take off if people keep putting bandages on IPv4 to keep it alive instead of configuring things correctly. It's time to shoot IPv4 in the head. Google is completely reachable via the 6bone, and they are configured correctly; pretty much if you are anywhere in Silicon Valley, you probably have 6bone connectivity to Google, Apple, and a number of other companies. Also all U.S. Federal agencies have been upgraded to IPv6 since early 2008.

-- Terry

It would be nice if people read the standards...

FWIW, I'm pretty sure the actual problem is DNS. Specifically, he's misconfiguring things such that IPv4 DNS requests return AAAA records indicating an IPv6 address when there is no end-to-end IPv6 connectivity. A DNS server that is queried via IPv4 should only return IPv4 addresses to the querant. See also http://www.ietf.org/rfc/rfc4074.txt.

So he's basically intentionally misconfigured the DNS server, and then is complaining about IPv6 connectivity "not working" for 6over4 when he's not running dual stacks and Ipv4 bridging of IPv6 traffic on both ends (via proxies or via relay routers; see http://www.ietf.org/rfc/rfc3068.txt for details).

IPv6 will *never* take off if people keep putting bandages on IPv4 to keep it alive instead of configuring things correctly. It's time to shoot IPv4 in the head. Google is completely reachable via the 6bone, and they are configured correctly; pretty much if you are anywhere in Silicon Valley, you probably have 6bone connectivity to Google, Apple, and a number of other companies. Also all U.S. Federal agencies have been upgraded to IPv6 since early 2008.

-- Terry

Do what works.
Don't get caught.

And that unfortunately, is partly why some people believed (albeit wrongly) that the internet is going to break this week.

The problem with only doing enough to make something "work" is that it doesn't cope with the edge cases, but sometimes those edge cases are important. Introducing DNSSEC exercises many more of those edge cases.

For more information on how not implementing the DNS RFCs properly lead to poor middlebox implementations that could break the internet for some people see RFC 5625.

You should try to IETF tools site, they have very good linking of the various RFCs and how they depend on each other. For instance, if you look at http://tools.ietf.org/html/rfc5395 you can click on the RFC it replaces (=obsoletes) or the RFCs it updates.

I presume the RTFA complains precisely about the index RFC, sometimes referred as RFC 0.

And yes, it is spaghetti-like and not always up-to-date.

You know the BCC list can still be intercepted at the recipient's server, right?

Not if the sender is well-behaved:

In the first case, when a message containing a "Bcc:" field is prepared to be sent, the "Bcc:" line is removed even though all of the recipients (including those specified in the "Bcc:" field) are sent a copy of the message. In the second case, recipients specified in the "To:" and "Cc:" lines each are sent a copy of the message with the "Bcc:" line removed as above, but the recipients on the "Bcc:" line get a separate copy of the message containing a "Bcc:" line. (When there are multiple recipient addresses in the "Bcc:" field, some implementations actually send a separate copy of the message to each recipient with a "Bcc:" containing only the address of that particular recipient.)

Also:

Each recipient address from a TO, CC, or BCC header field SHOULD be copied to a RCPT command (generating multiple message copies if that is required for queuing or delivery). This includes any addresses listed in a RFC 822 "group". Any BCC fields SHOULD then be removed from the headers.

meanwhile, government already has complete access to everyone's communication.

Remember, the Internet routes around damage - IF you let it.

Want to avoid government wire-sniffing or wireless-sniffing detection? Make use of RFC 2549.

... firewalls would be so much simpler:

The Security Flag in the IPv4 Header

(I saw some other Slashdot comment with this link in it, but it just fits so well here!)

And if Congress legislates that in all email messages, the "From:" headers cannot be forged, THAT will stop SPAM. I'm certain of it. Just like this will stop caller ID spoofing.

Just require that the Evil Bit be set to 1.

As a network analyst, I care more about the IP laws as defined by http://www.ietf.org/rfc.html
(TCP/IP in case anyone missed the joke)
Wouldn't it be great if real life laws were codified by RFCs?

The only reason that HTTP is "text-based" is because that's the way UNIX is designed and it derived from the UNIX community.

That seems like a stretch to me. HTTP was text-based largely because most other similar network protocols to date were text-based - most notably, FTP, and that one was originally spec'd in 1971, when Unix was still in its infancy - and definitely not in a state where it was usable for network servers. Indeed, the original FTP RFC (114) only mentions reference implementations on Multics and ITS.

There are plenty of open source technical specs.

http://www.ietf.org/download/rfc-index.txt

I believe there may be at least one loophole. RFC 2549 describes a method for applying QOS in a way the FCC may have no right to regulate.
RFC 2549

This isn't the real April Fool's RFC. The real one is RFC 5841, TCP Option to Denote Packet Mood.

http://www.ietf.org/rfc/rfc3041.txt

No. Dotted-decimal notation is the only acceptable way to represent an IPv4 address in a URI according to RFC 3986. That RFC even specifically mentions that many implementations that process URIs make use of platform-dependent system routines, such as gethostbyname() and inet_aton(), to translate the string literal to an actual IP address and that may allow ways around filtering software.

If it is explicitly against the RFC then browsers shouldn't allow it.

http://tools.ietf.org/html/rfc3986#page-20
http://tools.ietf.org/html/rfc3986#section-7.4

No. Dotted-decimal notation is the only acceptable way to represent an IPv4 address in a URI according to RFC 3986. That RFC even specifically mentions that many implementations that process URIs make use of platform-dependent system routines, such as gethostbyname() and inet_aton(), to translate the string literal to an actual IP address and that may allow ways around filtering software.

If it is explicitly against the RFC then browsers shouldn't allow it.

http://tools.ietf.org/html/rfc3986#page-20
http://tools.ietf.org/html/rfc3986#section-7.4

We don't. Dotted-decimal notation is the only acceptable way to represent an IPv4 address in a URI according to RFC 3986. That RFC even specifically mentions that many implementations that process URIs make use of platform-dependent system routines, such as gethostbyname() and inet_aton(), to translate the string literal to an actual IP address and that may allow ways around filtering software.

If it is explicitly against the RFC then browsers shouldn't allow it.

http://tools.ietf.org/html/rfc3986#page-20
http://tools.ietf.org/html/rfc3986#section-7.4

We don't. Dotted-decimal notation is the only acceptable way to represent an IPv4 address in a URI according to RFC 3986. That RFC even specifically mentions that many implementations that process URIs make use of platform-dependent system routines, such as gethostbyname() and inet_aton(), to translate the string literal to an actual IP address and that may allow ways around filtering software.

If it is explicitly against the RFC then browsers shouldn't allow it.

http://tools.ietf.org/html/rfc3986#page-20
http://tools.ietf.org/html/rfc3986#section-7.4

Apparently POP3 is from 1988. A 1993 RFC talks about it as a "draft" standard, but also mentions "the optional APOP facility (which is in interoperable, operational use in at least three implementations)" suggesting that despite being a draft standard it was already in wide use.

So you should be fine to use pop3.

Apparently POP3 is from 1988. A 1993 RFC talks about it as a "draft" standard, but also mentions "the optional APOP facility (which is in interoperable, operational use in at least three implementations)" suggesting that despite being a draft standard it was already in wide use.

So you should be fine to use pop3.

OpenBSD code quality is higher

Not uniformly. They've got some significant problems (e.g., a non-thread-safe getaddrinfo() for goodness' sake! They've not even bothered to put a lock internally, despite the fact that the specs for these functions have required thread safety since RFC 2553, i.e., over 10 years...) but they perhaps aren't strictly security problems. Just major functionality issues that every other vendor addressed long ago.

You're arguing semantics

Words have meanings

Yes, they do. Technical documents define what words mean when used in specific contexts, too.

Once such technical document being the Simple Mail Transport Protocol specification (RFC5321), which defines how email is transmitted across the Internet.

Unless you use encryption, there is no envelope.

"SMTP transports a mail object. A mail object contains an envelope and content." --RFC5321 (and RFC2821), section 2.3.1

Evil bit FTW. Yo man, you found the solution at last.

IETF meetings are larger (1200+ typically), and basically everyone has an uses a laptop / pda, so they make for a demanding wireless environment. After some really bad experiences, resources were put into this, and the last few years, things have really improved.

What we have found is that

- it is necessary to have good gear (not all access points are created equal)
- To serve a lot of people, lower the power per access point, and put in a lot of them. Raising the power because of poor reception is a mistake.
- having both 2 GHz and 5 GHz networks really helps.
- telling attendees how to turn off "ad hoc" mode on their computers really helps.
- tracking down ill-configured boxes doing bad things on the network really helps.

Having said that, most recent IETF meeting sponsors have chosen to pay for professional wireless network providers. This is not trivial, and there is no better way to cause a flame war than to have the WLAN melt down.

I noticed this exciting tidbit on their FAQ page:

What happens to Comcast Domain Helper, which offers DNS redirect services, when you fully implement DNSSEC?

        * We believe that the web error redirection function of Comcast Domain Helper is technically incompatible with DNSSEC.
        * Comcast has always known this and plans to turn off such redirection when DNSSEC is fully implemented.
        * The DNSSEC trial servers we are announcing today do not have Comcast Domain Helper's DNS redirect functionality enabled.
        * We plan to update our IETF Internet Draft on this subject, available at http://tools.ietf.org/html/draft-livingood-dns-redirect, to reflect this in the coming months.

Probably because they aren't rebranding their corporate entity.

Also, if you think this is the first cool thing Comcast has done in support of the internet, you're dead wrong. They have some very talented and involved engineers working hard on IPv6, publishing IETF drafts on IPv6 transition strategies, making nice after their BitTorrent escapades, etc.

Say what you will about their business practices, customer service, reliability, whatever... But when it comes to IPv6 and being involved in the technical community, they're kicking ass and taking names.

Probably because they aren't rebranding their corporate entity.

Also, if you think this is the first cool thing Comcast has done in support of the internet, you're dead wrong. They have some very talented and involved engineers working hard on IPv6, publishing IETF drafts on IPv6 transition strategies, making nice after their BitTorrent escapades, etc.

Say what you will about their business practices, customer service, reliability, whatever... But when it comes to IPv6 and being involved in the technical community, they're kicking ass and taking names.

It doesn't surprise me that the IETF has gone introspective since they have already turned to taoism.

"Rough consensus and running code"

They don't have to crack DHE in general, all they need to crack is diffie-hellman-group1-sha1.

Nah, the original question says the guy is using puTTY and OpenSSH. They both implement RFC4419.