Firewalls in service provider environments
mysidia at gmail.com
Wed Feb 8 00:51:16 UTC 2012
On Tue, Feb 7, 2012 at 3:31 PM, Matthew Reath <matt at mattreath.com> wrote:
> traffic to go through. I can accomplish filtering of known bad ports on my
> edge routers either facing my customers or upstream providers.
I wouldn't want my provider breaking my connectivity in the name of
security. My thought on this is: by all means filter, firewall, and
mangle packets addressed From/To service provider equipment (for
example, port 22 TCP packets sent to the address of the ISP router), in
order to protect ISP network, But, with some minor exceptions, in your
role as ISP, internal firewalls should be separate from customer networks,
and, never ever filter, firewall, or mangle packets _forwarded_ by service
provider equipment To/From customer networks.
If you manage the downstream network, the customer has requested special
filtering or restrictions, or a pattern of abuse has been detected from a
certain downstream that can be temporarily mitigated with a filter, that's
a different story.
It is acceptable to drop packets to enforce network policy, such as no-spam
rules that a customer or host has violated, for example: all IP packets
to a host. It is acceptable to drop erroneous packets, such as ones with
an incorrect checksum or source IP that the customer has not been
assigned, or has not informed the provider that they were assigned.
I would say it's in general unacceptable for an ISP to discriminate against
packets addressed to or sourced from specific port numbers.
That's actually breaking connectivity.
There's no such thing as a "bad port number"; there are port numbers that
certain applications have abused; the entire port range should be
available for any host as indicated by the various RFCs that define the
If packets with any valid bit pattern in the source port or destination
port field are dropped, based on a valid bit pattern in that field, then
that is really a breakage of proper connectivity by the provider.
What is the group's thought on this?
More information about the NANOG