Thank you, Comcast.

Fri Feb 26 15:12:43 UTC 2016

FWIW, Comcast's list of blocked ports is at http://customer.xfinity.com/help-and-support/internet/list-of-blocked-ports/. The suspensions this week are 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 list right now, and one big suggestion is SSDP. If you have any others you wish to suggest please send them to me and the guy on the cc line (Nirmal Mody).

Thanks!
Jason

On 2/26/16, 9:31 AM, "NANOG on behalf of Keith Medcalf" <nanog-bounces at nanog.org<mailto:nanog-bounces at nanog.org> on behalf of kmedcalf at dessus.com<mailto:kmedcalf at dessus.com>> wrote:

ISP's should block nothing, to or from the customer, unless they make it clear *before* selling the service (and include it in the Terms and Conditions of Service Contract), that they are not selling an Internet connection but are selling a partially functional Internet connection (or a limited Internet 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 at 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 at swm.pp.se<mailto:swmike at swm.pp.se>>
wrote:
>
> On Fri, 26 Feb 2016, Nick Hilliard wrote:
>
>> Traffic from dns-spoofing attacks generally has src port = 53 and dst
port = random.  If you block packets with udp src port=53 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 at swm.pp.se<mailto:swmike at swm.pp.se>