[187789] in North American Network Operators' Group
Re: Thank you, Comcast.
daemon@ATHENA.MIT.EDU (Livingood, Jason)
Fri Feb 26 10:16:54 2016
X-Original-To: nanog@nanog.org
From: "Livingood, Jason" <Jason_Livingood@comcast.com>
To: Keith Medcalf <kmedcalf@dessus.com>, NANOG list <nanog@nanog.org>
Date: Fri, 26 Feb 2016 15:12:43 +0000
In-Reply-To: <df93d62ef8e6cb4db2e0fd81f856cac1@mail.dessus.com>
Cc: "Mody, Nirmal" <Nirmal_Mody@cable.comcast.com>
Errors-To: nanog-bounces@nanog.org
FWIW, Comcast's list of blocked ports is at http://customer.xfinity.com/hel=
p-and-support/internet/list-of-blocked-ports/. The suspensions this week ar=
e in direct response to reported abuse from amplification attacks, which we=
obviously take very seriously.
We are in the process of considering adding some new ports to this block li=
st right now, and one big suggestion is SSDP. If you have any others you wi=
sh to suggest please send them to me and the guy on the cc line (Nirmal Mod=
y).
Thanks!
Jason
On 2/26/16, 9:31 AM, "NANOG on behalf of Keith Medcalf" <nanog-bounces@nano=
g.org<mailto:nanog-bounces@nanog.org> on behalf of kmedcalf@dessus.com<mail=
to:kmedcalf@dessus.com>> wrote:
ISP's should block nothing, to or from the customer, unless they make it cl=
ear *before* selling the service (and include it in the Terms and Condition=
s of Service Contract), that they are not selling an Internet connection bu=
t are selling a partially functional Internet connection (or a limited Inte=
rnet Service), and specifying exactly what the built-in deficiencies are.
Deficiencies may include:
port/protocol blockage toward the customer (destination blocks)
port/protocol blockage toward the internet (source blocks)
DNS diddling (filtering of responses, NXDOMAIN redirection/wildcards, etc=
)
Traffic Shaping/Policing/Congestion policies, inbound and outbound
Some ISPs are good at this and provide opt-in/out methods for at least the =
first three on the list. Others not so much.
-----Original Message-----
From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Maxwell Cole
Sent: Friday, 26 February, 2016 07:19
To: Mikael Abrahamsson
Cc: NANOG list
Subject: Re: Thank you, Comcast.
I agree,
At the very least things like SNMP/NTP should be blocked. I mean how many
people actually run a legit NTP server out of their home? Dozens? And the
people who run SNMP devices with the default/common communities aren't the
ones using it.
If the argument is that you need a Business class account to run a mail
server then I have no problem extending that to DNS servers also.
Cheers,
Max
> On Feb 26, 2016, at 8:55 AM, Mikael Abrahamsson <swmike@swm.pp.se<mailto:=
swmike@swm.pp.se>>
wrote:
>
> On Fri, 26 Feb 2016, Nick Hilliard wrote:
>
>> Traffic from dns-spoofing attacks generally has src port =3D 53 and dst
port =3D random. If you block packets with udp src port=3D53 towards
customers, you will also block legitimate return traffic if the customers
run their own DNS servers or use opendns / google dns / etc.
>
> Sure, it's a very interesting discussion what ports should be blocked or
not.
>
> http://www.bitag.org/documents/Port-Blocking.pdf
>
> This mentions on page 3.1, TCP(UDP)/25,135,139 and 445. They've been
blocked for a very long time to fix some issues, even though there is
legitimate use for these ports.
>
> So if you're blocking these ports, it seems like a small step to block
UDP/TCP/53 towards customers as well. I can't come up with an argument
that makes sense to block TCP/25 and then not block port UDP/TCP/53 as
well. If you're protecting the Internet from your customers
misconfiguraiton by blocking port 25 and the MS ports, why not 53 as well?
>
> This is a slippery slope of course, and judgement calls are not easy to
make.
>
> --
> Mikael Abrahamsson email: swmike@swm.pp.se<mailto:swmike@swm.pp.se>
