datatracker.ietf.org
Sign in
Version 5.3.0, 2014-04-12
Report a bug

ICMP Attacks against TCP
draft-ietf-tcpm-icmp-attacks-12

Note: This ballot was opened for revision 10 and is now closed.

Summary: Has enough positions to pass.

Jari Arkko

Comment (2010-02-18)

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?

[Alexey Melnikov]

Comment (2010-02-18)

Should [I-D.ietf-tsvwg-port-randomization] reference be Normative?

[Magnus Westerlund]

Comment (2010-02-18)

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.

[Tim Polk]

Comment (2010-02-18)

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...