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

From: Ronald Bonica <[email-masked]>
Date: Wed, 4 Jan 2012 14:01:04 -0500

Authors,

This draft changes the meaning of bits in the ICMP, TCP and UDP headers. Therefore, if published, it would UPDATE RFCs 792, 793 and 768. You may find that a very high bar to clear!

In order to lower the bar, I recommend the following changes to your draft:

1) Don't attempt to enhance PING. Therefore, you won't need to redefine any bits in the ICMP header.
2) Encode the Trace Extension structure at a fixed position in the TCP/UDP payload. Therefore, you won't need to redefine any bits in the TCP or UDP headers.

There isn't any reason to enhance PING. If you want information from a host beyond that which PING already provides, the appropriate protocol is SNMP.

The document doesn't explain why the starting position of the Trace Extension Structure needs to be variable. Possibilities are:

1) To reduce the probability of processing errors caused by magic numbers that sometimes occur in non-traceroute packets with TTL equal to 0
2) To preserve the low order bits of the TCP/UDP payload

If you are trying to address problem #1, you can do so by increasing the size of the magic number.

If you are trying to address problem #2, you can do so by encoding the extension structure at some reasonably large but fixed location in the TCP/UDP payload.

--------------------------
Ron Bonica
vcard:       www.bonica.org/ron/ronbonica.vcf

---

From: Naiming Shen <[email-masked]>
Date: Wed, 4 Jan 2012 11:21:30 -0800

Hi Ron,

Thanks for the good suggestions, some replies inline,

> This draft changes the meaning of bits in the ICMP, TCP and UDP headers. Therefore, if published, it would UPDATE RFCs 792, 793 and 768. You may find that a very high bar to clear!

We defined this only in the context of traceroute and ping applications, since the source port and ID field
only had private meaning to the sender. Those bits change has no meaning outside this context.

> If you are trying to address problem #2, you can do so by encoding the extension structure at some reasonably large but fixed location in the TCP/UDP payload.

The intension is only #2.
To have a fixed location is a good solution too, although the intention of the draft
is to allow a '0xf' to indicate we have no extension in this trace/ping packet, not even
bother with looking for it, to save some cpu time. Though I agree that, to have a fixed
location, and to just check the 'magic number' is also not much overhead.

thanks.
- Naiming

> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Carlos Pignataro <[email-masked]>
Date: Wed, 04 Jan 2012 15:29:44 -0500

Hi Ron,

Thanks for the comments, please see inline.

> This draft changes the meaning of bits in the ICMP, TCP and UDP headers. Therefore, if published, it would UPDATE RFCs 792, 793 and 768. You may find that a very high bar to clear!

This draft is not really changing the meaning of bits in the ICMP, TCP,
and UDP headers. This draft is just describing a way to allocate udp and
tcp source port and icmp identifier. And described within the context of
the application of this I-D, traceroute. Do you agree?

> 1) Don't attempt to enhance PING. Therefore, you won't need to redefine any bits in the ICMP header.

This is what draft-shen-udp-traceroute-ext (a predecessor) was doing to
some extent. The extension to ICMP (and TCP) came as a consequence to
feedback (IIRC) on including ICMP- and TCP-based traceroutes.

Based on the response above, if this is not redefining bits, do you have
the same suggestion?

> 2) Encode the Trace Extension structure at a fixed position in the TCP/UDP payload. Therefore, you won't need to redefine any bits in the TCP or UDP headers.

This is also good, and I'd be glad to go this route if this is
consensus. One reason to include the pointer to a variable start is that
during RFC 4884, the structure was at a fixed start and there was strong
consensus to have it variable and explicit.

> If you are trying to address problem #2, you can do so by encoding the extension structure at some reasonably large but fixed location in the TCP/UDP payload.

Problem #2. And same as above: I think that a fixed reasonably large
location would work as well, though it might imply more checks.

Thanks,

-- Carlos.

---

From: Thomas Narten <[email-masked]>
Date: Wed, 04 Jan 2012 17:43:51 -0500

> > This draft changes the meaning of bits in the ICMP, TCP and UDP
> > headers. Therefore, if published, it would UPDATE RFCs 792, 793
> > and 768. You may find that a very high bar to clear!

> and UDP headers.

Actually, it sort of does and sort of doesn't. It's not black and
white.

True, it doesn't redefine TCP/UDP headers in any way.

However, it does call for the placement of "magic values" within an
arbitrary TCP/UDP packet. When generating ICMP responses to such
packets, when the magic value is present, ICMP behaves differently
than before. That is a change.

Also, this technique by defintion encourages the creation of "test" or
"probe" TCP/UDP packets as part of network debugging (or even regular
monitoring). Should those probe packets "escape" and actually be
delivered to the destinations as defined by the TCP/IP headers and
port numbers, there may be unintended consequences to applications
that happen to be using those port numbers already. Oops.

Consequently, use of this technique may actually cause collateral
damage to existing, deployed applications. Maybe not a big risk, but a
risk nonetheless. 

I would feel much more comfortable with this technique if it could be
guaranteed that when probe packets are generated, they do not go
"anywhere" in the Internet, but stay within (say) a domain where
debugging is necessary. I.e, I could see an ISP doing this within
their network, but also preventing such packets from leaving their
networks.

Not sure how to enforce this though...

Now, I brought up this document because over in Trill, OAM is being
discussed, and the approach outlined in
draft-shen-traceroute-ping-ext-03.txt was cited as something that
might be useful to leverage. In a Trill environment, it might well be
possible to ensure that no OAM packet leaves a Trill campus. In that
case, the above concern largely goes away.

In terms of next steps, I'd suggest thinking of two kinds of issues,
and dealing with them separately.

First, is the concept OK?

Second, is the actual format of the packet, the encoding details,
etc. right? I personally don't want to bother discussing the latter
details unless we decide the basic concept itself  is workable and a
good way forward.

And my own opinion, based on the discussion so far leaves me on the
fence. I'm not yet convinced that the idea itself as defined in this
document makes sense.  We need to listen very carefully to what
operators are saying. We want to provide them with tools that will
actually help them. If they have concerns (which they do), and we
brush them off, we may well end up spending a lot of time developing a
solution that they won't ever get used. That's not a good use of
anyone's time/effort.

Thomas

---

From: Naiming Shen <[email-masked]>
Date: Wed, 4 Jan 2012 15:32:07 -0800

Hi Thomas,

> damage to existing, deployed applications. Maybe not a big risk, but a

This draft actually does not change those attributes. The current traceroute/ping
application has already picked up those high port numbers, and already has used the
source port and id field for some private number no one else cares. Let's say if this
draft is using a fixed location scheme, then there is no change to any of that.

> Not sure how to enforce this though...

Let's say if I'm using this extension in an particular ISP only meant to get
some private info for our management stations. First I think the operator
usually specify the destination to be within the range of the network they
want; secondly, even if not, the packet actually goes off the network, there
is not much harm done, those off-net stations should not supply those
private information or they probably don't care. yes, it will waste someone's
cpu and bandwidth resource, but it's also due to the operator didn't check
the address carefully.

I agree to focus on the concept or framework is the key for now.

thanks.
- Naiming

---

From: Thomas Narten <[email-masked]>
Date: Wed, 04 Jan 2012 19:24:14 -0500

> This draft actually does not change those attributes. The current
> traceroute/ping application has already picked up those high port
> numbers, and already has used the source port and id field for some
> private number no one else cares. Let's say if this draft is using a
> fixed location scheme, then there is no change to any of that.

This draft doesn't introduce the problem, but it will likely make it
worse. I.e., if this draft is successful (which presumably is the
goal), more collateral damage may result. I.e, the more such packets
are generated, the more likely some will cause problems.

> want;

False assumption. The reason why *any* packet (i.e., any src/dest
address) would be used is precisely to debug problems related to
traffic between a particular src/dest pair, and that src/dest pair may
not even belong to the ISP that gets a help desk call.

I.e., if you get a help desk call about some sort of packet loss or
unreachability for certain flows, you then generate trace packets that
mimic those flows. If we could just use regular packets to debug such
problems, we wouldn't need the proposed mechanism at all.

> secondly, even if not, the packet actually goes off the network, there
> private information or they probably don't care.

My concern isn't about the *response* messages leaking outside of the
site, it's that the *probe* packets will leak. Those are the ones that
could be delivered to a destination incorrectly, causing problems for
the receiving application.

Thomas

---

From: Naiming Shen <[email-masked]>
Date: Wed, 4 Jan 2012 21:35:57 -0800

> are generated, the more likely some will cause problems.

But the popular traceroute application is using a > 32K port#, so those
are not well-known ports, not used by well-known applications. In the case
of someone is using those ports (by destination), then the socket addresses will not match,
the receiver will send an different icmp error code back(instead of port unreachable),
those are the existing implementations, and works fine. this draft does not change
any of those, and unlikely causing problems.

> not even belong to the ISP that gets a help desk call.

But we are just using exact the same traceroute/ping packets, only with payload
change with addition information. it's not going to affect any source/destination
address or layer4 ports (those layer 4 ports are designed to be incremented each
additional ttl packets and they are random anyway) comparing to the existing way.

> the receiving application.

what I'm saying is, saying the probe is going outside the network(off-net),
it's just a ping packet, or a traceroute packet. yes it has some request in the
payload, but the receiver does not have to reply. it's like when I send a SNMP
query, but typed the host address wrong, the host can either not send me back
anything, or it can reply also if it does not really care who query this information.
but that is not a problem.

thanks.
- Naiming

---

From: Naiming Shen <[email-masked]>
Date: Thu, 5 Jan 2012 11:11:32 -0800

One note with this draft is that, for the past 30 years, Traceroute and Ping has been
widely implemented and used; every implementation has some "private" data in the
payload, which only the sender cares and understands.
This draft, in the essence, is to make some of the data in the payload to be "public",
not only the sender understands, but also the receiver may also understands them.
With that the sender have a mechanism to pass some message along to the
receivers during the Traceroute and Ping operations. each receiver has the option
of completely ignoring this 'public' data, or only replying to the interested ones. The extra
cpu is only spent on the checking the 'magic number' in a defined location.

Regards,
- Naiming

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Thu, 5 Jan 2012 13:47:00 -0600

> > not even belong to the ISP that gets a help desk call.

Is it really possible? 
I am not aware of any implementation that allows the source address of
the ping/traceroute packet to be any arbitrary number.
In fact, Most implementations limit the source address to be one of
those assigned to the device itself.

The point here is that if the helpdesk needs additional information from
their network devices during troubleshooting, then this proposal could
be useful.

Cheers,
Rajiv

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Naiming Shen (naiming)
> Sent: Thursday, January 05, 2012 12:36 AM
> To: Thomas Narten
> Cc: Carlos Pignataro (cpignata); [email-masked]; Ronald Bonica
> Subject: Re: [Int-area] I-D Action:
draft-shen-traceroute-ping-ext-03.txt
> of someone is using those ports (by destination), then the socket
addresses will
> not match,
> the receiver will send an different icmp error code back(instead of
port
> unreachable),
> those are the existing implementations, and works fine. this draft
does not
> change
> But we are just using exact the same traceroute/ping packets, only
with
> payload
> address or layer4 ports (those layer 4 ports are designed to be
incremented
> each
> additional ttl packets and they are random anyway) comparing to the
existing
> way.
> anything, or it can reply also if it does not really care who query
this
> information.

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 5 Jan 2012 16:14:57 -0500

Carlos,

Regardless whether the ICMP header is being updated, I don't think that it is necessary to enhance PING. Ping tells you that a host is reachable. SNMP can tell you anything else that you need to know about the host.

                                                    Ron

> From: Carlos Pignataro [mailto:[email-masked]]
> Sent: Wednesday, January 04, 2012 3:30 PM
> To: Ronald Bonica
> Cc: [email-masked]
> Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-
> 03.txt
> 
> Hi Ron,
> 
> headers. Therefore, if published, it would UPDATE RFCs 792, 793 and
> 768. You may find that a very high bar to clear!
> >
> 
> > 2) Encode the Trace Extension structure at a fixed position in the
> TCP/UDP payload. Therefore, you won't need to redefine any bits in the
> TCP or UDP headers.
> >
> 
> > There isn't any reason to enhance PING. If you want information from
> a host beyond that which PING already provides, the appropriate
> protocol is SNMP.
> >
> > The document doesn't explain why the starting position of the Trace
> Extension Structure needs to be variable. Possibilities are:
> >
> > 1) To reduce the probability of processing errors caused by magic
> numbers that sometimes occur in non-traceroute packets with TTL equal
> to 0
> > If you are trying to address problem #2, you can do so by encoding
> the extension structure at some reasonably large but fixed location in
> the TCP/UDP payload.
> >
>

---

From: Naiming Shen <[email-masked]>
Date: Thu, 5 Jan 2012 14:14:37 -0800

Hi Ron,

the traceroute can use either udp/tcp or icmp for transport, e.g. microsoft's 'tracer' uses icmp
for the transport actually.

thanks.
- Naiming

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Fri, 6 Jan 2012 11:26:49 -0800

Hi Ron

Please see my comments in-line below

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Ronald Bonica
Sent: Thursday, January 05, 2012 1:15 PM
To: Carlos Pignataro (cpignata)
Cc: [email-masked]
Subject: Re: [Int-area] I-D Action:
draft-shen-traceroute-ping-ext-03.txt

Carlos,

Regardless whether the ICMP header is being updated, I don't think that
it is necessary to enhance PING. Ping tells you that a host is
reachable. SNMP can tell you anything else that you need to know about
the host.

                                                    Ron
[TISSA]

What you indicated above may be true in general sense, however, with
various overlay technologies and virtualizations and use of ECMP in
networks require us to have ability to obtain additional information
that may not be possible or straightforward using SNMP.

Case in point is MPLS ping, we use MPLS ping to obtain label stack
information. Or derive various ECMP paths combinations.

In IP world similar information can be very useful. As an example in an
ECMP environments, it is very useful to identify upstream path that a
packet arrived. 

Currently there is no way ICMP ping can communicate this information nor
SNMP can tell that.

Extension proposed in this draft, in my opinion, allow to extend ICMP
echo messages in a manner that is backward compatible yet allow flexible
framework to extend to overlay networks and ECMP enviorements. 

Thanks
Tissa

---

From: Warren Kumari <[email-masked]>
Date: Sat, 7 Jan 2012 15:44:51 -0500

On Jan 4, 2012, at 6:32 PM, Naiming Shen wrote:

> cpu and bandwidth resource,

Speaking as a "someone", I don't want you wasting my cpu and bandwidth resources.

> but it's also due to the operator didn't check
> the address carefully.

You are looking at this from the wrong side.

I run a large network, with many many devices. I allow ping (and traceroute) into my network because lots of *customers* ping / traceroute to test their connectivity, especially if they think there is some sort of issue. I allow these packets because it benefits me and the customers, and the benefits outweigh the costs.

I (and I believe the other operators speaking) are not concerned that *we* accidentally leak these extended packets (because a: this so isn't something we want to run, b: we have no reason to destine these outside our networks, c: can filter these outbound if we want really easily and d: are relatively small in number), the big concern is that *large numbers* of *users* start sending these at our devices (or, attackers start sending them intentionally, and causing more work for my devices).

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.

This is why we are concerned about having protocols we have to (or are expected to) allow in from the Internet and would prefer it to be in a separate protocol that can be *easily* filtered at the edge of the network. If the proposal was to carry this in a protocol with a well known port (like, oh, I dunno, UDP/161) that I can filter I wouldn't care.

It is *not* an accident that:
snmpget -c public 209.85.254.233 SNMPv2-MIB::sysDescr.0
does not give you a response.

W

>> solution that they won't ever get used. That's not a good use of

---
Don't be impressed with unintelligible stuff said condescendingly .
    -- Radia Perlman.

Warren Kumari
[email-masked]

---

From: SM <[email-masked]>
Date: Sun, 08 Jan 2012 02:49:39 -0800

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.

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

---

From: Naiming Shen <[email-masked]>
Date: Sun, 8 Jan 2012 12:54:11 -0800

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

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?

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. 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. There is no place you actually need to do
special filtering just due to this extension. 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.

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.

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.

thanks.
- Naiming

On Jan 8, 2012, at 2:49 AM, SM wrote:

> 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

---

From: Jared Mauch <[email-masked]>
Date: Sun, 8 Jan 2012 16:34:30 -0500

If your goal is to replace snmp since it doesn't do what you want, it seems like that is another I-d

Jared Mauch

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Wed, 11 Jan 2012 12:01:55 -0600

Hi Naiming,

Very good clarification.

Additionally, an implementation could simply require this functionality
to be not enabled via default (or disabled via CLI), erasing any concern
one may have in the existing deployments. In other words, if I want this
functionality in my network, then I will go enable it (at whatever cost
I need to bear).

Cheers,
Rajiv 

Behalf
> Sent: Sunday, January 08, 2012 3:54 PM
> To: SM
> Cc: [email-masked]
> 
> 
> 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 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. 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
> 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
> 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. 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. There is no
place you
> actually need to do
> special filtering just due to this extension. 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
> 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.
> 
> On the other hand if one has an implementation using this extension,
for
> example an
> 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
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.
> >
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

---

From: Warren Kumari <[email-masked]>
Date: Wed, 11 Jan 2012 16:01:46 -0500

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

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

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

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

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

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.

> of just dumping everything the ICMP RFCs have defined, one may save some cpu and bandwidth

So I can save CPU? Over my current usage?

> 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

---

From: "George, Wes" <[email-masked]>
Date: Thu, 12 Jan 2012 09:56:13 -0500

> Behalf Of Naiming Shen
> on the router;
> extension while
> normally filter those
[WEG] Yes, that's clear. The concern is that the presence of this extension means that there will be an increase in "to us" traffic for each router in the network. If there is indeed a need for this extension to pass information back, there is an additional incentive for malicious use as well as simple non-malicious overuse, both of which result in an increase in the flow of trace/ping packets that your average box has to deal with somehow. Whether it drops them due to a filter, a rate-limit, a failed authentication, or responds to good packets, it still is going to see more of them than it does today. *That* is the scaling problem. This might not be a completely unacceptable tradeoff in all cases, but you've failed to make your case that the benefit outweighs this risk, nor to my knowledge have there been other operators who have stood up and said "we need this feature for X reason" such that we can validate your assertion that this would be something that is helpful for operations.
> actually related to this
[snip - do a bunch of stuff]
>  Now with this extension, you just check (in a well
> known location of the packet)
> would say may be 2-5%
[WEG] Yes, because you're leaving out several VERY important details -
1) the information this extension is proposing to supply back in a response requires additional IPC to collect information that is not available on the local linecard. That IPC isn't free, so it'll definitely increase overhead far more than just processing additional data in the packet, especially if your IPC isn't particularly efficient and scalable. This also eliminates any possibility that response to pings and traces can be offloaded exclusively to the linecard hardware instead of punting it to the RP.
2) as noted above, if this extension gets implemented, it'll generate more traffic from people trying to use it, either to gain access to information they're not authorized to, as another DoS attack vector, or assumedly, for its intended purpose. This is not exclusively about the minor overhead generated from processing this extension. It is also about the combined overhead of enforcing your proposed policy filtering, plus whatever else is already going on in the box, etc.

> Say take a 15 years old router, let's
> upgrade the software
> extension actually consume
> minute, now this
> wrong with that.
[WEG] Actually yes, yes there is. *Especially* on boxes that have very limited resources to start with, the last thing you need to be doing is being cavalier with the available resources. There are already plenty of boxes out there that are running at or above their designed scale limits because there aren't funds to replace/upgrade them, and they basically do what they need to do. Those same vendor assumptions about what is "good enough", whether arbitrary or based on what state of the art was capable of at the time are likely part of the problem in today's world where things have changed and they're no longer "good enough. "
Further, your assumption is totally wrong if the box is already processing enough traffic that it's routinely bumping up against that rate-limit with routine and legitimate traffic, because now it's being potentially crowded out by new traffic that may not even be legitimate. It's even worse if the box gets hit with enough traffic that its built-in filtering mechanisms can't cope and therefore can't differentiate between good and bad traffic enough to keep the box functional.

For boxes that are more modern, your assumption that this is essentially a non-impact is still wrong. Throwing more hardware at the problem is rarely the right solution when compared with being more efficient and judicious with your use of the existing hardware. Just because the latest and greatest CPU hardware is currently running at 25% utilization doesn't mean that it always will be. The combination of code bloat, new features, and increases in all of the scaling vectors that contribute to steady-state and peak CPU (route churn, multicast joins/prunes, protocol keepalives, etc) gradually eat up that spare capacity. We buy hardware so that we can use it for a period of years to recover our investment - the average Telco equipment depreciation cycle is 7 years, and we're lucky to get anywhere near that as it is! Anything that you do to tilt the growth curve in the wrong direction represents an opportunity cost against when we have to replace/upgrade the hardware. Sure, there are bigger impactors out there than your proposed extension, but they all add up, and it's our job as operators to make sure we don't end up dying the death of a thousand cuts anymore than we turn on one big thing that blows up the router or busts all of our scaling and growth assumptions.
> some cpu and bandwidth
[WEG] Unlikely, because for the most part, if that information is available via another, more widely implemented means (eg SNMP), chances are quite good that a) I already am polling the box for it and b) that I won't stop polling it and replace that with this extension. It is simply not a valid assumption that this will do anything other than duplicate existing methods unless it's pulling some unique information that isn't available via other methods. And so far, you have not presented a unique use case for this application.

Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.