nanog mailing list archives
RE: Thank you, Comcast.
From: "Keith Medcalf" <kmedcalf () dessus com>
Date: Fri, 26 Feb 2016 07:31:47 -0700
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, MaxOn 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 dstport = 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 ornot.http://www.bitag.org/documents/Port-Blocking.pdf This mentions on page 3.1, TCP(UDP)/25,135,139 and 445. They've beenblocked 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 blockUDP/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 tomake.-- Mikael Abrahamsson email: swmike () swm pp se
Current thread:
- Re: Thank you, Comcast., (continued)
- Re: Thank you, Comcast. Mikael Abrahamsson (Feb 26)
- Re: Thank you, Comcast. Maxwell Cole (Feb 26)
- Re: Thank you, Comcast. Jared Mauch (Feb 26)
- Re: Thank you, Comcast. Damian Menscher via NANOG (Feb 26)
- Re: Thank you, Comcast. Roland Dobbins (Feb 26)
- Re: Thank you, Comcast. Dovid Bender (Feb 26)
- Re: Thank you, Comcast. Jared Mauch (Feb 26)
- Re: Thank you, Comcast. Damian Menscher via NANOG (Feb 26)
- Re: Thank you, Comcast. Dovid Bender (Feb 26)
- Re[2]: Thank you, Comcast. Adam (Feb 26)
- RE: Thank you, Comcast. Keith Medcalf (Feb 26)
- Re: Thank you, Comcast. Livingood, Jason (Feb 26)
- RE: Thank you, Comcast. Keith Medcalf (Feb 26)
- Re: Thank you, Comcast. Mike Hammett (Feb 26)
- RE: Thank you, Comcast. Naslund, Steve (Feb 26)
- RE: Thank you, Comcast. Keith Medcalf (Feb 26)
- Re: Thank you, Comcast. Mike Hammett (Feb 26)
- RE: Thank you, Comcast. Keith Medcalf (Feb 26)
- Re: Thank you, Comcast. Rich Kulawiec (Feb 27)
- Re: Thank you, Comcast. Mike Hammett (Feb 27)
- Re: Thank you, Comcast. Rich Kulawiec (Feb 26)