Slashdot Mirror

There's an RFC for this, I think.

RFC 5325

Maybe other, related work - search for references to the working group named in the RFC.

You kids need to read more and game less.

Why IPv8? Why not IPv9?

http://www.rfc-archive.org/getrfc.php?rfc=1606

RFC 1925

Cheers,
Dave

Actually, having part of the hierarchy solely for kids would be a great idea, but not for the obvious reasons.

You should allocate kids.us (if you yanks are so worried about it, that's where it belongs, the rest of the world doesn't give a damn about it) for such content.

Then you could create penalties for posting "indecent" material into this subtree of DNS. Since we're talking about DNS, the penalties should go to the owner of the DNS domain. The meaning of "indecent" is irrelevant and can be anything (you'll see as I present my reasoning).

Now, when someone comes trying to do censorship "for the children", you can just point that there's a perfectly child-safe domain protected by laws, with very harsh penalties for not respecting its intended purpose. All of that would be true.

However, if you've had read the literature you'd know that making such guarantee is impossible. Therefore no sane person would get a subdomain of "kids.us". However any busybodies can be easily told they should stop complaining and use the tools given to them (after all, the subdomain would indeed be protected by laws, and they should really be enforced). If they balk at the prospect of having such punishments applied to them, telling them that they are obviously not that interested in the children and are clearly hypocrites (maybe they would be tempted to put something "indecent"? or maybe they just talk but aren't trully willing to take the responsibility to make a clean web for the future generations, blah, blah).

In the end, only extremists will be willing to get .kids.us domains, no sane people would be even interacting with that thing, parents would get to choose if they let their kids out of the walled garden (and if they fail to do so, when they wanted, then they're irresponsable parents), and everybody else gets to browse porn without being distracted by the think-of-the-children crowd.

I even have a slogan for the domain: "kids.us, the clean place for kids that sucks".

The most that can happen is that a few extremists get punished (or whatever) when the sites are inevitably hacked.

Problem solved.

Most users will keep using upstream DNS servers, which means that DNSSEC can prevent third party manipulations of that server's responses, but not manipulations which are injected on the "last hop".

Huh? Sure it can:

http://www.rfc-archive.org/getrfc.php?rfc=4033 (page 11, just before section 8)

There is one more step that a security-aware stub resolver can take if, for whatever reason, it is not able to establish a useful trust relationship with the recursive name servers that it uses: it can perform its own signature validation by setting the Checking Disabled (CD) bit in its query messages. A validating stub resolver is thus able to treat the DNSSEC signatures as trust relationships between the zone administrators and the stub resolver itself.

(a "stub resolver" being the system library that implements getaddrinfo() and friends)

The Society for Motion Picture Engineers has already gone to great lengths (in coordination with the EBU) to create some containers, such as GXF, and MXF.

MXF is already being used as part of the Digital Cinema Initiative (DCI) spec that delivers standardized digital cinema content to theaters. There is already a registered MIME type for MXF.

By the way, you can be mad at Microsoft and their love of Windows Media, but then there is Apple Final Cut Pro and QuickTime (ack!).

Then there are the privacy issues -- DHCP IPv4 provides some masking, while IPv6 provides none whatsoever and likely gets archived.

This is FUD. IPv6 has privacy extensions for stateless autoconfiguration that specifically address this problem. Please read RFC 3041. It has been around since 2001.

...is to sign the root and deploy DNSSEC.

Unfortunately that's politically non-expedient. But now that this vulnerability is out there, maybe the political will can at last materialize.

The second-best solution is to deploy DNSSEC using DNSSEC Lookaside Validation (which means you get trust anchors from some other known site, not from the root zone). And that's available now.

The worst thing about DNSSEC is it's too damn complicated at present; there needs to be the equivalent of "one-click" zone signing. ISC (and others) are working on getting us closer to that.

The third-best solution is what's been done today. We just made it a lot harder to exploit the vulnerability--typically about 16000 times harder, depending on your configuration. There's a difference between "harder" and "impossible" though.

That standard is out of date. IPoAC now has QoS, which would help in prioritizing traffic. Remember, the problem is with bird flu in humans. It's already in birds, so it wouldn't be such a catastrophy and we can implement IPoAC now, to provide peak capacity.

Oh crap! Maybe not!

I put a "no UCE" comment in my SMTP banners and make reference to an acceptable-use policy.

Which has what effect, exactly? The only reference I could find to something like this is RFC 3865 which covers your case. However, as with all RFCs, they are not enforceable by law as you'd need to prove that the sender is compliant with every ad-hoc RFC extension out there. Given that sending MTAs don't need to advertise what features of the various RFCs they support, you have no way of determining whether or not said MTA would even understand that your banner is anything more than "^250.*".

That you've been able to use this in pursuing spammers is quite surprising actually. To me, this has all the force of taking a pen and writing "please return" on your quarter before dropping it into a phone booth and then complaining to the phone company when it didn't get returned to you.

The reason people are against 'allowing' .xxx is because they realize that nobody just wants to allow it. Anyone who wants to regulate "smut," who are the main proponents of .xxx and similar schemes, must necessarily eventually want to make its use required by all porn sites, since without this requirement it has no value.

(Obligatory Godwin's-law-violating analogy: it's like somebody arguing that there's no problem in just building a concentration camp, since they're never going to require that anyone actually go there. Sometimes you should look at what's being created, regardless of what the people creating it are saying. If the two don't match: actions speak louder than words.)

Without a legal requirement that porn couldn't be in the regular TLDs, .xxx is just an additional advertising vehicle for pornography and a revenue source for the registrars.

If .xxx were created, it would only be a matter of time before its use was mandated (or attempted to be). It's just too tempting. You get an election year, and some politicians decide they can rile up their base by putting all the porn 'where it belongs.' Sure, it would be stupid; sure, it could never work -- but the adverse effect it could have on free speech would be enormous.

Thus -- because creating .xxx would serve only to tempt idiot politicans (see the article on the Hon. Senator from Alaska) into making its use mandatory -- it is a Pandora's Box better left unopened.

There are also a host of other valid reasons, aside from the political ones, why creating additional TLDs is a bad idea. Anytime you create a new one, you force anyone with a recognizable brand name to buy from it (in order to protect their brand -- e.g., Coke would almost certainly have to immeditately buy coke.mobi and coca-cola.mobi, if such a thing was instituted). The W3C Technical Architecture Group agrees: http://www.w3.org/DesignIssues/TLD; not to mention RFC 3675: .sex Considered Dangerous.

You are correct, ESP is a separate IP protocol (Protocol 50), and from that standpoint, has nothing to do with UDP. However, there is also RFC 3948, which specifies tunneling ESP over UDP.

Now, I've been using OpenVPN for a long time, but I will readily grant that I've never dug into the nitty gritty details of it's protocol, so I don't know for sure if this is what OpenVPN is doing. When I saw the comment on the OpenVPN page, I assumed they were using ESP over UDP for the transport protocol, though.

>Word, ppt, excel, smb, quicken, asf, wmv

wmv is open standard . Microsoft has submitted it to standards body inorder to get it as one of the codecs in Blue Ray disc standard, and HD-Disc standard.

From the RFC website: http://www.rfc-archive.org/getrfc.php?rfc=4330

Violating a RFC may make you a bad person, and certainly it looks like D-link is in the wrong here, but it's not like there's anybody out there enforcing RFCs in any way beyond `you shouldn't be doing that!' (unless they're kooks, of course.

Now, maybe you could sue somebody for violating a RFC, and perhaps that's what Mr. Kamp should do, but I'm no lawyer and he's already spoken with many about this, so I suspect he has considered it. But it's not likely that any actual laws are being broken here.

Now, if Mr Kamp wanted to play hardball, he could have his legitimate users of his NTP server move to another name, and then modify the GPS.dix.dk server to return a totally bogus time, which would probably help get the current users of the routers to upgrade their firmware. I suspect that only a small fraction of the users would even notice, but those that do would call D-Link, and those calls would cost D-Link money ...

Yes, Mr Kamp shouldn't have to do this, and maybe the /. effect (which does go beyond mere web traffic) will prompt D-Link to do what they can to fix the problem they've caused, but it's always an option, one which he's probably already considered.

From the RFC website: http://www.rfc-archive.org/getrfc.php?rfc=4330

10. Best Practices

      NTP and SNTP clients can consume considerable network and server
      resources if they are not good network citizens. There are now
      consumer Internet commodity devices numbering in the millions that
      are potential customers of public and private NTP and SNTP servers.
      Recent experience strongly suggests that device designers pay
      particular attention to minimizing resource impacts, especially if
      large numbers of these devices are deployed. The most important
      design consideration is the interval between client requests, called
      the poll interval. It is extremely important that the design use the
      maximum poll interval consistent with acceptable accuracy.

      1. A client MUST NOT under any conditions use a poll interval less
              than 15 seconds.

      2. A client SHOULD increase the poll interval using exponential
              backoff as performance permits and especially if the server does
              not respond within a reasonable time.

      3. A client SHOULD use local servers whenever available to avoid
              unnecessary traffic on backbone networks.

      4. A client MUST allow the operator to configure the primary and/or
              alternate server names or addresses in addition to or in place of
              a firmware default IP address.

      5. If a firmware default server IP address is provided, it MUST be a
              server operated by the manufacturer or seller of the device or
              another server, but only with the operator's permission.

      6. A client SHOULD use the Domain Name System (DNS) to resolve the
              server IP addresses, so the operator can do effective load
              balancing among a server clique and change IP address binding to
              canonical names.

      7. A client SHOULD re-resolve the server IP address at periodic
              intervals, but not at intervals less than the time-to-live field
              in the DNS response.

      8. A client SHOULD support the NTP access-refusal mechanism so that
              a server kiss-o'-death reply in response to a client request
              causes the client to cease sending requests to that server and to
              switch to an alternate, if available.

-daedone

5. If a firmware default server IP address is provided, it MUST be a
server operated by the manufacturer or seller of the device or
another server, but only with the operator's permission.

5. If a firmware default server IP address is provided, it MUST be a
server operated by the manufacturer or seller of the device or
another server, but only with the operator's permission.

The whole issue has been considered, filed, reconsidered, trashed,
untrashed, contemplated and cogitated for some while.

There is a relevant RFC with very cogent arguments as to why it is a bad idea.

http://www.rfc-archive.org/getrfc.php?rfc=3675

"...more traffic and more congestion. Does something similar apply to networks?"

Sure - RFC 1925 Section 2.9 of Networking Truths.

A lot is happening with DNSSEC these days. It is being deployed in the ccTLD for Sweden: ".se" Check out

http://dnssec.nic.se/

Tutorial/howto: http://www.ripe.net/disi/dnssec_howto/

$ dig @bind.dnssec.se www.ripe.net +retry=1 +dnssec +multiline
and look for the "flags" to include "ad": ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

http://www.dnssec-deployment.org/
  Threat Analysis Of The Domain Name System
    IETF RFC 3833 http://www.rfc-archive.org/getrfc.php?rfc=3833

Cache poisoning, in the wild:
      http://isc.sans.org/presentations/dnspoisoning.php
      http://www.dnssec-deployment.org/epi.htm

http://www.dnssec.net/

Dork that I am, I actually looked up the RFCs you mentioned.. RFC 2549 looks like it actually exists (http://www.rfc-archive.org/getrfc.php?rfc=2549)! The other one is pretty damn funny http://hive.devilnet.net/rfc3203/PoS-InternetDraft .txt but complete bs..

I'm not certain, but I'm sure CPIP may help.

IMarv

According to RFC 3022:

Traditional NAT can be viewed as providing a privacy mechanism as sessions are uni-directional from private hosts and the actual addresses of the private hosts are not visible to external hosts.