RFC 6592

The Null Packet

📅 published April 2012, from ietf

RFC 6592: The Null Packet 🧚

  • Request for Comments: 6592
  • Title: The Null Packet
  • Author: Carlos Pignataro, Cisco 💅
  • Category: Informational
  • Stream: Independent Submission
  • Date: 1 April 2012
  • ISSN: 2070-1721
  • Obsoletes / Updates: This title block doesn't list anything it obsoletes or updates 🫶

Abstract ✨

okay so the ever-elusive Null Packet has been name-dropped in a bunch of RFC-series documents, but nobody ever actually defined it. 😭 This memo finally fixes that. bestie, we're doing it. 🎀

Status of This Memo 📝

This document is not an Internet Standards Track specification. It's published for informational purposes, so no pressure 🌸

This is a contribution to the RFC Series, made independently of any other RFC stream. The RFC Editor chose to publish it at its discretion, and they make no statement about its value for implementation or deployment. Documents the RFC Editor approves for publication are not candidates for any level of Internet Standard, see Section 2 of RFC 5741. 💅

Info about the current status of this document, any errata, and how to give feedback on it lives at http://www.rfc-editor.org/info/rfc6592. ✨

Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. 💜

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication. Please read those carefully, because they spell out your rights and restrictions for this document. 🫶

Table of Contents 🗂️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.  The Null Packet . . . . . . . . . . . . . . . . . . . . . . . . 2
  2.1.  Formal Definition . . . . . . . . . . . . . . . . . . . . . 3
  2.2.  Faux Amis . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.  Performance Metrics Considerations  . . . . . . . . . . . . . . 3
4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 3
  4.1.  The Paradoxical Firewall  . . . . . . . . . . . . . . . . . 4
  4.2.  The Null Packet is Good . . . . . . . . . . . . . . . . . . 4
  4.3.  Just Encrypt It, Carefully  . . . . . . . . . . . . . . . . 4
  4.4.  Denial of Denial of Service . . . . . . . . . . . . . . . . 4
5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
  6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
  6.2.  Informative References  . . . . . . . . . . . . . . . . . . 5

1. Introduction 🦋

okay so Null Packets are neither sent nor acknowledged when they're not received. 🙈 They're perfect in their simplicity and honestly very true, because they follow from the twelfth Truth of networking [RFC1925]: there is literally nothing left to take away. 💀

An early mention of the Null Packet is credited to Van Jacobson, in the context of TCP/IP Header Compression [RFC1144]. Mind you, a Null Packet is not what you get from compressing a packet until it disappears into nothingness. That kind of compression scheme might not be reversible. Instead, Section 3.2.4 of [RFC1144] describes an explicit lack of response as "Nothing (a null packet) is returned". 🌈

Lots of documents try to define in-the-wire code points and protocol identifiers (PIDs) for a Null Packet [RFC4259] [RFC4571] [RFC5320]. ngl, that's giving futile. 🥲 This memo argues that a Null Packet cannot have a PID, because the existence of a protocol construct or value would null the null. That includes the inability to use 0x0, 0x0000, or even 0x00000000, but it doesn't rule out "" (see Section 2.1). 🍓

An IPv6 Next Header value of 59 (No Next Header) (see Section 4.7 of [RFC2460]) does not create a Null Packet. not me thinking it would. 🙃

2. The Null Packet 💖

The Null Packet is a zero-dimensional packet. It exists because it is non-self-contradictorily definable, and that's the whole slay. 👑

2.1. Formal Definition 📜

[This section is intentionally left blank, see also Section 0 of [NULL].]

2.2. Faux Amis 🎭

Lots of experts naively mix up the Null Packet with an Imaginary Packet. This happens in a rationalization attempt when they can't prove the Null Packet exists, which is so relatable. 😭 For reference, an Imaginary Packet contains the IP Version of 4i or 6i. Protocol purists are not fooled, though, and they quickly beg the experts to get real. 💅

The Null Packet's qualities shouldn't be mixed up with the bit-bucket blackhole nature of the null device, because the Null Packet does not discard packets. The confusion might come from the fact that the behavior is similar to input streams reading from /dev/null (i.e., "nothing is returned"). 🫠

3. Performance Metrics Considerations 📊

A protocol sending Null Packets effectively sends packets of zero length. The thing about flow streams of Null Packet traffic is that speeding up the rate of Null Packets does not increase the bit rate. The bit rate stays unequivocally null, unless an infinite number of Null Packets per unit of time could be sent, which is not happening, bestie. ♾️ Likewise, if a user stops sending Null Packets, the bit rate of Null Packets wouldn't change. 🙃

Traditional traffic performance metrics aren't a good fit for qualifying Null Packet traffic. This fact argues for making new sets of performance metrics that test positive for "usefulness" (see Section 5.2 of [RFC6390]). It's giving main character energy for the metrics world 🧚

4. Security Considerations 🔐

When used in a Multiprotocol Label Switching (MPLS) environment, the Null Packet can only use an Implicit NULL label (see Section 4.1.5 of [RFC3031]. The Implicit NULL label is a label that can be distributed, but which never actually appears in the encapsulation. The Nil FEC is not used. 🫶

The security considerations for the Null Packet are undefined, and here's why. The "good" nature of Null Packets is quite useless, and the "bad" nature of Null Packets is rather inefficient. 🥀

4.1. The Paradoxical Firewall 🧱

Lots of firewalls and other security devices have trouble spotting the Null Packet. Others claim they filter out Null Packets quite effectively and effortlessly. Interestingly, or not, both can be correct, and that raises the omnipotence paradox: Can a firewall create a rule to filter out the Null Packet coming from the "outside", without seeing Null Packets being allowed on the "inside"? 🤯

4.2. The Null Packet is Good 😇

The Null Packet cannot have the Evil Bit ("E") [RFC3514] set, by definition (see Section 2.1). So it's rather clear and undeniable that the Null Packet is harmless, with no evil intent. 🫶

4.3. Just Encrypt It, Carefully 🔒

It's a commonly accepted practice for Security Considerations sections to wrap a blanket "encrypt around foo" statement around almost any value of "foo". This document is no exception. However, surgical care must be taken to not apply NULL encryption [RFC2410] to the Null Packet. Such a careless act can bring discontinuities and "Oops" more epic than dividing by zero or Googling the word "Google". (It has been rumored that such action can break the Internet, although this can be easily disproved by reductio ad absurdum.) 💀

4.4. Denial of Denial of Service 🛡️

Even when sysadmins, netadmins, secadmins, and other NOC engineers face the undisputed inability to block Null Packets (see Section 4.1), attacks leveraging Null Packets aren't quite so common in the wild and don't show up in the seek^Wsecurity news. Maybe that's because these unusual packets are hard to spoof in the data plane, or because their Time to Live (TTL) or Hop Limit can't be altered since it doesn't exist [RFC5082]. Either way, the fact is that Null Packets present a denial of denial of service (DoDoS). 🙈

An important corollary: dropping Null Packets does not generate packets. 💅

5. IANA Considerations 🌸

This document explicitly and emphatically, yet very humbly, asks IANA to not create an empty registry for the Null Packet. 🥹

6. References 📚

6.1. Normative References

[NULL]     "".

[RFC1144]  Jacobson, V., "Compressing TCP/IP headers for low-speed
           serial links", RFC 1144, February 1990.

[RFC1925]  Callon, R., "The Twelve Networking Truths", RFC 1925,
           April 1996.

[RFC3514]  Bellovin, S., "The Security Flag in the IPv4 Header",
           RFC 3514, April 1 2003.

6.2. Informative References

[RFC2410]  Glenn, R. and S. Kent, "The NULL Encryption Algorithm and
           Its Use With IPsec", RFC 2410, November 1998.

[RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
           (IPv6) Specification", RFC 2460, December 1998.

[RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
           Label Switching Architecture", RFC 3031, January 2001.

[RFC4259]  Montpetit, M., Fairhurst, G., Clausen, H., Collini-Nocker,
           B., and H. Linder, "A Framework for Transmission of IP
           Datagrams over MPEG-2 Networks", RFC 4259, November 2005.

[RFC4571]  Lazzaro, J., "Framing Real-time Transport Protocol (RTP)
           and RTP Control Protocol (RTCP) Packets over Connection-
           Oriented Transport", RFC 4571, July 2006.

[RFC5082]  Gill, V., Heasley, J., Meyer, D., Savola, P., and C.
           Pignataro, "The Generalized TTL Security Mechanism
           (GTSM)", RFC 5082, October 2007.

[RFC5320]  Templin, F., "The Subnetwork Encapsulation and Adaptation
           Layer (SEAL)", RFC 5320, February 2010.

[RFC6390]  Clark, A. and B. Claise, "Guidelines for Considering New
           Performance Metric Development", BCP 170, RFC 6390,
           October 2011.

Author's Address 🧚

Carlos Pignataro
Cisco Systems, Inc.
7200-12 Kit Creek Road
Research Triangle Park, NC  27709
US

EMail:  cpignata@cisco.com
📦 where this page comes from