doc: Add RFC documents

1 files changed, 339 insertions, 0 deletions

diff --git a/doc/rfc/rfc6592.txt b/doc/rfc/rfc6592.txt
new file mode 100644
index 0000000..477493b
--- /dev/null
+++ b/doc/rfc/rfc6592.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Independent Submission                                      C. Pignataro
+Request for Comments: 6592                                        Cisco
+Category: Informational                                     1 April 2012
+ISSN:  2070-1721
+
+
+                            The Null Packet
+
+Abstract
+
+   The ever-elusive Null Packet received numerous mentions in documents
+   in the RFC series, but it has never been explicitly defined.  This
+   memo corrects that omission.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This is a contribution to the RFC Series, independently of any other
+   RFC stream.  The RFC Editor has chosen to publish this document at
+   its discretion and makes no statement about its value for
+   implementation or deployment.  Documents approved for publication by
+   the RFC Editor are not a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6592.
+
+Copyright Notice
+
+   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 of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.
+
+
+
+
+
+
+
+
+
+
+Pignataro                     Informational                     [Page 1]
+
+RFC 6592                     The Null Packet                1 April 2012
+
+
+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
+
+   Null Packets are neither sent nor acknowledged when not received.
+   They are perfect in their simplicity and they are very true, as they
+   extrapolate from the twelfth Truth of networking [RFC1925]:  there is
+   *literally* nothing left to take away.
+
+   An early mention of the Null Packet is attributed to Van Jacobson in
+   the context of TCP/IP Header Compression [RFC1144].  Mind you, the
+   Null Packet is not created by compressing a packet until it
+   disappears into nothingness.  Such a 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".
+
+   Many documents attempt to define in-the-wire code points and protocol
+   identifiers (PIDs) for a Null Packet [RFC4259] [RFC4571] [RFC5320].
+   However, such an exercise is futile.  This memo postulates that a
+   Null Packet cannot have a PID, as the existence of a protocol
+   construct or value would null the null; this includes the inability
+   to use 0x0, 0x0000, or even 0x00000000, but excludes the restriction
+   to use "" (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.
+
+2.  The Null Packet
+
+   The Null Packet is a zero-dimensional packet.  The Null Packet exists
+   since it is non-self-contradictorily definable.
+
+
+
+
+
+Pignataro                     Informational                     [Page 2]
+
+RFC 6592                     The Null Packet                1 April 2012
+
+
+2.1.  Formal Definition
+
+   [This section is intentionally left blank, see also Section 0 of
+   [NULL].]
+
+2.2.  Faux Amis
+
+   Many experts naively confuse the Null Packet with an Imaginary
+   Packet, in a rationalization attempt when faced with the inability to
+   prove the existence of the Null Packet.  For reference, an Imaginary
+   Packet contains the IP Version of 4i or 6i.  However, protocol
+   purists are not fooled and quickly plea with experts to get real.
+
+   The Null Packet's qualities should not be confused with the bit-
+   bucket blackhole nature of the null device, since the Null Packet
+   does not discard packets.  Confusion might stem from the fact that
+   the behavior is similar to that of 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.  One characteristic of flow streams of Null Packet traffic is
+   that increasing the rate at which Null Packets are sent does not
+   increase the bit rate of the Null Packet traffic.  The bit rate
+   continues being unequivocally null, unless an infinite number of Null
+   Packets per unit of time could be sent.  Similarly, should a user
+   stop sending Null Packets, the bit rate of Null Packets would not
+   vary.  Traditional traffic performance metrics are not well suited to
+   qualify Null Packet traffic; this fact argues for the creation of new
+   sets of performance metrics that test positive for "usefulness" (see
+   Section 5.2 of [RFC6390]).
+
+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, as
+   hereby described.  The "good" nature of Null Packets is quite
+   useless, and the "bad" nature of Null Packets is rather inefficient.
+
+
+
+
+
+
+
+Pignataro                     Informational                     [Page 3]
+
+RFC 6592                     The Null Packet                1 April 2012
+
+
+4.1.  The Paradoxical Firewall
+
+   Many firewalls and other security devices have trouble identifying
+   the Null Packet.  Others claim to filter out Null Packets quite
+   effectively and effortlessly.  Interestingly, or not, both might be
+   correct, which begs the omnipotence paradox:  Can a firewall create a
+   rule to filter out the Null Packet coming from the "outside", and not
+   see 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).  Consequently, it is rather clear and
+   undeniable that the Null Packet is harmless, having no evil intent.
+
+4.3.  Just Encrypt It, Carefully
+
+   A commonly accepted practice for Security Considerations sections is
+   to wrap a blanket "encrypt around foo" statement, for 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
+   are faced with the undisputed inability to block Null Packets (see
+   Section 4.1), attacks leveraging Null Packets are not quite so common
+   in the wild and are not seen in the seek^Wsecurity news.  Perhaps
+   because these unusual packets are hard to spoof in the data plane, or
+   because their Time to Live (TTL) or Hop Limit cannot be altered since
+   it does not exist [RFC5082], the fact is that Null Packets present a
+   denial of denial of service (DoDoS).
+
+   An important corollary is that dropping Null Packets does not
+   generate packets.
+
+5.  IANA Considerations
+
+   This document explicitly and emphatically, yet very humbly, requests
+   IANA to not create an empty registry for the Null Packet.
+
+
+
+
+
+
+
+Pignataro                     Informational                     [Page 4]
+
+RFC 6592                     The Null Packet                1 April 2012
+
+
+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.
+
+
+
+
+
+
+
+Pignataro                     Informational                     [Page 5]
+
+RFC 6592                     The Null Packet                1 April 2012
+
+
+Author's Address
+
+   Carlos Pignataro
+   Cisco Systems, Inc.
+   7200-12 Kit Creek Road
+   Research Triangle Park, NC  27709
+   US
+
+   EMail:  cpignata@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pignataro                     Informational                     [Page 6]
+