Last Call Review of draft-ietf-tcpm-icmp-attacks-

Request Review of draft-ietf-tcpm-icmp-attacks
Requested rev. no specific revision (document currently at 12)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2010-02-16
Requested 2010-02-05
Authors Fernando Gont
Draft last updated 2010-02-20
Completed reviews Secdir Last Call review of -?? by Phillip Hallam-Baker
Assignment Reviewer Phillip Hallam-Baker 
State Completed
Review review-ietf-tcpm-icmp-attacks-secdir-lc-hallam-baker-2010-02-20
Review completed: 2010-02-20



I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

ICMP is one of those IP layer protocols that we all have some idea
exist even if only the network level people understand what they do.
This document is designed to describe security issues arising from the
ICMP protocol and commonly implemented counter-measures.

The principal security risks considered are service risks. ICMP may be
used to perform certain denial of service and performance downgrade
attacks. As such it probably needs rather more justification than 'we
have always done this' when building critical infrastructures.


Given that TCP streams will eventually time-out, I have something of a
hard time seeing why we would be using a non-authenticated control
protocol at all. Yes, I know the legacy reasons etc. etc. But this is
not the way we would approach this problem today. This argument is
almost made on page 15. Some statement giving the case for taking
notice of ICMP messages at all is in order. It might well be that an
appropriate control in certain cases would be to turn off ICMP hard
errors and rely on timeouts, I am thinking here of critical
infrastructure applications and communications between hosts running
BGP functions.

In particular I note that the draft says "It is interesting to note
that, as ICMP error messages are transmitted unreliably, transport
protocols should not depend on them for correct functioning."

Given the extreme approach to security of starting from nothing and
only adding systems that are essential, this would seem to suggest
ICMP is not necessary and could be eliminated. There may be a case to
the contrary but it needs to be made before page 15.

Page 15/16

The following phrase repeats in a way that suggests an editing oversight:
aborting the
   connection would be to ignore the valuable feature of the Internet
   that for many internal failures it reconstructs its function without
   any disruption of the end points

Page 24-26

A more general way of describing the mitigation strategy would be to
point out the general principle that error messages may be ignored
whenever a packet indicating success is received within the timeout
window. In other words no final processing decisions should be made on
an unauthenticated ICMP packet until after the timeout window expires.

New Website:

View Quantum of Stupid podcasts, Tuesday and Thursday each week,