tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6274


Security Assessment of the Internet Protocol Version 4

Part 2 of 5, p. 8 to 30
Prev RFC Part       Next RFC Part


prevText      Top      Up      ToC       Page 8 
3.  Internet Protocol Header Fields

   The IETF specifications of the Internet Protocol define the syntax of
   the protocol header, along with the semantics of each of its fields.
   Figure 1 shows the format of an IP datagram, as specified in

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     |Version|  IHL  |Type of Service|          Total Length         |
     |         Identification        |Flags|      Fragment Offset    |
     |  Time to Live |    Protocol   |         Header Checksum       |
     |                       Source Address                          |
     |                    Destination Address                        |
     |                  [ Options ]                  |  [ Padding ]  |

                 Figure 1: Internet Protocol Header Format

   Even though the minimum IP header size is 20 bytes, an IP module
   might be handed an (illegitimate) "datagram" of less than 20 bytes.
   Therefore, before doing any processing of the IP header fields, the
   following check should be performed by the IP module on the packets
   handed by the link layer:

                        LinkLayer.PayloadSize >= 20

   where LinkLayer.PayloadSize is the length (in octets) of the datagram
   passed from the link layer to the IP layer.

Top      Up      ToC       Page 9 
   If the packet does not pass this check, it should be dropped, and
   this event should be logged (e.g., a counter could be incremented
   reflecting the packet drop).

   The following subsections contain further sanity checks that should
   be performed on IP packets.

3.1.  Version

   This is a 4-bit field that indicates the version of the Internet
   Protocol (IP), and thus the syntax of the packet.  For IPv4, this
   field must be 4.

   When a link-layer protocol de-multiplexes a packet to an Internet
   module, it does so based on a Protocol Type field in the data-link
   packet header.

   In theory, different versions of IP could coexist on a network by
   using the same Protocol Type at the link layer, but a different value
   in the Version field of the IP header.  Thus, a single IP module
   could handle all versions of the Internet Protocol, differentiating
   them by means of this field.

   However, in practice different versions of IP are identified by a
   different Protocol Type (e.g., EtherType in the case of Ethernet)
   number in the link-layer protocol header.  For example, IPv4
   datagrams are encapsulated in Ethernet frames using an EtherType of
   0x0800, while IPv6 datagrams are encapsulated in Ethernet frames
   using an EtherType of 0x86DD [IANA_ET].

   Therefore, if an IPv4 module receives a packet, the Version field
   must be checked to be 4.  If this check fails, the packet should be
   silently dropped, and this event should be logged (e.g., a counter
   could be incremented reflecting the packet drop).  If an
   implementation does not perform this check, an attacker could use a
   different value for the Version field, possibly evading NIDSs that
   decide which pattern-matching rules to apply based on the Version

   If the link-layer protocol employs a specific "Protocol Type" value
   for encapsulating IPv4 packets (e.g., as is the case of Ethernet), a
   node should check that IPv4 packets are de-multiplexed to the IPv4
   module when such value was used for the Protocol Type field of the
   link-layer protocol.  If a packet does not pass this check, it should
   be silently dropped.

Top      Up      ToC       Page 10 
      An attacker could encapsulate IPv4 packets using other link-layer
      "Protocol Type" values to try to subvert link-layer Access Control
      Lists (ACLs) and/or for tampering with NIDSs.

3.2.  IHL (Internet Header Length)

   The IHL (Internet Header Length) field indicates the length of the
   Internet header in 32-bit words (4 bytes).  The following paragraphs
   describe a number of sanity checks to be performed on the IHL field,
   such that possible packet-of-death vulnerabilities are avoided.

   As the minimum datagram size is 20 bytes, the minimum legal value for
   this field is 5.  Therefore, the following check should be enforced:

                                  IHL >= 5

   If the packet does not pass this check, it should be dropped, and
   this event should be logged (e.g., a counter could be incremented
   reflecting the packet drop).

   For obvious reasons, the Internet header cannot be larger than the
   whole Internet datagram of which it is part.  Therefore, the
   following check should be enforced:

                          IHL * 4 <= Total Length

      This needs to refer to the size of the datagram as specified by
      the sender in the Total Length field, since link layers might have
      added some padding (see Section 3.4).

   If the packet does not pass this check, it should be dropped, and
   this event should be logged (e.g., a counter could be incremented
   reflecting the packet drop).

   The above check allows for Internet datagrams with no data bytes in
   the payload that, while nonsensical for virtually every protocol that
   runs over IP, are still legal.

3.3.  Type of Service (TOS)

3.3.1.  Original Interpretation

   Figure 2 shows the original syntax of the Type of Service field, as
   defined by RFC 791 [RFC0791] and updated by RFC 1349 [RFC1349].  This
   definition has been superseded long ago (see Sections and, but it is still assumed by some deployed implementations.

Top      Up      ToC       Page 11 
                0     1     2     3     4     5     6     7
             |   PRECEDENCE    |  D  |  T  |  R  |  C  |  0  |

         Figure 2: Type of Service Field (Original Interpretation)

        | Bits 0-2 |                  Precedence                  |
        | Bit 3    |        0 = Normal Delay, 1 = Low Delay       |
        | Bit 4    |  0 = Normal Throughput, 1 = High Throughput  |
        | Bit 5    | 0 = Normal Reliability, 1 = High Reliability |
        | Bit 6    |  0 = Normal Cost, 1 = Minimize Monetary Cost |
        | Bits 7   |    Reserved for Future Use (must be zero)    |

                    Table 1: Semantics of the TOS Bits

                         | 111 | Network Control |
                         | 110 |   Internetwork  |
                         | 101 |    CRITIC/ECP   |
                         | 100 |  Flash Override |
                         | 011 |      Flash      |
                         | 010 |    Immediate    |
                         | 001 |     Priority    |
                         | 000 |     Routine     |

        Table 2: Semantics of the Possible Precedence Field Values

   The Type of Service field can be used to affect the way in which the
   packet is treated by the systems of a network that process it.
   Section 4.2.1 ("Precedence-Ordered Queue Service") and Section 4.2.2

Top      Up      ToC       Page 12 
   ("Weak Type of Service") of this document describe the security
   implications of the Type of Service field in the forwarding of

3.3.2.  Standard Interpretation  Differentiated Services Field

   The Differentiated Services Architecture is intended to enable
   scalable service discrimination in the Internet without the need for
   per-flow state and signaling at every hop [RFC2475].  RFC 2474
   [RFC2474] redefined the IP "Type of Service" octet, introducing a
   Differentiated Services Field (DS Field).  Figure 3 shows the format
   of the field.

                       0   1   2   3   4   5   6   7
                     |         DSCP          |  CU   |

    Figure 3: Revised Structure of the Type of Service Field (RFC 2474)

   The DSCP ("Differentiated Services CodePoint") is used to select the
   treatment the packet is to receive within the Differentiated Services
   Domain.  The CU ("Currently Unused") field was, at the time the
   specification was issued, reserved for future use.  The DSCP field is
   used to select a PHB (Per-Hop Behavior), by matching against the
   entire 6-bit field.

   Considering that the DSCP field determines how a packet is treated
   within a Differentiated Services (DS) domain, an attacker could send
   packets with a forged DSCP field to perform a theft of service or
   even a Denial-of-Service (DoS) attack.  In particular, an attacker
   could forge packets with a codepoint of the type '11x000' which,
   according to Section of RFC 2474 [RFC2474], would give the
   packets preferential forwarding treatment when compared with the PHB
   selected by the codepoint '000000'.  If strict priority queuing were
   utilized, a continuous stream of such packets could cause a DoS to
   other flows that have a DSCP of lower relative order.

   As the DS field is incompatible with the original Type of Service
   field, both DS domains and networks using the original Type of
   Service field should protect themselves by remarking the
   corresponding field where appropriate, probably deploying remarking
   boundary nodes.  Nevertheless, care must be taken so that packets
   received with an unrecognized DSCP do not cause the handling system
   to malfunction.

Top      Up      ToC       Page 13  Explicit Congestion Notification (ECN)

   RFC 3168 [RFC3168] specifies a mechanism for routers to signal
   congestion to hosts exchanging IP packets, by marking the offending
   packets rather than discarding them.  RFC 3168 defines the ECN field,
   which utilizes the CU field defined in RFC 2474 [RFC2474].  Figure 4
   shows the current syntax of the IP Type of Service field, with the
   DSCP field used for Differentiated Services and the ECN field.

                0     1     2     3     4     5     6     7
             |          DS FIELD, DSCP           | ECN FIELD |

        Figure 4: The Differentiated Services and ECN Fields in IP

   As such, the ECN field defines four codepoints:

                         | ECN field | Codepoint |
                         |     00    |  Not-ECT  |
                         |     01    |   ECT(1)  |
                         |     10    |   ECT(0)  |
                         |     11    |     CE    |

                          Table 3: ECN Codepoints

   ECN is an end-to-end transport protocol mechanism based on
   notifications by routers through which a packet flow passes.  To
   allow this interaction to happen on the fast path of routers, the ECN
   field is located at a fixed location in the IP header.  However, its
   use must be negotiated at the transport layer, and the accumulated
   congestion notifications must be communicated back to the sending
   node using transport protocol means.  Thus, ECN support must be
   specified per transport protocol.

      [RFC6040] specifies how the Explicit Congestion Notification (ECN)
      field of the IP header should be constructed on entry to and exit
      from any IP-in-IP tunnel.

Top      Up      ToC       Page 14 
   The security implications of ECN are discussed in detail in a number
   of Sections of RFC 3168.  Of the possible threats discussed in the
   ECN specification, we believe that one that can be easily exploited
   is that of a host falsely indicating ECN-Capability.

   An attacker could set the ECT codepoint in the packets it sends, to
   signal the network that the endpoints of the transport protocol are
   ECN-capable.  Consequently, when experiencing moderate congestion,
   routers using active queue management based on Random Early Detection
   (RED) would mark the packets (with the CE codepoint) rather than
   discard them.  In this same scenario, packets of competing flows that
   do not have the ECT codepoint set would be dropped.  Therefore, an
   attacker would get better network service than the competing flows.

   However, if this moderate congestion turned into heavy congestion,
   routers should switch to drop packets, regardless of whether or not
   the packets have the ECT codepoint set.

   A number of other threats could arise if an attacker was a man in the
   middle (i.e., was in the middle of the path the packets travel to get
   to the destination host).  For a detailed discussion of those cases,
   we urge the reader to consult Section 16 of RFC 3168.

   There is also ongoing work in the research community and the IETF to
   define alternate semantics for the CU/ECN field of IP TOS octet (see
   [RFC5559], [RFC5670], and [RFC5696]).  The application of these
   methods must be confined to tightly administered domains, and on exit
   from such domains, all packets need to be (re-)marked with ECN

3.4.  Total Length

   The Total Length field is the length of the datagram, measured in
   bytes, including both the IP header and the IP payload.  Being a
   16-bit field, it allows for datagrams of up to 65535 bytes.  RFC 791
   [RFC0791] states that all hosts should be prepared to receive
   datagrams of up to 576 bytes (whether they arrive as a whole, or in
   fragments).  However, most modern implementations can reassemble
   datagrams of at least 9 Kbytes.

   Usually, a host will not send to a remote peer an IP datagram larger
   than 576 bytes, unless it is explicitly signaled that the remote peer
   is able to receive such "large" datagrams (for example, by means of
   TCP's Maximum Segment Size (MSS) option).  However, systems should
   assume that they may receive datagrams larger than 576 bytes,
   regardless of whether or not they signal their remote peers to do so.
   In fact, it is common for Network File System (NFS) [RFC3530]

Top      Up      ToC       Page 15 
   implementations to send datagrams larger than 576 bytes, even without
   explicit signaling that the destination system can receive such
   "large" datagram.

      Additionally, see the discussion in Section 4.1 ("Fragment
      Reassembly") regarding the possible packet sizes resulting from
      fragment reassembly.

   Implementations should be aware that the IP module could be handed a
   packet larger than the value actually contained in the Total Length
   field.  Such a difference usually has to do with legitimate padding
   bytes at the link-layer protocol, but it could also be the result of
   malicious activity by an attacker.  Furthermore, even when the
   maximum length of an IP datagram is 65535 bytes, if the link-layer
   technology in use allows for payloads larger than 65535 bytes, an
   attacker could forge such a large link-layer packet, meaning it for
   the IP module.  If the IP module of the receiving system were not
   prepared to handle such an oversized link-layer payload, an
   unexpected failure might occur.  Therefore, the memory buffer used by
   the IP module to store the link-layer payload should be allocated
   according to the payload size reported by the link layer, rather than
   according to the Total Length field of the IP packet it contains.

   The IP module could also be handed a packet that is smaller than the
   actual IP packet size claimed by the Total Length field.  This could
   be used, for example, to produce an information leakage.  Therefore,
   the following check should be performed:

                   LinkLayer.PayloadSize >= Total Length

   If this check fails, the IP packet should be dropped, and this event
   should be logged (e.g., a counter could be incremented reflecting the
   packet drop).  As the previous expression implies, the number of
   bytes passed by the link layer to the IP module should contain at
   least as many bytes as claimed by the Total Length field of the IP

      [US-CERT2002] is an example of the exploitation of a forged IP
      Total Length field to produce an information leakage attack.

3.5.  Identification (ID)

   The Identification field is set by the sending host to aid in the
   reassembly of fragmented datagrams.  At any time, it needs to be
   unique for each set of {Source Address, Destination Address,

Top      Up      ToC       Page 16 
   In many systems, the value used for this field is determined at the
   IP layer, on a protocol-independent basis.  Many of those systems
   also simply increment the IP Identification field for each packet
   they send.

   This implementation strategy is inappropriate for a number of
   reasons.  Firstly, if the Identification field is set on a protocol-
   independent basis, it will wrap more often than necessary, and thus
   the implementation will be more prone to the problems discussed in
   [Kent1987] and [RFC4963].  Secondly, this implementation strategy
   opens the door to an information leakage that can be exploited in a
   number of ways.

   [Sanfilippo1998a] describes how the Identification field can be
   leveraged to determine the packet rate at which a given system is
   transmitting information.  Later, [Sanfilippo1998b] described how a
   system with such an implementation can be used to perform a stealth
   port scan to a third (victim) host.  [Sanfilippo1999] explained how
   to exploit this implementation strategy to uncover the rules of a
   number of firewalls.  [Bellovin2002] explains how the IP
   Identification field can be exploited to count the number of systems
   behind a NAT.  [Fyodor2004] is an entire paper on most (if not all)
   of the ways to exploit the information provided by the Identification
   field of the IP header.

      Section 4.1 contains a discussion of the security implications of
      the IP fragment reassembly mechanism, which is the primary
      "consumer" of this field.

3.5.1.  Some Workarounds Implemented by the Industry

   As the IP Identification field is only used for the reassembly of
   datagrams, some operating systems (such as Linux) decided to set this
   field to 0 in all packets that have the DF bit set.  This would, in
   principle, avoid any type of information leakage.  However, it was
   detected that some non-RFC-compliant middle-boxes fragmented packets
   even if they had the DF bit set.  In such a scenario, all datagrams
   originally sent with the DF bit set would all result in fragments
   with an Identification field of 0, which would lead to problems
   ("collision" of the Identification number) in the reassembly process.

   Linux (and Solaris) later set the IP Identification field on a per-
   IP-address basis.  This avoids some of the security implications of
   the IP Identification field, but not all.  For example, systems
   behind a load balancer can still be counted.

Top      Up      ToC       Page 17 
3.5.2.  Possible Security Improvements

   Contrary to common wisdom, the IP Identification field does not need
   to be system-wide unique for each packet, but has to be unique for
   each {Source Address, Destination Address, Protocol} tuple.

      For instance, the TCP specification defines a generic send()
      function that takes the IP ID as one of its arguments.

   We provide an analysis of the possible security improvements that
   could be implemented, based on whether the protocol using the
   services of IP is connection-oriented or connection-less.  Connection-Oriented Transport Protocols

   To avoid the security implications of the information leakage
   described above, a pseudo-random number generator (PRNG) could be
   used to set the IP Identification field on a {Source Address,
   Destination Address} basis (for each connection-oriented transport

      [RFC4086] provides advice on the generation of pseudo-random

      [Klein2007] is a security advisory that describes a weakness in
      the pseudo-random number generator (PRNG) employed for the
      generation of the IP Identification by a number of operating

   While in theory a pseudo-random number generator could lead to
   scenarios in which a given Identification number is used more than
   once in the same time span for datagrams that end up getting
   fragmented (with the corresponding potential reassembly problems), in
   practice, this is unlikely to cause trouble.

   By default, most implementations of connection-oriented protocols,
   such as TCP, implement some mechanism for avoiding fragmentation
   (such as the Path-MTU Discovery mechanism described in [RFC1191]).
   Thus, fragmentation will only take place if a non-RFC-compliant
   middle-box that still fragments packets even when the DF bit is set
   is placed somewhere along the path that the packets travel to get to
   the destination host.  Once the sending system is signaled by the
   middle-box (by means of an ICMP "fragmentation needed and DF bit set"
   error message) that it should reduce the size of the packets it
   sends, fragmentation would be avoided.  Also, for reassembly problems
   to arise, the same Identification value would need to be reused very
   frequently, and either strong packet reordering or packet loss would
   need to take place.

Top      Up      ToC       Page 18 
   Nevertheless, regardless of what policy is used for selecting the
   Identification field, with the current link speeds fragmentation is
   already bad enough (i.e., very likely to lead to fragment reassembly
   errors) to rely on it.  A mechanism for avoiding fragmentation (such
   as [RFC1191] or [RFC4821] should be implemented, instead.  Connectionless Transport Protocols

   Connectionless transport protocols often have these characteristics:

   o  lack of flow-control mechanisms,

   o  lack of packet sequencing mechanisms, and/or,

   o  lack of reliability mechanisms (such as "timeout and retransmit").

   This basically means that the scenarios and/or applications for which
   connection-less transport protocols are used assume that:

   o  Applications will be used in environments in which packet
      reordering is very unlikely (such as Local Area Networks), as the
      transport protocol itself does not provide data sequencing.

   o  The data transfer rates will be low enough that flow control will
      be unnecessary.

   o  Packet loss is can be tolerated and/or is unlikely.

   With these assumptions in mind, the Identification field could still
   be set according to a pseudo-random number generator (PRNG).

      [RFC4086] provides advice on the generation of pseudo-random

   In the event a given Identification number was reused while the first
   instance of the same number is still on the network, the first IP
   datagram would be reassembled before the fragments of the second IP
   datagram get to their destination.

   In the event this was not the case, the reassembly of fragments would
   result in a corrupt datagram.  While some existing work
   [Silbersack2005] assumes that this error would be caught by some
   upper-layer error detection code, the error detection code in
   question (such as UDP's checksum) might not be able to reliably
   detect data corruption arising from the replacement of a complete
   data block (as is the case in corruption arising from collision of IP
   Identification numbers).

Top      Up      ToC       Page 19 
      In the case of UDP, unfortunately some systems have been known to
      not enable the UDP checksum by default.  For most applications,
      packets containing errors should be dropped by the transport layer
      and not delivered to the application.  A small number of
      applications may benefit from disabling the checksum; for example,
      streaming media where it is desired to avoid dropping a complete
      sample for a single-bit error, and UDP tunneling applications
      where the payload (i.e., the inner packet) is protected by its own
      transport checksum or other error detection mechanism.

   In general, if IP Identification number collisions become an issue
   for the application using the connection-less protocol, the
   application designers should consider using a different transport
   protocol (which hopefully avoids fragmentation).

   It must be noted that an attacker could intentionally exploit
   collisions of IP Identification numbers to perform a DoS attack, by
   sending forged fragments that would cause the reassembly process to
   result in a corrupt datagram that either would be dropped by the
   transport protocol or would incorrectly be handed to the
   corresponding application.  This issue is discussed in detail in
   Section 4.1 ("Fragment Reassembly").

3.6.  Flags

   The IP header contains 3 control bits, two of which are currently
   used for the fragmentation and reassembly function.

   As described by RFC 791, their meaning is:

   o  Bit 0: reserved, must be zero (i.e., reserved for future

   o  Bit 1: (DF) 0 = May Fragment, 1 = Don't Fragment

   o  Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments

   The DF bit is usually set to implement the Path-MTU Discovery (PMTUD)
   mechanism described in [RFC1191].  However, it can also be exploited
   by an attacker to evade Network Intrusion Detection Systems.  An
   attacker could send a packet with the DF bit set to a system
   monitored by a NIDS, and depending on the Path-MTU to the intended
   recipient, the packet might be dropped by some intervening router
   (because of being too big to be forwarded without fragmentation),
   without the NIDS being aware of it.

Top      Up      ToC       Page 20 
                                          | H |
                                          +---+  Victim host
                 Router A                   |  MTU=1500
                  +---+     +---+         +---+
                  | R |-----| R |---------| R |
                  +---+     +---+         +---+
                    |            MTU=17914      Router B
          +---+     |
          | S |-----+
          +---+     |
      NIDS Sensor   |
           _   ___/---\______                  Attacker
          / \_/              \_          +---+
         /       Internet      |---------| H |
         \_                  __/         +---+
           \__     __    ___/    <------
              \___/  \__/         17914-byte packet
                                  DF bit set

      Figure 5: NIDS Evasion by Means of the Internet Protocol DF Bit

   In Figure 3, an attacker sends a 17914-byte datagram meant for the
   victim host in the same figure.  The attacker's packet probably
   contains an overlapping IP fragment or an overlapping TCP segment,
   aiming at "confusing" the NIDS, as described in [Ptacek1998].  The
   packet is screened by the NIDS sensor at the network perimeter, which
   probably reassembles IP fragments and TCP segments for the purpose of
   assessing the data transferred to and from the monitored systems.
   However, as the attacker's packet should transit a link with an MTU
   smaller than 17914 bytes (1500 bytes in this example), the router
   that encounters that this packet cannot be forwarded without
   fragmentation (Router B) discards the packet, and sends an ICMP
   "fragmentation needed and DF bit set" error message to the source
   host.  In this scenario, the NIDS may remain unaware that the
   screened packet never reached the intended destination, and thus get
   an incorrect picture of the data being transferred to the monitored

      [Shankar2003] introduces a technique named "Active Mapping" that
      prevents evasion of a NIDS by acquiring sufficient knowledge about
      the network being monitored, to assess which packets will arrive
      at the intended recipient, and how they will be interpreted by it.

Top      Up      ToC       Page 21 
   Some firewalls are known to drop packets that have both the MF (More
   Fragments) and the DF (Don't Fragment) bits set.  While in principle
   such a packet might seem nonsensical, there are a number of reasons
   for which non-malicious packets with these two bits set can be found
   in a network.  First, they may exist as the result of some middle-box
   processing a packet that was too large to be forwarded without
   fragmentation.  Instead of simply dropping the corresponding packet
   and sending an ICMP error message to the source host, some middle-
   boxes fragment the packet (copying the DF bit to each fragment), and
   also send an ICMP error message to the originating system.  Second,
   some systems (notably Linux) set both the MF and the DF bits to
   implement Path-MTU Discovery (PMTUD) for UDP.  These scenarios should
   be taken into account when configuring firewalls and/or tuning NIDSs.

   Section 4.1 contains a discussion of the security implications of the
   IP fragment reassembly mechanism.

3.7.  Fragment Offset

   The Fragment Offset is used for the fragmentation and reassembly of
   IP datagrams.  It indicates where in the original datagram payload
   the payload of the fragment belongs, and is measured in units of
   eight bytes.  As a consequence, all fragments (except the last one),
   have to be aligned on an 8-byte boundary.  Therefore, if a packet has
   the MF flag set, the following check should be enforced:

                     (Total Length - IHL * 4) % 8 == 0

   If the packet does not pass this check, it should be dropped, and
   this event should be logged (e.g., a counter could be incremented
   reflecting the packet drop).

   Given that Fragment Offset is a 13-bit field, it can hold a value of
   up to 8191, which would correspond to an offset 65528 bytes within
   the original (non-fragmented) datagram.  As such, it is possible for
   a fragment to implicitly claim to belong to a datagram larger than
   65535 bytes (the maximum size for a legitimate IP datagram).  Even
   when the fragmentation mechanism would seem to allow fragments that
   could reassemble into such large datagrams, the intent of the
   specification is to allow for the transmission of datagrams of up to
   65535 bytes.  Therefore, if a given fragment would reassemble into a
   datagram of more than 65535 bytes, the resulting datagram should be
   dropped, and this event should be logged (e.g., a counter could be
   incremented reflecting the packet drop).  To detect such a case, the
   following check should be enforced on all packets for which the
   Fragment Offset contains a non-zero value:

Top      Up      ToC       Page 22 
    Fragment Offset * 8 + (Total Length - IHL * 4) + IHL_FF * 4 <= 65535

   where IHL_FF is the IHL field of the first fragment (the one with a
   Fragment Offset of 0).

   If a fragment does not pass this check, it should be dropped.

   If IHL_FF is not yet available because the first fragment has not yet
   arrived, for a preliminary, less rigid test, IHL_FF == IHL should be
   assumed, and the test is simplified to:

                Fragment Offset * 8 + Total Length <= 65535

   Once the first fragment is received, the full sanity check described
   earlier should be applied, if that fragment contains "don't copy"

   In the worst-case scenario, an attacker could craft IP fragments such
   that the reassembled datagram reassembled into a datagram of 131043

      Such a datagram would result when the first fragment has a
      Fragment Offset of 0 and a Total Length of 65532, and the second
      (and last) fragment has a Fragment Offset of 8189 (65512 bytes),
      and a Total Length of 65535.  Assuming an IHL of 5 (i.e., a header
      length of 20 bytes), the reassembled datagram would be 65532 +
      (65535 - 20) = 131047 bytes.

   Additionally, the IP module should implement all the necessary
   measures to be able to handle such illegitimate reassembled
   datagrams, so as to avoid them from overflowing the buffer(s) used
   for the reassembly function.

      [CERT1996c] and [Kenney1996] describe the exploitation of this
      issue to perform a DoS attack.

   Section 4.1 contains a discussion of the security implications of the
   IP fragment reassembly mechanism.

3.8.  Time to Live (TTL)

   The Time to Live (TTL) field has two functions: to bound the lifetime
   of the upper-layer packets (e.g., TCP segments) and to prevent
   packets from looping indefinitely in the network.

   Originally, this field was meant to indicate the maximum time a
   datagram was allowed to remain in the Internet system, in units of
   seconds.  As every Internet module that processes a datagram must

Top      Up      ToC       Page 23 
   decrement the TTL by at least one, the original definition of the TTL
   field became obsolete, and in practice it is interpreted as a hop
   count (see Section 5.3.1 of [RFC1812]).

   Most systems allow the administrator to configure the TTL to be used
   for the packets they originate, with the default value usually being
   a power of 2, or 255 (e.g., see [Arkin2000]).  The recommended value
   for the TTL field, as specified by the IANA is 64 [IANA_IP_PARAM].
   This value reflects the assumed "diameter" of the Internet, plus a
   margin to accommodate its growth.

   The TTL field has a number of properties that are interesting from a
   security point of view.  Given that the default value used for the
   TTL is usually either a power of two, or 255, chances are that unless
   the originating system has been explicitly tuned to use a non-default
   value, if a packet arrives with a TTL of 60, the packet was
   originally sent with a TTL of 64.  In the same way, if a packet is
   received with a TTL of 120, chances are that the original packet had
   a TTL of 128.

      This discussion assumes there was no protocol scrubber,
      transparent proxy, or some other middle-box that overwrites the
      TTL field in a non-standard way, between the originating system
      and the point of the network in which the packet was received.

   Determining the TTL with which a packet was originally sent by the
   source system can help to obtain valuable information.  Among other
   things, it may help in:

   o  Fingerprinting the originating operating system.

   o  Fingerprinting the originating physical device.

   o  Mapping the network topology.

   o  Locating the source host in the network topology.

   o  Evading Network Intrusion Detection Systems.

   However, it can also be used to perform important functions such as:

   o  Improving the security of applications that make use of the
      Internet Protocol (IP).

   o  Limiting spread of packets.

Top      Up      ToC       Page 24 
3.8.1.  Fingerprinting the Operating System in Use by the Source Host

   Different operating systems use a different default TTL for the
   packets they send.  Thus, asserting the TTL with which a packet was
   originally sent will help heuristics to reduce the number of possible
   operating systems in use by the source host.  It should be noted that
   since most systems use only a handful of different default values,
   the granularity of OS fingerprinting that this technique provides is
   negligible.  Additionally, these defaults may be configurable
   (system-wide or per protocol), and managed systems may employ such
   opportunities for operational purposes and to defeat the capability
   of fingerprinting heuristics.

3.8.2.  Fingerprinting the Physical Device from which the Packets

   When several systems are behind a middle-box such as a NAT or a load
   balancer, the TTL may help to count the number of systems behind the
   middle-box.  If each of the systems behind the middle-box uses a
   different default TTL value for the packets it sends, or each system
   is located at different distances in the network topology, an
   attacker could stimulate responses from the devices being
   fingerprinted, and responses that arrive with different TTL values
   could be assumed to come from a different devices.

      Of course, there are many other (and much more precise) techniques
      to fingerprint physical devices.  One weakness of this method is
      that, while many systems differ in the default TTL value that they
      use, there are also many implementations which use the same
      default TTL value.  Additionally, packets sent by a given device
      may take different routes (e.g., due to load sharing or route
      changes), and thus a given packet may incorrectly be presumed to
      come from a different device, when in fact it just traveled a
      different route.

   However, these defaults may be configurable (system-wide or per
   protocol) and managed systems may employ such opportunities for
   operational purposes and to defeat the capability of fingerprinting

3.8.3.  Mapping the Network Topology

   An originating host may set the TTL field of the packets it sends to
   progressively increasing values in order to elicit an ICMP error
   message from the routers that decrement the TTL of each packet to
   zero, and thereby determine the IP addresses of the routers on the
   path to the packet's destination.  This procedure has been
   traditionally employed by the traceroute tool.

Top      Up      ToC       Page 25 
3.8.4.  Locating the Source Host in the Network Topology

   The TTL field may also be used to locate the source system in the
   network topology [Northcutt2000].

             +---+     +---+      +---+    +---+     +---+
             | A |-----| R |------| R |----| R |-----| R |
             +---+     +---+      +---+    +---+     +---+
                        /           |               /   \
                       /            |              /     \
                      /             |             /       +---+
                     /   +---+    +---+      +---+        | E |
                    /    | R |----| R |------| R |--      +---+
                   /     +---+    +---+\     +---+  \
                  /     /          /    \       \    \
                 /  ----          /      +---+   \    \+---+
                /  /             /       | F |    \    | D |
             +---+          +---+        +---+     \   +---|
             | R |----------| R |--                 \
             +---+          +---+  \                 \
               |  \         /       \    +---+|     +---+
               |   \       /         ----| R |------| R |
               |    \     /              +---+      +---+
             +---+   \ +---+    +---+
             | B |    \| R |----| C |
             +---+     +---+    +---+

            Figure 6: Tracking a Host by Means of the TTL Field

   Consider network topology of Figure 6.  Assuming that an attacker
   ("F" in the figure) is performing some type of attack that requires
   forging the Source Address (such as for a TCP-based DoS reflection
   attack), and some of the involved hosts are willing to cooperate to
   locate the attacking system.

   Assuming that:

   o  All the packets A gets have a TTL of 61.

   o  All the packets B gets have a TTL of 61.

   o  All the packets C gets have a TTL of 61.

   o  All the packets D gets have a TTL of 62.

Top      Up      ToC       Page 26 
   Based on this information, and assuming that the system's default
   value was not overridden, it would be fair to assume that the
   original TTL of the packets was 64.  With this information, the
   number of hops between the attacker and each of the aforementioned
   hosts can be calculated.

   The attacker is:

   o  Four hops away from A.

   o  Four hops away from B.

   o  Four hops away from C.

   o  Four hops away from D.

   In the network setup of Figure 3, the only system that satisfies all
   these conditions is the one marked as the "F".

   The scenario described above is for illustration purposes only.  In
   practice, there are a number of factors that may prevent this
   technique from being successfully applied:

   o  Unless there is a "large" number of cooperating systems, and the
      attacker is assumed to be no more than a few hops away from these
      systems, the number of "candidate" hosts will usually be too large
      for the information to be useful.

   o  The attacker may be using a non-default TTL value, or, what is
      worse, using a pseudo-random value for the TTL of the packets it

   o  The packets sent by the attacker may take different routes, as a
      result of a change in network topology, load sharing, etc., and
      thus may lead to an incorrect analysis.

3.8.5.  Evading Network Intrusion Detection Systems

   The TTL field can be used to evade Network Intrusion Detection
   Systems.  Depending on the position of a sensor relative to the
   destination host of the examined packet, the NIDS may get a different
   picture from that of the intended destination system.  As an example,
   a sensor may process a packet that will expire before getting to the
   destination host.  A general countermeasure for this type of attack
   is to normalize the traffic that gets to an organizational network.
   Examples of such traffic normalization can be found in [Paxson2001].
   OpenBSD Packet Filter is an example of a packet filter that includes
   TTL-normalization functionality [OpenBSD-PF]

Top      Up      ToC       Page 27 
3.8.6.  Improving the Security of Applications That Make Use of the
        Internet Protocol (IP)

   In some scenarios, the TTL field can be also used to improve the
   security of an application, by restricting the hosts that can
   communicate with the given application [RFC5082].  For example, there
   are applications for which the communicating systems are typically in
   the same network segment (i.e., there are no intervening routers).
   Such an application is the BGP (Border Gateway Protocol) utilized by
   two peer routers (usually on a shared link medium).

   If both systems use a TTL of 255 for all the packets they send to
   each other, then a check could be enforced to require all packets
   meant for the application in question to have a TTL of 255.

   As all packets sent by systems that are not in the same network
   segment will have a TTL smaller than 255, those packets will not pass
   the check enforced by these two cooperating peers.  This check
   reduces the set of systems that may perform attacks against the
   protected application (BGP in this case), thus mitigating the attack
   vectors described in [NISCC2004] and [Watson2004].

      This same check is enforced for related ICMP error messages, with
      the intent of mitigating the attack vectors described in
      [NISCC2005] and [RFC5927].

   The TTL field can be used in a similar way in scenarios in which the
   cooperating systems are not in the same network segment (i.e., multi-
   hop peering).  In that case, the following check could be enforced:

                           TTL >= 255 - DeltaHops

   This means that the set of hosts from which packets will be accepted
   for the protected application will be reduced to those that are no
   more than DeltaHops away.  While for obvious reasons the level of
   protection will be smaller than in the case of directly connected
   peers, the use of the TTL field for protecting multi-hop peering
   still reduces the set of hosts that could potentially perform a
   number of attacks against the protected application.

   This use of the TTL field has been officially documented by the IETF
   under the name "Generalized TTL Security Mechanism" (GTSM) in

Top      Up      ToC       Page 28 
   Some protocol scrubbers enforce a minimum value for the TTL field of
   the packets they forward.  It must be understood that depending on
   the minimum TTL being enforced, and depending on the particular
   network setup, the protocol scrubber may actually help attackers to
   fool the GTSM, by "raising" the TTL of the attacking packets.

3.8.7.  Limiting Spread

   The originating host sets the TTL field to a small value (frequently
   1, for link-scope services) in order to artificially limit the
   (topological) distance the packet is allowed to travel.  This is
   suggested in Section of RFC 1812 [RFC1812].  Further
   discussion of this technique can be found in RFC 1112 [RFC1112].

3.9.  Protocol

   The Protocol field indicates the protocol encapsulated in the
   Internet datagram.  The Protocol field may not only contain a value
   corresponding to a protocol implemented by the system processing the
   packet, but also a value corresponding to a protocol not implemented,
   or even a value not yet assigned by the IANA [IANA_PROT_NUM].

   While in theory there should not be security implications from the
   use of any value in the protocol field, there have been security
   issues in the past with systems that had problems when handling
   packets with some specific protocol numbers [Cisco2003] [CERT2003].

   A host (i.e., end-system) that receives an IP packet encapsulating a
   Protocol it does not support should drop the corresponding packet,
   log the event, and possibly send an ICMP Protocol Unreachable (type
   3, code 2) error message.

3.10.  Header Checksum

   The Header Checksum field is an error-detection mechanism meant to
   detect errors in the IP header.  While in principle there should not
   be security implications arising from this field, it should be noted
   that due to non-RFC-compliant implementations, the Header Checksum
   might be exploited to detect firewalls and/or evade NIDSs.

   [Ed3f2002] describes the exploitation of the TCP checksum for
   performing such actions.  As there are Internet routers known to not
   check the IP Header Checksum, and there might also be middle-boxes
   (NATs, firewalls, etc.) not checking the IP checksum allegedly due to
   performance reasons, similar malicious activity to the one described
   in [Ed3f2002] might be performed with the IP checksum.

Top      Up      ToC       Page 29 
3.11.  Source Address

   The Source Address of an IP datagram identifies the node from which
   the packet originated.

      Strictly speaking, the Source Address of an IP datagram identifies
      the interface of the sending system from which the packet was
      sent, (rather than the originating "system"), as in the Internet
      Architecture there's no concept of "node address".

   Unfortunately, it is trivial to forge the Source Address of an
   Internet datagram because of the apparent lack of consistent "egress
   filtering" near the edge of the network.  This has been exploited in
   the past for performing a variety of DoS attacks [NISCC2004]
   [RFC4987] [CERT1996a] [CERT1996b] [CERT1998a] and for impersonating
   other systems in scenarios in which authentication was based on the
   Source Address of the sending system [daemon91996].

   The extent to which these attacks can be successfully performed in
   the Internet can be reduced through deployment of ingress/egress
   filtering in the Internet routers.  [NISCC2006] is a detailed guide
   on ingress and egress filtering.  [RFC2827] and [RFC3704] discuss
   ingress filtering.  [GIAC2000] discusses egress filtering.
   [SpooferProject] measures the Internet's susceptibility to forged
   Source Address IP packets.

      Even when the obvious field on which to perform checks for
      ingress/egress filtering is the Source Address and Destination
      Address fields of the IP header, there are other occurrences of IP
      addresses on which the same type of checks should be performed.
      One example is the IP addresses contained in the payload of ICMP
      error messages, as discussed in [RFC5927] and [Gont2006].

   There are a number of sanity checks that should be performed on the
   Source Address of an IP datagram.  Details can be found in
   Section 4.3 ("Addressing").

   Additionally, there exist freely available tools that allow
   administrators to monitor which IP addresses are used with which MAC
   addresses [LBNL2006].  This functionality is also included in many

   It is also very important to understand that authentication should
   never rely solely on the Source Address used by the communicating

Top      Up      ToC       Page 30 
3.12.  Destination Address

   The Destination Address of an IP datagram identifies the destination
   host to which the packet is meant to be delivered.

      Strictly speaking, the Destination Address of an IP datagram
      identifies the interface of the destination network interface,
      rather than the destination "system", as in the Internet
      Architecture there's no concept of "node address".

   There are a number of sanity checks that should be performed on the
   Destination Address of an IP datagram.  Details can be found in
   Section 4.3 ("Addressing").

(page 30 continued on part 3)

Next RFC Part