Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Security Programming IT Technology

RFC 3514: New Bit Defined for IPv4 Headers 270

Posted by jamie from the SHOULD dept.
RFC 3514 was just released, with a new bit definition for use in the headers of IP packets. Because there are important security implications, anyone coding internet services (on either the client or server end) should probably take a look.
This discussion has been archived. No new comments can be posted.

RFC 3514: New Bit Defined for IPv4 Headers More

RFC 3514: New Bit Defined for IPv4 Headers

Comments Filter:

  • It's about time! (Score:5, Funny)

    by Motherfucking Shit ( 636021 ) on Monday March 31, 2003 @10:26PM (#5635663) Journal
    Finally, the scriptkiddie bit! Now we'll be able to drop all that pesky DDoS traffic with ease!

  • I can see it now. (Score:5, Funny)

    by Renraku ( 518261 ) on Monday March 31, 2003 @10:26PM (#5635665) Homepage
    The bit set to 1 indicates a pr0n site, the bit set to 0 indicates a non-pr0n site.

    • sex or war (Score:5, Funny)

      by lingqi ( 577227 ) on Monday March 31, 2003 @10:51PM (#5635840) Journal
      Actually I think somebody famous* established long time ago that sex, as strange as some of its involved rituals may seem to many at times, are a better alternative to war.

      I propose that instead anything coming from or going to a .gov extension has the eBit** set.

      *note: Larry Flint. Watch the movie.

      **I hereforth trademark this name.
    • So, running a porn site, should I only accept traffic with the bit set to 1? Obviously set to 0 is a benign user..

      Ah, doesn't matter anyways, most of my users try to set their bit to 2.. :)

  • you are 2 hours early... (Score:4, Funny)

    by MarvinMouse ( 323641 ) on Monday March 31, 2003 @10:27PM (#5635674) Homepage Journal
    This is such an amazingly important invention, but you are 2 hours early on the release. No one was supposed to know that.

    Darn! You have already thwarted my evil plans yet again.

  • In other news.... (Score:5, Funny)

    by VC ( 89143 ) on Monday March 31, 2003 @10:27PM (#5635679)
    Microsoft have released a beowulf distro.
    Linus has joined redhat.
    Slackware is closing down.
    Linux now runs on single entangled electrons at MIT
    etc etc etc
  • that's gotta be a record. I know subscribers get early access, but geez!

  • ...and so it begins (Score:5, Funny)

    by stevens ( 84346 ) on Monday March 31, 2003 @10:29PM (#5635690) Homepage

    I love April fool's day.

    Perl programmers may want to check out their beloved cpan.org [cpan.org] site today, too. :-)

    • Now we were really rolling on the floor laughing on that one. Is there a link explaining why they chose that theme?

      • Re:Nasty! (Score:5, Informative)

        by stevens ( 84346 ) on Monday March 31, 2003 @10:50PM (#5635824) Homepage
        Is there a link explaining why they chose that theme?

        No link necessary. Matt's Script archive is well-known among Perl programmers as one of the densest collections of hole-ridden crappy code on the net.

        There's even a project [sourceforge.net] to write secure, well-written clones of his scripts so the poor bastards stuck with his can drop-in something that won't allow remote exploits on their machine. :-)

        • No link necessary. Matt's Script archive is well-known among Perl programmers as one of the densest collections of hole-ridden crappy code on the net.

          And the author is *very* defensive about it. I'm surprised he went along with the gag.

    • One may also want to check out grsecurity.net.

      Apparently AOL/TW have gotten a lot more agressive at cracking down on TOS violations.

  • A couple of mirrors (Score:5, Informative)

    by Motherfucking Shit ( 636021 ) on Monday March 31, 2003 @10:30PM (#5635695) Journal
    Mirror 1 [phplabs.com]

    Mirror 2 [shat.net]

    To lighten the load.

  • Patch for Cisco IOS needed (Score:5, Funny)

    by Degrees ( 220395 ) <`em.hcsireg' `ta' `seerged'> on Monday March 31, 2003 @10:30PM (#5635696) Homepage Journal
    Now, best practices will include setting this bit for all interfaces connected to Microsoft servers and AOL users.

    It'll be the Router Admin Full Employment Act of 2003!

    ;-)

    • All interfaces inside the firewall are, by default, to not set the bit.

      I think I will set it for the IIS servers anyway. I can remove it the day Microsoft stops adding sabotage code to their products.

      Anyone care to place a bet? I need the URL of those 'Betting Pool' web sites. This one will need to run until at least the year 2050....

      ;-)

  • Chomping at the bit (Score:5, Funny)

    by Brett Glass ( 98525 ) on Monday March 31, 2003 @10:31PM (#5635700) Homepage
    Does the DMCA impose penalties for modifying the bit?
  • First post with the Evil flag set. If you are reading this comment, Slashdot is not RFC3514-compliant.
  • And not the last....

    [In case you don't wanna bother or it's Slashdotted, it's about designating bits "evil" or not. Not that funny IMO, compared to some other good RFCs [google.com].]

    Last 4/1 the editors posted about 15 of these in a row. Moderators got punchy and the whole place went to... well... be prepared.

    • Re:Yes it's a joke (Score:2, Interesting)

      by SN74S181 ( 581549 )
      Actually, some of the humor in this RFC is that it mocks the futile 'consensus' basis of all the RFCs.

      Take it just a little bit serious and you say to yourself 'Wait a minute, this isn't that funny. People really do believe a consensus-based network will scale well worldwide....'

  • ROFL (Score:2)

    by Tensor ( 102132 )
    I was reading the txt, thinking this is the stupidest thing ever, before i realized it was April Fool's.

    ARggghhhhhh

  • 100% Correct Spam Filters Now Possible (Score:4, Funny)

    by Persnickity ( 47761 ) on Monday March 31, 2003 @10:35PM (#5635726)
    Please, please, please take this wonderful advance in technology and extend it to email. Then Spam can have a new header called "Evil: Yes". Then we can leverage the same technology to do perfect Spam filtering.

  • Timing problem (Score:3, Funny)

    by jpetts ( 208163 ) on Monday March 31, 2003 @10:37PM (#5635737)
    Hey: it's still before midnight where I am! I'll need to take this seriously for the next couple of hours...

  • Must remember (Score:4, Funny)

    by the_other_one ( 178565 ) on Monday March 31, 2003 @10:37PM (#5635739) Homepage

    Benign packets have this bit set to 0; those that are used for an attack will have the bit set to 1.

    Note to self: Remember to set "evil" bit to 1 when launching world domination attempt.

    • Note to self: Remember to set "evil" bit to 1 when launching world domination attempt.

      Which makes me think: Will the cable company terminate my account if I forget to set the evil bit when I am DDoSing someone, as a TOS violation?
    • Note to self: Remember to set "evil" bit to 1 when launching world domination attempt.
      I don't know if there's an RFC for this, but I believe Netiquette demands...
      banner WORLD DOMINATION > ~/.plan

  • Why computers crash, by Dr. Seuss (Score:5, Funny)

    by Mattygfunk1 ( 596840 ) on Monday March 31, 2003 @10:37PM (#5635741)
    If a packet hits a pocket on a socket on a port, and the bus is interrupted at a very last resort, and the access of the memory makes your floppy disk abort, then the socket packet pocket has an error to report.

    If your cursor finds a menu item followed by a dash, and the double-clicking icon puts your Window in the trash, and your data is corrupted 'cause the index doesn't hash, then your situation's hopeless and your system's gonna crash!!

    If the label on the cable on the table at your house says the network is connected to the button on your mouse, but your packets want to tunnel to another protocol that's repeatedly rejected by the printer down the hall, and your screen is all distorted by the side effects of gauss, so your icons in the window are as wavy as a souse; then you may as well reboot and go out with a bang, 'cuz sure as I'm a poet, the sucker's gonna hang!

    When the copy of your floppy's getting sloppy in the disk, and the macro code instructions cause unnecessary risk, then you'll have to flash the memory and you'll want to RAM your ROM. Quick, turn off the computer and be sure to tell your Mom!

    Blatently pinched from - Twisted Monkey Entertainment [twistedmonkey.org]

    _________________
    Cheap Web Site Hosting [cheap-web-...ing.com.au] - recommended by some worker posting on slashdot!

  • Don't forget RFC3251 as well (Score:3, Interesting)

    by Billly Gates ( 198444 ) on Monday March 31, 2003 @10:39PM (#5635758) Journal
    More info is here [faqs.org]

  • The 128-bit strength indicator levels! (Score:4, Funny)

    by EvilNTUser ( 573674 ) on Monday March 31, 2003 @10:40PM (#5635761)
    Unfortunately the RFC neglects to define what levels of evil the values of the 128-bit strength indicator maps to.

    Therefore I, on behalf of the United Corp^H^H^H^H^H States government, submit that the top values should be reserved for the following:

    2^127-n
    4: Unpatriotic activity.
    3: Terrorism. For up to date definition, see www.dhs.gov
    2: Attempt to secure personal communication by encryption
    1: Circumvention of copy protection mechanisms for purposes of piracy
    0: Circumvention of copy protection mechanisms for purposes of "fair use"

    Note that the last bit is reserved to indicate whether the packet originates from a foreign country.
  • Cached in my journal [slashdot.org]

  • I have security. (Score:4, Funny)

    by rice_burners_suck ( 243660 ) on Monday March 31, 2003 @10:40PM (#5635770)
    Security implications? Bah, humbug. I have the most secure network anywhere. First of all, I use 100% wireless networking with no encryption whatsoever. I am using Windows operating systems, which are unbreakable in terms of security because nobody other than Microsoft, the most respectable organization in the world, has access to the source code, which is flawless in every way. Sharing is turned on for all drives with no passwords. As a matter of fact, there are no passwords on anything. And the computers are being kept on all the time. Private documents are stored on these computers, as are diaries, pictures, videos and other proofs of the illegal crimes my organization commits (see fine print below). As such, I firmly believe that no update to any aspect of my network needs to take place, as I am 100% safe from evil hackers and from those evil people who do not agree 100% with the viewpoints of Microsoft, the RIAA, the MPAA, AOL Time Warner, The Walt Disney Company and Saddam Hussein.



    The fine print: Aforementioned crimes are only illegal in Afghanistan and include, but are limited to, allowing women to walk around without being entirely concealed under a table cloth, teaching children how to read and write, and singing nursery rhymes.

  • HTTP link (Score:2, Funny)

    by apankrat ( 314147 )
    Here [aist.go.jp]

    Also note that it's actually based on the ideas initially developed by HTCPCP [ietf.org] protocol, which just turned 5 years.

  • A potential hole... (Score:4, Funny)

    by russotto ( 537200 ) on Monday March 31, 2003 @10:42PM (#5635781) Journal
    An attacker can take advantage of the quantum nature of reality to set this bit to an indeterminate/combined value influenced by the nature of the observer of the packet. An observer who knows the evil nature of the sender of the packet will see the "evil" bit set to one, as it should be. However, unsuspecting observers, including firewalls and potential victims, will see the bit set to zero and be fooled.

    The inherent subtlety of this attack is revealed by considering what happens when a security expert attempts to analyze the attack. As soon as he recognizes the evil nature of the attacker, the packets appear to have the 'evil' bit set, and his firewalls start dropping the packets, depriving him of further packets for analysis. The attack is thus even more precisely targeted towards the naive than an attack on Microsoft IIS.

  • Evil (Score:3, Funny)

    by NickisGod.com ( 453769 ) on Monday March 31, 2003 @10:43PM (#5635787)
    Is it time to bring out the April Fools Day Tree yet?

    Should I start opening the April Fools Day gifts?

    Serious question: Will this bit work over Carrier Pigeon?

    And one other thought, will Windows2003Server recognize it? Oh...they'll have to release the Service Pack because anything set to 0 won't get through because of a buffer overflow extension illegal operation segfault doo-hickey.

    Any other cliches missed?

    • Re:Evil (Score:3, Funny)

      by Caraig ( 186934 )
      Considering that carrier pigeons used to carry TCP packets are already compliant with IPv4, then I'd say that the evil bit can be set.

      Usually, it can be detected for by a specially-designed packet sniffer: a freshly-washed car right beneath the carrier pigeons' flight path.

      I think a much more pressing ssue would be making carrier pigeons compatable with IPv6. Perhaps if there were two pigeons, and they carried the packet on a string held between them.....

  • Oh geez... (Score:5, Funny)

    by sfe_software ( 220870 ) on Monday March 31, 2003 @10:44PM (#5635790) Homepage
    ...it's 4/1 already...

    I liked this bit (emphasis mine):

    0x0 If the bit is set to 0, the packet has no evil intent. Hosts,
    network elements, etc., SHOULD assume that the packet is
    harmless, and SHOULD NOT take any defensive measures. (We note
    that this part of the spec is already implemented by many common
    desktop operating systems.    )

    0x1 If the bit is set to 1, the packet has evil intent. Secure
    systems SHOULD try to defend themselves against such packets.
    Insecure systems MAY chose to crash, be penetrated, etc.

    • Actually, something else rather interesting:

      4. Processing of the Evil Bit

      Devices such as firewalls MUST drop all inbound packets that have the
      evil bit set. Packets with the evil bit off MUST NOT be dropped.
      Dropped packets SHOULD be noted in the appropriate MIB variable.

      Many [broken] routers and firewalls drop packets with reserved bit(s) set in various header fields of TCP and IP. This is one of the reasons Explicit Congestion Notification (see RFC 3168 [isi.edu]) has problems behind certain devices [gtf.org]. Sin

    • Nah, by far the funniest part is this:

      The bit field is laid out as follows:

      0
      +-+
      |E|
      +-+

      I laughed out loud on that one. Reminds me of those books Mr. Bunny's Guide to ActiveX and Mr. Bunnies Big Cup 'o Java

      Screenshots will be provided for developers trying to follow along but don't have monitors
    • hehehehehe Doesn't this remind you of ActiveX control signing?
    • Some link layers, notably those based on optical switching, may bypass routers (and hence firewalls) entirely. Accordingly, some link-layer scheme MUST be used to denote evil. This may involve evil lambdas, evil polarizations, etc.
    • It seems to me that by setting the EVIL bit, a packet thereby becomes less evil, in fact not evil at all, and thus should set the bit to 0, but of course then it would be truly evil, and back at square one are we.

      My head spins along with this bit. Can someone please clear this up? Is it a bit intended only for quantum computers?
  • If only it was that easy to detect evil intent in real life...

    "Sally, cross your legs! His bit is set to 'evil'!"

    On second thought...
  • I sent an email to my TCP/IP professor asking if he could explain this RFC to us in class because I couldn't understand it, and he wrote back saying I just earned an F. ^^;;

  • This will never work (Score:4, Funny)

    by falsification ( 644190 ) on Monday March 31, 2003 @10:56PM (#5635854) Journal
    That is totally the wrong approach. It will never work. In reality, there is no evil per se. One system's evil is another's good.

    Let's say there's a so-called "cyberterrorist attack" against Windows-architecture systems. Why should Unix-architecture systems treat that "attack" as evil, even if the "evil bit" is set? If it doesn't harm the Unix system, then it must be the equivalent of valid data.

    What we really need is more social justice and handouts to resource-needy systems, like those with Windows-architecture. More handshakes wouldn't be bad, either. Thus, we are forced to answer the question: why do they hate us? It is because we are secure, and they are not.

    An evil bit is discriminatory. Just because they're evil, is that sufficient justification for sending it to /dev/null? Have a heart, people. Have a heart. Just remember that every evil bit has a parent bit. Allowing "bit profiling" to pervade our systems will mean that the evildoers will have already one.

    • That is totally the wrong approach. It will never work. In reality, there is no evil per se. One system's evil is another's good.

      Sounds like the beginning of another r.g.f.d alignment flamefest...
    • Ah, but Unix should necessarily just turn the evil bit on as it is they that are usually passing the data (virus') between all those hacked (Windows) clients. Obviously, therefor, Unix is the problem in the equation. Remove it and the Windows boxes, trying to talk solely among their infected and crashing selves, will ultimately simply self-detroy themselves. See. Evil will reign.

  • What a day! (Score:5, Funny)

    by Ridge ( 37884 ) on Monday March 31, 2003 @11:05PM (#5635914)
    First this and now I noticed the W3C added an addendum to HTTP 1.1:

    10.5.4.1 503.1 Slashdotted

    The server is currently unable to handle the request due to a fucking slashdotting of the server. Visit slashdot.org for potential mirrors.

  • April 1st RFCs are always the most important... (Score:5, Informative)

    by Bradee-oh! ( 459922 ) on Monday March 31, 2003 @11:07PM (#5635928)
    There may be some strange cosmic significance about April 1st, or just a series of amazing coincidences, but many RFCs published on April 1st are of amazing importance.

    Potentially devastating Y10k problem [rfc-editor.org]

    Lifesaving method to temporarily reroute ip in cause of equipment failure [rfc-editor.org]

    Protocol to guarantee software engineer productivity and efficiency [rfc-editor.org]

    Addressing ipv6 with incredible bandwidth savings [rfc-editor.org]

    Planning ahead to Star Trek technology with current protocols and infrastructure [rfc-editor.org]

    I don't even know what this one is about... [rfc-editor.org]

    And many, many more. Any self-respecting network engineer should be especially familiar with all April 1st RFCs, in my opinion...

  • In networks protected by firewalls, it is axiomatic that all
    attackers are on the outside of the firewall. Therefore, hosts inside the firewall MUST NOT set the evil bit on any packets.


    Our IT group must have contributed to this RFC! Now I know exactly what to think of it... :)

  • Perspiring minds want to know.... (Score:5, Funny)

    by unitron ( 5733 ) on Monday March 31, 2003 @11:24PM (#5636001) Homepage Journal
    Enough about the evil bit, where are the "naughty bits"?

  • If we lobby hard enough (Score:3, Funny)

    by lpontiac ( 173839 ) on Monday March 31, 2003 @11:39PM (#5636071)
    I bet we could get the US Congress to pass a law making it illegal to set this bit incorrectly.
  • I am going to be distributing this at the office tomorrow and announcing that all of our hardware is going evil-bit-compliant. This is going to rock!
  • Fooled you - with my stupid bit~!

    have we forgotten that evil people often masquerade in sheep's clothing????
    stupid!
    joshua
  • I won't comment on the legitimatcy of the article due to the date (4/1) but, this RFC seems to be technically perfect, but flawed in every other way.

    Attacking systems MUST set the "evil" bit. Secure systems MUST drop the packets, insecure systems MAY chose their action -- drop, crash, give in.

    Basically, this system, you give implicit trust to the remote system on the end of the communications, and let that system determine the security your own network will take in response to the communications.

    Let one
  • and responding accordingly you can prevent access of evil packets.

  • Previous April 1 RFCs (Score:4, Informative)

    by arvindn ( 542080 ) on Tuesday April 01, 2003 @12:43AM (#5636385) Homepage Journal
    There's a list here [xs4all.nl]. I guess the most famous of them is the IP over avian carriers thing. On the subject of avians, google came out with a cool pigeonrank [google.com] joke last year.

    Back to the RFCs: the list above doesn't seem exhaustive. I found some more: 12 networking truths RFC [ibiblio.org], telnet randomly lose option [ibiblio.org] and Hyper Text Coffee Pot Control Protocol [ibiblio.org]

  • Here's yer problem... (Score:3, Funny)

    by jose c rivera ( 662993 ) on Tuesday April 01, 2003 @01:00AM (#5636444)
    somebody set this thing to "Evil."

  • It isn't April 1st yet (Score:3, Insightful)

    by Istealmymusic ( 573079 ) on Tuesday April 01, 2003 @01:31AM (#5636527) Homepage Journal
    In my timezone, it is currently 10:30 of March 31st. Shouldn't the Internet community wait until it is April 1st everywhere before trying to implement this suggestion?

  • another joke you probably missed in this (Score:3, Funny)

    by Imperator ( 17614 ) <slashdot2.omershenker@net> on Tuesday April 01, 2003 @01:45AM (#5636575)
    6. IANA Considerations

    This document defines the behavior of security elements for the 0x0 and 0x1 values of this bit. Behavior for other values of the bit may be defined only by IETF consensus [RFC2434].
    (emphasis mine)

  • Full text, ftp server slashdotted (Score:3, Informative)

    by oPless ( 63249 ) on Tuesday April 01, 2003 @06:12AM (#5637130) Journal
    Network Working Group S. Bellovin
    Request for Comments: 3514 AT&T Labs Research
    Category: Informational 1 April 2003
    The Security Flag in the IPv4 Header

    Status of this Memo

    This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

    Copyright Notice

    Copyright (C) The Internet Society (2003). All Rights Reserved.

    Abstract

    Firewalls, packet filters, intrusion detection systems, and the like often have difficulty distinguishing between packets that have malicious intent and those that are merely unusual. We define a security flag in the IPv4 header as a means of distinguishing the two cases.

    1. Introduction

    Firewalls CBR03 , packet filters, intrusion detection systems, and the like often have difficulty distinguishing between packets that have malicious intent and those that are merely unusual. The problem is that making such determinations is hard. To solve this problem, we define a security flag, known as the "evil" bit, in the IPv4 RFC791 header. Benign packets have this bit set to 0; those that are used for an attack will have the bit set to 1.

    1.1. Terminology

    The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC2119 .

    2. Syntax

    The high-order bit of the IP fragment offset field is the only unused bit in the IP header. Accordingly, the selection of the bit position is not left to IANA.

    The bit field is laid out as follows:

    0
    +-+
    |E|
    +-+

    Currently-assigned values are defined as follows:

    0x0 If the bit is set to 0, the packet has no evil intent. Hosts, network elements, etc., SHOULD assume that the packet is harmless, and SHOULD NOT take any defensive measures. (We note
    that this part of the spec is already implemented by many common desktop operating systems.)

    0x1 If the bit is set to 1, the packet has evil intent. Secure systems SHOULD try to defend themselves against such packets. Insecure systems MAY chose to crash, be penetrated, etc.

    3. Setting the Evil Bit

    There are a number of ways in which the evil bit may be set. Attack applications may use a suitable API to request that it be set. Systems that do not have other mechanisms MUST provide such an API; attack programs MUST use it.

    Multi-level insecure operating systems may have special levels for attack programs; the evil bit MUST be set by default on packets emanating from programs running at such levels. However, the system MAY provide an API to allow it to be cleared for non-malicious activity by users who normally engage in attack behavior.

    Fragments that by themselves are dangerous MUST have the evil bit set. If a packet with the evil bit set is fragmented by an intermediate router and the fragments themselves are not dangerous, the evil bit MUST be cleared in the fragments, and MUST be turned back on in the reassembled packet.

    Intermediate systems are sometimes used to launder attack connections. Packets to such systems that are intended to be relayed to a target SHOULD have the evil bit set.

    Some applications hand-craft their own packets. If these packets are part of an attack, the application MUST set the evil bit by itself.

    In networks protected by firewalls, it is axiomatic that all attackers are on the outside of the firewall. Therefore, hosts inside the firewall MUST NOT set the evil bit on any packets.

    Because NAT RFC3022 boxes modify packets, they SHOULD set the evil bit on such packets. "Transparent" http and email proxies SHOULD set the evil bit on their reply packets to the innocent client host.

    Some hosts scan other hosts in a fashion that can alert intrusion detection systems. If the scanning is part of a be

Slashdot Top Deals

Beware the new TTY code!

Close