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

[Warren Kumari <[e-mail]>]

On Jan 8, 2012, at 3:54 PM, Naiming Shen wrote:

> 
> I have seen several comments regarding this extension having scaling issue on the Internet
> and this probably is due to confusion on how this extension will be used or how the
> traceroute/ping application is processed today.

Or potentially the comments are coming from operators who understand how traceroute/ping work, how their devices currently operate, what sort of traffic they allow in (and why).


> Let's do some analysis here.
> 
> Traceroute packets if they are not TTL expired you don't process them on the router;
> or Ping packets not destination to your address, you don't process them on your router.
> This extension does not change those behavior. You only check those extension while
> you are normally processing those packets anyway.

<sarcasm>
Wow, cool, I never knew that... You mean that there is some sort of separation between data traffic that transits the device and control / exception traffic? Neat!
</sarcasm>


> So if you don't normally filter those
> packets (which is a good thing you are doing), you will have no need to filter them just
> because the router support this extension later. I hope this point is clear.

No. The point is clear, but I don't agree with it.

> 
> Now let's see what will be the percentage of processing which is actually related to this
> Traceroute/ping extension. For normal Traceroute for example, you need to check UDP
> header information, you need to verify things such as checksum, you need to fetch information
> to format packet to send back through your ICMP socket, information can be many, such as
> interface IP address, Nexthop information, interface names (all defined in RFCs now), copy the
> original payload (even you don't understand the format) and finally format the ICMP packet
> to send it back. Now with this extension, you just check (in a well known location of the packet)
> if it exists this extension by the magic#, if not there is nothing more to do. Or you can
> have a policy to check only if the probe source address is from network x.x.x.x/y,
> otherwise don't even bother with the extension. For those checks, I would say may be 2-5%
> of the original processing you have already needed to do. So, does this actually cause a
> concern of scaling on the Internet?

Sure, you chose traceroute over ICMP because that helps support your position, fine.

How did you come up with this 2-5% number? Is this only under the you have a policy to check the source address case, or are you trying to claim that authentication will only be an additional 2-5%?

> 
> For every Traceroute/ping router implementation, they do rate-limiting. Some do flow
> based, some just do a flat time based rate-limiting, e.g. they only allow 100 such packets
> per minute. Let's forget about the Moor's Law, forget about the hardware/cpu capability
> these days, let's forget about multi-core cpu development anymore; let's only concentrate
> on the legacy stuff of the past. Say take a 15 years old router, let's upgrade the software
> to this extension for the Traceroute/ping. Let's assume also this extension actually consume
> 10% more cpu.
> So instead of default punting 100 such a packet per minute, now this
> router is programmed only punting 90 such packets to process.

Or 0.1%  CPU, or 100000% more CPU. Where (and more why!) are you coming up with these numbers? What router from 15 years ago supported (non-CPU) rate-limiting of TTL expired at around 100ppm, and might still be in use?

> Nothing wrong with that.
> This 100 per minute was some vendor's arbitrary decision 15 years back, who can say
> 50 is not perfect or 200 is not the right thing for now.

Ah, arbitrary vendor decisions.  Is there *any* chance that instead of picking a number out of the air they based it upon what customers were looking for / what the device was capable of?

> There is no place you actually need to do
> special filtering just due to this extension.


Yes, yes there is...

1: I only run management protocols that support some level of authentication (e.g SSH, SNMP)
2: My internal devices only accept management traffic from specified (internal) addresses.
3: I *also* filter out SSH, SNMP, Telnet and similar at the edge of my network.

If I have 1 and 2, why do I bother with 3 as well?
A: During new turnups / testing / maintenance, etc it is possible that the filters in 2 might get dropped.
B: Where the rate-limiters and filters get invoked differs between implementations. If I don't filter at the edge my (legitimate) management traffic (5-10pps) may be competing with O(tens of thousands) of attack packets.
C: Not all of the devices in the network are managed by a single group. In many (most?) organizations the security policy is set by a security group and they would like to ensure that ALL devices get some level of protection. If someone in a different group installs a device on the network, it should get some level of protection, even if they misconfigure it.
See layered security, etc.


> The point here is that, if the implementation does
> want to take this overhead into account, they can adjust that easily with also in consideration
> of today's hardware/cpu capabilities.
> 

Yes. I *have* todays hardware/cpu capabilities, and they are *already* busy. I don't want *want* them spending any additional time on a protocol that doesn't solve an actual issue.


> Then if you think about this extension can actually ask for a subset of information, instead
> of just dumping everything the ICMP RFCs have defined, one may save some cpu and bandwidth
> in that sense.

So I can save CPU? Over my current usage?

> 
> On the other hand if one has an implementation using this extension, for example an
> OpenFlow ID trace which actually trace through the real path on the programed OpenFlow
> based switches. this operation let's say cost 100% of the normal Traceroute processing,
> but here we hope it does not do this for every Traceroute packet, and it actually checks to see
> if this is from an authorized network or station for using this feature. And this is a new feature
> you want so you are willing to spend more cpu on that.

Ah, thank you for telling me what I want, and what I'm willing to spend CPU on. 

W

> 
> thanks.
> - Naiming
> 
> 
> On Jan 8, 2012, at 2:49 AM, SM wrote:
> 
>> At 12:44 07-01-2012, Warren Kumari wrote:
>>> If ping processing goes from being a negligible use of resources to something noticeable, the only reasonable solution I have is "deny icmp any any echo" on edge.
>>> This is not good for me, this is not good for my customers, this is not good for the Internet at large.
>> 
>> Agreed.
>> 
>> If the authors really want to see draft-shen-traceroute-ping-ext-03 published, they could add an Applicability Statement saying that the domain of use is not the Internet.  Not giving due consideration to input from operators can only discourage them from providing input in future.
>> 
>> Regards,
>> -sm 
>> _______________________________________________
>> Int-area mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/int-area
> 
> _______________________________________________
> Int-area mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/int-area
>