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. まったくもって捉えどころのないヌルパケットというもの、RFCシリーズの 文書中での言及は多いが、明示的には定義されていない。このメモは、その 欠落を補完する。 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. これは RFC への貢献であり、他の RFC の系統とは独立している。 RFC Editor は自らの権限でこの文書を公開することを選択し、実装や展開の 価値については触れない。RFC Editor によって公開を承認をされた文書はイ ンターネット標準のいかなるレベルの候補でもない。RFC 5714 の第２章参照。 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. この文書の現在の状況、正誤表、フィードバックの提供方法の情報は 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. この文書は BCP 78 と、この文書の公開日に有効な IETF 文書 (http://trustee.ietf.org/license-info)に関連する IETF トラストの法律 条項の対象である。この文書に関連する読者の権利と制限が記述されている ので、これらの条項は注意深く読んでほしい。 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. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. ヌルパケット . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1. 形式的な定義 . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. 同音異義 . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. 性能の測定基準に関する考察 . . . . . . . . . . . . . . . . . . 3 4. セキュリティについての考察 . . . . . . . . . . . . . . . . . . 3 4.1. 矛盾したファイヤーウォール . . . . . . . . . . . . . . . . 4 4.2. 善なるヌルパケット . . . . . . . . . . . . . . . . . . . . 4 4.3. 単純な暗号化は注意深く . . . . . . . . . . . . . . . . . . 4 4.4. サービス拒絶の拒否 . . . . . . . . . . . . . . . . . . . . 4 5. IANA の意見 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 6. 参考文献 . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.1. 基本参考文献 . . . . . . . . . . . . . . . . . . . . . . . 5 6.2. 有益な参考文献 . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction 1. はじめに 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. ヌルパケットは、受信されたときに限り送信される。それはシンプルさという 点において完璧であるとともに、真実性も申し分ないと、ネットワークの真実 の12番目[RFC1925]から推定される： *文字どおり* 何も取り去るものがない からだ。 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". ヌルパケットについての最初の言及は、TCP/IPヘッダー圧縮[RFC1144]の文書 でのヴァン・ジャコブソンによるものである。覚えておきたいことは、ヌルパ ケットは、パケットが無に帰するまで圧縮されることでは作成されない。その ような圧縮技術は非可逆かもしれない。その代わり、[RFC1144]の3.2.4章は、 明確な応答がないことを「ヌルパケットがかえってくる」と記載している。 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). 多くの文書が、ヌルパケットのための通信用コード番号およびプロトコル識別 子(PID)を定義しようとしている。[RFC4259] [RFC4571] [RFC5320]　しかし、 そのような定義は役に立たない。このメモでは、プロトコルの構成またはヌル の値はヌルであるがゆえに、ヌルパケットはPIDを持てないと仮定する；これは 値としての0x0、0x0000、あるいは0x00000000でさえも使えないことを意味する が、""（訳注：空文字列）の使用は制限されない。（2.1章参照） An IPv6 Next Header value of 59 (No Next Header) (see Section 4.7 of [RFC2460]) does not create a Null Packet. IPv6のネクストヘッダフィールドでの値59（次ヘッダなし）（[RFC2460]の 4.7章参照）はヌルパケットを生成しない。 2. The Null Packet 2. ヌルパケット 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 2.1. 形式的な定義 [This section is intentionally left blank, see also Section 0 of [NULL].] [この章は意図的に空白にされている。[NULL]の０章参照のこと。] 2.2. Faux Amis 2.2. 同音異義 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. 多くの専門家は、ヌルパケットと架空のパケットを単に混同する。これはヌル パケットの存在証明がないときは合理的な行動である。ちなみに、架空のパケ ットとは、IPv4iとIPv6iの両方である。だがプロトコル原理主義者達はごまか されず、それら専門家に対してはすぐに、まじめにやれと抗議する。 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 3. 性能の測定基準に関する考察 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]). ヌルパケットを送信するプロトコルは、長さゼロのパケットを効果的に送信す る。ヌルパケットのトラフィックの流れの１つの特徴は、ヌルパケットの送信 比率を大きくしても、ヌルパケットのトラフィックのビットレートを増加させ ないということである。ヌルパケットが単位時間あたりに無限に送信される場 合を除き、ビットレートは、明確にヌルのままである。同様に、ユーザーがヌ ルパケットの送信を停止しても、ヌルパケットのビットレートは変化しないだ ろう。これまでのトラフィック性能測定基準をヌルパケットのトラフィックに 適合させることはふさわしくない；この事実は、「有用性」（[RFC6390]の5.2 章参照）の面で肯定的に評価された新しい一連の性能測定基準を作成するため の論拠となる。 4. Security Considerations 4. セキュリティについての考察 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. マルチプロトコルラベルスイッチング（MPLS）環境で使用する場合、ヌルパケ ットは暗黙のヌルラベルだけを使える。（[RFC3031]の4.1.5章参照）暗黙のヌ ルパケットは配布可能ラベルであるが、カプセル化において実際に現れること はない。Nil FECは使われない。 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 4.1. 矛盾したファイヤーウォール 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 4.2. ヌルパケットは善 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. ヌルパケットは、その定義に基づき、Evil Bit（"E"）[RFC3514]を持つことが できない。（2.1章参照）したがって、悪意を持たないことから、ヌルパケッ トが無害なことは間違いなく明白である。 4.3. Just Encrypt It, Carefully 4.3. 単純な暗号化は注意深く 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.) セキュリティについての考察のセクションにおいて一般的に受け入れられてい る慣例では、"foo"のほとんどの値を対象とするものを、"fooの周辺の暗号化" という記述で包含する。この文書でも対象となる。しかしながら、ヌルパケッ トにNULL暗号化[RFC2410]を適用しないために注意深い対応をしなければなら ない；そのような不注意な行為は、途絶やら、０除算や「Google」という単語 をググるよりも壮大な「しまった」をもたらすことがある。（そのような行動 はインターネットを壊せると噂されたが、これは背理法によって簡単に反証で きる） 4.4. Denial of Denial of Service 4.4. サービス拒絶の拒否 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). システム管理者、ネットワーク管理者、セキュリティ管理者、および他のネッ トワークオペレーションセンタの技術者は、ヌルパケットをブロックすること の異論なき不可能性（4.1章参照）に直面しているが、ヌルパケットを活用し た攻撃は世間ではそれほど一般的ではないし、セキュリティニュースにおいて も見かけられない。おそらく、これらの異常なパケットはデータプレーン内で のなりすましは難しいこと、またはそれらの生存時間（TTL）やホップリミッ トはそもそも存在しない[RFC5082]ことから変更できないので、これらの事実 からヌルパケットはサービス拒絶を拒否（DoDoS）を提供する。 An important corollary is that dropping Null Packets does not generate packets. 重要な結論は、ヌルパケットの破棄がパケットを生成しないということである。 5. IANA Considerations 5. IANA の意見 This document explicitly and emphatically, yet very humbly, requests IANA to not create an empty registry for the Null Packet. このドキュメントは、明示的にかつきっぱりと、けれども非常につつましく、 ヌルパケット用の空のレジストリを作成しないことをIANAに要求する。 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]