Re: Thank you, Comcast.

[Mike Hammett <nanog () ics-il net>]

*yawn* I expected this from the news sites selling page views, not NANOG where people are supposed to actually know how 
things work. 




----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

----- Original Message -----

From: "Keith Medcalf" <kmedcalf () dessus com> 
To: "NANOG list" <nanog () nanog org> 
Sent: Friday, February 26, 2016 8:31:47 AM 
Subject: RE: Thank you, Comcast. 


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