Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-04.txt

"Eggert, Lars" <lars@netapp.com> Tue, 06 March 2012 06:50 UTC

Return-Path: <lars@netapp.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5224021F86E0 for <int-area@ietfa.amsl.com>; Mon, 5 Mar 2012 22:50:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.074
X-Spam-Level:
X-Spam-Status: No, score=-10.074 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNnnJSbwJCWG for <int-area@ietfa.amsl.com>; Mon, 5 Mar 2012 22:50:58 -0800 (PST)
Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id C528E21F86D1 for <int-area@ietf.org>; Mon, 5 Mar 2012 22:50:58 -0800 (PST)
X-IronPort-AV: E=Sophos; i="4.73,538,1325491200"; d="p7s'?scan'208"; a="631004388"
Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 05 Mar 2012 22:50:58 -0800
Received: from vmwexceht05-prd.hq.netapp.com (vmwexceht05-prd.hq.netapp.com [10.106.77.35]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q266owLB027925; Mon, 5 Mar 2012 22:50:58 -0800 (PST)
Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.92]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.02.0247.003; Mon, 5 Mar 2012 22:50:57 -0800
From: "Eggert, Lars" <lars@netapp.com>
To: Naiming Shen <naiming@cisco.com>
Thread-Topic: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-04.txt
Thread-Index: AQHM+Rtrgvojn5f6E0aFnPeUKN41pZZc02KAgACLeQA=
Date: Tue, 06 Mar 2012 06:50:57 +0000
Message-ID: <2C2F2761-E2BD-4E55-97F3-4E5B3155A3BB@netapp.com>
References: <20120227213938.20370.68711.idtracker@ietfa.amsl.com> <9C0C873C-D52F-4EC8-939C-FD2373FDC9ED@cisco.com> <709D93F8-C6C0-4F7D-A823-35540D683EE6@netapp.com> <4705AE0F-CAE1-46D9-84D5-AF6D11BD35BC@cisco.com>
In-Reply-To: <4705AE0F-CAE1-46D9-84D5-AF6D11BD35BC@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.104.60.115]
Content-Type: multipart/signed; boundary="Apple-Mail=_9B0CEF49-F3D6-4B45-AADC-051F693CFB3D"; protocol="application/pkcs7-signature"; micalg="sha1"
MIME-Version: 1.0
Cc: "int-area@ietf.org" <int-area@ietf.org>
Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-04.txt
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/int-area>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Mar 2012 06:50:59 -0000

Hi,

On Mar 5, 2012, at 23:31, Naiming Shen wrote:
> On Mar 3, 2012, at 12:55 AM, Eggert, Lars wrote:
>>> 8.  IANA Considerations
>>> 
>>>  The IANA is requested to assign a well-known port number, Trace-Ping
>>>  Port, for the UDP and TCP of this Trace-Ping extensions.
>> 
>> I'm curious why you think you need a port number for this ping extension. Ping is a diagnostic procedure that can be used with any port, and placing payload into the packet sent to elicit the ICMP response doesn't change that.
> 
> Yes, I understand Ping can use any port(or Identifier as in this draft). But it's rate-limited
> also randomly by routers on the Internet. This well-known port/id can signal a new service
> for the network, and can be subject to different filtering profile.

Clarification: you mean that the *generation* of ICMP messages at routers is rate-limited, correct? And the hope is that if the packets eliciting ICMP responses contained a transport packet with a certain source or destination port, the router would apply a more lenient rate limit when generating ICMP responses for those packets.

Is this realistic? I'm not a router guy, but I thought routers rate-limit the generation of ICMP messages because it involves slow-path processing. In your scheme, a router would need to further DPI packets that may cause ICMP responses in order to determine what rate limit to apply, requiring even more processing. Doesn't that kind of defeat the purpose?

In addition, eyeball ISPs would need to filter that port at the boundary to prevent the clients from using it, too, which again complicates things. Because once you set up more lenient rate limits for ICMPs for a given port, you can be sure that clients would start using that port, too.

>> Also, with regards to TCP ping, do you envision your payload data to be placed inside the SYN?
> 
> Yes for syn or ack. The tcp server should not care about the length being zero or not though.

I don't understand what you mean by "length being zero." Could you elaborate?

Thanks,
Lars