headers
George, Wes | 3 Jan 2012 16:18

Re: I-D Action: draft-shen-traceroute-ping-ext-03.txt

> From: int-area-bounces <at> ietf.org [mailto:int-area-bounces <at> ietf.org] 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
George, Wes | 3 Jan 2012 16:29

Re: I-D Action: draft-shen-traceroute-ping-ext-03.txt

> From: int-area-bounces <at> ietf.org [mailto:int-area-bounces <at> ietf.org] On
> Behalf Of Tissa Senevirathne (tsenevir)
> Sent: Wednesday, December 21, 2011 9:49 PM
> To: Jared Mauch; Naiming Shen (naiming)
> Cc: Thomas Narten; Carlos Pignataro (cpignata); Enke Chen (enkechen);
> int-area <at> ietf.org; akatlas <at> juniper.net
> Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-
> 03.txt
>
> 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 swi
 vel-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,
(Continue reading)

Permalink | Reply | 5 comments |
headers
Rajiv Asati (rajiva | 3 Jan 2012 18:53
Picon
Favicon

Re: I-D Action: draft-shen-traceroute-ping-ext-03.txt

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Carlos Pignataro | 3 Jan 2012 20:20
X-Face
Picon
Favicon

Re: I-D Action: draft-shen-traceroute-ping-ext-03.txt

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

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
(Continue reading)

Permalink | Reply | 2 comments |
headers
Carlos Pignataro | 3 Jan 2012 20:33
X-Face
Picon
Favicon

Re: I-D Action: draft-shen-traceroute-ping-ext-03.txt

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?
(Continue reading)

Permalink | Reply | 4 comments |
headers
Warren Kumari | 3 Jan 2012 20:34

Re: I-D Action: draft-shen-traceroute-ping-ext-03.txt


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

>> From: int-area-bounces <at> ietf.org [mailto:int-area-bounces <at> ietf.org] On
>> Behalf Of Tissa Senevirathne (tsenevir)
>> Sent: Wednesday, December 21, 2011 9:49 PM
>> To: Jared Mauch; Naiming Shen (naiming)
>> Cc: Thomas Narten; Carlos Pignataro (cpignata); Enke Chen (enkechen);
>> int-area <at> ietf.org; akatlas <at> juniper.net
>> Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-
>> 03.txt
>> 
>> 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.

++.

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Warren Kumari | 3 Jan 2012 20:38

Re: I-D Action: draft-shen-traceroute-ping-ext-03.txt


On Jan 3, 2012, at 2:33 PM, Carlos Pignataro wrote:

> 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
(Continue reading)

Permalink | Reply | 2 comments |
headers
Carlos Pignataro | 3 Jan 2012 20:46
X-Face
Picon
Favicon

Re: I-D Action: draft-shen-traceroute-ping-ext-03.txt

Wes,

Thanks for the comment, please see inline.

On 1/3/2012 10:29 AM, George, Wes wrote:
>> From: int-area-bounces <at> ietf.org [mailto:int-area-bounces <at> ietf.org] On
>> Behalf Of Tissa Senevirathne (tsenevir)
>> Sent: Wednesday, December 21, 2011 9:49 PM
>> To: Jared Mauch; Naiming Shen (naiming)
>> Cc: Thomas Narten; Carlos Pignataro (cpignata); Enke Chen (enkechen);
>> int-area <at> ietf.org; akatlas <at> juniper.net
>> Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-
>> 03.txt
>>
>> 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 s
 wivel-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
(Continue reading)

Permalink | Reply | 3 comments |
headers
Rajiv Asati (rajiva | 3 Jan 2012 20:56
Picon
Favicon

Re: I-D Action: draft-shen-traceroute-ping-ext-03.txt

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

> -----Original Message-----
> From: int-area-bounces <at> ietf.org [mailto:int-area-bounces <at> ietf.org] On
Behalf
> Of Warren Kumari
> Sent: Tuesday, January 03, 2012 2:39 PM
> To: Carlos Pignataro (cpignata)
> Cc: int-area <at> ietf.org
> Subject: Re: [Int-area] I-D Action:
draft-shen-traceroute-ping-ext-03.txt
> 
> 
> On Jan 3, 2012, at 2:33 PM, Carlos Pignataro wrote:
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jared Mauch | 3 Jan 2012 21:47
Favicon

Re: I-D Action: draft-shen-traceroute-ping-ext-03.txt


On Jan 3, 2012, at 2:20 PM, Carlos Pignataro wrote:

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

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

> 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
>> 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.
>>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane