ICMP Attacks against TCP
draft-ietf-tcpm-icmp-attacks-12
Yes
(Lars Eggert)
No Objection
(Adrian Farrel)
(Dan Romascanu)
(Pasi Eronen)
(Ralph Droms)
(Robert Sparks)
(Ron Bonica)
(Ross Callon)
(Russ Housley)
(Tim Polk)
Note: This ballot was opened for revision 12 and is now closed.
Jari Arkko Former IESG member
Yes
Yes
(2010-02-18)
Unknown
This document should be approved as an RFC. Thanks for writing it. However, I would like to note the following text from the document: The consensus of the TCPM WG (TCP Maintenance and Minor Extensions Working Group) was to document this widespread implementation of nonstandard TCP behavior but to not change the TCP standard. This would seem to imply that the TCPM WG has decided to deviate from the old IETF operating principle of "rough consensus and running code". For at least some of the techniques described in this draft, they are generally accepted and widely implemented on key implementations. I ask what the reason is for divorcing IETF standards from established best practices and actual running code?
Lars Eggert Former IESG member
Yes
Yes
()
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
()
Unknown
Alexey Melnikov Former IESG member
No Objection
No Objection
(2010-02-18)
Unknown
Should [I-D.ietf-tsvwg-port-randomization] reference be Normative?
Dan Romascanu Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Magnus Westerlund Former IESG member
No Objection
No Objection
(2010-02-18)
Unknown
Section 7.1: For IPv6, the reported Next-Hop MTU could be as low as 1280 octets (the minimum IPv6 MTU) [RFC2460]. Actually the reported MTU can be lower than 1280. The proper response is to send if I understand RFC 2460 is to send a <= 1280 bytes packet with fragmentation header. From section 5 of RFC 2460: In response to an IPv6 packet that is sent to an IPv4 destination (i.e., a packet that undergoes translation from IPv6 to IPv4), the originating IPv6 node may receive an ICMP Packet Too Big message reporting a Next-Hop MTU less than 1280. In that case, the IPv6 node is not required to reduce the size of subsequent packets to less than 1280, but must include a Fragment header in those packets so that the IPv6-to-IPv4 translating router can obtain a suitable Identification value to use in resulting IPv4 fragments. Note that this means the payload may have to be reduced to 1232 octets (1280 minus 40 for the IPv6 header and 8 for the Fragment header), and smaller still if additional extension headers are used.
Pasi Eronen Former IESG member
No Objection
No Objection
()
Unknown
Ralph Droms Former IESG member
No Objection
No Objection
()
Unknown
Robert Sparks Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Ross Callon Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Tim Polk Former IESG member
(was No Record, Discuss)
No Objection
No Objection
(2010-02-18)
Unknown
section 7.3.2, figure 3 line 2: DATA size should be 1460, not 1500 (established MTU is 1500) Section 7.3.5, figure 6 line 8: for this example, shouldn't TCPseq#=201 or 301? 101 has already been acknowledged...