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

From: "George, Wes" <[email-masked]>
Date: Tue, 3 Jan 2012 10:18:08 -0500

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Tissa Senevirathne (tsenevir)
> Sent: Wednesday, December 21, 2011 9:46 PM
> Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-
> 03.txt
>
> Also, do not forget, the authentication object specified here is
> similar to what is used in OSPF. If routers can do that for OSPF, they
> certainly can do this for Ping. If they cannot we can fall back to
> default information and return additional error code to say
> authentication failure.
>
[WEG] Key point here - SP routers don't get a lot of OSPF messages from random hosts on the internet, and even if we do, we pretty much summarily drop them because we aren't expecting to use them ever. We do, however get a lot of ICMP for traceroute/ping, meaning that the filters already have to be a lot less restrictive. You're *way* oversimplifying the method to secure this such that it doesn't create added router load.
Even if we assume multiple tiers of validation - say authorized source IP vs not, some sort of auth key vs not, and tie independent rate-limits to each, if they're not processed in the right order, you might open an attack vector simply by receiving too many packets that fail auth check. I'm also wondering about whether it's realistic to assume that looking deeper into the packet to find the absence or presence of these proposed options can still be done in hardware, or whether some older (and therefore less stout) platforms have to punt it because their hardware is optimized to look to only a certain depth when handling ICMP in a scalable way. There are lots of opportunities for assumptions about the relative rate of different types of ICMP messages such that you can use a more optimized way to process certain ones at higher scale while punting others, and those are quite likely to bite us when proposing new ones.

Additionally, managing such ACLs and auth keys to govern who has access to management information and the associated rate limit, scale, and security considerations for internal stuff is onerous enough without even thinking about adding this capability for external hosts, whether partners or otherwise. This is less a technical problem than a political/organizational one, but it exists nonetheless.
SNMP is a great example - If you ask every large provider exactly what each of the permitted SNMP hosts in their config are doing (which MIBs, rate of query, etc), it's likely that only about half can tell you with any certainty, and you're almost guaranteed to find overlap and cruft in what's being permitted/used. SNMP is one of those things that gradually rots in the config despite everyone's best intentions, because the polling servers and the polled routers (or VMs or whatever) are managed by different groups that don't communicate well with one another, and tools get added/removed/changed all the time. Depending on how tightly you control your config standards, people might stand up poller boxes mostly on their own, configure them with the right IP range and SNMP key and start beating the hell out of your boxes in order to use some new tool, up to and including polling way more information than they actually need, "just in case." And worse yet, they're often polling for information that is already being polled and stored on a different box that they didn't know existed or don't have access to. When implementing a new platform, after exhausting all leads to figure out what the config is doing, you're often stuck saying "no one knows what that entry does, leave it out, let's see who screams". Alternately, you end up troubleshooting scale problems because you have too many hosts asking for too much information in near real-time such that you find and exercise all of the poor IPC design in the larger-scale systems and end up with delayed or incomplete information from your monitoring system.

All of this points to a need for a better method for warehousing, distributing, parsing/correlating, and presenting existing information, not another method to carry the information between two points.

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

---

From: "George, Wes" <[email-masked]>
Date: Tue, 3 Jan 2012 10:29:51 -0500

> Sent: Wednesday, December 21, 2011 9:49 PM
> To: Jared Mauch; Naiming Shen (naiming)
> Cc: Thomas Narten; Carlos Pignataro (cpignata); Enke Chen (enkechen);
> [email-masked]; [email-masked]
> Yes. But the problem is you have to switch back and forth between
> different applications (SNMP browsers, Network Management applications
> etc..) to get the information. With integrated ICMP Ping, you should be
> able to get interested data as part of the ping output.
>

[WEG] Sure, "should", except for hosts in the middle that don't support the new options, are configured to ignore them, or are not configured to see your querying host as trusted enough to receive that information, etc. etc. This is a solution that rapidly loses value in an incremental deployment model if that's indeed the problem it's purporting to solve. The above issue of needing to switch between tools may be a problem, but it's a presentation/application layer problem with the *tools*, not the network elements or protocols, and therefore the solution belongs in the application space. I love direct CLI access as much as the next guy, so I'm trying to keep an open mind on something that potentially makes it better, but I'm really not in favor of reinventing the wheel if reduction of swivel-seating for NOC folks is the primary justification.
As I have noted in my message about SNMP, there is already a lot of this "solution" happening, where instead of using the same information for multiple presentation/correlation tools, we end up with multiple pollers/stores of the same information and a failure to correlate, to the detriment to the scale of the device and its risk of attack.

Thanks,
Wes George

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Tue, 3 Jan 2012 11:53:53 -0600

Jared,

> A commonly used platform can only populate about 8k entries per second
> under
> load, making a 150k prefix change take 18 seconds or more.  This is a
> significant
> amount of time.  Any IPC contention during this time results in
further
> customer observed downtime.

We may be ignoring the fact that CPU could check for the prioritization
when scheduling processes, so such important events (as downloading of
RIB/FIB changes to the LC) would be prioritized over less important
events such as ICMP handling. Of course, this is implementation
specific, but I gather that most platforms live by this notion.

	One could argue that fetching the info from the LC for SNMP
related
	Polling could be qualified as the contender.

Microcode programming (or lack thereof) is a way too implementation
specific to be discussed (with sufficient details) at the IETF, though I
see your point about involved complexity.

We would be better off discussing the value of this draft in regards to
use-cases of proposed extensions in networks (whether SP or Enterprise).

Cheers,
Rajiv

> -----Original Message-----
Behalf
> Of Jared Mauch
> Sent: Tuesday, December 27, 2011 7:39 PM
> To: Carlos Pignataro (cpignata)
> Cc: Thomas Narten; [email-masked]; [email-masked]; Enke Chen
> (enkechen)
> Subject: Re: [Int-area] I-D Action:
draft-shen-traceroute-ping-ext-03.txt
> 
> Happy Holidays!
> 
> On Dec 23, 2011, at 10:02 AM, Carlos Pignataro wrote:
> 
> > Have you read the Security Considerations section? The first
paragraph
> > reads:
> 
> I have not, because any additional complexity in the distributed
forwarding
> plane
> or centralized cpu utilization is undesirable in SP operations..
> 
> Any code where you perform additional checks prior to replying adds
load to
> the
> device and with minimal cpu provided on line cards, this is my main
problem.
> 
> Authentication and other mechanisms take away valuable microcode space
and
> increase the complexity.
> 
> Tier-1 networks have likely evolved significantly since Naiming was in
the
> space.  A single network (Level3) today announces about 50% of the DFZ
rib on
> a peering session.  When this interface goes down, the time spent
> processing the rib -> fib -> lc events can be significant on a
platform.
> 
> A commonly used platform can only populate about 8k entries per second
> under
> load, making a 150k prefix change take 18 seconds or more.  This is a
> significant
> amount of time.  Any IPC contention during this time results in
further
> customer observed downtime.
> 
> These are operational challenges that are faced today with modern
hardware.
> I'm concerned that the innovation provided by this draft is
unnecessary for
> the network operator and will place undue load upon the network.
> 
> - Jared
> 
> >
http://tools.ietf.org/html/draft-shen-traceroute-ping-ext-03#section-6
> >
> > 6.  Security Considerations
> >
> >   This extension enhances the security of traceroute and ping
operation
> >   in a backwards-compatible fashion.  The mechanism allows the
receiver
> >   to verify the sender of the traceroute/ping packet such that
certain
> >   sensitive application, interface and network related information
can
> >   be supplied in the internal network or across trusted networks.
> >
> > Additionally, the existing framework of RFC 4884 + associated
extensions
> > (e.g., RFC 4950 and RFC 5837) already address this point:
> >
> > http://tools.ietf.org/html/rfc4950#section-6
> >
> >   interaction between MPLS and ICMP.  However, this document defines
an
> >   extension that allows an MPLS router to append MPLS information to
> >   multi-part ICMP messages, and therefore can provide the user of
the
> >   TRACEROUTE application with additional information.  Consequently,
a
> >   network operator may wish to provide this information selectively
> >   based on some policy; for example, only include the MPLS
extensions
> >   in ICMP messages destined to addresses within the network
management
> >   blocks with administrative control over the router.  An
> >
> > http://tools.ietf.org/html/rfc5837#section-6
> >
> >   It may be desirable to provide this information to a particular
> >   network's operators and not to others.  If such policy controls
are
> >   desirable, then an implementation could determine what sub-objects
to
> >   include based upon the destination IP address of the ICMP message
> >   that will contain the sub-objects.  The implementation of policy
> >   controls could also be based upon the mechanisms described in
> >   [TRACEROUTE-EXT] for those limited cases supported.
> >
> > The authentication in this I-D attempts to make it easier and more
scalable.
> 
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Carlos Pignataro <[email-masked]>
Date: Tue, 03 Jan 2012 14:20:44 -0500

Happy Holidays!

Jared,

Thanks for the responses. I will attempt to group some follow-ups and
responses here in a single reply to this email, as most (or all) of your
comments are quite related and center around the same root concern.
Please see inline.

On 12/27/2011 7:38 PM, Jared Mauch wrote:
>> Have you read the Security Considerations section? The first paragraph
>> reads:
> 
> I have not, because any additional complexity in the distributed forwarding plane
> Any code where you perform additional checks prior to replying adds load to the
> device and with minimal cpu provided on line cards, this is my main problem.

IMHO, there is -- there always is -- a benefit curve and a trade-off.
While I understand the point you are making, I would not go as far as
saying that any check is bad. Yes, as little as possible given a problem
space and an applicabiloity, but certainly not less than that.

On the one hand side we have a (security) need for not sending
information to any source on an ICMP error. We also have a manageability
consideration for *inband* "OAM" requesting specific elements. On the
other hand side, there is a (security) consideration to not
DoS/overloading a router CPU (or more generically control plane). My
point is that there is a curve of benefit between these datapoints that
can maximize both.

Take for example a layered approach to protection, in which a
processing-expensive check (e.g., is performed only after a cheaper test
passes, much like GTSM). An authentication check is only performed after
rate-limiting and other cheaper checks, or only performed under certain
conditions.

That said, however, there is an argument that authentication might be
too heavyweight. To this, a suggestion of making it optional or even
separate from the "probe framework" and modulated by Applicability
Considerations seems sensible.

> 
> Authentication and other mechanisms take away valuable microcode space and
> increase the complexity.  
> 
> Tier-1 networks have likely evolved significantly since Naiming was in the
> space.  A single network (Level3) today announces about 50% of the DFZ rib on
> processing the rib -> fib -> lc events can be significant on a platform.
> 
> A commonly used platform can only populate about 8k entries per second under
> load, making a 150k prefix change take 18 seconds or more.  This is a significant
> amount of time.  Any IPC contention during this time results in further 
> These are operational challenges that are faced today with modern hardware.
> I'm concerned that the innovation provided by this draft is unnecessary for

Staying away from platform specifics but diving into the core of this
comment, those are implementation considerations and prioritization to
include in a functional spec and not an I-D.

I would fundamentally disagree with an advocacy that every check uses
CPU cycles and is therefore bad -- and apologies as I might be
misunderstanding or mis-generalizing your perspective.

Later, on 12/27/2011 7:52 PM, Jared Mauch wrote:

>> This I-D is not proposing an operational security feature. These generic
>> comments are very interesting but perhaps better fitting Opsec; RFC 6192
>> <http://tools.ietf.org/html/rfc6192> also comes to mind.
>>
>> What's your take on
>> <http://tools.ietf.org/html/draft-shen-traceroute-ping-ext-03#section-6>?
> Carlos,
> 
> Including the text for reference:
> 
> -- snip --
>    A router needs to protect against purposefully-bogus Traceroute
>    packets with extensions that fail the authentication, as a high rate
>    of messages can require significant processing time.  [
> RFC1812
> ]
>    specifies how rate-limiting is applied to the generation of ICMP
>    messages, and this rate-limiting deters the threat when applied
>    before checking the Authentication.  Additionally, when using
>    Cryptographic authentication, the HMAC includes the source IP
>    address, which means the HMAC will not validate if the traceroute/
>    ping packet is sent over a NAT.
> -- snip --
> 
> Traceroute packets (ie: ICMP Exception of TTL Expiry).  If the authentication is provided in hardware prior to the application of rate-limiting, this can be used to attack the limited CPU resources in a line card.  If rate-limited after the authentication, which is more expensive, replying or performing the authentication?  While this is an implementation detail, it's important to measure the inherent cost.  Sometimes it is more expensive to authenticate vs "just reply".
> 
> Has this cost been measured in the network elements?  Reducing performance of the network hardware is not a desired outcome, and a major concern of mine here.
> 

Yes, I would say perform authentication after rate-limiting, make
authentication optional, and also default to a very processing cheap reply.

Rajiv just mentioned also the difficulties to go into more specifics
here. I echo the same comment, and also suggest focusing on the use case
and problem being solved.

We are after a framework on which we can have more control over what is
included in an ICMP message or error.

> I'm also concerned that referencing rfc1812 4.3.2.8 could be overly simplistic in talking about rate-limits involved,
> are you specifically talking about the Cisco implementation referenced
here:

No, we are not discussing any particular implementation here, from any
vendor.

> 
> http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-addrg_bsc_con.html#wp1373663
> 
> -- snip --
> In Cisco IOS Release 12.2(8)T or later releases, the IPv6 ICMP rate limiting feature implements a token bucket algorithm for limiting the rate at which IPv6 ICMP error messages are sent out on the network. The initial implementation of IPv6 ICMP rate limiting defined a fixed interval between error messages, but some applications, such as traceroute, often require replies to a group of requests sent in rapid succession. The fixed interval between error messages is not flexible enough to work with applications such as traceroute and can cause the application to fail.
> -- snip --
> 
> Where will this rate-limiting be implemented?  Hardware?  Software?  Both?  The 7600 and 6500 platform (for example) have a hardware based rate-limiter on a per-lc basis, but the traffic that is punted to the cpu is the aggregate across all linecards and must be policed a second time before being processed for the punt/exception cases.  Processing this policy in actual implementations has proved to be more expensive than "just replying" in operations.
> 
> I'm concerned that without implementation requirements we will see troubles in the future with this.
> 
> I'm also reminded of Solaris 2.6 and the 500ms rate-limit it provided to TTL expiry handling that confused network and sysadmins to think the host may be experiencing loss.  The traceroute processing would show the 1st and 3rd packets fine, but the 2nd would be dropped due to rate-limit.
> 

If the reference from RFC 1812 is too simplistic, do you have a better
Internet RFC reference to cite? Again, only RFC 6192 comes to mind.

Minutes after, on 12/27/2011 7:59 PM, Jared Mauch wrote:
>> Thanks again, please see inline.
> Sure,
> 
>> On 12/21/2011 7:49 PM, Jared Mauch wrote:
>>> The data is available via alternate means. Not sure why encoding it
>>> in an exception packet is necessary.
>>>
>> This is from my home, right now:
>> # traceroute puck.nether.net
>> <snip>
>> 9  ae-6.r20.asbnva02.us.bb.gin.ntt.net (129.250.3.109)  25 ms  31 ms  28 ms
>>    MPLS Label=445248 Exp=0 TTL=1 S=1
> Yes, I'm unaware of a way to exclude this information from replies, but this data
> is already there on the FPC in the local FIB.  Placing the HMAC and other crypto
> in the FIB path seems problematic and would increase the cost of replying.
> 
> There was also the case (around JunOS 5.5 iirc) they implemented a hard-limit of
> icmp exception handling that caused numerous issues with clueless network admins
> thinking they were observing packet loss.  The optics of this issue does matter
> to operators, even if the forwarding plane is minimally impacted.

This again speaks (to me) to the trade-off: more control on the replies
at the expense of more checks, sometimes.

It also occurs to me that really there is a (lacking) Applicability
Statement as to when to use (and when *not* to use) the (optional)
authentication.

I would here also refer to the Abstract from this I-D:

   This document specifies extensions to traceroute and ping techniques
   to facilitate addition application information to be carried in UDP,
   TCP and ICMP traceroute probe messages and ICMP echo request and
   reply messages.  This proposal also allows the receiver to
   authenticate the source of the traceroute and ping senders.

The main goal is to provide a framework to include application
information in the "probe". This is given the fact that RFC4884,
RFC4950, and RFC5837 (the first and last from int-area) include extra
information in the elicited ICMP message.

Note how there is a "This proposal also allows" modifier when describing
the authentication.

> 
>> On 12/22/2011 6:33 AM, Jared Mauch wrote:
>>> I think you are overestimating the ability of the routers to respond.
>>>
>>> Cisco and Juniper have so far failed in many ways that have created pain for operators over the years when it comes to processing packets directed to the device.  Developers see these as vulnerabilities and have moved to rate-limit packets directed at the control-plane, either by processing on the FPC, DFC, Linecard CPU, or the centralized processor.
>>>
>>> The experiences I've had demonstrate that platforms are underpowered for processing these packets and leave the system vulnerable to resource exhaustion attacks, even with CPP.  If you want to take the discussion off-line I can provide you a number of examples where platforms have gotten this wrong despite the experiences already learned by other groups inside and outside your respective employers.
>>>
>>> Choosing to ignore these hard learned lessons leads us down a dim path for the future.
>>>
>>> Additionally, nothing is stopping someone from developing proper management software that processes the TTL expiry packets and mapping that with the various enterprise mibs for the device.  Think of a version of MTR that sends a series of SNMP queries based on these messages and can be configured to understand the scope of ones network, e.g.:
>>>
>>> snmp_poll {
>>>  address-space 3ffe:2001::/48 {
>>>    snmp-community public;
>>>  }
>>> }
>>>
>> MTR hits the routers with a lot more packets, no? After a traceroute it
>> starts to ping, I understand. Just to be clear, do you mean that
>> processing a set of snmp polls is less processor intensive?
> Certainly not.  Anyone spending time with ASN.1 will know it's very expensive.
> (I used to own one of the internal SNMP tools at a major carrier).
> 
> But providing the information to an authorized set of people (network operators/NOC
> would seem to be more appropriate than possibly exposing private data that may be
> considered proprietary to ones network).

Both are important, and frankly this I-D actually attempts to solve
these both issues...

> 
>>> This combined with existing shipping tools/software would keep excessive traffic from degrading the device.
>>>
>> The challenge is that, often times, troubleshooters do not have access
>> to a full-blown NMS. Or the NMS does not have access to the devices.
>> Or... This is embedding a response in the traceroute path.
> I think trying to solve the trouble of operators without access to manage their
> equipment via traceroute extensions is the wrong way to approach the problem. 
> 
> This sounds more like a business issue.  If the people doing the troubleshooting
> don't have access, then there are many jobs available today for qualified network
> people.  Natural selection and market forces will work against those carriers
> without the skill/access to resolve their troubles.

No, the comment here is one of inband versus out-of-band.

>> -- Carlos.

Sorry for the length of this reply, and hopefully I did address all
comments.

In summary, ack to the "authentication" comment. Have in mind that this
is a proposal to support inband information elements in the probes, and
reduce the exposure of not having control on the replies.

Thanks,

-- Carlos.

---

From: Carlos Pignataro <[email-masked]>
Date: Tue, 03 Jan 2012 14:33:27 -0500

Joel, Jared,

On 12/27/2011 8:03 PM, Jared Mauch wrote:
> Joel,
> 
> On Dec 24, 2011, at 1:28 PM, Joel jaeggli wrote:
> 
>> So, something targeted through the forwarding plane that filters up to
>> the control plane will be filtered first either by source address or
>> passed through a rate limiter or both because those are the protections
>> we have that actually scale. Authentication increases the vulnerability
>> to some kinds of abuse rather that decreasing it.
> 
> 
> Thanks.  I think I mentioned this in another message, but captures an important
> concern about the network elements being managed.  Implementation details matter.
> 

Yes, this is an inband packet flowing through the forwarding plane, that
upon exception needs processing. What you describe is the existing
traceroute mechanism, as well as other protocols, some widely
operationally deployed (including MPLS Ping in RFC 4379 with the
complexity and computational expense of a dsmap hashing, RAO in RFC 5971
and RSVP, etc).

I agree with your point that authentication increases the surface area
for abuse in some conditions. I think that one approach here is to
describe, in an applicability statement, in which cases an
authentication is useful versus in which ones it is potentially harmful.
Would you agree?

Also, please note that the authentication mechanism is not the most
important part of draft-shen-traceroute-ping-ext.

Thanks,

-- Carlos.

---

From: Warren Kumari <[email-masked]>
Date: Tue, 3 Jan 2012 14:34:35 -0500

On Jan 3, 2012, at 10:29 AM, George, Wes wrote:

> [WEG] Sure, "should", except for hosts in the middle that don't support the new options, are configured to ignore them, or are not configured to see your querying host as trusted enough to receive that information, etc. etc. This is a solution that rapidly loses value in an incremental deployment model if that's indeed the problem it's purporting to solve. The above issue of needing to switch between tools may be a problem, but it's a presentation/application layer problem with the *tools*, not the network elements or protocols, and therefore the solution belongs in the application space.

++.

And I note that you didn't say "Application Area" -- I'm assuming that this was intentional.

This proposal still seems to me to be solving a non-problem, and doing it in a way / place that the operators involved in the discussions have repeatedly expressed concerns about.

I already have a number of well supported methods to get diagnostic and reporting information from my devices from within my network, and they work well. I filter SNMP and ssh (and other management type protocols) at the edge of my network because a: it's none of your business and b: I don't want to burn cycles throwing away management attempts from you -- this is currently easy to do because I can easily filter on port and protocol.

This proposal would require me looking much further into the packet to be able to filter this stuff from the outside (and no, I don't want to just allow it in and filter on each device -- security is like an onion[0]) and so all I am left with is filtering out ICMP.. oh, and UDP... and TCP.  For obvious reasons this is, um, suboptimal...

> I love direct CLI access as much as the next guy, so I'm trying to keep an open mind on something that potentially makes it better, but I'm really not in favor of reinventing the wheel if reduction of swivel-seating for NOC folks is the primary justification.

Yup. Effort would be much better spent on being able to share the currently collected information amongst multiple tools.

> Wes George

W
[0]: It makes you cry.

---

From: Warren Kumari <[email-masked]>
Date: Tue, 3 Jan 2012 14:38:30 -0500

> important part of draft-shen-traceroute-ping-ext.

To me the biggest issue is that there is no way to easily filter this out at the edge of the network (or anywhere else) without looking deeply into the packet. If this didn't look (and smell) like packets that I have to let into my network for normal operations I would be fine it it...

W

---

From: Carlos Pignataro <[email-masked]>
Date: Tue, 03 Jan 2012 14:46:40 -0500

Wes,

Thanks for the comment, please see inline.

> As I have noted in my message about SNMP, there is already a lot of this "solution" happening, where instead of using the same information for multiple presentation/correlation tools, we end up wit…

Not disagreeing with anything you wrote here, and in fact all very good
points.

Just one comment that from my perspective, the difference here between
draft-shen-traceroute-ping-ext versus what you describe is in-band /
in-flow versus out-of-band.

Thanks,

-- Carlos.

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Tue, 3 Jan 2012 13:56:08 -0600

Hi Warren,

> If this didn't look (and smell) like packets that I have to let into
my network for
> normal operations I would be fine it it...

That's reasonable. 

If the default behavior is to not provide any additional info to the
probe sender (upon ttl expiry, for example), then it could meet the
deployment expectation.  
One could compare this to not enabling any IGP on the external-facing
interfaces to avoid advertise internal prefix info.

Cheers,
Rajiv

Behalf
> Of Warren Kumari
> Sent: Tuesday, January 03, 2012 2:39 PM
> Cc: [email-masked]
> >> Thanks.  I think I mentioned this in another message, but captures
an
> important
> To me the biggest issue is that there is no way to easily filter this
out at the
> edge of the network (or anywhere else) without looking deeply into the
packet.
> If this didn't look (and smell) like packets that I have to let into
my network for
> normal operations I would be fine it it...
> 
> W
> 
> 
> 
> >
> > Thanks,
> >
> > -- Carlos.
> >
> >> - Jared
> >>
> >>

---

From: Jared Mauch <[email-masked]>
Date: Tue, 3 Jan 2012 15:47:53 -0500

> rate-limiting and other cheaper checks, or only performed under certain

Not all vendors and platforms do GTSM in hardware, some do it in software after it has passed the hardware filters.

> misunderstanding or mis-generalizing your perspective.

I think it's a concern, but not a hard blocker issue.  I've been on the wrong side of someones "functional spec" before where the developers lacked the creative experience of the global internet backbone space.

But citing the platform specifics and repeated mistakes is important to capture here before the devices melted down.  I'm not in a trusting mood and want to protect the vendors from making a customers network melt due to the repeated mistakes after the lessons have been learned.

- jared

---

From: Jared Mauch <[email-masked]>
Date: Tue, 3 Jan 2012 15:49:37 -0500

> To me the biggest issue is that there is no way to easily filter this out at the edge of the network (or anywhere else) without looking deeply into the packet. If this didn't look (and smell) like…

+1

---

From: "George, Wes" <[email-masked]>
Date: Tue, 3 Jan 2012 16:13:28 -0500

> From: Carlos Pignataro [mailto:[email-masked]]
> Sent: Tuesday, January 03, 2012 2:47 PM

[WEG] I've seen reference to this distinction in a couple of your replies, and I'm not sure I'm understanding it. Fundamentally I understand in-band vs out of band, but I'm not sure I'm making the connection you're drawing here. Can you try to explain why this difference is important in this case?

Thanks
Wes George

---

From: "George, Wes" <[email-masked]>
Date: Tue, 3 Jan 2012 16:38:13 -0500

> Sent: Tuesday, January 03, 2012 2:21 PM
[WEG] I think you're misunderstanding our concern. We're not saying that we don't want authentication. In fact, in many cases, just the opposite. We're saying that most of the examples that you've provided of "additional information" to be carried in these responses are considered private info thus necessitating one or more methods of controlling its availability and distribution. However, the value in providing this information makes it questionable as to whether the scale impact of controlling access (via authentication and other filtering methods) to it is justified.

> Note how there is a "This proposal also allows" modifier when

[WEG] This is the fundamental disconnect. Currently, this is providing a framework to distribute information, and thus far the examples of the type of information that could be distributed have all been things which are available via other methods. So acknowledging that these exist, I guess the question still remains - what would this framework be used for in terms of unique information-passing or solving a problem that exists in the current options that make this implementation worth the tradeoffs? That's where you're currently on the wrong side of the benefit/tradeoff curve - implementing something that represents a security risk and a scale risk with no documented use case to justify this particular solution to a problem. I know you're proposing a framework with the idea that it might be flexible enough to address future uses, but typically such things have at least one valid use case that drives their implementation now vs when a valid use case presents itself.

Hope this helps...

Wes George

---

From: Joel jaeggli <[email-masked]>
Date: Wed, 04 Jan 2012 01:24:45 -0800

> complexity and computational expense of a dsmap hashing, RAO in RFC 5971

The existing icmp exception generation mechanism can and is distributed
to line card cpus in some router platforms. there's quantitative
differences associated with handling those requests in a distributed
fashion and punting them up to the control plane because you need more
information than is generally available on a linecard in order to
process the request. that applies both to the contents and the
authentication mechanism.

> authentication is useful versus in which ones it is potentially harmful.

I think that would be acceptable.

---

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

Hello, Wes,

> [WEG] I've seen reference to this distinction in a couple of your replies, and I'm not sure I'm understanding it. Fundamentally I understand in-band vs out of band, but I'm not sure I'm making the…

Sure. What I meant is this: an NMS can query nodes to figure out a path
a packet/flow would take, as well as specific information along that
path, such as the MPLS label stack, information about the unnumbered
incoming interface, etc. It can then correlate all that information and
present it to a human (or a machine) in various formats. However, that
does not tell the user (or script) that the path is dataplane-alive. As
a troubleshooting (or management, sla, etc.) tool, a goal here is to
complement RFC 4884 on the probe side, as a packet flows inband through
the forwarding path checking the path.

Hope that clarifies, sorry for the lack of precision.

-- Carlos.

---

From: "George, Wes" <[email-masked]>
Date: Wed, 4 Jan 2012 16:22:28 -0500

> Sent: Wednesday, January 04, 2012 3:09 PM
> However, that

[WEG] Ah, but that's largely dependent on the way that the management tools and other bits are implemented. Not all networks use separate out of band paths for things like SNMP, so in many cases, if it's SNMP-reachable, it's alive, and SNMP actually can represent something very similar to what Ping might be able to. You're right that it doesn't necessarily validate the exact path that a ping or trace might, but often those don't follow the exact same path either since they're punted to either the LC or the RP's slow path for processing vs going through the forwarding machinery like normal packets.

Wes George