IAB concerns against permanent deployment of edge-based filtering

IAB concerns against permanent deployment of edge-based filtering

The IAB notes that there ISPs/ASes undertaking permanent deployment of
edge-based protocol number/port number packet filtering on traffic
received from eBGP peers.

As a short term response to security incidents this is a prudent
operational measure that limits the spread of various forms of attack, and
also mitigates some level of risk associated with network vulnerabilities.
For example, many ISPs installed temporary filters in response to a July
2003 security advisory for CISCO routers (
http://www.cert.org/advisories/CA-2003-15.html). In the case of this
incident PIM (protocol # 103) and mobile-ip4 (55) packets could trigger
the vulnerability. The operational community responded with widespread
deployment of filters at AS borders for these protocol numbers. Because
of this, PIM and mobile-ip4 no longer work across such AS borders.

The IAB is concerned about the practice of the permanent deployment of
such traffic filters, since this could block the operation of certain
applications in current use, as well as limiting the potential for
deployment of future applications. Such filters ultimately limit
extensibility of the Internet protocol as well as the Internet itself.

It is an entirely appropriate and operationally prudent response to filter
at the AS border as a short term mitigation of various network
vulnerabilities. However, filters at AS borders do not provide any more
than a relatively short term mitigation, and certainly do not solve the
real problem of eliminating all forms of exploitation of such
vulnerabilities. Over time knowledge of a vulnerability spreads across
the network and potential exploiters of a vulnerability will be within an
ISP/AS as well as being on the outside. The only stable and appropriate
longer term operational response is to upgrade network equipment to
eliminate the vulnerability, rather than attempting to configure packet
filters intended to prevent externally located third parties from
exploiting it.

While short term traffic filters are deployed, the appropriate recommended
longer term action is to:

- To install filters to detect packets that are directed to the router
   itself to protect the router. (do not filter traffic that goes through
   the routers).

- To update router firmware to a version known to eliminate the
   vulnerability

Regards,

Jun-ichiro itojun Hagino, on behalf of IAB (iab@ietf.org)

Jun-ichiro itojun Hagino wrote:

While short term traffic filters are deployed, the appropriate recommended
longer term action is to:

Edge networks have a lot more to upgrade than backbone networks. Obtaining IOS code that works for all the different types of routers and meets the ISP's policy is not an easy task. Some files had to be specifically requested from the vendor as they no longer supported the version and didn't have pre-compiles. In addition, there are "other" bugs in IOS which must be considered for each application of a router deployment. This must be tested and monitored at one application locale and once verified can be deployed for all similar applications.

In some cases,there were no alternatives, and this forced hardware upgrades at various locations (ie, memory). Such upgrades require money and time on the part of the edge customers. The peering blocks allow for limited protection of a majority of the customers while they continue to repair their networks.

RPC blocks will be much worse, as the storm is still pretty loud, and low bandwidth customers cannot handle the extra noise.

-Jack

[...]

Agreed, but when an edge network fails to upgrade, it just harms itself.
Backbone networks harms everyone concerned. It's good to remember who
bears the pain for (in)action in whichever case.