[tcpm] feedcback on tcp-secure-05

Joe Touch <touch@ISI.EDU> Thu, 13 July 2006 17:29 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G14zk-0001pi-E7; Thu, 13 Jul 2006 13:29:00 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G14zi-0001nJ-EO for tcpm@ietf.org; Thu, 13 Jul 2006 13:28:58 -0400
Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G14zg-0000EX-2F for tcpm@ietf.org; Thu, 13 Jul 2006 13:28:58 -0400
Received: from [132.219.18.179] (h12b3-net84db.lab.risq.net [132.219.18.179] (may be forged)) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k6DHSHH22103; Thu, 13 Jul 2006 10:28:17 -0700 (PDT)
Message-ID: <44B682AB.9010702@isi.edu>
Date: Thu, 13 Jul 2006 10:28:11 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: tcpm@ietf.org
X-Enigmail-Version: 0.94.0.0
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
Subject: [tcpm] feedcback on tcp-secure-05
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1559540400=="
Errors-To: tcpm-bounces@ietf.org

I had the following comments on v05.

Joe
--------

The doc continues to have a detailed but somewhat incomplete discussion
of the attack scenario; the point of tcp-antispoof was to provide a much
more detailed version of that discussion that should not be
recapitulated but rather cited.

The doc cites a *very* old version of tcp-antispoof, too.

No reasoning is given for numeric limits to ACK throttling (why 10 in 5
seconds? why not a ratio of the number of conventional ACKs provided)

TCP-MD5 isn't considered as a useful protection from these attacks (and
it is).

The use of both IPsec-AH and IPsec-ESP is suggested for on-path attacks,
where only one of the two is required.

The doc should also indicate that preventing these attacks does NOT
prevent ICMP attacks (and cite Gont's draft in this regard); it would be
useful for the security considerations to address whether ICMPs should
be blocked altogether and what the impact of that would be. Without such
blocking, it's not clear what the utility of this solution would be.

The middlebox considerations (sec 8.1) declare that some behavior is
noncompliant, but don't consider whether it already exists and how to
make their system avoid ACK wars that might result (e.g., to detect and
quench such a war, which seems separate from ACK throtling per se).

-----------------------------------------
THIS IS THE BIG POINT REGARDING REVISION:

The specific modifications suggested are given as loosely discussed
recipes rather than a specific list of the modifications to TCP; IMO,
the latter should be required.

-----------------------------------------

The blind data injection attack suggests that the window of
vulnerability can be as large as the amount of unacknowledged data,
which can be as large as the window. This means that even if the RST
attack is reduced from a fraction of the windowsize to 1, a similarly
detrimental attack can still occur from data injection. This needs to be
discussed in the security considerations, and continues to render the
utility of the RST protection of limited comparable value.


_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm