IAB concerns against permanent deployment of edge-based filtering

Mon Oct 20 17:57:42 UTC 2003

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

--On Monday, October 20, 2003 05:00:58 AM -0700 bmanning at karoshi.com wrote:

>
>>
>> > 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:
> ----
> 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... :)
>
> 	then there is the idea of "permanent" deployment ...
> 	little is permanent in networking.  the hard problem
> 	is when vendors put filters in silicon. :(
>
> --bill