広告
広告
https://www.7key.jp/rfc/1981/rfc1981_6.html#sourcehttps://www.7key.jp/rfc/1981/rfc1981_6.html#translationThis Path MTU Discovery mechanism makes possible two denial-of- service attacks, both based on a malicious party sending false Packet Too Big messages to a node.
当経路MTU探索メカニズムは、2つのサービス不能攻撃の可能性となり、両方とも悪意をもつものがノードへ偽造したパケット過大メッセージを送信することによる。
In the first attack, the false message indicates a PMTU much smaller than reality. This should not entirely stop data flow, since the victim node should never set its PMTU estimate below the IPv6 minimum link MTU. It will, however, result in suboptimal performance.
1つ目の攻撃では、偽造メッセージは実際より非常に小さいPMTUを示す。被害ノードがIPv6最小リンクMTUより小さなPMTUの概算を設定しないため、これはデータフローを完全に停止させることとなる。しかし、これはパフォーマンスが多少下がるだけだろう。
In the second attack, the false message indicates a PMTU larger than reality. If believed, this could cause temporary blockage as the victim sends packets that will be dropped by some router. Within one round-trip time, the node would discover its mistake (receiving Packet Too Big messages from that router), but frequent repetition of this attack could cause lots of packets to be dropped. A node, however, should never raise its estimate of the PMTU based on a Packet Too Big message, so should not be vulnerable to this attack.
2つ目の攻撃では、偽造メッセージは実際より大きなPMTUを示す。これが信用されたのであれば、犠牲者があるルータに破棄されたパケットを送信することによって一時的な封鎖状態を引き起こすだろう。1ラウンドトリップ時間内では、ノードは（パケット過大メッセージを受信し）その誤りに気付くが、この攻撃が頻繁に繰り返されることによって多くのパケットが破棄される結果となる。しかし、ノードはパケット過大メッセージに基づくPMTUの概算を増加すべきではなく、この攻撃に対し脆弱であるべきではない。
A malicious party could also cause problems if it could stop a victim from receiving legitimate Packet Too Big messages, but in this case there are simpler denial-of-service attacks available.
犠牲者が正当なパケット過大メッセージの受信を止めるのであれば、悪意をもつものが問題を起こすこともあるが、この場合有効なより単純なサービス不能攻撃がある。
We would like to acknowledge the authors of and contributors to [RFC-1191], from which the majority of this document was derived. We would also like to acknowledge the members of the IPng working group for their careful review and constructive criticisms.
当文書の大部分を得ることとなった[RFC-1191]の著者と貢献者達に謝辞を述べる。また、注意深い査読と建設的な批評を頂いたIPngワーキンググループのメンバにも謝辞を述べる。
This document is based in large part on RFC 1191, which describes
Path MTU Discovery for IPv4. Certain portions of RFC 1191 were not
needed in this document:
router specification - Packet Too Big messages and corresponding
router behavior are defined in [ICMPv6]
Don't Fragment bit - there is no DF bit in IPv6 packets
TCP MSS discussion - selecting a value to send in the TCP MSS
option is discussed in [IPv6-SPEC]
old-style messages - all Packet Too Big messages report the
MTU of the constricting link
MTU plateau tables - not needed because there are no old-style
messages
当文書の大部分は、IPv4用の経路MTU探索を記述しているRFC1191が基になっている。RFC1191のある部分は当文書に必要がなかった：
[CONG] Van Jacobson. Congestion Avoidance and Control. Proc.
SIGCOMM '88 Symposium on Communications Architectures and
Protocols, pages 314-329. Stanford, CA, August, 1988.
[FRAG] C. Kent and J. Mogul. Fragmentation Considered Harmful.
In Proc. SIGCOMM '87 Workshop on Frontiers in Computer
Communications Technology. August, 1987.
[ICMPv6] Conta, A., and S. Deering, "Internet Control Message
Protocol (ICMPv6) for the Internet Protocol Version 6
(IPv6) Specification", RFC 1885, December 1995.
[IPv6-SPEC] Deering, S., and R. Hinden, "Internet Protocol, Version
6 (IPv6) Specification", RFC 1883, December 1995.
[ISOTP] ISO. ISO Transport Protocol Specification: ISO DP 8073.
RFC 905, SRI Network Information Center, April, 1984.
[ND] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", Work in Progress.
[RFC-1191] Mogul, J., and S. Deering, "Path MTU Discovery",
RFC 1191, November 1990.
[RPC] Sun Microsystems, Inc., "RPC: Remote Procedure Call
Protocol", RFC 1057, SRI Network Information Center,
June, 1988.
Jack McCann Digital Equipment Corporation 110 Spitbrook Road, ZKO3-3/U14 Nashua, NH 03062 Phone: +1 603 881 2608 Fax: +1 603 881 0120 Email: mccann@zk3.dec.com Stephen E. Deering Xerox Palo Alto Research Center 3333 Coyote Hill Road Palo Alto, CA 94304 Phone: +1 415 812 4839 Fax: +1 415 812 4471 EMail: deering@parc.xerox.com Jeffrey Mogul Digital Equipment Corporation Western Research Laboratory 250 University Avenue Palo Alto, CA 94301 Phone: +1 415 617 3304 EMail: mogul@pa.dec.com
広告