Slashdot Mirror

Easy. Setup a Linux-based router and use HTB/iptables to prioritize your upstream. Thats what I do and it works beautifully. I can saturate my upload w/non-interactive programs (P2P, FTP, etc), and my ssh connecitons work fine. http://www.faqs.org/docs/Linux-HOWTO/ADSL-Bandwidt h-Management-HOWTO.html has a really good howto on setting up an example QoS system. It can be easily modified to suit your needs.

Yes, I agree... something as important as this can't be modeled after a protocol in which netsplits are a way of life.

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.

whats the latency on this kinda thing

reminds me of

http://www.faqs.org/rfcs/rfc1149.html

Good grief, no. Use PICS.

(See also: RFC 3675)

... like PICS. Of course, this has already been discussed in RFC 3675.

You people are idiots. (Score: -1, Redundant... This is Slashdot, after all.)

Please do the world a favour by tagging this article "rfc3675", then go read it.

That's because you failed to read RFC 3675.

I have RFC1925 (Pt 2, Sec 3: "With sufficient thrust, pigs fly just fine.") posted at my desk here at work, with the aforementioned phrase highlighted.

I work for the Federal Government in IT.

Derive from this what you will.

Keeping the same IP doesn't mean they keep record of who had that IP. Afaik, when using DHCP, you're assigned with a timed lease. When that lease end and you're not connected, then the address is released and when you'll log back, your system may ask for the old address. If it's still unassigned, the server will give it back to you, but if it was assigned meanwhile, you'll get a new one. That's why you can keep the same addresse for a year.
See chapter 3.2 of DHCP RFC for more info.

The real link: http://www.faqs.org/rfcs/rfc1149.html

If you really don't want to worry about a sucked up channel try RFC 1149:

http://www.faqs.org/rfcs/rfc1149.html/

There's even a proof!

Even better, there is an RFC for it as well: http://www.faqs.org/rfcs/rfc2795.html

This RFC proposes several protocols to be used in the transmission of IP datagrams using the Vertical Blanking Interval (VBI) of a television signal. The VBI is a non-viewable portion of the television signal that can be used to provide point-to-multipoint IP data services which will relieve congestion and traffic in the traditional Internet access networks. Wherever possible these protocols make use of existing RFC standards and non-standards.

[...]

Today, IP is quickly becoming the preferred method of distributing one-to-many data on intranets and the Internet. The coming availability of low cost PC hardware for receiving television signals accompanied by broadcast data streams makes a defined standard for the transmission of data over traditional broadcast networks imperative. A lack of standards in this area as well as the expense of hardware has prevented traditional broadcast networks from becoming effective deliverers of data to the home and office.

This FAQ seems to suggest that MTBF would imply actual hours of active use:

http://www.faqs.org/faqs/arch-storage/part2/sectio n-151.html

There is significant evidence that, in the mechanical area "thing-time" is much more related to activity rate than it is to clock time.

That's correct, but thanks to human ingenuity, there is a way.

It's not a typo. When addresses are configured, there is a universal/local bit set. See the appendix of RFC 3513 for more info, under the section "Links or Nodes with IEEE 802 48 bit MAC's."

http://www.faqs.org/rfcs/rfc3513.html

5 Q. With respect to the various data you
6 relied on from MediaSentry or Verizon, do you have
7 any information sitting here today, Dr. Jacobson, to
8 suggest that any of that is not correct?
9 A. No.

10 Q. Do you have an opinion as to whether
11 a reasonable expert in your field would rely on
12 information like that?
13 MR. BECKERMAN: Objection. He
14 hasn't shown himself qualified to give an
15 opinion on something like that.
16 Q. You can answer.
17 A. I believe that a person in my field
18 would use the same information.

10 Q. And with respect to the IP -- the
11 public IP address that you talked about a lot today
12 relating to this case, was that within one of the
13 ranges for internal addresses?
14 A. No.

Since when do spiders have to obey a robots.txt file? A better idea - enable the Evil-Bit.

the process of identifying copyrighted material is not automated

Well, it *could* be, if they implemented RFC 3514.

Probably some sort of encapsulation would be necessary.
RFC 1149

No pitchforks here. I agree with you - when the accusation includes anything at all similar to 'kiddie porn', the high moral ground has been occupied, and it seems like everything else goes out the windows

Glad to see the ex-judge busted, but wouldn't trust the kid as far as I can throw him. He weirds me out at least as much as the judge.

I mean, you can't argue the result here. But the method sure creeps me out. By focusing on child porn images, this dude gets to stalk 3000 people. And he does is by distributing a trojan, and manually reviewing the material on target computers.

The alt.comp.virus FAQ http://www.faqs.org/faqs/computer-virus/alt-faq/pa rt3/ references a backgrounder on the legalities of computer crime. It's venerable (1998), so I don't know to what extent the author's assertions are still accurate, but he is pretty clear: Distributing a virus affecting computers used substantially by the government or financial institutions is a federal crime under the Computer Fraud and Abuse Act. So if this had ended up on a qualifying computer, the kid would (should) have been busted. Furthermore, Most states have statutes that make it a crime to intentionally interfere with a computer system. These statutes will often cover viruses as well as other forms of computer crime.

The referenced document can be found at http://www.loundy.com/E-LAW/E-Law4-full.html#VII in Section D.

As well, if the judge hadn't admitted the journal in question was his, and disclaimed knowledge of the images, how far could they have gotten with this prosecution? The kid admits distributing a trojan, how far is it from there to distributing material? I think a defence lawyer could have a field day with this, but IANAL, just another guy with an opinion.

The first result for a google search for 'bigit bit' seems to confirm kdawson's claim.

Apparently some people have some issues with the language.

Take with a grain of salt.

The only thing that could be in danger is the protocol described in RFC 1149

In case anyone is unaware of the relevant RFC: RFC 3514 - The Security Flag in the IPv4 Header

You're right! Microsoft shouldn't be moving to more compatible, open standards; that would be stealing! And would you believe some people thin that Office should adopt the ODF format? I can't believe they'd advocate stealing from OpenOffice like that! Despicable!

(PS: OE has had the capability to save to eml since the first version; the only thing that's changed is that that's now its default behavior.)
(PPS: The ironic thing is that Apple's emlx format *doesn't* follow RFC822, wheras OE's eml does.)

The only way to truly win freedom from the telecoms and cable companies is to build a network which doesn't rely on telecoms and cable companies.

I agree completely! This is why RFC 1149 is only going to become more important in the future. We need to start rolling out alternatives to the telco backbones immediately.

average Joe started to use the net as a replacement for TV, then the ISP's would no longer be able to deliver on the bandwidth they have sold

There are two aspects to this: contract timeframes and immediacy of data.

Broadband contracts are not vastly longer than engineering or upgrade cycles, and marketing timeframes are even shorter. If overselling becomes an actual market problem (affecting all providers to some degree) then there is ample scope for adjustment by the market as a whole. We have seen this with the coming and going of all you can eat versus metered-at-peak tariffs in a wide range of related industries.

Some teenagers downloading movies is not a problem

... because it hasn't been just "some" people since about 2002.

File sharing is pervasive and tends to run around the clock, although the peak load can be shifted around contractually. A common example: peak hour usage caps or threshold charging but all-you-can-eat offpeak. With large caps or thresholds, people are encouraged to throttle back or turn off file sharing systems during peak hours, so that they can watch youtube videos or the like during the day.

There has been a close correlation between bandwidth usage and business (and school) hours for more than ten years, and ISPs have been used to threshold charging in contracts with their own international providers for more than five years. That correlation has made it easier to estimate future bandwidth needs, and contracts have been framed to defend that predictability.

From a purely technical perspective, video via TCP bulk transfers is virtuous because of the congestion avoiding behaviour of TCPs (RFC 2001). These bulk transfers typically quickly find and maintain equilibrium with other traffic. These bulk transfers, in other words, are on average fair sharers of bottleneck bandwidth.

There is the occasional objection to bulk transfers because large receive window sizes often run into oversized FIFO queues on the last WAN hop between the sender and the ultimate receiver. Even more often are oversized FIFO queues in the opposite direction. In both cases, there is a many-millisecond pileup between a residential user and the Internet when the user is doing large bulk transfers in either direction (or in both in the case of file sharing).

Although there are known fixes for this behaviour -- rightsized queues, non-FIFO scheduling, or early congestion notification (via explicit congestion notification or by drop, which is just implicit congestion notification) or any combination of these. Sadly, these are not widely used, and neither ISPs nor users demand these features from their last mile equipment or software vendors.

Experimental TCPs also have workarounds for this behaviour, but new TCP features are slow to deploy for a variety of reasons, largely because the overall stability of the Internet is hinged on the dynamics explained in RFC 2001. (Essentially in the event of failure of network infrastructure, transmitters will back off and slowly re-explore the new bottlenecks. Widespread deployment of a slower backoff or much more aggressive exploration can lead to massive congestion and packet loss when there are topology changes (router crashes, line cuts) and this can in turn lead to secondary failures).

At the moment the industry's general non-solution answer is: "if file sharing makes your web browsing slow, stop file sharing".

Or, paraphrasing you: "the industry cannot cope with widespread video transfers".

This may actually be true -- that is the industry might not cope -- but that is mostly because of a depressingly poor understanding of open loop congestion avoidance dynamics across the industry, even in engineering groups which should at least understand the terminology.

There is a final problem associated with video over the Internet, which generalizes into the single sen

The problem isn't filtering content. The problem is that domain names are a terrible way to do it (see RFC 3675), and there are better ways of doing it (see PICS).

As for a voluntary .xxx, the public and legislators will misunderstand its limitations. It's practically begging for bad law. It's better not to set it up in the first place.

I don't really get why people who are discussing Internet policy are so opposed to reading RFCs, like, for example, the RFC that specifically addresses this issue: RFC 3675.

Three words: Network Working Group.

Maybe you should read existing RFCs before you propose your own.

No. Really, stop asking.

I realize most of us here would ordinarily prefer for our ISPs to just move bits around, but it seems like they are in a pretty good position to curb spam if they were to start look at traffic patterns like this. If some DSL customer suddenly starts opening hundreds of outgoing SMTP connections, that would be a pretty reliable sign that his machine is pwned. Just block or throttle port 25, and send the customer an email telling him to fix his computer, and keep it blocked until he does - or he contacts abuse@ with a legitimate explanation. Not filtering based on the contents of the data should let them maintain plausible deniability and common carrier status.

We can't do this on our personal or company internet connections because we only see individual messages coming from many different IPs, but on the other end of the connection, or even at the backbone level, this strikes me as a pretty solid solution. They could even just tag the packets with the evil bit and let us decide if we want to filter them or not.

It's that "general Welfare" part. Just because Joe Smoe (you) call it a pipe dream doesn't make it a pipe dream or even mean that anyone else cares. Others have argued the facts, I'll argue with you:

You are an idiot. You let your irrational dislike of government subsidies and/or your obviously unstudied belief that it is a pipe dream lead you to the conclusion that something is wrong.

I invoke Quirk's Exception to Godwin's law, you fucking Nazi prick.

And we could use IP over Avian Carriers for longer distance service...

They might want to look into this RFC: http://www.faqs.org/rfcs/rfc1149.html

No, avian carriers. Obviously.

Intrinsic to a Red Book Audio CD is the ability to extract the audio in its pristine digital form.

(Disclaimer: I am not an audio or CD technology expert. Take the following with a pinch of salt.)

My understanding is that audio CDs can't be copied exactly because the lowest-level information stored on the CD cannot be returned directly by existing recorders.

Bear in mind that the files which *can* be copied exactly to and from CD-ROMs sit on top of several layers of encoding. Even though you can make a copy which is identical at the filesystem level (which is all you care about in most cases), AFAIK the lowest-level bits (i.e. those actually stamped/burned onto the disc) may not be identical. Multiple layers of encoding and corrections mean that this isn't a problem.

IIRC audio CDs include fewer encoding levels, and whilst most players can read and extract the audio information from the raw bits, I believe that some corrections and "fixing" of damaged audio data (*) occur at a lower level than that of any data the CD-ROM is able to return. In other words, the "rawest" audio data you can get your hands on may already have been processed and "fixed" at a lower level.

(*) Not counting mathematical algorithms which exploit clever encoding techniques so that you can still retrieve the uncorrupted info if (e.g.) 3 or fewer out of 10 bits are damaged. (I just made that up, but you get the broad idea...) What I mean is actual unrepairable damage that the CD player interpolates before you ever get it.

See also:-
http://www.everything2.com/index.pl?node_id=944615 &lastnode_id=918089
http://www.faqs.org/faqs/cdrom/cd-recordable/part2 /

Information Assurance has long been one of NSA's primary missions. NSA ran the Trusted Product Evaluation Program (TPEP) since 1983, which evaluated off-the-shelf commercial products against standardized security criteria, and employed various experts from government, military, academia, and industry. Contributions or recommendations from TPEP often were incorporated into future iterations of vendor products. The expanded Common Criteria programs, which grew in part out of the US Trusted Computer System Evaluation Criteria (TCSEC, the famous Rainbow Series of security publications), picked up where TPEP left off, now administered by the National Information Assurance Partnership (NAIP) of NSA and NIST.

NSA's Information Assurance Directorate also provides public security configuration guides for many popular applications, operating systems, database servers, routers, and other networking equipment.

Also, don't forget to check out NSA's Security-enhanced Linux (SELinux) (FAQ).

When US computing, communications, and networking implementations are more secure, we all benefit, and NSA contributes to this in its overall mission.

I use CPTP, because pigeons are cheap and plentiful where I live. Granted, a page takes forever to load, but I have this rack of old hollowed out ACER monitor shells that I use as roosts for the birds.

A win all around.

http://www.faqs.org/rfcs/rfc1149.html

Long before Bill Joy, UNIX had a good full-screen editor - the RAND editor. The RAND editor dated from the early 1970s. I used it at Ford Aerospace, and it was much nicer than "vi". But it wasn't free. You had to pay RAND for each copy.

The RAND editor was much closer to "what you see is what you get" than "vi". It was a full-screen editor with all the commands on function keys. All the keys like "insert", "delete", etc. did what you'd expect. Labels were provided to show what each function key did. So it was far more user-friendly than "vi".

The RAND editor was modestly portable from terminal to terminal. It worked best on HP terminals of the period, and was table driven so that it could support different devices. But you had to change the tables in C and rebuild to add support for a new device.

The RAND editor had fewer "mode" issues than "vi". What you typed went in at the cursor position. For a few special commands, like "find", a special line at the bottom of the screen was used. But you could always see visually what was going on. Much better look and feel than "vi".

Those of us who had both available used the RAND editor.

Some of what Joy is credited for in the early days of UNIX reflects the fact that he worked for a tax-funded organization working under a contract that allowed them to give software away.

Unless he means this: http://www.faqs.org/rfcs/rfc1191.html. It does involve ICMP messages (MTU too large). Not "ping" though (whatever that means)

... Internet by Email?

http://www.faqs.org/faqs/internet-services/access- via-email/
http://www.expita.com/howto1.html

I did this in 98, when I was overseas, and my internet access was a 15 minute on one of 4 PCs for about a hundred people, with a local SMTP/POP solution that dialed in twice daily for sending / receiving mail. Worked quite nicely, actually.

Then again, I don't know if any of the servers listed are still up, but it ought to be easier to have someone install something like this...

Have you ever had to do low level Windows programming? If Linux was popular I doubt I would have had to.

Believe me, I used to think like you do. Then I went through an experience like this and I went from being OS-agnostic to anti-Windows.

I don't care if Linux wins or not, I just want something that has a sane and open development environment, so I can spend less time figuring out badly-written (if existent) documentation and more time providing features for users.

If you want to see how bogged down (and costly) developing for the deck-of-cards that is Windows, look no further than Microsoft itself. Look how long it took them to make Vista, and look at how many things they couldn't do. Now imagine not having access to Windows source code and trying to accomplish certain things.

I think this is my ~4th post on a similar rant. So sorry about the dupes.

• Ensure sending mail servers have valid mx or a record for the sending IP address
• Sending IP of mail server should have a valid reverse dns record (PTR) and should match the A record for the IP.
• The information in the HELO/EHLO portion of the smtp session should be a valid hostname and should resolve to the sending IP address or PTR.
• SMTP Authentication for outbound
• Published SPF records for the sending domain. http://www.openspf.org/
• Domain Keys
• plus more that I can't think of at the moment.

Umm... Where are those things in the UDP header?

A connection doesn't get opened with UDP by sending a new packet, both ends must negotiate that they will listen on that UDP port.

For instance, syslogd listens on a UDP port. When a client wishes to send data to the server, it just sends it. If the server's not listening, so what!

The only reason those states can exist is because an intermediate network device is trying to reconstruct what the endpoints are doing and thus must track "connections".

So in the syslog example, the server sends nothing back. It's a one way protocol and your "connection" tracker is going to watch all these UDP "connections" for no reason.

So I guess you can say Skype is the #1 STUNna?