Re: Nmap compliance with new RFC 3514

Is there someone running around with a bit bucket to catch
the packets dropped by Avian carriers when they do fail?  I 
was hit by a packet from an Avian Carrier once, right on 
the forehead .. man was that disturbing!  Dropped packets
smell horrible!

On Tue, 01 Apr 2003 15:15:29 MST, "Bryan Waters" wrote:
> Sounds like just one more dropped packet to me...
> 
> -----Original Message-----
> From: Florin Andrei [mailto:[email protected]]
> Sent: Tuesday, April 01, 2003 3:05 PM
> To: Steven P. Adelman
> Cc: [email protected]; [email protected]
> Subject: Re: Nmap compliance with new RFC 3514
> 
> 
> I don't know, my Avian Carrier got killed by a boy with a slingshot, so
> i didn't got my email.
> 
> On Tue, 2003-04-01 at 14:06, Steven P. Adelman wrote:
> > We all know this was an April fools joke right?
> >
> > SPA
> >
> >
> >
> > On 1 Apr 2003, Florin Andrei wrote:
> >
> > > The Evil Bit should be set to 1 automatically when packets are routed
> > > through Avian Carriers (see RFC1149).
> > >
> > > On Mon, 2003-03-31 at 21:49, Fyodor wrote:
> > > > Hey everyone,
> > > >
> > > > Security expert Steven Bellovin just released RFC 3514 which details
> > > > an innovative new approach to IPv4 security.  The described "security
> > > > bit" flags the intention of IP traffic (0x0 means innocent and 0x1 is
> > > > for "evil" packets).  The RFC (below) specifically notes the
> > > > dual-purpose nature of security scanners such as Nmap:
> > > >
> > > > "Some hosts scan other hosts in a fashion that can alert intrusion
> > > >  detection systems.  If the scanning is part of a benign research
> > > >  project, the evil bit MUST NOT be set.  If the scanning per se is
> > > >  innocent, but the ultimate intent is evil and the destination site
> > > >  has such an intrusion detection system, the evil bit SHOULD be set."
> > > >
> > > > I think this leads to two important questions WRT Nmap compliance:
> > > >
> > > > 1) How should Nmap determine evil intent?  Perhaps an --evil option
> > > >    would be handy, or maybe a standard environmental variable should
> > > >    be used (SCRIPT_KIDDIE=1?) so that all security programs run by the
> > > >    hacker set the flag appropriately?  Or maybe Nmap could ship with a
> > > >    hardcoded list of UNIX usernames used by known malicious hackers?
> > > >    Maybe shady options like "decoy scan" and Idle Stealth scan should
> > > >    always set the bit.
> > > >
> > > > 2) Should the overall Nmap default be to set the bit unless the user
> > > >    gives a "good intentions" option, or should we assume innocence
> > > >    until proven guilty?
> > > >
> > > > Let me know what you think :).  As usual, I don't plan to implement
> > > > the IPv6 extensions unless I get sufficient requests to demonstrate
> > > > demand.
> > > >
> > > > -Fyodor
> > > >
> > > > Here is the RFC text:
> > > >
> > > > [ ftp://ftp.rfc-editor.org/in-notes/rfc3514.txt ]
> > > > 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 benign research
> > > >    project, the evil bit MUST NOT be set.  If the scanning per se is
> > > >    innocent, but the ultimate intent is evil and the destination site
> > > >    has such an intrusion detection system, the evil bit SHOULD be set.
> > > >
> > > > 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.
> > > >
> > > >    Intrusion detection systems (IDSs) have a harder problem.  Because
> of
> > > >    their known propensity for false negatives and false positives,
> IDSs
> > > >    MUST apply a probabilistic correction factor when evaluating the
> evil
> > > >    bit.  If the evil bit is set, a suitable random number generator
> > > >    [RFC1750] must be consulted to determine if the attempt should be
> > > >    logged.  Similarly, if the bit is off, another random number
> > > >    generator must be consulted to determine if it should be logged
> > > >    despite the setting.
> > > >
> > > >    The default probabilities for these tests depends on the type of
> IDS.
> > > >    Thus, a signature-based IDS would have a low false positive value
> but
> > > >    a high false negative value.  A suitable administrative interface
> > > >    MUST be provided to permit operators to reset these values.
> > > >
> > > >    Routers that are not intended as as security devices SHOULD NOT
> > > >    examine this bit.  This will allow them to pass packets at higher
> > > >    speeds.
> > > >
> > > >    As outlined earlier, host processing of evil packets is operating-
> > > >    system dependent; however, all hosts MUST react appropriately
> > > >    according to their nature.
> > > >
> > > > 5. Related Work
> > > >
> > > >    Although this document only defines the IPv4 evil bit, there are
> > > >    complementary mechanisms for other forms of evil.  We sketch some
> of
> > > >    those here.
> > > >
> > > >    For IPv6 [RFC2460], evilness is conveyed by two options.  The
> first,
> > > >    a hop-by-hop option, is used for packets that damage the network,
> > > >    such as DDoS packets.  The second, an end-to-end option, is for
> > > >    packets intended to damage destination hosts.  In either case, the
> > > >    option contains a 128-bit strength indicator, which says how evil
> the
> > > >    packet is, and a 128-bit type code that describes the particular
> type
> > > >    of attack intended.
> > > >
> > > >    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.
> > > >
> > > >    DDoS attack packets are denoted by a special diffserv code point.
> > > >
> > > >    An application/evil MIME type is defined for Web- or email-carried
> > > >    mischief.  Other MIME types can be embedded inside of evil
> sections;
> > > >    this permit easy encoding of word processing documents with macro
> > > >    viruses, etc.
> > > >
> > > > 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].
> > > >
> > > > 7. Security Considerations
> > > >
> > > >    Correct functioning of security mechanisms depend critically on the
> > > >    evil bit being set properly.  If faulty components do not set the
> > > >    evil bit to 1 when appropriate, firewalls will not be able to do
> > > >    their jobs properly.  Similarly, if the bit is set to 1 when it
> > > >    shouldn't be, a denial of service condition may occur.
> > > >
> > > > 8. References
> > > >
> > > >    [CBR03]   W.R. Cheswick, S.M. Bellovin, and A.D. Rubin, "Firewalls
> > > >              and Internet Security: Repelling the Wily Hacker", Second
> > > >              Edition, Addison-Wesley, 2003.
> > > >
> > > >    [RFC791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
> September
> > > >              1981.
> > > >
> > > >    [RFC1750] Eastlake, D., 3rd, Crocker, S. and J. Schiller,
> "Randomness
> > > >              Recommendations for Security", RFC 1750, December 1994.
> > > >
> > > >    [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
> > > >              Requirement Levels", BCP 14, RFC 2119, March 1997.
> > > >
> > > >    [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
> > > >              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
> > > >              October 1998.
> > > >
> > > >    [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
> > > >              (IPv6) Specification", RFC 2460, December 1998.
> > > >
> > > >    [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
> > > >              Address Translator (Traditional NAT)", RFC 3022, January
> > > >              2001.
> > > >
> > > > 9. Author's Address
> > > >
> > > >    Steven M. Bellovin
> > > >    AT&T Labs Research
> > > >    Shannon Laboratory
> > > >    180 Park Avenue
> > > >    Florham Park, NJ 07932
> > > >
> > > >    Phone: +1 973-360-8656
> > > >    EMail: [email protected]
> > > >
> > > >
> > > > 10. Full Copyright Statement
> > > >
> > > >    Copyright (C) The Internet Society (2003).  All Rights Reserved.
> > > >
> > > >    This document and translations of it may be copied and furnished to
> > > >    others, and derivative works that comment on or otherwise explain
> it
> > > >    or assist in its implementation may be prepared, copied, published
> > > >    and distributed, in whole or in part, without restriction of any
> > > >    kind, provided that the above copyright notice and this paragraph
> are
> > > >    included on all such copies and derivative works.  However, this
> > > >    document itself may not be modified in any way, such as by removing
> > > >    the copyright notice or references to the Internet Society or other
> > > >    Internet organizations, except as needed for the purpose of
> > > >    developing Internet standards in which case the procedures for
> > > >    copyrights defined in the Internet Standards process must be
> > > >    followed, or as required to translate it into languages other than
> > > >    English.
> > > >
> > > >    The limited permissions granted above are perpetual and will not be
> > > >    revoked by the Internet Society or its successors or assigns.
> > > >
> > > >    This document and the information contained herein is provided on
> an
> > > >    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
> > > >    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
> > > >    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
> > > >    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
> > > >    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
> > > >
> > > > Acknowledgement
> > > >
> > > >    Funding for the RFC Editor function is currently provided by the
> > > >    Internet Society.
> > > >
> > > > --------------------------------------------------
> > > > For help using this (nmap-hackers) mailing list, send a blank email to
> > > > [email protected] . List run by ezmlm-idx
> (www.ezmlm.org).
> > > >
> > > --
> > > Florin Andrei
> > >
> > > "The Internet's elementary laws never figured people would build
> > > careers on not understanding them." -  Doc Searls and David Weinberger
> > >
> > >
> > > ---------------------------------------------------------------------
> > > For help using this (nmap-dev) mailing list, send a blank email to
> > > [email protected] . List run by ezmlm-idx (www.ezmlm.org).
> > >
> > >
> >
> --
> Florin Andrei
> 
> "The Internet's elementary laws never figured people would build
> careers on not understanding them." -  Doc Searls and David Weinberger
> 
> 
> ---------------------------------------------------------------------
> For help using this (nmap-dev) mailing list, send a blank email to
> [email protected] . List run by ezmlm-idx (www.ezmlm.org).
> 
> 
> 
> 
> ---------------------------------------------------------------------
> For help using this (nmap-dev) mailing list, send a blank email to 
> [email protected] . List run by ezmlm-idx (www.ezmlm.org).
> 

---------------------------------------------------------------------
For help using this (nmap-dev) mailing list, send a blank email to 
[email protected] . List run by ezmlm-idx (www.ezmlm.org).