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

[Naiming Shen <[e-mail]>]

Hi Lars,

On Mar 5, 2012, at 10:50 PM, Eggert, Lars wrote:

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

The previous version of this draft didn't have this well-known port defined, and we got
many comments on how to distinguish the packets with new features from the general
traceroute/ping packets on the Internet, as you mentioned below, it needs more deeper
packet inspection. With this well-known port, a provider's internal use of certain feature with
this extension can be more easily sort out from normal trace/ping packets (before the deeper
packet inspection).

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

It requires more processing since if there is a new service using this extension, then the packets need more processing.
But those extra processing will not be imposed on the "normal" trace/ping packets. The well-known port here is
to distinguish those two types.

rate-limit is just an example of implementation related to this. icmp or trace ratelimit is to protect the slow path,
or even when the replies are done on the LC(fast path), they are normally rate-limited. If this extension for
example, at the router inbound it detects the packet with this well-known port, it can hand it to that feature processing
to run through an ACL (e.g. the configure requires the features only be allowed from their mgmt station
subnets), if all is well, then punt the packet to the feature handling(the slow path) with its own rate-limit.

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

I agree. This draft also has a section on the scalability of implementation and configuration.
Usually the features should be enabled with configuration and also filtering along with it.

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

I meant the TCP payload length of the SYN packet doesn't have to be zero.

thanks.
- Naiming

> 
> Thanks,
> Lars