IETF Logo Mail Archive

[tcpm] comments on draft-ietf-tcpm-icmp-attacks-05

"Eddy, Wesley M. (GRC-MS00)[Verizon]" <wesley.m.eddy@nasa.gov> Thu, 11 June 2009 04:25 UTC

Return-Path: <wesley.m.eddy@nasa.gov>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A2C73A6839 for <tcpm@core3.amsl.com>; Wed, 10 Jun 2009 21:25:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.381
X-Spam-Level:
X-Spam-Status: No, score=-6.381 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VhJyk4UNz2k3 for <tcpm@core3.amsl.com>; Wed, 10 Jun 2009 21:25:03 -0700 (PDT)
Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by core3.amsl.com (Postfix) with ESMTP id 91C7B3A680A for <tcpm@ietf.org>; Wed, 10 Jun 2009 21:25:03 -0700 (PDT)
Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id A336A328043; Wed, 10 Jun 2009 23:25:10 -0500 (CDT)
Received: from ndjshub01.ndc.nasa.gov (ndjshub01.ndc.nasa.gov [198.117.4.160]) by ndjsppt02.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id n5B4PAA4020883; Wed, 10 Jun 2009 23:25:10 -0500
Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub01.ndc.nasa.gov ([198.117.4.160]) with mapi; Wed, 10 Jun 2009 23:25:10 -0500
From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <wesley.m.eddy@nasa.gov>
To: "tcpm@ietf.org" <tcpm@ietf.org>
Date: Wed, 10 Jun 2009 23:25:15 -0500
Thread-Topic: comments on draft-ietf-tcpm-icmp-attacks-05
Thread-Index: AcnqTJ5N/OQHUFfvTA+OQMGvgkY7Qg==
Message-ID: <C304DB494AC0C04C87C6A6E2FF5603DB221796D53C@NDJSSCC01.ndc.nasa.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-06-10_14:2009-06-01, 2009-06-10, 2009-06-10 signatures=0
Cc: Fernando Gont <fernando@gont.com.ar>, Fernando Gont <fernando.gont@gmail.com>
Subject: [tcpm] comments on draft-ietf-tcpm-icmp-attacks-05
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Jun 2009 04:25:06 -0000

As a WG participant (not co-chair), here are some
comments I have after reading the latest version
of the ICMP attacks draft:

1) (editorial) In Section 2.1, don't capitalize
"Architecture", as it makes "Internet Architecture"
look like some kind of specific proper noun, which
it definitely isn't.

2) (question) In Section 2.1, we have:
"When an intermediate router detects a network
problem while trying to forward an IP packet,
it will usually send an ICMP ..."  Do we
want "will usually" or "has the option to", or
something similar?  I'm not aware of the actual
statistics on this.

3) (editorial) In Section 3, first sentence,
"internet header" -> "IP header" ?

4) (technical) For the last paragraph in section
3, we focus on the lack of IKE usage as a reason
why IPsec can't generally be used to authenticate
ICMP messages, but I think the bigger problem is
that even if we all ran IPsec, we'd need to have
routers using certificates with paths compatible
for all other hosts on the network ... not too
feasible from what I can tell.  I think this is
more difficult than either the deployment or the
embedded devices issue that the draft mentions.

5) (general) Section 5.1, last paragraph, it
seems like we should be mentioning TCP-AO as
well here, though I don't think it changes any
part of the claim.

6) (editorial) Section 5.2, typo "preferebable"

7) (editorial) Section 6.2, "On the other hand,
TCP implements its own congestion control
mechanisms ..." ... I don't think this is
really an "on the other hand", I think it's
more of a "Furthermore".

8) (general) In Section 6.2, I think we can be
stronger and say that the 1122 requirement to
react to source quench is no longer pertinent,
as the Internet has moved well beyond needing
this.

9) (general) Wow, section 7 takes a much closer
look at PMTUD than I ever expected to find here;
roughly half the document sits in this topic
alone.  Is this *really* an attack that we're
that worried about in a general case?  

The modifications in this part of the document
seem too complex for what they buy, to me.  It
seems like in places where there's concern about
it, we can just say to ignore these ICMPs and use
the PLPMTUD (4821) instead.  I can understand
that what's in the draft has been implemented,
but how valuable is it really when we already
have a Proposed Standard in PLPMTUD that can
totally answer to this concern by just ignoring
the ICMPs in question?

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------

v2.23.0 | Report a Bug | By Email