[187790] in North American Network Operators' Group
Re: Thank you, Comcast.
daemon@ATHENA.MIT.EDU (Mike Hammett)
Fri Feb 26 10:20:12 2016
X-Original-To: nanog@nanog.org
Date: Fri, 26 Feb 2016 09:14:19 -0600 (CST)
From: Mike Hammett <nanog@ics-il.net>
Cc: NANOG list <nanog@nanog.org>
In-Reply-To: <df93d62ef8e6cb4db2e0fd81f856cac1@mail.dessus.com>
Errors-To: nanog-bounces@nanog.org
*yawn* I expected this from the news sites selling page views, not NANOG wh=
ere people are supposed to actually know how things work.=20
-----=20
Mike Hammett=20
Intelligent Computing Solutions=20
http://www.ics-il.com=20
Midwest-IX=20
http://www.midwest-ix.com=20
----- Original Message -----
From: "Keith Medcalf" <kmedcalf@dessus.com>=20
To: "NANOG list" <nanog@nanog.org>=20
Sent: Friday, February 26, 2016 8:31:47 AM=20
Subject: RE: Thank you, Comcast.=20
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.=
=20
Deficiencies may include:=20
port/protocol blockage toward the customer (destination blocks)=20
port/protocol blockage toward the internet (source blocks)=20
DNS diddling (filtering of responses, NXDOMAIN redirection/wildcards, etc)=
=20
Traffic Shaping/Policing/Congestion policies, inbound and outbound=20
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.=20
> -----Original Message-----=20
> From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Maxwell Cole=20
> Sent: Friday, 26 February, 2016 07:19=20
> To: Mikael Abrahamsson=20
> Cc: NANOG list=20
> Subject: Re: Thank you, Comcast.=20
>=20
> I agree,=20
>=20
> At the very least things like SNMP/NTP should be blocked. I mean how many=
=20
> people actually run a legit NTP server out of their home? Dozens? And the=
=20
> people who run SNMP devices with the default/common communities aren=E2=
=80=99t the=20
> ones using it.=20
>=20
> If the argument is that you need a Business class account to run a mail=
=20
> server then I have no problem extending that to DNS servers also.=20
>=20
> Cheers,=20
> Max=20
>=20
> > On Feb 26, 2016, at 8:55 AM, Mikael Abrahamsson <swmike@swm.pp.se>=20
> wrote:=20
> >=20
> > On Fri, 26 Feb 2016, Nick Hilliard wrote:=20
> >=20
> >> Traffic from dns-spoofing attacks generally has src port =3D 53 and ds=
t=20
> port =3D random. If you block packets with udp src port=3D53 towards=20
> customers, you will also block legitimate return traffic if the customers=
=20
> run their own DNS servers or use opendns / google dns / etc.=20
> >=20
> > Sure, it's a very interesting discussion what ports should be blocked o=
r=20
> not.=20
> >=20
> > http://www.bitag.org/documents/Port-Blocking.pdf=20
> >=20
> > This mentions on page 3.1, TCP(UDP)/25,135,139 and 445. They've been=20
> blocked for a very long time to fix some issues, even though there is=20
> legitimate use for these ports.=20
> >=20
> > So if you're blocking these ports, it seems like a small step to block=
=20
> UDP/TCP/53 towards customers as well. I can't come up with an argument=20
> that makes sense to block TCP/25 and then not block port UDP/TCP/53 as=20
> well. If you're protecting the Internet from your customers=20
> misconfiguraiton by blocking port 25 and the MS ports, why not 53 as well=
?=20
> >=20
> > This is a slippery slope of course, and judgement calls are not easy to=
=20
> make.=20
> >=20
> > --=20
> > Mikael Abrahamsson email: swmike@swm.pp.se=20
