"sd" == Sean Donelan <sean@donelan.com> writes:
sd> On Tue, 12 Feb 2002, Alex Rubenstein wrote:
sd> ASN.1 is pretty cool, but I've been wondering are there that sd> many ISPs which allow external SNMP access to their equipment? sd> SNMP is a UDP management protocol, and even under the best of sd> conditions, accepting packets from out of the blue isn't a good sd> idea. Spoofed packets? It's not feasible to filter antispoof at OC-12 or OC-48 line rate on all customer facing interfaces. ericb -- Eric Brandwine | To assert that the earth revolves around the sun is as UUNetwork Security | erroneous as to claim that Jesus was not born of a ericb@uu.net | virgin. +1 703 886 6038 | - Cardinal Bellarmine (during the Key fingerprint = 3A39 2C2F D5A0 FC7C 5F60 4118 A84A BD5D 59D7 4E3E
On 12 Feb 2002, Eric Brandwine wrote:
sd> SNMP is a UDP management protocol, and even under the best of sd> conditions, accepting packets from out of the blue isn't a good sd> idea.
Spoofed packets?
It's not feasible to filter antispoof at OC-12 or OC-48 line rate on all customer facing interfaces.
I can remember many cases when my HP Openview network discovery process would attempt to map the entire Internet because it strayed into a peers network. So it may fairly common. At least one provider has told me they don't use in-band management for their network infrastructure. They have a completely seperate frame network connecting to POP management LANs which in turn is connected to seperate management ports on the equipment. I don't know how common this is among large providers. I had a smaller network, so I filtered the IP block used for my management LAN from all external sources (and "logged" the ACL's so I picked up the stray packets from places I missed). A "real" packet should never be sourced from outside my network topology, so even if you spoofed the IP address the topology would block it. Of course, this depended on topological integrity. I can understand if larger providers why large can't do that, it doesn't scale. But there are a lot of small and medium providers that can do it. I agree, its a glass house issue. I was just wondering how bad of an issue it really is.
The PROTOS group also tested HTTP, WAP, and LDAP in addition to SNMP. They also have a paper on constructive disclosure wherein they outline the need to a black-box test suite for use by customers and vendors to ensure simple buffer overflows, format string errors, etc. are easier to find. So, they are essentially attempting to empower the consumer and the vendor to prevent these types of programming errors by releasing a test suite to test for these things. See this paper for more information: http://www.ee.oulu.fi/research/ouspg/protos/sota/FIRST2001-disclosures/paper... On 12-Feb-2002, Sean Donelan wrote:
On 12 Feb 2002, Eric Brandwine wrote:
sd> SNMP is a UDP management protocol, and even under the best of sd> conditions, accepting packets from out of the blue isn't a good sd> idea.
Spoofed packets?
It's not feasible to filter antispoof at OC-12 or OC-48 line rate on all customer facing interfaces.
I can remember many cases when my HP Openview network discovery process would attempt to map the entire Internet because it strayed into a peers network. So it may fairly common.
At least one provider has told me they don't use in-band management for their network infrastructure. They have a completely seperate frame network connecting to POP management LANs which in turn is connected to seperate management ports on the equipment. I don't know how common this is among large providers.
I had a smaller network, so I filtered the IP block used for my management LAN from all external sources (and "logged" the ACL's so I picked up the stray packets from places I missed). A "real" packet should never be sourced from outside my network topology, so even if you spoofed the IP address the topology would block it. Of course, this depended on topological integrity. I can understand if larger providers why large can't do that, it doesn't scale.
But there are a lot of small and medium providers that can do it.
I agree, its a glass house issue. I was just wondering how bad of an issue it really is.
On Tue, Feb 12, 2002 at 07:32:07PM +0000, Eric Brandwine wrote:
"sd" == Sean Donelan <sean@donelan.com> writes:
sd> On Tue, 12 Feb 2002, Alex Rubenstein wrote:
sd> ASN.1 is pretty cool, but I've been wondering are there that sd> many ISPs which allow external SNMP access to their equipment? sd> SNMP is a UDP management protocol, and even under the best of sd> conditions, accepting packets from out of the blue isn't a good sd> idea.
Spoofed packets?
It's not feasible to filter antispoof at OC-12 or OC-48 line rate on all customer facing interfaces.
But it should be not only feasible, but standard practice. -ron
On Wed, 13 Feb 2002, Ron da Silva wrote:
On Tue, Feb 12, 2002 at 07:32:07PM +0000, Eric Brandwine wrote:
> "sd" == Sean Donelan <sean@donelan.com> writes:
sd> On Tue, 12 Feb 2002, Alex Rubenstein wrote:
sd> ASN.1 is pretty cool, but I've been wondering are there that sd> many ISPs which allow external SNMP access to their equipment? sd> SNMP is a UDP management protocol, and even under the best of sd> conditions, accepting packets from out of the blue isn't a good sd> idea.
Spoofed packets?
It's not feasible to filter antispoof at OC-12 or OC-48 line rate on all customer facing interfaces.
But it should be not only feasible, but standard practice.
'Should be' is the key word here... in practical terms though this is not feasible. There are revisions of oc-12 and oc-48 cards in platforms that don't support filtering. Long term all users of internet routing hardware (or routing hardware in general) should push their vendors to implement line-rate filtering. There really is no reason NOT to do it is there? Even better would be the ability to look inside the entire packet, this way the next code-red can be stopped at a higher level in the network where people that actually care about the problem can take appropriate action. -Chris
On Wed, Feb 13, 2002 at 04:06:23PM +0000, Christopher L. Morrow wrote:
Long term all users of internet routing hardware (or routing hardware in general) should push their vendors to implement line-rate filtering. There really is no reason NOT to do it is there? Even better would be the ability to look inside the entire packet, this way the next code-red can be stopped at a higher level in the network where people that actually care about the problem can take appropriate action.
BOTH linerate filtering and packet inspection should be part of the minimal requirements to sell routing hardware. Hmm...so in case any vendor out there hasn't heard this directly from us, consider this a clarification of our requirements. And UUnet's...and ?? any other providers want to make sure that the vendor community gets the message here? -ron
BOTH linerate filtering and packet inspection should be part of the minimal requirements to sell routing hardware. Hmm...so in case any vendor out
Thus spake "Ron da Silva" <ron@aol.net> there
hasn't heard this directly from us, consider this a clarification of our requirements. And UUnet's...and ?? any other providers want to make sure that the vendor community gets the message here?
The people paying the bill often don't have the same concept of requirements as the engineers. Don't get me wrong -- I think you're right and all gear should be capable of line-rate bi-directional filtering (and forwarding for that matter ;). However, speaking in general terms, when presented with a box that can and a box that can't, 90% of customers will end up buying the cheaper one, and that dictates vendors' development priorities. S
BOTH linerate filtering and packet inspection should be part of the minimal requirements to sell routing hardware. Hmm...so in case any vendor out
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Stephen Sprunk Sent: Thursday, February 14, 2002 2:52 AM To: Ron da Silva; nanog@merit.edu Subject: Re: it's here Thus spake "Ron da Silva" <ron@aol.net> there
hasn't heard this directly from us, consider this a clarification of our requirements. And UUnet's...and ?? any other providers want to make sure that the vendor community gets the message here?
The people paying the bill often don't have the same concept of requirements as the engineers. Don't get me wrong -- I think you're right and all gear should be capable of line-rate bi-directional filtering (and forwarding for that matter ;). However, speaking in general terms, when presented with a box that can and a box that can't, 90% of customers will end up buying the cheaper one, and that dictates vendors' development priorities. --- This also is related to concept that most vendors [when creating a box that does and a box that doesn't] don't charge anywhere near in line for the cost of inputs [hardware, design, software, etc] for the additional feature [assuming profit is already built into the original price of the box that doesn't]. Deepak Jain AiNET
participants (7)
-
Christopher L. Morrow -
Deepak Jain -
Eric Brandwine -
Jon O . -
Ron da Silva -
Sean Donelan -
Stephen Sprunk