IAB concerns against permanent deployment of edge-based filtering

Mailman List Mirror (Read Only)
1

> prudent/paranoid folk over the years have persuaded me that
> it makes the best sense to only run those applications/services
> that I need to and shut off everything else - until/unless there
> is a demonstrated need for it.

very true for a host, even somewhat true for a site. very untrue
for a backbone.

randy

there appears to be a disconnect in the wording of the IAB document:
it starts:

2

prudent/paranoid folk over the years have persuaded me that
it makes the best sense to only run those applications/services
that I need to and shut off everything else - until/unless there
is a demonstrated need for it.

very true for a host, even somewhat true for a site. very untrue
for a backbone.

there appears to be a disconnect in the wording of the IAB document:
it starts:
----
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.
----
  it can be viewed from the perspective of a transit provider
  looking toward its edges, the clients.

  it can be viewed from the perspective of a multihomed client
  looking toward its edges, the transit providers.

  which one you take depends on where you start... :slight_smile:

  then there is the idea of "permanent" deployment ...
  little is permanent in networking. the hard problem
  is when vendors put filters in silicon. :frowning:

i have been assuming, possibly quite incorrectly, that the iab concern
was with backbone providers. possibly this is due to my perspective.
imiho, backbones move packets, and the more we muck with them the less
happier our customers are.

but i filter like hell at my personal site edge, and do try to keep
unwanted things off my hosts.

randy

3

a message of 35 lines which said:

  then there is the idea of "permanent" deployment ...
  little is permanent in networking. the hard problem
  is when vendors put filters in silicon. :frowning:

I worked in network service company ("Setting up a firewall in one
morning on a router you do not know"). My definition of "permanent" is
"something installed by someone who left just after".

4

OK... I've been lurking for a while.

I think the definition IAB intended to express concern about was:

Backbones (transit providers) deploying [permanent] filtration on their
connections with other ISPs.

I would like to propose the following terminology definitions FOR THIS EMAIL message
and ask that my following comments be viewed with these definitions in mind:

"Edge Network" A network which does not provide transit between multiple BGP speaking
    neighboring ASs.

"End Network" Or "End User Network" a network which has may or may not speak BGP, but,
    provides services to a single organization and has a single administrative
    control at it's border(s). (e.g. Sun Microsystems, Tellme, HP, etc.,
    not MSN, C&W, Verio, etc.)

"Transit Network"
    A network which does not meet the definitions of Edge Network or
    End Network.

I think given those terms, there is generally agreement that the following are good
operational practice:

  1. Edge Networks and End Networks should not emit packets containing source
    address specifications outside of their assigned (or allocated) ranges.
    They should employ filters at their peering-points to prevent this.

  2. Transit Networks should _NOT_ permanently (or quasi-permanently) block
    traffic to other transit networks other than to the minimal extent
    necessary to meet operational considerations around attacks. The general
    deployment of such filters would in itself be a form of denial of service.

  3. End networks should accept and emit traffic related to their desired
    service profile (what internet features they want to take advantage of)
    and block others.

  4. Any network connecting to an Edge or End network may (and in some cases
    should) cooperate in filtering traffic at conneciton-points to said
    Edge or End networks in a manner consistent with the desires of the
    Edge or End network in question. To do so contrary to the wishes of
    the Edge or End network in question is a form of denial of service.

  5. It is generally good practice for any network providing services to
    Edge or End networks to have a published AUP and to disconnect customers
    which violate the AUP. This is not contrary to the wishes of the client,
    or they should not have signed the AUP.

Having said that,
  I don't think IAB is trying to tell people how to run their networks.
  I do think IAB has a point that if I'm connected to an ISP which is a customer
of UUNET, and I want to exchange traffic of some unpopular service with another host
that is a connected via an ISP that is a customer of C&W, it is a bad thing if C&W
and UUNET block that traffic at their peering point(s). If my ISP blocks it
or the ISP that connects the other host blocks it, then, presumably, I (or the
person at the other end of the connection) have some ability to address it with
the service provider we are paying. Having UUNET or C&W block it at some arbitrary
point in between is:

  1. Hard to isolate.
  2. Hard to troubleshoot.
  3. Unexpected damage
  4. Not a good idea in most cases.

Assuming that this is what IAB was attempting to address, I agree it should be addressed.
The fact that I need to make this assumption should, IMHO, also be addressed by IAB and
they should clarify what their concern is.

Owen

5

OK... I've been lurking for a while.

I think the definition IAB intended to express concern about was:

Backbones (transit providers) deploying [permanent] filtration on their
connections with other ISPs.

I would like to propose the following terminology definitions FOR THIS EMAIL message
and ask that my following comments be viewed with these definitions in mind:

What you're doing here reminds me of what we did in the BGP Convergence Technology draft, http://www.ietf.org/draft-ietf-bmwg-conterm-05.txt (now with the IESG). We made what we felt was a useful but informal distinction between customer edge routers at the POP, and interprovider edge routers. Randy Bush, as the advisor, pointed out these definitions are not rigorous, and indeed might be considered a research problem. We modified our language to reflect his concerns, and that we didn't expect the definitions to be normative.

Nevertheless, there seems a practical need, which you put as a policy consideration here, to distinguish between routers that connect an ISP to transit and nontransit peers. The nontransit peers often will not be taking full routes.