Slashdot Mirror

Oh shut the fuck up and read the names on the RFCs the IETF puts out. Cisco contributes reguarly to protocol standardization. Several of the protocols you're bitching about have equivilant open standard alternatives that are fully supported in IOS. HSRP -> VRRP; isl -> 802.1q

examples:
ftp://ftp.rfc-editor.org/in-notes/rfc4456.txt
ftp://ftp.rfc-editor.org/in-notes/rfc4364.txt
ftp://ftp.rfc-editor.org/in-notes/rfc4062.txt
ftp://ftp.rfc-editor.org/in-notes/rfc3137.txt
ftp://ftp.rfc-editor.org/in-notes/rfc4443.txt
ftp://ftp.rfc-editor.org/in-notes/rfc4659.txt

Oh shut the fuck up and read the names on the RFCs the IETF puts out. Cisco contributes reguarly to protocol standardization. Several of the protocols you're bitching about have equivilant open standard alternatives that are fully supported in IOS. HSRP -> VRRP; isl -> 802.1q

examples:
ftp://ftp.rfc-editor.org/in-notes/rfc4456.txt
ftp://ftp.rfc-editor.org/in-notes/rfc4364.txt
ftp://ftp.rfc-editor.org/in-notes/rfc4062.txt
ftp://ftp.rfc-editor.org/in-notes/rfc3137.txt
ftp://ftp.rfc-editor.org/in-notes/rfc4443.txt
ftp://ftp.rfc-editor.org/in-notes/rfc4659.txt

Oh shut the fuck up and read the names on the RFCs the IETF puts out. Cisco contributes reguarly to protocol standardization. Several of the protocols you're bitching about have equivilant open standard alternatives that are fully supported in IOS. HSRP -> VRRP; isl -> 802.1q

examples:
ftp://ftp.rfc-editor.org/in-notes/rfc4456.txt
ftp://ftp.rfc-editor.org/in-notes/rfc4364.txt
ftp://ftp.rfc-editor.org/in-notes/rfc4062.txt
ftp://ftp.rfc-editor.org/in-notes/rfc3137.txt
ftp://ftp.rfc-editor.org/in-notes/rfc4443.txt
ftp://ftp.rfc-editor.org/in-notes/rfc4659.txt

Oh shut the fuck up and read the names on the RFCs the IETF puts out. Cisco contributes reguarly to protocol standardization. Several of the protocols you're bitching about have equivilant open standard alternatives that are fully supported in IOS. HSRP -> VRRP; isl -> 802.1q

examples:
ftp://ftp.rfc-editor.org/in-notes/rfc4456.txt
ftp://ftp.rfc-editor.org/in-notes/rfc4364.txt
ftp://ftp.rfc-editor.org/in-notes/rfc4062.txt
ftp://ftp.rfc-editor.org/in-notes/rfc3137.txt
ftp://ftp.rfc-editor.org/in-notes/rfc4443.txt
ftp://ftp.rfc-editor.org/in-notes/rfc4659.txt

There is no .xxx domain because it is already known how good such course of action is.
Now, they've made one in order to allow some organization to get some easy cash, while screwing us all with all this "think of the children" stuff. Gee, thanks a lot for listening to what the technical community has to say.

(At least read the title of the document linked, it says a lot)

BTW, I agree with you on TLDs, only country codes should be allowed as TLDs.

Can you imagine the world without the Web? (It was only about 10 years ago.)

The web was created by Al Gore in 1996?

My word ignorance has passed on even to our elders. /me cries.

Just a quick look at AltaVista's about pages shows they *indexed* the web in 95. Of course, the Internet wasn't there before Google, so it must be bogus.

RFC 1580/FYI23 which was published in March 1994, contains a definition of the web.

In actuality, the World Wide Web came about in 1992 about 15 years ago.

Now, had Bjorn meant that slashdotters wouldn't remember before ten years ago because that's about how old most moderators are, i could understand, but he should have been more clear on the matter.

I can only answer points one and two in your post, since I have no experience whatsoever with SEC.

E-mail? Sometimes, but not so much anymore, IME. ISP and other sys admins *are* using a number of e-mail filters, and yes, there are a number of good, free (as in speech *and* as in beer) e-mail filters. One of the more popular is clamav http://www.clamav.net/. At an ISP where I used to work, we had a Sendmail farm that ran clamav, mimedefang, a number of custom perl scripts, sieve http://www.rfc-editor.org/rfc/rfc3028.txt and maybe a few other things to filter our e-mail, and *still* our clients complained about spam (but not about too much e-mail virii).

Exploits in the OS? Yep, more often than not. So why don't ISP's filter incoming traffic? There are a number of answers to this question. First, a lot of sys admins take an ideological approach--"I am providing you with a pipe to the internet. Filtering this pipe is your responsibility; not mine." IMHO, this is kind of like saying "The internet was founded on open principles, and therefore, *all* mail servers should be open relays." It's nice, warm, fuzzy, lets-gather-round-the-campfire-and-sing-kumbaya idea, but it just doesn't work in real life. Second, there is a legal/liability reason. If I, as an ISP, start filtering traffic, then sooner or later some stupid schmuck is going to take me to court because something slipped through the filters and infected his machine. I may win, but the legal battle still wastes my time and my resources. So, instead, a number of ISP's cop out and provide no filtering. Third, and this is the big reason, most common networking equipment simply hasn't got the CPU to handle a bunch of filters. A Cisco 3640 on my network, for example, shows it only has a 100MHz processor--how much filtering do you think it can do without impacting throughput? An AS5300 on my network is only 150MHz. So most ISPs apply access lists very sparingly, since trying to firewall an entire ISP on a router will crater your router in short order. Fourth, the only way to effectively block with an access list is to block either a specific IP address (dynamic IP addressing, anyone?) or to block by port. Yes, you can tell your Cisco iron to drop all incoming traffic on ports 135-139, but this only works to a point. A lot of malware uses high-numbered ports ( >1024, IIRC), which are used at random for *any* network traffic. So yes, you can drop all traffic on port 3127 for example, but when you start filtering too many high-numbered ports, you begin impacting legitimate traffic as well.

In a nutshell, if you are a sys admin for a small business with a reasonably beefy SOHO router, it's pretty easy to filter for legitimate traffic at your edge. But it doesn't scale. Just because you can do it for 100-1,000 employees doesn't mean you can do it for 10,000 or 100,000 (or more) customers.

AFAIK, SMB was not "reverse engineered" -- Microsoft actually submitted the spec to IETF in 1996.

As noted, Samba antedated that spec. However, specs for earlier versions of SMB were available at the time Tridgell first developed Samba. The problem was that he didn't know that the protocol PATHWORKS was using was SMB or that specs were available. (Reminds me of my reverse-engineering work to implement code in Ethereal to read files from Sun's snoop - I later discovered it was documented in RFC 1761.)

The Network Time Protocol hasn't sued anyone.

Ask Dave Mills, he's right down the road at the University of Delaware!

And there isn't any other NTP that matters.

The relevant standards show that unless you are serving "HTML compatible" XHTML (this is XHTML 1.0 transitional), you are in violation of the standards by serving XHTML as text/html. And since everyone's favourite web browser, IE6 (and 7), do not support proper XHTML mime types, you're stuck with at most XHTML 1.0 transitional.

SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.

I'm pretty sure that you can't show me a single example of a page that validates as both XHTML and HTML, so you are sending invalid content under at least one of the mime types.

From RFC2854

The text/html media type is now defined by W3C Recommendations; the latest published version is [HTML401]. In addition, [XHTML1] defines a profile of use of XHTML which is compatible with HTML 4.01 and which may also be labeled as text/html.

And you are discriminating against non-IE users, because all the XML parsers currently used require the full data, while HTML parsers start parsing (and displaying) the page as soon as they can.

WTF? Validating parsers are a feature, not a bug. The IE parser however results in a brief display of unstyled content on IE, with CSS imports this is a bug and designers have been known to employ workarounds.

And don't tell me "no problems reported": web browsers can display almost any crap you can put together, if you use standard DOCTYPEs and/or XHTML mimetype try validating your pages first.

All my sites validate. Again, WTF?

Which is why I always use example.com.

That feature goes by the name "format=flowed" and is a standard, and a good one, I might add, especially if you get emails from many people who don't know about the older standard (lines are 78 chars wide, new lines don't exceed 65 chars, to leave room for quote marks).

Of course, ping is ICMP not TCP and thus is not subject to this problem.

Actually, the IPv4 packet will expire long before the maximum TCP RTT comes into effect. From RFC 791, section 3.1; page 14 (with emphasis added):

Time to Live: 8 bits

This field indicates the maximum time the datagram is allowed to remain in the internet system. If this field contains the value zero, then the datagram must be destroyed. This field is modified in internet header processing. The time is measured in units of seconds, but since every module that processes a datagram must decrease the TTL by at least one even if it process the datagram in less than a second, the TTL must be thought of only as an upper bound on the time a datagram may exist. The intention is to cause undeliverable datagrams to be discarded, and to bound the maximum datagram lifetime.

So, the maximum lifetime for an IPv4 packet is 255 seconds. That gives you a 510-second maximum ping time for IPv4.

IPv6 changed the field to be a pure "hop count", so perhaps you'll be able to use it to ping Voyager 1.

Brilliant!

We might just have a collary to rule number eight!

Some packets are more equal than others. http://www.rfc-editor.org/rfc/rfc4542.txt/

Now, *IF* they were talking about a new transport class (like http:/// and ftp:// for encapsulating telephone numbers, such that a link to tel://8675309 would get me Jenny on the line, that *might* be useful.

In fact, "tel:", "fax:", and "modem:" URL schemes were proposed six(!) years ago by a Nokia researcher (RFC 2806), but no one seems to have paid them much mind.

The Internet Evangelical-Theological Force (IETF) has published their own objection: .sex Considered Dangerous (RFC 3675) in 2004, when ".xxx" was still called ".sex".

I'm appalled by the way those Christian Conservatives shape the Internet!

Latency in non-overloaded devices is a function of the speed of light. Perhaps you can tell us how to transmit information faster than light.

http://www.rfc-editor.org/rfc/rfc1925.txt is an important read.

Odd, it took out the link on "here". It's http://www.rfc-editor.org./

Right, but you have to tie it all together: Kerberos, LDAP, NTP, Login Restrictions by Time of Day.

That's what an IMPLEMENTATION like NDS/eDirectory does for you.

And, believe it or not, IMPLEMENTATIONS are not trivial. Trying to roll your own - from scratch - could take from now until forever.

Look, back in May of 2000, LDAP folks were fantasizing about some hypothetical "Access Control Factors" they might implement someday:

Authentication Methods for LDAP

3.2. Access Control Factors

A request, when it is being processed by a server, may be associated with a wide variety of security-related factors (section 4.2 of [1]). The server uses these factors to determine whether and how to process the request. These are called access control factors (ACFs). They might include source IP address, encryption strength, the type of operation being requested, time of day, etc. Some factors may be specific to the request itself, others may be associated with the connection via which the request is transmitted, others (e.g. time of day) may be "environmental".

Access control policies are expressed in terms of access control factors. E.g., a request having ACFs i,j,k can perform operation Y on resource Z. The set of ACFs that a server makes available for such expressions is implementation-specific.

ftp://ftp.rfc-editor.org/in-notes/rfc2829.txt

Now again: Obviously everyone is free to try to roll their own implementations, but, gee whiz, it's really hard to imagine that you'd beat the price of NDS/eDirectory licenses, much less match NDS/eDirectory reliability & stability.

With PAM, time-of-day is easily arranged in a flat file: /etc/security/time.conf using pam_time.so. Unfortunately, this is a single host-based answer, and the complex collection of systems in use means this isn't feasible.

Novell has used NTP since the version of NDS that shipped with NetWare 4.00 way back in about 1993/1994.

So Novell would give you the time synchronization, with a good 12 to 13 years' worth of debugging of the algorithms and the implementations.

But trying to wing your own Kerberos + LDAP + NTP - gee whiz, that sounds like something at about the level of a Masters's Thesis, and probably the better part of a year's worth of work. The RFC for NTP is about the most challenging reading I've ever encountered in networking theory - to really understand what's going on, you need about a thousand pages' worth of background in the theory of stochastic processes & its application to a bunch of old AT&T switching standards.

I'd say "Screw that," and give the local Novell Rep a call - see what kind of a deal he can quote you.

The proper example domains are example.com, net and org. Please remember to use these when ever you need a made up address.

-- Thanks
  durkadurka@hotmail.com

To quickly derail this thread, you're not only incorrect (or misstating yourself), but you're missing the point entirely.

Port 80 == http
Well, no, actually. According to the HTTP 1.1 RFC, port 80 is an [AFAIK] arbitrary port that's simply the de facto standard for HTTP traffic ("The default port is TCP 80 [19], but other ports can be used." Source). This argument is just like the standard /. retort to the "Let's wrest control of the DNS root servers out of the US's hands!" debate: If you don't want to use our stuff, do it your own way. If an incredibly isolationist China were to decide to mandate all internal Webservers to operate over Port 1938138, and announce this to all ISPs, the public, et al. they could simply block port 80 at all outgoing routers, and effectively cut off any Chinese accesses to the rest of the world's Web. The same thing goes with DNS root servers, they could just set up their own, instead of implicitly giving the US root servers authority by registering domains there.

Back on topic. The OP was talking about the "RSS port" being blocked, but as you've established, there is no "RSS port", and one may transmit RSS over any port they wish. However, just like the de facto [but again, not required1] port for HTTP is 80, the de facto transmission protocol for transmitting RSS XML files is: HTTP. As someone mentioned, this person probably just doesn't notice his aggregator picking up new headlines before he gets to the airport, then while at the airport (where port 80 is blocked/redirected) he checks his 'fresh' headlines, but is not their long enough or with enough frequency to notice that no new headlines are being populated while he is there (because the default port for his RSS streams is being blocked).

The difference between security by obscurity and a key is that when using a key, you publicly announce (or assume it is known) the exact proceedure to enter a key (relying solely on the key strength).

Let's use your mesh point as an example. If, when you build it, you say "to access this router you have to use such IP address", and for each device you write a different address (or make it user changeable), then you have a 32 bit key (assuming IPv4). Everybody knows what to do in order to access your (or anyone's) device, and you rely on the difficulty of trying addresses until they hit.

If, on the other hand you do not announce why you use such address to access the device, it's security by obscurity. You rely on the secrecy of the method for security. You're not likely to treat it like a real key (if you do, then you have both a key and obscurity). You might then be relying on a security feature that is not secure (you told a friend, somebody copied the programming of your box, etc).

Anyway, the IP address is just a lousy place to add your authentication. You cannot change on demand your IP address unless you want to isolate yourself from your network.

As for hacking your device, assuming a fixed knocking scheme, telnet port and root password, I'd say it can be cracked as soon as someone taps your channel. If you change normally your root password, complexity is the same (password gets sniffed). If knocking and port changes, then there's a key, unless the changing algorithm is fixed, in that case the attacker will just have to deduce which algorithm is (or he might already have it, he might have found your docs). If the algorithm is fixed, what would you do if someone finds out?

If you're relying on the box to automatically change the password, the just use a one time password system (crypto, but cheap in your terms, although it does not protect against session hijacking).

Anyway, if speed if so important, there are specialized chips that do crypto lighting fast by themselves. Even COTS hardware does simmetric key operations really fast, the bottleneck is probably your wifi throughput.

But realistically, would we want our computers as "safe" as our cars? There is a tradeoff. Modern car engines are a lot harder to tinker with and self-service. Moding your exhaust system for a nice rumble sound is illegal. Many of us on /. take the computer equivalent of these sorts of mods for granted.

We don't like the idea of the "general purpose" computer disappearing but I don't think we can have "safe as cars" computers without severe restrictions on a person's ability to do whatever they want with their PC.

Unless, of course, we figure out how to implement RCF 3514

ftp://ftp.rfc-editor.org/in-notes/rfc3514.txt

Domain names can be outside latin alphabet:

http://www.rfc-editor.org/rfc/rfc3491.txt

And the encoding is presented in http://www.rfc-editor.org/rfc/rfc3492.txt and http://en.wikipedia.org/wiki/Punycode

Domain names can be outside latin alphabet:

http://www.rfc-editor.org/rfc/rfc3491.txt

And the encoding is presented in http://www.rfc-editor.org/rfc/rfc3492.txt and http://en.wikipedia.org/wiki/Punycode

Doesn't anyone ever read their RFC's?

http://www.rfc-editor.org/rfc/rfc1627.txt

NAT sucks, ipv6+firewall will be a better system. I hope.

IPv6 is a bit like HDTV... it's been "coming" for a long time,
but I can actually watch some shows in HD now, so maybe there is
hope after all!

yup, 8 years ago they were saying the ip4 space would be exhausted in next 5 years. Heck, I sat at a presentation on IPng in 1994 where that was said. At least such a statement is more true now than it was then, but I'll bet reclaiming old absurdly huge allocations of IP space could push this out beyond 10-12 years.

Already taken.

something like this, this, this, this... (should i go on?)

Reminds me of Packet-over-Sheep (RFC 3203) ...

You can always use a RFC-1149-compliant network setup. It would be much better if QoS is supported, according to RFC-2549.

You can always use a RFC-1149-compliant network setup. It would be much better if QoS is supported, according to RFC-2549.

I always set the evil bit on my TCP/IP stack outgoing, just to check for RFC compliance: ftp://ftp.rfc-editor.org/in-notes/rfc3514.txt

So Longhorn converted from Unicode to URL entities?* Talk about your two steps forward and eighty steps back...

*%20 is a space in URLs. See the RFC on URLs and one example. 20% is twenty percent.

A /64 is 1.84e+19 IPs
A /48 is 1.21e+24 IPs

My blocklist is going to end up being 6.2e^29 lines long

No, it wont. Instead of individual IP addresses you'll need to block subnets.

Take a look at RFC 3177 IAB/IESG Recommendations on IPv6 Address Allocations to Sites
ftp://ftp.rfc-editor.org/in-notes/rfc3177.txt

In it they recommend Home network subscribers should receive a /48 allocation. So if you want to block a specific 'home' just block that specific /48 subnet.

Except it doesn't work like that. IPv6 uses a hierarchical routing model, much stricter even than IPv4 classful routing.

The other common misconception is that IPv6 has more addresses (2^128) than particules in the known universe. This isn't really true as the lower 64 bits are not routable.

THERE WAS NO SPECIFICATION back then, or at least not any coherant ones.

This is not true. The HTML specification and the HTML 2.0 specification. Additionally, there was an HTML+ draft. The W3C were working on HTML 3 (draft here) and browser vendors were free to participate.

Remember, HTML 1 and 2 were specifications of the IETF who then summarily dropped it.

This is not true either. HTML 2 was published as an RFC by the IETF, but HTML "1" had nothing to do with the IETF.

HTML 3 was the first spec they issued

Again, incorrect. HTML 3 was never finished. The reason why it wasn't finished was because the W3C considered it more valuable to specify all the proprietary crap that the browser vendors were adding so that it worked consistently across browsers, instead of publishing a well designed specification like HTML 3.

Nobody wanted to implement it.

That's funny. The development process was open to all-comers. If the HTML 3 drafts were so terrible, why didn't the browser vendors suggest changes?

You are talking about the browser vendors as if they were somehow forced to ignore people. When Netscape explained their concept of frames on the mailing lists, they got several responses explaining how the concept was fundamentally flawed, exactly how they could break, and suggestions for fixing them. Netscape ignored everyone and went ahead with their original plans. And lo and behold, we all found out that frames are crap, and even Netscape stopped using them on their own homepage.

Big noise, nothing behind it.

To call this issue well-known would be an understatement. It is even mentioned in the RFC2406 in the Introduction. RFC2406 happens to be to RFC that defines ESP mode in IPsec.

It must be a slow news day in Great Britain.

Why embrace and extend? All they really need to do is support the evil bit.

But of course, being Microsoft, you're probably right. They'll make their own implementation of the evil bit, patent it, and charge royalties to others who want to support their new "EDDP" protocol (Evil Data Detection Protocol).

Not to mention that IIS, Exchange, IE, and Outlook will grow to require use of EDDP during transfers of data, locking Mozilla, Apple, Linux, and others from accessing much of the internet.

Finally, John C. Dvorak will boldly claim that EDDP is the wave of the future, and Apple, Linux, and Mozilla are clearly inferior for not supporting what is clearly a web standard, because if Microsoft says it is, it MUST be.

Sorry, all that was copied from RFC 2821.

Nope.
TCP: September 1981. Standard 7/RFC 793 (replaces RFC 761)
FTP: October 1985. Standard 9/RFC 959 (replaces RFC 765)

Nope.
TCP: September 1981. Standard 7/RFC 793 (replaces RFC 761)
FTP: October 1985. Standard 9/RFC 959 (replaces RFC 765)

Nope.
TCP: September 1981. Standard 7/RFC 793 (replaces RFC 761)
FTP: October 1985. Standard 9/RFC 959 (replaces RFC 765)

Nope.
TCP: September 1981. Standard 7/RFC 793 (replaces RFC 761)
FTP: October 1985. Standard 9/RFC 959 (replaces RFC 765)

Nope.
TCP: September 1981. Standard 7/RFC 793 (replaces RFC 761)
FTP: October 1985. Standard 9/RFC 959 (replaces RFC 765)