Re: Thank you, Comcast.

[David Bass <davidbass570 () gmail com>]

I agree with this...from a customer perspective.  I've seen ISPs block other traffic as well...even on "business" 
accounts, and break their customers networks.  

It's the Internet not a private network...

I've never been a typical user though...maybe one of the "dozen" Mike refers to that runs a email server, web server, 
dns server, etc, etc, etc out of their house. 

> On Feb 26, 2016, at 9:31 AM, Keith Medcalf <kmedcalf () 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 () 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>
> > > 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 () swm pp se