Re: Thank you, Comcast.

[Jay R. Ashworth]

- Original Message -
> From: "Mike Hammett" 

> I think you'd be hard pressed to find more than a tenth of a percent of people
> attempt to run their own DNS server. Some do because they think it'll be 
> better
> in some way. Rare is the occasion where anything user configured would
> outperform a local DNS server managed by the ISP that does no form of 
> trickery.

I suspect it's higher than that, because of the fraction of edge routers which
do DNS masquerading.  Since that caches, I'm assuming it's a recursor, rather
than merely a pass-through, though I suppose it might be implementation 
dependent.

And *most* eyeball customer resolver servers engage in search stupidity now,
don't they? :-)

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

Re: Thank you, Comcast. (aka patch your D-Link gear)

[Scott Weeks]

--- jason_living...@comcast.com wrote:

As noted last week we're ...


Thank you for sharing this and all the other stuff over 
the years with the NANOG community.

scott

Re: Thank you, Comcast. (aka patch your D-Link gear)

[Livingood, Jason]

As a followup to this issue, and looking specifically at SSDP abuse (not the 
DNS amplification noted in the 1st email), one point of commonality we have 
identified in many customers is a D-Link device (range of different models). If 
you or someone you know uses a D-Link device, please see this page as you may 
need to upgrade your firmware: 
http://support.dlink.ca/FAQView.aspx?f=sY5vcvfAuAV6bXgi%2F8WoVw%3D%3D

As noted last week we're continuing to examine whether / how / when to update 
our blocked port list.

Jason / Comcast

Re: Thank you, Comcast.

[Mike Hammett]

I'm fairly certainly we'll never agree., so might as well end it now. 




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

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

- Original Message -

From: "Rich Kulawiec" <r...@gsp.org> 
To: nanog@nanog.org 
Sent: Saturday, February 27, 2016 7:07:04 AM 
Subject: Re: Thank you, Comcast. 

On Fri, Feb 26, 2016 at 07:21:04PM -0600, Mike Hammett wrote: 
> So we have people saying that blocking residential users from hosting 
> DNS servers is not really providing Internet service. Now we have people 
> saying it isn't service if it doesn't (more or less) completely work 
> in lynx. 

Actually, nobody is saying that, but: there is zero reason why that page 
shouldn't work in a text-only browser like lynx or w3m. It conveys technical 
information of importance to current and prospective users of the service. 
It *should* comply with the ADA and other accessability standards, and one 
well-known baseline way to (at minimum) take a vague step in that direction 
is to ensure that it's reasable (and navigable) in a text-only browser. 

There's also zero reason why that page should require Javascript, 
plugins (especially obsolete and dangerous plugins like Flash), or why 
it should utilize advertising, trackers, and malicious third-party sites, 
or why it should be horribly bloated with useless junk. 

The problem here is not the people who choose to use browsers and browser 
configurations set for security and privacy. The problem is the 
jerks who published important information in a cesspool. 

---rsk 

Re: Thank you, Comcast.

[Rich Kulawiec]

On Fri, Feb 26, 2016 at 07:21:04PM -0600, Mike Hammett wrote:
> So we have people saying that blocking residential users from hosting
> DNS servers is not really providing Internet service. Now we have people
> saying it isn't service if it doesn't (more or less) completely work
> in lynx.

Actually, nobody is saying that, but: there is zero reason why that page
shouldn't work in a text-only browser like lynx or w3m.  It conveys technical
information of importance to current and prospective users of the service.
It *should* comply with the ADA and other accessability standards, and one
well-known baseline way to (at minimum) take a vague step in that direction
is to ensure that it's reasable (and navigable) in a text-only browser.

There's also zero reason why that page should require Javascript,
plugins (especially obsolete and dangerous plugins like Flash), or why
it should utilize advertising, trackers, and malicious third-party sites,
or why it should be horribly bloated with useless junk.

The problem here is not the people who choose to use browsers and browser
configurations set for security and privacy.   The problem is the
jerks who published important information in a cesspool.

---rsk

RE: Thank you, Comcast.

[Keith Medcalf]

Who said that?  Of course, it is almost impossible to do anything malicious 
with lynx as the browser.

Why you need to run scripts from google, adobe, and a myriad of other sources 
(including not less than 3 third party malvertizing sites, 6 tracking sites, 
and 2 miscellaneous known-malicious content sites is beyond me.

It is downright disgusting that your page requires that such malicious sh*t be 
allowed free reign in order to view your web pages (which would be more 
properly known as infection pages).

Of course, you might also be requiring Flash or some other dildo-ass plugin as 
well, all of which will not run because I do not permit them to run without 
permission (in fact, the blocking is so damn good that you will be unable to 
detect whether those facilities exist or not).


> Now we have people
> saying it isn't service if it doesn't (more or less) completely work in
> lynx.
>
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> - Original Message -
>
> From: "Keith Medcalf" <kmedc...@dessus.com>
> To: "NANOG list" <nanog@nanog.org>
> Sent: Friday, February 26, 2016 6:59:28 PM
> Subject: RE: Thank you, Comcast.
>
>
> The default configuration of IE (all versions), Firefox (all versions),
> Edge (all versions) and Chrome (all versions) is a zero-security
> configuration. Of course it works fine in a zero-security configuration --
> I said that from the get go.
>
> It does not work if you do not permit javascript to run unless approved,
> and do not permit unapproved (and unapprovable scripts from third-party
> sites of unknown provenance) to run. It does not work if you block cross-
> site access to widgets and crap coming from third-parties of equally
> unknown provenance.
>
> I do not know what it is looking for, but it cannot do that, so therefore
> it does not work.
>
> You may not care about how insecure your browser is -- I do.
>
> > -Original Message-----
> > From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Naslund, Steve
> > Sent: Friday, 26 February, 2016 10:11
> > To: NANOG list
> > Subject: RE: Thank you, Comcast.
> >
> > Also worked fine in IE 11 and Firefox. I didn't change any particular
> > security settings either. Might want to check your stuff before you rant
> > on someone's web site.
> >
> > Steven Naslund
> > Chicago IL
> >
> > -Original Message-
> > From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Mike Hammett
> > Sent: Friday, February 26, 2016 10:01 AM
> > To: NANOG list
> > Subject: Re: Thank you, Comcast.
> >
> > Works fine on a default Chrome installation. *shrugs*
> >
> >
> >
> >
> > -
> > Mike Hammett
> > Intelligent Computing Solutions
> > http://www.ics-il.com
> >
> > Midwest-IX
> > http://www.midwest-ix.com
> >
> > - Original Message -
> >
> > From: "Keith Medcalf" <kmedc...@dessus.com>
> > To: "NANOG list" <nanog@nanog.org>
> > Cc: "Nirmal Mody" <nirmal_m...@cable.comcast.com>
> > Sent: Friday, February 26, 2016 9:55:20 AM
> > Subject: RE: Thank you, Comcast.
> >
> >
> > On Friday, 26 February, 2016 08:13, jason_living...@comcast.com said:
> >
> > > 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.
> >
> > God is that a horrid web page. I cannot view it. The wheels on the bus
> go
> > round and round non-stop.
> >
> > It has so much intertwined malicious javascript, cross-site scripting,
> and
> > malicious trackers that the alarm klaxons go off when I attempt to
> access
> > it. I spent a couple of minutes attempting to access the page but still
> > maintaining blocks to the malicious links. Apparently, viewing the page
> > requires that all security be turned off and that the viewer allows
> > completely untrusted code from completely untrustworty sources to run
> > unabated on the viewers computer.
> >
> > I do not permit this. For anyone. Ever.
> >
> > This pretty much ensures that I would never be one of your customers. If
> > you cannot operate a server which serves renderable non-malicious web
> > pages properly, what hope is there that you can do anything else right?
> >
> > > W

Re: Thank you, Comcast.

[Mike Hammett]

So we have people saying that blocking residential users from hosting DNS 
servers is not really providing Internet service. Now we have people saying it 
isn't service if it doesn't (more or less) completely work in lynx. 




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

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

- Original Message -

From: "Keith Medcalf" <kmedc...@dessus.com> 
To: "NANOG list" <nanog@nanog.org> 
Sent: Friday, February 26, 2016 6:59:28 PM 
Subject: RE: Thank you, Comcast. 


The default configuration of IE (all versions), Firefox (all versions), Edge 
(all versions) and Chrome (all versions) is a zero-security configuration. Of 
course it works fine in a zero-security configuration -- I said that from the 
get go. 

It does not work if you do not permit javascript to run unless approved, and do 
not permit unapproved (and unapprovable scripts from third-party sites of 
unknown provenance) to run. It does not work if you block cross-site access to 
widgets and crap coming from third-parties of equally unknown provenance. 

I do not know what it is looking for, but it cannot do that, so therefore it 
does not work. 

You may not care about how insecure your browser is -- I do. 

> -Original Message- 
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Naslund, Steve 
> Sent: Friday, 26 February, 2016 10:11 
> To: NANOG list 
> Subject: RE: Thank you, Comcast. 
> 
> Also worked fine in IE 11 and Firefox. I didn't change any particular 
> security settings either. Might want to check your stuff before you rant 
> on someone's web site. 
> 
> Steven Naslund 
> Chicago IL 
> 
> -Original Message- 
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Mike Hammett 
> Sent: Friday, February 26, 2016 10:01 AM 
> To: NANOG list 
> Subject: Re: Thank you, Comcast. 
> 
> Works fine on a default Chrome installation. *shrugs* 
> 
> 
> 
> 
> - 
> Mike Hammett 
> Intelligent Computing Solutions 
> http://www.ics-il.com 
> 
> Midwest-IX 
> http://www.midwest-ix.com 
> 
> - Original Message - 
> 
> From: "Keith Medcalf" <kmedc...@dessus.com> 
> To: "NANOG list" <nanog@nanog.org> 
> Cc: "Nirmal Mody" <nirmal_m...@cable.comcast.com> 
> Sent: Friday, February 26, 2016 9:55:20 AM 
> Subject: RE: Thank you, Comcast. 
> 
> 
> On Friday, 26 February, 2016 08:13, jason_living...@comcast.com said: 
> 
> > 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. 
> 
> God is that a horrid web page. I cannot view it. The wheels on the bus go 
> round and round non-stop. 
> 
> It has so much intertwined malicious javascript, cross-site scripting, and 
> malicious trackers that the alarm klaxons go off when I attempt to access 
> it. I spent a couple of minutes attempting to access the page but still 
> maintaining blocks to the malicious links. Apparently, viewing the page 
> requires that all security be turned off and that the viewer allows 
> completely untrusted code from completely untrustworty sources to run 
> unabated on the viewers computer. 
> 
> I do not permit this. For anyone. Ever. 
> 
> This pretty much ensures that I would never be one of your customers. If 
> you cannot operate a server which serves renderable non-malicious web 
> pages properly, what hope is there that you can do anything else right? 
> 
> > 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). 
> 
> > On 2/26/16, 9:31 AM, "NANOG on behalf of Keith Medcalf"  > boun...@nanog.org on behalf of kmedc...@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 response

Re: Thank you, Comcast.

[Roland Dobbins]

On 27 Feb 2016, at 8:06, Keith Medcalf wrote:


Consumer Narrowband Access Networks use these protocols all the time.


Most broadband access customers do not actively use these protocols, 
themselves, with the partial exception of SIP.


---
Roland Dobbins 

RE: Thank you, Comcast.

[Keith Medcalf]

Really?  Consumer Narrowband Access Networks use these protocols all the time. 
(I call them narrowband since that is what they are -- even though the common 
euphamism is broadband, "broad" it certainly is not).

> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Roland Dobbins
> Sent: Friday, 26 February, 2016 10:55
> To: NANOG list
> Subject: Re: Thank you, Comcast.
>
> On 26 Feb 2016, at 22:52, Jay Nugent wrote:
>
> >Customers regularly use various VPN protocols from GRE, SIT, and
> > IPIP, monitoring protocols such as SNMP, as well as RTP and SIP (where
> > we spend the bulk of our time troubleshooting).
>
> Not so on consumer broadband access networks, which are what's being
> discussed in this thread.
>
> It's a different story for transit operators.
>
> ---
> Roland Dobbins <rdobb...@arbor.net>

Re: Thank you, Comcast.

[Roland Dobbins]

On 27 Feb 2016, at 7:59, John Levine wrote:

I think that most if not all of the consumer over the top VoIP phones 
like Vonage use SIP.


That's true.  One would hope that they're not globally reachable, 
however.


---
Roland Dobbins 

Re: Thank you, Comcast.

[John Levine]

>True, but how prevalent are 'bare' SIP phones vs. VoIP systems utilized 
>by remote workers via VPNs?

Dunno, but I have two of them.  I think that most if not all of the
consumer over the top VoIP phones like Vonage use SIP.

R's,
John

RE: Thank you, Comcast.

[Keith Medcalf]

The default configuration of IE (all versions), Firefox (all versions), Edge 
(all versions) and Chrome (all versions) is a zero-security configuration.  Of 
course it works fine in a zero-security configuration -- I said that from the 
get go.

It does not work if you do not permit javascript to run unless approved, and do 
not permit unapproved (and unapprovable scripts from third-party sites of 
unknown provenance) to run.  It does not work if you block cross-site access to 
widgets and crap coming from third-parties of equally unknown provenance.

I do not know what it is looking for, but it cannot do that, so therefore it 
does not work.

You may not care about how insecure your browser is -- I do.

> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Naslund, Steve
> Sent: Friday, 26 February, 2016 10:11
> To: NANOG list
> Subject: RE: Thank you, Comcast.
>
> Also worked fine in IE 11 and Firefox.  I didn't change any particular
> security settings either.  Might want to check your stuff before you rant
> on someone's web site.
>
> Steven Naslund
> Chicago IL
>
> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Mike Hammett
> Sent: Friday, February 26, 2016 10:01 AM
> To: NANOG list
> Subject: Re: Thank you, Comcast.
>
> Works fine on a default Chrome installation. *shrugs*
>
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> - Original Message -
>
> From: "Keith Medcalf" <kmedc...@dessus.com>
> To: "NANOG list" <nanog@nanog.org>
> Cc: "Nirmal Mody" <nirmal_m...@cable.comcast.com>
> Sent: Friday, February 26, 2016 9:55:20 AM
> Subject: RE: Thank you, Comcast.
>
>
> On Friday, 26 February, 2016 08:13, jason_living...@comcast.com said:
>
> > 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.
>
> God is that a horrid web page. I cannot view it. The wheels on the bus go
> round and round non-stop.
>
> It has so much intertwined malicious javascript, cross-site scripting, and
> malicious trackers that the alarm klaxons go off when I attempt to access
> it. I spent a couple of minutes attempting to access the page but still
> maintaining blocks to the malicious links. Apparently, viewing the page
> requires that all security be turned off and that the viewer allows
> completely untrusted code from completely untrustworty sources to run
> unabated on the viewers computer.
>
> I do not permit this. For anyone. Ever.
>
> This pretty much ensures that I would never be one of your customers. If
> you cannot operate a server which serves renderable non-malicious web
> pages properly, what hope is there that you can do anything else right?
>
> > 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).
>
> > On 2/26/16, 9:31 AM, "NANOG on behalf of Keith Medcalf"  > boun...@nanog.org on behalf of kmedc...@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-boun...@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
&

Re: Thank you, Comcast.

[Roland Dobbins]

On 27 Feb 2016, at 7:23, John Levine wrote:


The VoIP phones sure use SIP.


True, but how prevalent are 'bare' SIP phones vs. VoIP systems utilized 
by remote workers via VPNs?


---
Roland Dobbins 

Re: Thank you, Comcast.

[John Levine]

>> A certain number of us work from home and connect to headquarters with 
>> a VPN. and have SIP phones, you know.
>
>Not typically via/requiring the protocols you mentioned.

The VoIP phones sure use SIP.

R's,
John

Re: Thank you, Comcast.

[Roland Dobbins]

On 27 Feb 2016, at 4:03, John Levine wrote:

A certain number of us work from home and connect to headquarters with 
a VPN. and have SIP phones, you know.


Not typically via/requiring the protocols you mentioned.

---
Roland Dobbins 

Re: Thank you, Comcast.

[Brielle Bruns]

On 2/26/16 1:08 PM, Rich Kulawiec wrote:

On Fri, Feb 26, 2016 at 10:16:33AM -0700, Brielle Bruns wrote:

You can't do anything about idiots buying a pro-sumer/professional
device like an EdgeRouter and misconfiguring it, but Linksys/Cisco,
D-Link, Netgear, etc that are targeted towards home users should be
held to the fire for that kind of screw up.


That is starting to happen:

FTC Dings ASUS For Selling 'Secure' Routers That Shipped With Default 
Admin/Admin Login (And Other Flaws)

https://www.techdirt.com/articles/20160223/11103133687/ftc-dings-asus-selling-secure-routers-that-shipped-with-default-admin-admin-login-other-flaws.shtml

---rsk




It looks like they nailed ASUS due to it claiming to be 'secure'.

I don't have a problem per-se with default passwords being used on a new 
device that requires configuration before it actually works and isn't 
marketed to the ignorant end user.


IE:  (again my experience with Ubiquiti stuff being a baseline) The 
EdgeRouter series is power user/professional targeted, default 
passwords, however it does not come 'pre-configured', can't route, can't 
NAT, etc without some initial setup.


Cisco's non-consumer stuff like the Cat6500, etc having no password by 
default doesn't bug me because the thing is useless until you actually 
configure it.


Its all about the market you are targeting IMHO.

--
Brielle Bruns
The Summit Open Source Development Group
http://www.sosdg.org/ http://www.ahbl.org

Re: Thank you, Comcast.

[John Levine]

>The difference in blocking any of the existing ports on your list and 
>blocking UDP/1900 is that the ports on your list are all registered 
>ports. Port 1900 is not registered -

IANA is under the impression it's registered for SSDP.  Do you have
some reason to believe they're mistaken?

http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?=34

Re: Thank you, Comcast.

[John Levine]

>>Customers regularly use various VPN protocols from GRE, SIT, and 
>> IPIP, monitoring protocols such as SNMP, as well as RTP and SIP (where 
>> we spend the bulk of our time troubleshooting).
>
>Not so on consumer broadband access networks, which are what's being 
>discussed in this thread.

A certain number of us work from home and connect to headquarters with
a VPN. and have SIP phones, you know.  Not just meganerds.

R's,
John

Re: Thank you, Comcast.

[Dovid Bender]

Lawsuits? There is no reason the dedicated server I have with a 100meg pipe for 
$65.00 per month is able to spoof IP's. The colo's should be doing a better job 
to lock this down.

Regards,

Dovid

-Original Message-
From: Damian Menscher <dam...@google.com>
Date: Fri, 26 Feb 2016 11:47:43 
To: Dovid B<do...@telecurve.com>
Cc: Jared Mauch<ja...@puck.nether.net>; Jason 
Livingood<jason_living...@cable.comcast.com>; Mody, 
Nirmal<nirmal_m...@cable.comcast.com>; NANOG list<nanog@nanog.org>
Subject: Re: Thank you, Comcast.

"We all know..." followed by a false statement is amusing.

A significant portion of spoofing originates from North America.  In a
recent attack I'm reviewing, the top sources of spoofing were the
southwestern US, the northwestern US, and east Asia (and almost none from
Europe).

If ISPs understood how to collect and review netflow we might get
somewhere... why is this so hard, and how do we fix it?

Damian

On Fri, Feb 26, 2016 at 10:48 AM, Dovid Bender <do...@telecurve.com> wrote:

> We all know what countries this traffic is coming from. While you can
> threaten the local ISP's the ones over seas where the traffic is coming
> from won't care.
>
> Regards,
>
> Dovid
>
> -Original Message-
> From: Damian Menscher via NANOG <nanog@nanog.org>
> Sender: "NANOG" <nanog-boun...@nanog.org>Date: Fri, 26 Feb 2016 08:02:52
> To: Jared Mauch<ja...@puck.nether.net>; Jason Livingood<
> jason_living...@cable.comcast.com>; Mody, Nirmal<
> nirmal_m...@cable.comcast.com>
> Reply-To: Damian Menscher <dam...@google.com>
> Cc: NANOG list<nanog@nanog.org>
> Subject: Re: Thank you, Comcast.
>
> On Fri, Feb 26, 2016 at 6:28 AM, Jared Mauch <ja...@puck.nether.net>
> wrote:
>
> > As a community we need to determine if this background radiation and
> these
> > responses are proper. I think it's a good response since vendors can't do
> > uRPF at line rate and the major purchasers of BCM switches don't ask for
> it
> > and aren't doing it, so it's not optimized or does not exist. /sigh
> >
>
> I don't agree with the approach of going after individual reflectors
> (open*project) or blocking specific ports (Comcast's action here) as both
> are reactive, unlikely to be particularly effective (there are still
> millions of reflectors and plenty of open ports available), and don't solve
> the root problem (spoofed packets making it onto the public internet).
> What I'd much rather see Comcast do is use their netflow to trace the
> source of the spoofed packets (one of their peers or transit providers, no
> doubt) and strongly encourage (using their legal or PR team as needed) them
> to trace back and stop the spoofing.  This benefits everyone in a much more
> direct and scalable way.  Until some of the larger providers start doing
> that, amplification attacks and other spoofed-source attacks (DNS and
> synfloods) will continue to thrive.
>
> (I've contacted several ISPs about the spoofed traffic they send to us.
> The next major hurdle is that so many don't have netflow or other useful
> monitoring of their networks)
>
> Damian
>

Re: Thank you, Comcast.

[Rich Kulawiec]

On Fri, Feb 26, 2016 at 10:16:33AM -0700, Brielle Bruns wrote:
> You can't do anything about idiots buying a pro-sumer/professional
> device like an EdgeRouter and misconfiguring it, but Linksys/Cisco,
> D-Link, Netgear, etc that are targeted towards home users should be
> held to the fire for that kind of screw up.

That is starting to happen:

FTC Dings ASUS For Selling 'Secure' Routers That Shipped With Default 
Admin/Admin Login (And Other Flaws)

https://www.techdirt.com/articles/20160223/11103133687/ftc-dings-asus-selling-secure-routers-that-shipped-with-default-admin-admin-login-other-flaws.shtml

---rsk

Re: Thank you, Comcast.

[Blake Hudson]

Blake Hudson wrote on 2/26/2016 2:01 PM:


Livingood, Jason wrote on 2/26/2016 1:32 PM:
On 2/26/16, 11:44 AM, "Blake Hudson" > wrote:


Jason, how do you propose to block SSDP without also blocking
legitimate traffic as well (since SSDP uses a port > 1024 and is
used as part of the ephemeral port range on some devices) ?


As Roland suggested, very likely via UDP/1900. This will obviously be 
disclosed in advance to customers and tested thoroughly. I believe a 
few other ISPs have already taken this step.


And is this practice /Open Internet/ friendly?


Port blocking is considered a form of reasonable network management 
provided it can be justified by security or operational stability 
reasons. Of course it must also be transparently disclosed and so on.


Jason
The difference in blocking any of the existing ports on your list and 
blocking UDP/1900 is that the ports on your list are all registered 
ports. Port 1900 is not registered - a host may use port 1900 when 
making an outbound connection to another host (lookup ephemeral port 
range for more info) regardless of whether either host is using or 
running an SSDP server. A block on port 1900 will result in blocking 
legitimate customer traffic if the customer's device happened to 
select port 1900 as parts of its ephemeral port range.


To my knowledge, a current Windows, Linux, Apple device will not use 
port 1900 as part of its ephemeral port range, but Wikipedia suggests 
XP and older Windows operating systems will and I know that many NAT 
routers will (which affects all clients behind that NAT router, 
regardless of their OS). I have no idea what popular mobile clients 
use for their ephemeral port ranges. I imagine the NAT routers will be 
most common actors using ports outside of the IANA suggested ephemeral 
port range. Do you suggest that it is "reasonable network management" 
that users behind a NAT router have their 876th (1900 - 1024) UDP 
connection attempt blocked?


--Blake
Correction, I should have stated that the ports < 1024 were well-known. 
1900 is not a well-known port

Re: Thank you, Comcast.

[Blake Hudson]

Livingood, Jason wrote on 2/26/2016 1:32 PM:
On 2/26/16, 11:44 AM, "Blake Hudson" > wrote:


Jason, how do you propose to block SSDP without also blocking
legitimate traffic as well (since SSDP uses a port > 1024 and is
used as part of the ephemeral port range on some devices) ?


As Roland suggested, very likely via UDP/1900. This will obviously be 
disclosed in advance to customers and tested thoroughly. I believe a 
few other ISPs have already taken this step.


And is this practice /Open Internet/ friendly?


Port blocking is considered a form of reasonable network management 
provided it can be justified by security or operational stability 
reasons. Of course it must also be transparently disclosed and so on.


Jason
The difference in blocking any of the existing ports on your list and 
blocking UDP/1900 is that the ports on your list are all registered 
ports. Port 1900 is not registered - a host may use port 1900 when 
making an outbound connection to another host (lookup ephemeral port 
range for more info) regardless of whether either host is using or 
running an SSDP server. A block on port 1900 will result in blocking 
legitimate customer traffic if the customer's device happened to select 
port 1900 as parts of its ephemeral port range.


To my knowledge, a current Windows, Linux, Apple device will not use 
port 1900 as part of its ephemeral port range, but Wikipedia suggests XP 
and older Windows operating systems will and I know that many NAT 
routers will (which affects all clients behind that NAT router, 
regardless of their OS). I have no idea what popular mobile clients use 
for their ephemeral port ranges. I imagine the NAT routers will be most 
common actors using ports outside of the IANA suggested ephemeral port 
range. Do you suggest that it is "reasonable network management" that 
users behind a NAT router have their 876th (1900 - 1024) UDP connection 
attempt blocked?


--Blake

Re: Thank you, Comcast.

[Damian Menscher via NANOG]

"We all know..." followed by a false statement is amusing.

A significant portion of spoofing originates from North America.  In a
recent attack I'm reviewing, the top sources of spoofing were the
southwestern US, the northwestern US, and east Asia (and almost none from
Europe).

If ISPs understood how to collect and review netflow we might get
somewhere... why is this so hard, and how do we fix it?

Damian

On Fri, Feb 26, 2016 at 10:48 AM, Dovid Bender <do...@telecurve.com> wrote:

> We all know what countries this traffic is coming from. While you can
> threaten the local ISP's the ones over seas where the traffic is coming
> from won't care.
>
> Regards,
>
> Dovid
>
> -Original Message-
> From: Damian Menscher via NANOG <nanog@nanog.org>
> Sender: "NANOG" <nanog-boun...@nanog.org>Date: Fri, 26 Feb 2016 08:02:52
> To: Jared Mauch<ja...@puck.nether.net>; Jason Livingood<
> jason_living...@cable.comcast.com>; Mody, Nirmal<
> nirmal_m...@cable.comcast.com>
> Reply-To: Damian Menscher <dam...@google.com>
> Cc: NANOG list<nanog@nanog.org>
> Subject: Re: Thank you, Comcast.
>
> On Fri, Feb 26, 2016 at 6:28 AM, Jared Mauch <ja...@puck.nether.net>
> wrote:
>
> > As a community we need to determine if this background radiation and
> these
> > responses are proper. I think it's a good response since vendors can't do
> > uRPF at line rate and the major purchasers of BCM switches don't ask for
> it
> > and aren't doing it, so it's not optimized or does not exist. /sigh
> >
>
> I don't agree with the approach of going after individual reflectors
> (open*project) or blocking specific ports (Comcast's action here) as both
> are reactive, unlikely to be particularly effective (there are still
> millions of reflectors and plenty of open ports available), and don't solve
> the root problem (spoofed packets making it onto the public internet).
> What I'd much rather see Comcast do is use their netflow to trace the
> source of the spoofed packets (one of their peers or transit providers, no
> doubt) and strongly encourage (using their legal or PR team as needed) them
> to trace back and stop the spoofing.  This benefits everyone in a much more
> direct and scalable way.  Until some of the larger providers start doing
> that, amplification attacks and other spoofed-source attacks (DNS and
> synfloods) will continue to thrive.
>
> (I've contacted several ISPs about the spoofed traffic they send to us.
> The next major hurdle is that so many don't have netflow or other useful
> monitoring of their networks)
>
> Damian
>

Consumer Equipment Sucks (Re: Thank you, Comcast.)

[Jared Mauch]

> On Feb 26, 2016, at 2:28 PM, Livingood, Jason  
> wrote:
> 
> I think the bigger culprit is not the stuff ISPs buy but what consumers
> buy (aka COAM).

I’m certainly not a comcast apologist, (I do wish they would service the 
communities where they had their call centers, like here in the unserved parts 
of their Scio Township call center).

But Jason is spot-on here.  There are clear scale problems when dealing with 
large numbers of customers, and no matter what some of them will use crap 
equipment.

We as an the techies in industry often “just fix it” for our 
friends/parents/colleagues.  I am an enabler of CGN as I often help a local 
WISP with their environment when they should be doing IPv6 or something else.  
Often people are willing to leave as a customer because their device which gets 
no firmware updates blocks valid DNS requests or has some other problem.

These items are shipped freight 6 months in advance from someplace like 
Shenzhen and never updated, then when they don’t work, customers who don’t 
understand RF propagation issues, why running a cable through the wall is 
better, etc.. end up ditching because of the $200 gift card offered for 8 hours 
of time waiting for an installation appointment in 2 years.

These incentives are all wrong in the marketplace, we need better equipment, 
better people and better responses to the issues.

We all have committed various technical sins, I’m not immune, nor is Comcast or 
likely most people on the list.  This thread was started because Comcast and 
the teams led by Michael actually worked to remediate abusive customer 
equipment that wasn’t their fault.

As we continue to connect devices to the network, the ability to do this type 
of remediation is essential.  If you don’t believe me, look at the recent 
settlement with ASUS 
(http://arstechnica.com/security/2016/02/asus-lawsuit-puts-entire-industry-on-notice-over-shoddy-router-security/)
  or this twitter account - http://tinyurl.com/p6tfh8d where things are 
comically documented.  (Short URL as it uses a profane term that some systems 
may filter).

- Jared

Re: Thank you, Comcast.

[Livingood, Jason]

On 2/26/16, 11:44 AM, "Blake Hudson" > 
wrote:
Jason, how do you propose to block SSDP without also blocking legitimate 
traffic as well (since SSDP uses a port > 1024 and is used as part of the 
ephemeral port range on some devices) ?

As Roland suggested, very likely via UDP/1900. This will obviously be disclosed 
in advance to customers and tested thoroughly. I believe a few other ISPs have 
already taken this step.

And is this practice Open Internet friendly?

Port blocking is considered a form of reasonable network management provided it 
can be justified by security or operational stability reasons. Of course it 
must also be transparently disclosed and so on.

Jason

Re: Thank you, Comcast.

[Livingood, Jason]

On 2/26/16, 12:33 PM, "NANOG on behalf of Octavio Alvarez"
 wrote:


>On 26/02/16 09:16, Brielle Bruns wrote:
>> Place the blame for local resolvers listening on WAN squarely where it
>>belongs - the router vendors who make these devices.
>
>As long as ISPs massively buy crappy hardware pieces, vendors will make
>them and sell them. That's how it works.

I think the bigger culprit is not the stuff ISPs buy but what consumers
buy (aka COAM).

Jason

Re: Thank you, Comcast.

[Brielle Bruns]

On 2/26/16 10:22 AM, Mike Hammett wrote:

Said in a forum comprised largely of ISPs? Bold move.



I appreciate the work the technical people here do, but doesn't change 
the fact that the people who call the shots aren't always on the same 
page or have the same goals as do the technical people.


I don't work for ISPs anymore like I did in my early career, but my 
experiences from back then burned quite a bit into my brain.


So, sorry if anyone feels slighted by what I said, but
honesty hurts. Dancing around the truth does no one any good.


--
Brielle Bruns
The Summit Open Source Development Group
http://www.sosdg.org/ http://www.ahbl.org

Re: Thank you, Comcast.

[John Kristoff]

On Fri, 26 Feb 2016 07:20:28 +0100 (CET)
Mikael Abrahamsson  wrote:

> I know historically there were resolvers that used UDP/53 as source
> port for queries, but is this the case nowadays?

Empirically from what I've observed, much less than there once was.
Looking at a sample of a few thousand queries on a server set I can
see, I don't need much more than what two hands can count.

I still see the occasional ISP name server, probably having been around
forever and perhaps locked in with the query-source option in BIND.
You also see what is probably as a result of some local oddball policy,
making something easier, such as the queries *.labs.rapid7.com (hi guys)
like to issue for things like VERSION.BIND CH TXT.

John

Re: Thank you, Comcast.

[Dovid Bender]

This is one of my pet peeves. Another is default passwords for devices. Kudo to 
TP-Link for not shipping devices with default passwords.


Regards,

Dovid

-Original Message-
From: Brielle Bruns <br...@2mbit.com>
Sender: "NANOG" <nanog-boun...@nanog.org>Date: Fri, 26 Feb 2016 10:16:33 
To: <nanog@nanog.org>
Subject: Re: Thank you, Comcast.

On 2/26/16 10:02 AM, Chris Adams wrote:
>>
>> Except that half the time people run their own DNS resolvers because
>> their provider's resolvers are
>
> Resolver != authoritative server.  Your local DNS resolver doesn't need
> to be (and should not be) listening to port 53 on the Internet.  Only
> DNS authoritative servers need to accept Internet traffic on port 53,
> and almost nobody needs to be running one on a typical residential
> connection (especially since residential IPs do change from time to
> time).
>

UDP is a fun protocol - stateless, so blocking a DST of 53/UDP to the 
customer also will block responses to recursive queries that originate 
from SRC 53/UDP.  Connection tracking sorta makes it stateful to a 
point, but it can get ugly with enough traffic.

Place the blame for local resolvers listening on WAN squarely where it 
belongs - the router vendors who make these devices.

You can't do anything about idiots buying a pro-sumer/professional 
device like an EdgeRouter and misconfiguring it, but Linksys/Cisco, 
D-Link, Netgear, etc that are targeted towards home users should be held 
to the fire for that kind of screw up.

-- 
Brielle Bruns
The Summit Open Source Development Group
http://www.sosdg.org/ http://www.ahbl.org

Re: Thank you, Comcast.

[Jared Mauch]

Disconnecting the US isn’t a viable solution.

> On Feb 26, 2016, at 1:48 PM, Dovid Bender  wrote:
> 
> We all know what countries this traffic is coming from. While you can 
> threaten the local ISP's the ones over seas where the traffic is coming from 
> won't care.

Re: Thank you, Comcast.

[Valdis . Kletnieks]

On Fri, 26 Feb 2016 10:52:55 -0500, Jay Nugent said:

> However, if a 'provider' wishes to block ANYTHING, then they need to
> inform the customer IN WRITING exactly what will be blocked so that
> customer doesn't waste their time and money with said (limited) service
> and vote with their wallet by buying *real* Internet service, elsewhere.

Which is only an option in those rare places where there's actual real
competition.  In most places, it's a monopoly, or a non-functional
duopoly (Let's face it - how many users will protest a 10M cable connection
with 4 ports punched out by moving to 768K DSL?)


pgpt1ESEeGZjR.pgp
Description: PGP signature

Re: Thank you, Comcast.

[Dovid Bender]

We all know what countries this traffic is coming from. While you can threaten 
the local ISP's the ones over seas where the traffic is coming from won't care.

Regards,

Dovid

-Original Message-
From: Damian Menscher via NANOG <nanog@nanog.org>
Sender: "NANOG" <nanog-boun...@nanog.org>Date: Fri, 26 Feb 2016 08:02:52 
To: Jared Mauch<ja...@puck.nether.net>; Jason 
Livingood<jason_living...@cable.comcast.com>; Mody, 
Nirmal<nirmal_m...@cable.comcast.com>
Reply-To: Damian Menscher <dam...@google.com>
Cc: NANOG list<nanog@nanog.org>
Subject: Re: Thank you, Comcast.

On Fri, Feb 26, 2016 at 6:28 AM, Jared Mauch <ja...@puck.nether.net> wrote:

> As a community we need to determine if this background radiation and these
> responses are proper. I think it's a good response since vendors can't do
> uRPF at line rate and the major purchasers of BCM switches don't ask for it
> and aren't doing it, so it's not optimized or does not exist. /sigh
>

I don't agree with the approach of going after individual reflectors
(open*project) or blocking specific ports (Comcast's action here) as both
are reactive, unlikely to be particularly effective (there are still
millions of reflectors and plenty of open ports available), and don't solve
the root problem (spoofed packets making it onto the public internet).
What I'd much rather see Comcast do is use their netflow to trace the
source of the spoofed packets (one of their peers or transit providers, no
doubt) and strongly encourage (using their legal or PR team as needed) them
to trace back and stop the spoofing.  This benefits everyone in a much more
direct and scalable way.  Until some of the larger providers start doing
that, amplification attacks and other spoofed-source attacks (DNS and
synfloods) will continue to thrive.

(I've contacted several ISPs about the spoofed traffic they send to us.
The next major hurdle is that so many don't have netflow or other useful
monitoring of their networks)

Damian

Re: Thank you, Comcast.

[Henry Yen]

On Fri, Feb 26, 2016 at 12:17:32PM -0500, Rich Kulawiec wrote:
> On Fri, Feb 26, 2016 at 08:55:20AM -0700, Keith Medcalf wrote:
> > On Friday, 26 February, 2016 08:13, jason_living...@comcast.com said:
> > > http://customer.xfinity.com/help-and-support/internet/list-of-blocked-
> > > ports/
> > 
> > ...  I cannot view it. ...

> Agreed -- it's completely dysfunctional worthless crap.  I wonder if it
> occurred to anybody that a list of blocked ports could be published as
> a single static web page with no scripting, or better yet, as a text
> file so that it could be acquired with and used by scripts.

And also be made usable by the visually-impaired (section 508, e.g.
http://webaim.org/standards/508/checklist).

--
Henry Yen   Aegis Information Systems, Inc.
Senior Systems Programmer   Hicksville, New York

Re: Thank you, Comcast.

[Jared Mauch]

> On Feb 26, 2016, at 12:42 PM, John Levine  wrote:
> 
> Huh.  Is it 1998 again?

More like NANOG again. 

- jared 

Re: Thank you, Comcast.

[Roland Dobbins]

On 26 Feb 2016, at 22:52, Jay Nugent wrote:

   Customers regularly use various VPN protocols from GRE, SIT, and 
IPIP, monitoring protocols such as SNMP, as well as RTP and SIP (where 
we spend the bulk of our time troubleshooting).


Not so on consumer broadband access networks, which are what's being 
discussed in this thread.


It's a different story for transit operators.

---
Roland Dobbins 

Re: Thank you, Comcast.

[Roland Dobbins]

On 27 Feb 2016, at 0:25, Anthony Junk wrote:

There is so much arrogance in these posts saying that these things 
should be blocked because it's best or because it's negligible.


I think there's a lack of comprehension on the part of those who don't 
run large networks and/or who aren't responsible for maintaing network 
availability for their customer base.


Blocking or QoSing down port-pairs at the peering/transit edge is all 
too often the least worst option these operators have



Please tell me again about my need for a business connection.


Caveat emptor.

---
Roland Dobbins 

Re: Thank you, Comcast.

[John Levine]

In article  you write:
>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.

Huh.  Is it 1998 again?

R's,
John

Re: Thank you, Comcast.

[Chris Adams]

Once upon a time, Brielle Bruns  said:
> UDP is a fun protocol - stateless, so blocking a DST of 53/UDP to
> the customer also will block responses to recursive queries that
> originate from SRC 53/UDP.  Connection tracking sorta makes it
> stateful to a point, but it can get ugly with enough traffic.

Sending queries from port 53 has been considered bad behavior and
deprecated for what, 15 years now?

-- 
Chris Adams 

Re: Thank you, Comcast.

[Octavio Alvarez]

On 26/02/16 09:16, Brielle Bruns wrote:
> Place the blame for local resolvers listening on WAN squarely where it
> belongs - the router vendors who make these devices.

As long as ISPs massively buy crappy hardware pieces, vendors will make
them and sell them. That's how it works.

Best regards.

Re: Thank you, Comcast.

[Roland Dobbins]

On 27 Feb 2016, at 0:16, Brielle Bruns wrote:

You can't do anything about idiots buying a pro-sumer/professional 
device like an EdgeRouter and misconfiguring it, but Linksys/Cisco, 
D-Link, Netgear, etc that are targeted towards home users should be 
held to the fire for that kind of screw up.


Also, see this article:



and this .pdf preso:



---
Roland Dobbins 

RE: Thank you, Comcast.

[Jay Nugent]

Greetings,

On Fri, 26 Feb 2016, Keith Medcalf 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.



   I wholeheartedly agree!  When purchasing an "Internet connection", we 
expect that to be full access to the Internet.  Granted, *some* parts of 
the Internet are up/down or never available, but the *protocols* should 
*ALL* be available.


   Customers regularly use various VPN protocols from GRE, SIT, and IPIP, 
monitoring protocols such as SNMP, as well as RTP and SIP (where we spend 
the bulk of our time troubleshooting).  Customers EXPECT their packets to 
be passed unhampered.  Otherwise, all the provider is giving them is acces 
to email and to surf for porn.  That provider would simply be offering an 
"entertainment" connection to the public Internet, not full Internet 
access.


   However, if a 'provider' wishes to block ANYTHING, then they need to 
inform the customer IN WRITING exactly what will be blocked so that 
customer doesn't waste their time and money with said (limited) service 
and vote with their wallet by buying *real* Internet service, elsewhere.


  --- Jay Nugent
  Nugent Telecommunications consulting
  Ypsilanti, Michigan



-Original Message-
From: NANOG [mailto:nanog-boun...@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 <swm...@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 Abrahamssonemail: swm...@swm.pp.se








--

() ascii ribbon campaign in
/\ support of plain text e-mail

 o Averaging at least 3 days of MTBWTF!?!?!?
 o The solution for long term Internet growth is IPv6.
++
| Jay Nugent   j...@nuge.com(734)484-5105(734)649-0850/Cell   |
|   Nugent Telecommunications  [www.nuge.com]|
|   Internet Consulting/Linux SysAdmin/Engineering & Design  |
|   ISP Monitoring [www.ispmonitor.org] ISP Performance Monitoring   |
++
10:01:01 up 6 days, 20:04, 2 users, load average: 0.40, 0.54, 0.43

Re: Thank you, Comcast.

[Roland Dobbins]

On 27 Feb 2016, at 0:16, Brielle Bruns wrote:

UDP is a fun protocol - stateless, so blocking a DST of 53/UDP to the 
customer also will block responses to recursive queries that originate 
from SRC 53/UDP.


Which are relatively rare, these days.  Any device doing this by default 
is likely running out-of-date software that is abusable in multiple 
ways.


---
Roland Dobbins 

Re: Thank you, Comcast.

[Mike Hammett]

Said in a forum comprised largely of ISPs? Bold move. 




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

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

- Original Message -

From: "Brielle Bruns" <br...@2mbit.com> 
To: nanog@nanog.org 
Sent: Friday, February 26, 2016 11:09:03 AM 
Subject: Re: Thank you, Comcast. 

On 2/26/16 10:01 AM, Mike Hammett wrote: 
> They have to be honest or face litigation. Transparency is the biggest (if 
> not the only) useful thing out of the Open Internet Order. 


As long as the profit from doing shady things and lying is greater then 
the cost of settling a lawsuit, companies will be dishonest and do shady 
things. 

So, no, I don't believe threat of litigation is any barrier to how ISPs 
conduct their business. In fact, with how pro-business and 
fuck-consumer the current climate is from the govt, its just going to 
get worse. 


-- 
Brielle Bruns 
The Summit Open Source Development Group 
http://www.sosdg.org / http://www.ahbl.org 

Re: Thank you, Comcast.

[Rich Kulawiec]

On Fri, Feb 26, 2016 at 11:04:49AM -0500, Curtis Maurand wrote:
> I run my own resolver from behind my firewall at my home.  I don't
> allow incoming port 53 traffic.  I realize there's not a lot of
> privacy on the net, but I don't like having my dns queries tracked
> in order to target advertising at me and for annoying failed queries
> to end up at some annoying search page.

Likewise, and I don't like getting back forged DNS responses because
some already-bloated ISP needs to tuck a few more dollars into their
executives' paychecks.  I've tested it fairly thoroughly in order to
ensure that it can't be conscripted into an attack and do so again every
time I make a firewall configuration change or a software upgrade.

I've also started running local resolvers on portable systems in order
to avoid the same set of problems when connecting to random networks.
It often occurs to me that if the engineers of those networks invested the
time that they spend corrupting DNS into preventing DNS-borne attacks
that the entire Internet would be better off.

---rsk

Re: Thank you, Comcast.

[Anthony Junk]

There is so much arrogance in these posts saying that these things should
be blocked because it's best or because it's negligible. The point of
having an open internet is that people are going to have use cases that you
haven't even thought of and should not be hindered. Even the reasons you
have identified--who are you to say that I can't run services for my own
use to my home? Why should I have to pay for two separate connections so
that I can have tv and internet because I require ports not being blocked
for it to function? I maintain a lab out of my home and it's on my dime to
maintain and for my personal use. Please tell me again about my need for a
business connection.

Sincerely,

Anthony R Junk
Network and Security Engineer
(410) 929-1838
anthonyrj...@gmail.com


On Fri, Feb 26, 2016 at 12:02 PM, Chris Adams  wrote:

> Once upon a time, Brielle Bruns  said:
> > >I'm fine with that. Residential customers shouldn't be running DNS
> > >servers anyway and as far as the outside resolvers to go, e... I
> > >see the case for OpenDNS given that you can use it to filter (though
> > >that's easily bypassed), but not really for any others.
> >
> >
> > Except that half the time people run their own DNS resolvers because
> > their provider's resolvers are
>
> Resolver != authoritative server.  Your local DNS resolver doesn't need
> to be (and should not be) listening to port 53 on the Internet.  Only
> DNS authoritative servers need to accept Internet traffic on port 53,
> and almost nobody needs to be running one on a typical residential
> connection (especially since residential IPs do change from time to
> time).
>
> --
> Chris Adams 
>

RE: Thank you, Comcast.

[Naslund, Steve]

I don't have a problem with an ISP blocking certain things by default as long 
as they identify them like Comcast has done especially for consumer service.  
It would be nice if there was a way to opt out of the protection for the few 
people that need those services either through a web interface or a phone call. 
  They might make the case though that certain services require a business 
class of service.

Back in the 90s we used to block port 25 traffic for all customers unless they 
needed it opened because there were so many insecure mail systems out there.  
Sometimes you have to protect the clueless majority at the expense of a slight 
inconvenience for the geeks.  So if you were smart enough to know that you need 
port 25 opened, we would do it.  Most people did not know that it should be 
blocked most of the time so we protected them.

Steven Naslund
Chicago IL




>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  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.
> 

Re: Thank you, Comcast.

[Rich Kulawiec]

On Fri, Feb 26, 2016 at 08:55:20AM -0700, Keith Medcalf wrote:
> 
> On Friday, 26 February, 2016 08:13, jason_living...@comcast.com said:
> 
> > 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.
> 
> God is that a horrid web page.  I cannot view it.  The wheels on the bus go 
> round and round non-stop.

Agreed -- it's completely dysfunctional worthless crap.  I wonder if it
occurred to anybody that a list of blocked ports could be published as
a single static web page with no scripting, or better yet, as a text
file so that it could be acquired with and used by scripts.

---rsk

Re: Thank you, Comcast.

[Brielle Bruns]

On 2/26/16 10:02 AM, Chris Adams wrote:


Except that half the time people run their own DNS resolvers because
their provider's resolvers are


Resolver != authoritative server.  Your local DNS resolver doesn't need
to be (and should not be) listening to port 53 on the Internet.  Only
DNS authoritative servers need to accept Internet traffic on port 53,
and almost nobody needs to be running one on a typical residential
connection (especially since residential IPs do change from time to
time).



UDP is a fun protocol - stateless, so blocking a DST of 53/UDP to the 
customer also will block responses to recursive queries that originate 
from SRC 53/UDP.  Connection tracking sorta makes it stateful to a 
point, but it can get ugly with enough traffic.


Place the blame for local resolvers listening on WAN squarely where it 
belongs - the router vendors who make these devices.


You can't do anything about idiots buying a pro-sumer/professional 
device like an EdgeRouter and misconfiguring it, but Linksys/Cisco, 
D-Link, Netgear, etc that are targeted towards home users should be held 
to the fire for that kind of screw up.


--
Brielle Bruns
The Summit Open Source Development Group
http://www.sosdg.org/ http://www.ahbl.org

RE: Thank you, Comcast.

[Naslund, Steve]

Also worked fine in IE 11 and Firefox.  I didn't change any particular security 
settings either.  Might want to check your stuff before you rant on someone's 
web site.

Steven Naslund
Chicago IL

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Mike Hammett
Sent: Friday, February 26, 2016 10:01 AM
To: NANOG list
Subject: Re: Thank you, Comcast.

Works fine on a default Chrome installation. *shrugs* 




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

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

- Original Message -

From: "Keith Medcalf" <kmedc...@dessus.com>
To: "NANOG list" <nanog@nanog.org>
Cc: "Nirmal Mody" <nirmal_m...@cable.comcast.com>
Sent: Friday, February 26, 2016 9:55:20 AM
Subject: RE: Thank you, Comcast. 


On Friday, 26 February, 2016 08:13, jason_living...@comcast.com said: 

> 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.

God is that a horrid web page. I cannot view it. The wheels on the bus go round 
and round non-stop. 

It has so much intertwined malicious javascript, cross-site scripting, and 
malicious trackers that the alarm klaxons go off when I attempt to access it. I 
spent a couple of minutes attempting to access the page but still maintaining 
blocks to the malicious links. Apparently, viewing the page requires that all 
security be turned off and that the viewer allows completely untrusted code 
from completely untrustworty sources to run unabated on the viewers computer. 

I do not permit this. For anyone. Ever. 

This pretty much ensures that I would never be one of your customers. If you 
cannot operate a server which serves renderable non-malicious web pages 
properly, what hope is there that you can do anything else right? 

> 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).

> On 2/26/16, 9:31 AM, "NANOG on behalf of Keith Medcalf"  boun...@nanog.org on behalf of kmedc...@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-boun...@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
> <swm...@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 

Re: Thank you, Comcast.

[Brielle Bruns]

On 2/26/16 10:01 AM, Mike Hammett wrote:

They have to be honest or face litigation. Transparency is the biggest (if not 
the only) useful thing out of the Open Internet Order.



As long as the profit from doing shady things and lying is greater then 
the cost of settling a lawsuit, companies will be dishonest and do shady 
things.


So, no, I don't believe threat of litigation is any barrier to how ISPs 
conduct their business.  In fact, with how pro-business and 
fuck-consumer the current climate is from the govt, its just going to 
get worse.



--
Brielle Bruns
The Summit Open Source Development Group
http://www.sosdg.org/ http://www.ahbl.org

Re: Thank you, Comcast.

[Mike Hammett]

This small audience also consists of predominately people that administer 
networks and would be doing such things. I'll be you'll find a vastly different 
percentage of the Cross Stitch Operators Group even know what DNS is, much less 
have any desire to change it. 




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

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

- Original Message -

From: "David Bass" <davidbass...@gmail.com> 
To: "Mike Hammett" <na...@ics-il.net> 
Cc: "Brielle Bruns" <br...@2mbit.com>, nanog@nanog.org 
Sent: Friday, February 26, 2016 10:47:55 AM 
Subject: Re: Thank you, Comcast. 

I disagree...the point of what I sent (missed by some) is that in just this 
small audience there are many that do/have/know about customers that run their 
own stuff. 

Trying to blow it off, or minimize those customers just makes you seem a little 
arrogant. Nothing worse than an arrogant business... 

> On Feb 26, 2016, at 11:15 AM, Mike Hammett <na...@ics-il.net> wrote: 
> 
> I think you'd be hard pressed to find more than a tenth of a percent of 
> people attempt to run their own DNS server. Some do because they think it'll 
> be better in some way. Rare is the occasion where anything user configured 
> would outperform a local DNS server managed by the ISP that does no form of 
> trickery. 
> 
> 
> 
> 
> - 
> Mike Hammett 
> Intelligent Computing Solutions 
> http://www.ics-il.com 
> 
> Midwest-IX 
> http://www.midwest-ix.com 
> 
> - Original Message - 
> 
> From: "Brielle Bruns" <br...@2mbit.com> 
> To: nanog@nanog.org 
> Sent: Friday, February 26, 2016 9:56:40 AM 
> Subject: Re: Thank you, Comcast. 
> 
>> On 2/26/16 6:27 AM, Mike Hammett wrote: 
>> "you will also block legitimate return traffic if the customers run 
>> their own DNS servers or use opendns / google dns / etc." 
>> 
>> I'm fine with that. Residential customers shouldn't be running DNS 
>> servers anyway and as far as the outside resolvers to go, e... I 
>> see the case for OpenDNS given that you can use it to filter (though 
>> that's easily bypassed), but not really for any others. 
> 
> 
> Except that half the time people run their own DNS resolvers because 
> their provider's resolvers are 
> 
> 1) Absolute garbage and either fail queries for no reason, don't respond 
> at times, respond super slow, etc. 
> 
> 2) Hijack NXDOMAIN for advertising / money generation 
> 
> 3) Hijack responses to inject their own ads, popups, etc. 
> 
> 
> 
> -- 
> Brielle Bruns 
> The Summit Open Source Development Group 
> http://www.sosdg.org / http://www.ahbl.org 
> 

Re: Thank you, Comcast.

[Chris Adams]

Once upon a time, Brielle Bruns  said:
> >I'm fine with that. Residential customers shouldn't be running DNS
> >servers anyway and as far as the outside resolvers to go, e... I
> >see the case for OpenDNS given that you can use it to filter (though
> >that's easily bypassed), but not really for any others.
> 
> 
> Except that half the time people run their own DNS resolvers because
> their provider's resolvers are

Resolver != authoritative server.  Your local DNS resolver doesn't need
to be (and should not be) listening to port 53 on the Internet.  Only
DNS authoritative servers need to accept Internet traffic on port 53,
and almost nobody needs to be running one on a typical residential
connection (especially since residential IPs do change from time to
time).

-- 
Chris Adams 

Re: Thank you, Comcast.

[Mike Hammett]

They have to be honest or face litigation. Transparency is the biggest (if not 
the only) useful thing out of the Open Internet Order. 




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

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

- Original Message -

From: "Brielle Bruns" <br...@2mbit.com> 
To: "Mike Hammett" <na...@ics-il.net> 
Cc: nanog@nanog.org 
Sent: Friday, February 26, 2016 10:46:27 AM 
Subject: Re: Thank you, Comcast. 

On 2/26/16 9:15 AM, Mike Hammett wrote: 
> I think you'd be hard pressed to find more than a tenth of a percent of 
> people attempt to run their own DNS server. Some do because they think 
> it'll be better in some way. Rare is the occasion where anything user 
> configured would outperform a local DNS server managed by the ISP that 
> does no form of trickery. 

"does no form of trickery" 

Therein lies the problem. Can we trust ISPs to be honest about not 
messing with our traffic? 

Kudos to you if you can say that with a straight face :-) 

Doesn't matter how many people actually have what we think is a 'valid' 
reason to do it. People have their reasons, may it be because of 
performance, or what they perceive as CDN issues, or just not trusting 
their provider. 

-- 
Brielle Bruns 
The Summit Open Source Development Group 
http://www.sosdg.org / http://www.ahbl.org 

Re: Thank you, Comcast.

[Roland Dobbins]

On 26 Feb 2016, at 23:44, Blake Hudson wrote:

Jason, how do you propose to block SSDP without also blocking 
legitimate traffic as well (since SSDP uses a port > 1024 and is used 
as part of the ephemeral port range on some devices) ?


I'm not Jason, but blocking specific port-pairs such as UDP/80 ---> 
UDP/1900 and UDP/443 ---> UDP/1900 solves close to 90% of the problem, 
as UDP/80 and UDP/443 are the most common destination ports leveraged in 
this type of attack.


For an explanation of how UDP reflection/amplification attacks work, see 
this .pdf preso:




---
Roland Dobbins 

Re: Thank you, Comcast.

[David Bass]

I disagree...the point of what I sent (missed by some) is that in just this 
small audience there are many that do/have/know about customers that run their 
own stuff.  

Trying to blow it off, or minimize those customers just makes you seem a little 
arrogant.  Nothing worse than an arrogant business...  

> On Feb 26, 2016, at 11:15 AM, Mike Hammett <na...@ics-il.net> wrote:
> 
> I think you'd be hard pressed to find more than a tenth of a percent of 
> people attempt to run their own DNS server. Some do because they think it'll 
> be better in some way. Rare is the occasion where anything user configured 
> would outperform a local DNS server managed by the ISP that does no form of 
> trickery. 
> 
> 
> 
> 
> - 
> Mike Hammett 
> Intelligent Computing Solutions 
> http://www.ics-il.com 
> 
> Midwest-IX 
> http://www.midwest-ix.com 
> 
> - Original Message -
> 
> From: "Brielle Bruns" <br...@2mbit.com> 
> To: nanog@nanog.org 
> Sent: Friday, February 26, 2016 9:56:40 AM 
> Subject: Re: Thank you, Comcast. 
> 
>> On 2/26/16 6:27 AM, Mike Hammett wrote: 
>> "you will also block legitimate return traffic if the customers run 
>> their own DNS servers or use opendns / google dns / etc." 
>> 
>> I'm fine with that. Residential customers shouldn't be running DNS 
>> servers anyway and as far as the outside resolvers to go, e... I 
>> see the case for OpenDNS given that you can use it to filter (though 
>> that's easily bypassed), but not really for any others.
> 
> 
> Except that half the time people run their own DNS resolvers because 
> their provider's resolvers are 
> 
> 1) Absolute garbage and either fail queries for no reason, don't respond 
> at times, respond super slow, etc. 
> 
> 2) Hijack NXDOMAIN for advertising / money generation 
> 
> 3) Hijack responses to inject their own ads, popups, etc. 
> 
> 
> 
> -- 
> Brielle Bruns 
> The Summit Open Source Development Group 
> http://www.sosdg.org / http://www.ahbl.org 
> 

Re: Thank you, Comcast.

[Brielle Bruns]

On 2/26/16 9:15 AM, Mike Hammett wrote:

I think you'd be hard pressed to find more than a tenth of a percent of
people attempt to run their own DNS server. Some do because they think
it'll be better in some way. Rare is the occasion where anything user
configured would outperform a local DNS server managed by the ISP that
does no form of trickery.


"does no form of trickery"

Therein lies the problem.  Can we trust ISPs to be honest about not 
messing with our traffic?


Kudos to you if you can say that with a straight face :-)

Doesn't matter how many people actually have what we think is a 'valid' 
reason to do it.  People have their reasons, may it be because of 
performance, or what they perceive as CDN issues, or just not trusting 
their provider.


--
Brielle Bruns
The Summit Open Source Development Group
http://www.sosdg.org/ http://www.ahbl.org

Re: Thank you, Comcast.

[Blake Hudson]

Livingood, Jason wrote on 2/26/2016 9:12 AM:

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




Jason, how do you propose to block SSDP without also blocking legitimate 
traffic as well (since SSDP uses a port > 1024 and is used as part of 
the ephemeral port range on some devices) ? Is the downside of blocking 
(admittedly a small amount of) legitimate user traffic worth the upside? 
And is this practice /Open Internet/ friendly?


--Blake

Re: Thank you, Comcast.

[Roland Dobbins]

On 26 Feb 2016, at 23:15, Mike Hammett wrote:

I think you'd be hard pressed to find more than a tenth of a percent 
of people attempt to run their own DNS server.


You'll find a heck of a lot more of them doing so unknowingly, because 
they're running misconfigured, abusable CPE devices which can be 
leveraged by attackers to launch DNS reflection/amplification attacks.


Note that outbound/crossbound DDoS attacks can have just as much of a 
negative impact on availability as inbound DDoS attacks; even more, when 
multiple attackers are abusing the same reflectors/amplifiers (which is 
often the case).


And even that small tenth of a percent who're deliberately running their 
own DNS servers can end up inadvertently causing disruption if they're 
running those DNS servers as open recursors.


---
Roland Dobbins 

Re: Thank you, Comcast.

[Roland Dobbins]

On 26 Feb 2016, at 23:02, Damian Menscher via NANOG wrote:


What I'd much rather see Comcast do is use their netflow to trace the
source of the spoofed packets (one of their peers or transit 
providers, no
doubt) and strongly encourage (using their legal or PR team as needed) 
them

to trace back and stop the spoofing.


These approaches aren't necessarily mutually exclusive, as most flow 
telemetry implementations still report on blocked traffic from exporting 
devices.


Keeping the network up and available for the vast majority of the 
customer base trumps all other considerations.  DNS queries should not 
typically be directed towards consumer broadband access netblocks, 
period; and when they cause operational problems due to abusable CPE 
being, well, abused, immediate remediation action(s) must be taken.


To do otherwise would be irresponsible.

---
Roland Dobbins 

Re: Thank you, Comcast.

[Mike Hammett]

I think you'd be hard pressed to find more than a tenth of a percent of people 
attempt to run their own DNS server. Some do because they think it'll be better 
in some way. Rare is the occasion where anything user configured would 
outperform a local DNS server managed by the ISP that does no form of trickery. 




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

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

- Original Message -

From: "Brielle Bruns" <br...@2mbit.com> 
To: nanog@nanog.org 
Sent: Friday, February 26, 2016 9:56:40 AM 
Subject: Re: Thank you, Comcast. 

On 2/26/16 6:27 AM, Mike Hammett wrote: 
> "you will also block legitimate return traffic if the customers run 
> their own DNS servers or use opendns / google dns / etc." 
> 
> I'm fine with that. Residential customers shouldn't be running DNS 
> servers anyway and as far as the outside resolvers to go, e... I 
> see the case for OpenDNS given that you can use it to filter (though 
> that's easily bypassed), but not really for any others. 


Except that half the time people run their own DNS resolvers because 
their provider's resolvers are 

1) Absolute garbage and either fail queries for no reason, don't respond 
at times, respond super slow, etc. 

2) Hijack NXDOMAIN for advertising / money generation 

3) Hijack responses to inject their own ads, popups, etc. 



-- 
Brielle Bruns 
The Summit Open Source Development Group 
http://www.sosdg.org / http://www.ahbl.org 

Re: Thank you, Comcast.

[Curtis Maurand]

I run my own resolver from behind my firewall at my home.  I don't allow 
incoming port 53 traffic.  I realize there's not a lot of privacy on the 
net, but I don't like having my dns queries tracked in order to target 
advertising at me and for annoying failed queries to end up at some 
annoying search page.




On 2/26/2016 9:18 AM, Maxwell Cole wrote:

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  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 Abrahamssonemail: swm...@swm.pp.se


--
Best Regards
Curtis Maurand
Principal
Xyonet Web Hosting
mailto:cmaur...@xyonet.com
http://www.xyonet.com

Re: Thank you, Comcast.

[Damian Menscher via NANOG]

On Fri, Feb 26, 2016 at 6:28 AM, Jared Mauch  wrote:

> As a community we need to determine if this background radiation and these
> responses are proper. I think it's a good response since vendors can't do
> uRPF at line rate and the major purchasers of BCM switches don't ask for it
> and aren't doing it, so it's not optimized or does not exist. /sigh
>

I don't agree with the approach of going after individual reflectors
(open*project) or blocking specific ports (Comcast's action here) as both
are reactive, unlikely to be particularly effective (there are still
millions of reflectors and plenty of open ports available), and don't solve
the root problem (spoofed packets making it onto the public internet).
What I'd much rather see Comcast do is use their netflow to trace the
source of the spoofed packets (one of their peers or transit providers, no
doubt) and strongly encourage (using their legal or PR team as needed) them
to trace back and stop the spoofing.  This benefits everyone in a much more
direct and scalable way.  Until some of the larger providers start doing
that, amplification attacks and other spoofed-source attacks (DNS and
synfloods) will continue to thrive.

(I've contacted several ISPs about the spoofed traffic they send to us.
The next major hurdle is that so many don't have netflow or other useful
monitoring of their networks)

Damian

Re: Thank you, Comcast.

[Brielle Bruns]

On 2/26/16 7:31 AM, Keith Medcalf 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.



Thumbs up to this one.  I like how CenturyLink gives me the option of 
turning off port 25 blocking quickly if you know where to go, but it is 
on by default.


I can live with blocks on by default, but easily be able to be turned 
off (if you are smart enough to know where to look to disable the options).


Only thing I dislike is that they don't seem to remember it between 
service upgrades, and every time I bump my customer speeds I have to 
remember to go reset it or they can't send e-mail.  :-)


--
Brielle Bruns
The Summit Open Source Development Group
http://www.sosdg.org/ http://www.ahbl.org

Re: Thank you, Comcast.

[Maxwell Cole]

Thats not really a fair comparison, I think a lot of people have issues with 
people censoring/controlling/prioritizing internet access to make money. Its a 
somewhat more nuanced conversation when you are talking about doing the same 
thing to prevent abuse. 

Cheers,
Max

> On Feb 26, 2016, at 10:32 AM, James Downs  wrote:
> 
> 
>> On Feb 26, 2016, at 06:31, Keith Medcalf  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.
> 
> Absolutely. It’s funny that a group that worries about about net neutrality 
> and whinges about T-Mobile’s zero-rating certain video sources is perfectly 
> fine with blindly blocking *ports*, without even understanding if it’s 
> legitimate traffic.
> 
>> 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)
> 
> This would be a big reason to point to a different DNS...
> 
>> 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.
> 

RE: Thank you, Comcast.

[Philip Dorr]

On Feb 26, 2016 8:34 AM, "Keith Medcalf"  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.
>

Every ISP I have felt with that messes with the DNS, has no valid opt-out
other than using different DNS.  The opt-out they use is a HTTP cookie,
which only works for web browsers.  It doesn't work for any other program.

Re: Thank you, Comcast.

[Mike Hammett]

Works fine on a default Chrome installation. *shrugs* 




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

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

- Original Message -

From: "Keith Medcalf" <kmedc...@dessus.com> 
To: "NANOG list" <nanog@nanog.org> 
Cc: "Nirmal Mody" <nirmal_m...@cable.comcast.com> 
Sent: Friday, February 26, 2016 9:55:20 AM 
Subject: RE: Thank you, Comcast. 


On Friday, 26 February, 2016 08:13, jason_living...@comcast.com said: 

> 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. 

God is that a horrid web page. I cannot view it. The wheels on the bus go round 
and round non-stop. 

It has so much intertwined malicious javascript, cross-site scripting, and 
malicious trackers that the alarm klaxons go off when I attempt to access it. I 
spent a couple of minutes attempting to access the page but still maintaining 
blocks to the malicious links. Apparently, viewing the page requires that all 
security be turned off and that the viewer allows completely untrusted code 
from completely untrustworty sources to run unabated on the viewers computer. 

I do not permit this. For anyone. Ever. 

This pretty much ensures that I would never be one of your customers. If you 
cannot operate a server which serves renderable non-malicious web pages 
properly, what hope is there that you can do anything else right? 

> 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). 

> On 2/26/16, 9:31 AM, "NANOG on behalf of Keith Medcalf"  boun...@nanog.org on behalf of kmedc...@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-boun...@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 
> <swm...@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: swm...@swm.pp.se 
> 
> 
> 
> 
> 
> 

Re: Thank you, Comcast.

[Brielle Bruns]

On 2/26/16 6:27 AM, Mike Hammett wrote:

"you will also block legitimate return traffic if the customers run
their own DNS servers or use opendns / google dns / etc."

I'm fine with that. Residential customers shouldn't be running DNS
servers anyway and as far as the outside resolvers to go, e... I
see the case for OpenDNS given that you can use it to filter (though
that's easily bypassed), but not really for any others.



Except that half the time people run their own DNS resolvers because
their provider's resolvers are

1) Absolute garbage and either fail queries for no reason, don't respond
at times, respond super slow, etc.

2) Hijack NXDOMAIN for advertising / money generation

3) Hijack responses to inject their own ads, popups, etc.



--
Brielle Bruns
The Summit Open Source Development Group
http://www.sosdg.org/ http://www.ahbl.org

RE: Thank you, Comcast.

[Keith Medcalf]

On Friday, 26 February, 2016 08:13, jason_living...@comcast.com said:

> 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.

God is that a horrid web page.  I cannot view it.  The wheels on the bus go 
round and round non-stop.

It has so much intertwined malicious javascript, cross-site scripting, and 
malicious trackers that the alarm klaxons go off when I attempt to access it.  
I spent a couple of minutes attempting to access the page but still maintaining 
blocks to the malicious links.  Apparently, viewing the page requires that all 
security be turned off and that the viewer allows completely untrusted code 
from completely untrustworty sources to run unabated on the viewers computer.

I do not permit this.  For anyone.  Ever.

This pretty much ensures that I would never be one of your customers.  If you 
cannot operate a server which serves renderable non-malicious web pages 
properly, what hope is there that you can do anything else right?

> 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).

> On 2/26/16, 9:31 AM, "NANOG on behalf of Keith Medcalf"  boun...@nanog.org on behalf of kmedc...@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-boun...@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
> <swm...@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 Abrahamssonemail: swm...@swm.pp.se
>
>
>
>
>
>

Re: Thank you, Comcast.

[David Bass]

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 <kmedc...@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-boun...@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 <swm...@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 Abrahamssonemail: swm...@swm.pp.se
> 
> 
> 
> 

Re: Thank you, Comcast.

[James Downs]

> On Feb 26, 2016, at 06:31, Keith Medcalf  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.

Absolutely. It’s funny that a group that worries about about net neutrality and 
whinges about T-Mobile’s zero-rating certain video sources is perfectly fine 
with blindly blocking *ports*, without even understanding if it’s legitimate 
traffic.

> 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)

This would be a big reason to point to a different DNS...

>  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.

Re: Thank you, Comcast.

[Mike Hammett]

*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" <kmedc...@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-boun...@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 <swm...@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: swm...@swm.pp.se 

Re: Thank you, Comcast.

[Livingood, Jason]

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-boun...@nanog.org<mailto:nanog-boun...@nanog.org> on behalf of 
kmedc...@dessus.com<mailto:kmedc...@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-boun...@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 
> <swm...@swm.pp.se<mailto:swm...@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 Abrahamssonemail: swm...@swm.pp.se<mailto:swm...@swm.pp.se>

Re: Thank you, Comcast.

[Livingood, Jason]

On 2/26/16, 8:27 AM, "NANOG on behalf of Mike Hammett"
 wrote:


>"you will also block legitimate return traffic if the
>customers run their own DNS servers or use opendns / google dns / etc."
>
>I'm fine with that. Residential customers shouldn't be running DNS
>servers anyway and as far as the outside resolvers to go, e... I see
>the case for OpenDNS given that you can use it to filter (though that's
>easily bypassed), but not really for any others.

There¹s some question about whether the FCC or 3rd party DNS providers
would be though. Especially under the Title-II rules around non-blocking
of legitimate traffic.

- Jason

Re: Thank you, Comcast.

[Livingood, Jason]

And you¹d be correct (about SSDP). ;-)


- Jason (Comcast)

On 2/25/16, 10:52 PM, "NANOG on behalf of Paras Jha"
 wrote:

>It's interesting that they'd call about DNS amplification... You don't
>typically see DNS amplified floods coming from home ISPs. I would imagine
>SSDP amplification is a far greater issue for any home ISP.
>
>On Thu, Feb 25, 2016 at 10:46 PM, Mike Hammett  wrote:
>
>> I know. It seems odd, doesn't it?
>>
>> They're actually suspending people's accounts for DNS amplification. My
>> aunt got a call about it tonight. I had already firewalled that off on
>>her
>> router before they called, but they're doing it. There's more that they
>> could do I'm sure, but they're doing it. Maybe it's flooding their
>>upstream
>> causing other service issues but they're doing it.
>>
>> So many others aren't doing much at all.
>>
>>
>>
>>
>> -
>> Mike Hammett
>> Intelligent Computing Solutions
>> http://www.ics-il.com
>>
>> Midwest-IX
>> http://www.midwest-ix.com
>>
>

RE: Thank you, Comcast.

[Keith Medcalf]

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-boun...@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 <swm...@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 Abrahamssonemail: swm...@swm.pp.se

Re: Thank you, Comcast.

[Jared Mauch]

Most of the NTP hosts have been remediated or blocked. 

Using QoS to set a cap of the amount of SNMP and DNS traffic is a fair response 
IMHO. 

Some carriers eg: 7018 block chargen wholesale across their network. We haven't 
taken that step but it's also something I'm not opposed to. 

As a community we need to determine if this background radiation and these 
responses are proper. I think it's a good response since vendors can't do uRPF 
at line rate and the major purchasers of BCM switches don't ask for it and 
aren't doing it, so it's not optimized or does not exist. /sigh

Jared Mauch

> On Feb 26, 2016, at 9:18 AM, Maxwell Cole  
> wrote:
> 
> 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  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 Abrahamssonemail: swm...@swm.pp.se

Re: Thank you, Comcast.

[Maxwell Cole]

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  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 Abrahamssonemail: swm...@swm.pp.se

Re: Thank you, Comcast.

[Mike Hammett]

I'm sure someone smarter than I will chime in here, but I'd say far too much 
effort\resources for too little tangible results. 




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

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

- Original Message -

From: "Dovid Bender" <do...@telecurve.com> 
To: "Mike Hammett" <na...@ics-il.net>, "NANOG" <nanog-boun...@nanog.org> 
Cc: "NANOG list" <nanog@nanog.org> 
Sent: Friday, February 26, 2016 7:32:09 AM 
Subject: Re: Thank you, Comcast. 

I had a client with a few boxes that had dns wide open. Couldn't you use snort 
to match against those specific requests and just drop those packets? 


Regards, 

Dovid 

-Original Message- 
From: Mike Hammett <na...@ics-il.net> 
Sender: "NANOG" <nanog-boun...@nanog.org>Date: Fri, 26 Feb 2016 07:27:50 
Cc: NANOG list<nanog@nanog.org> 
Subject: Re: Thank you, Comcast. 

"you will also block legitimate return traffic if the 
customers run their own DNS servers or use opendns / google dns / etc." 

I'm fine with that. Residential customers shouldn't be running DNS servers 
anyway and as far as the outside resolvers to go, e... I see the case for 
OpenDNS given that you can use it to filter (though that's easily bypassed), 
but not really for any others. 




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

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

- Original Message - 

From: "Nick Hilliard" <n...@foobar.org> 
To: "Mikael Abrahamsson" <swm...@swm.pp.se> 
Cc: "NANOG list" <nanog@nanog.org> 
Sent: Friday, February 26, 2016 7:17:30 AM 
Subject: Re: Thank you, Comcast. 

Mikael Abrahamsson wrote: 
> Why isn't UDP/53 blocked towards customers? I know historically there 
> were resolvers that used UDP/53 as source port for queries, but is this 
> the case nowadays? 
> 
> I know providers that have blocked UDP/53 towards customers as a 
> countermeasure to the amplification attacks. As far as I heard, there 
> were no customer complaints. 

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. 

Nick 

Re: Thank you, Comcast.

[Mikael Abrahamsson]

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 Abrahamssonemail: swm...@swm.pp.se

Re: Thank you, Comcast.

[Roland Dobbins]

On 26 Feb 2016, at 20:17, Nick Hilliard wrote:


 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.


Actually, what they're talking about is blocking packets *destined* for 
UDP/53 on broadband access networks, not *sourced from*.


---
Roland Dobbins 

Re: Thank you, Comcast.

[Ca By]

On Thursday, February 25, 2016, Mike Hammett  wrote:

> I know. It seems odd, doesn't it?
>
> They're actually suspending people's accounts for DNS amplification. My
> aunt got a call about it tonight. I had already firewalled that off on her
> router before they called, but they're doing it. There's more that they
> could do I'm sure, but they're doing it. Maybe it's flooding their upstream
> causing other service issues but they're doing it.
>
> So many others aren't doing much at all.
>
>
>
+1 for thank you Comcast and all the folks that file and respond to network
abuse reports.

Comcast is one of the good ones helping the internet thrive  (IPv6,
dnsssec, responding to and shutting down abuse)

CB


>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>

Re: Thank you, Comcast.

[Dovid Bender]

I had a client with a few boxes that had dns wide open. Couldn't you use snort 
to match against those specific requests and just drop those packets?


Regards,

Dovid

-Original Message-
From: Mike Hammett <na...@ics-il.net>
Sender: "NANOG" <nanog-boun...@nanog.org>Date: Fri, 26 Feb 2016 07:27:50 
Cc: NANOG list<nanog@nanog.org>
Subject: Re: Thank you, Comcast.

"you will also block legitimate return traffic if the 
customers run their own DNS servers or use opendns / google dns / etc." 

I'm fine with that. Residential customers shouldn't be running DNS servers 
anyway and as far as the outside resolvers to go, e... I see the case for 
OpenDNS given that you can use it to filter (though that's easily bypassed), 
but not really for any others. 




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

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

- Original Message -

From: "Nick Hilliard" <n...@foobar.org> 
To: "Mikael Abrahamsson" <swm...@swm.pp.se> 
Cc: "NANOG list" <nanog@nanog.org> 
Sent: Friday, February 26, 2016 7:17:30 AM 
Subject: Re: Thank you, Comcast. 

Mikael Abrahamsson wrote: 
> Why isn't UDP/53 blocked towards customers? I know historically there 
> were resolvers that used UDP/53 as source port for queries, but is this 
> the case nowadays? 
> 
> I know providers that have blocked UDP/53 towards customers as a 
> countermeasure to the amplification attacks. As far as I heard, there 
> were no customer complaints. 

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. 

Nick 

Re: Thank you, Comcast.

[Mike Hammett]

"you will also block legitimate return traffic if the 
customers run their own DNS servers or use opendns / google dns / etc." 

I'm fine with that. Residential customers shouldn't be running DNS servers 
anyway and as far as the outside resolvers to go, e... I see the case for 
OpenDNS given that you can use it to filter (though that's easily bypassed), 
but not really for any others. 




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

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

- Original Message -

From: "Nick Hilliard" <n...@foobar.org> 
To: "Mikael Abrahamsson" <swm...@swm.pp.se> 
Cc: "NANOG list" <nanog@nanog.org> 
Sent: Friday, February 26, 2016 7:17:30 AM 
Subject: Re: Thank you, Comcast. 

Mikael Abrahamsson wrote: 
> Why isn't UDP/53 blocked towards customers? I know historically there 
> were resolvers that used UDP/53 as source port for queries, but is this 
> the case nowadays? 
> 
> I know providers that have blocked UDP/53 towards customers as a 
> countermeasure to the amplification attacks. As far as I heard, there 
> were no customer complaints. 

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. 

Nick 

Re: Thank you, Comcast.

[Nick Hilliard]

Mikael Abrahamsson wrote:
> Why isn't UDP/53 blocked towards customers? I know historically there
> were resolvers that used UDP/53 as source port for queries, but is this
> the case nowadays?
> 
> I know providers that have blocked UDP/53 towards customers as a
> countermeasure to the amplification attacks. As far as I heard, there
> were no customer complaints.

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.

Nick

Re: Thank you, Comcast.

[Mike Hammett]

I do on my network (well, the ISP, not the IX). It makes complete sense. 




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

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

- Original Message -

From: "Mikael Abrahamsson" <swm...@swm.pp.se> 
To: "Jared Mauch" <ja...@puck.nether.net> 
Cc: "NANOG list" <nanog@nanog.org> 
Sent: Friday, February 26, 2016 12:20:28 AM 
Subject: Re: Thank you, Comcast. 

On Thu, 25 Feb 2016, Jared Mauch wrote: 

> Make sure you permit TCP/53 for DNS queries so if TC=1 lookups work. 

Speaking of which, historically ISPs have been blocking TCP/135, TCP/445 
and a few others towards customers (at least that's what I know). TCP/25 
seems to be blocked as well. 

Why isn't UDP/53 blocked towards customers? I know historically there were 
resolvers that used UDP/53 as source port for queries, but is this the 
case nowadays? 

I know providers that have blocked UDP/53 towards customers as a 
countermeasure to the amplification attacks. As far as I heard, there were 
no customer complaints. 

-- 
Mikael Abrahamsson email: swm...@swm.pp.se 

Re: Thank you, Comcast.

[Mikeal Clark]

Totally agree.  It's silly that my home lab has to cost me 5x the
normal rate if I want to use some of the standard ports but that is
normal now.

On Fri, Feb 26, 2016 at 12:27 AM, Mark Andrews  wrote:
>
> In message , Mikael 
> Abrah
> amsson writes:
>> On Thu, 25 Feb 2016, Jared Mauch wrote:
>>
>> > Make sure you permit TCP/53 for DNS queries so if TC=1 lookups work.
>>
>> Speaking of which, historically ISPs have been blocking TCP/135, TCP/445
>> and a few others towards customers (at least that's what I know). TCP/25
>> seems to be blocked as well.
>>
>> Why isn't UDP/53 blocked towards customers? I know historically there were
>> resolvers that used UDP/53 as source port for queries, but is this the
>> case nowadays?
>>
>> I know providers that have blocked UDP/53 towards customers as a
>> countermeasure to the amplification attacks. As far as I heard, there were
>> no customer complaints.
>
> Because complaining is like talking to a brick wall most of the
> time.  People work around the ISP idiocy by shifting ports, its
> easier than trying to get through help desk hell.
>
>> --
>> Mikael Abrahamssonemail: swm...@swm.pp.se
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Thank you, Comcast.

[Mark Andrews]

In message , Mikael Abrah
amsson writes:
> On Thu, 25 Feb 2016, Jared Mauch wrote:
> 
> > Make sure you permit TCP/53 for DNS queries so if TC=1 lookups work.
> 
> Speaking of which, historically ISPs have been blocking TCP/135, TCP/445 
> and a few others towards customers (at least that's what I know). TCP/25 
> seems to be blocked as well.
> 
> Why isn't UDP/53 blocked towards customers? I know historically there were 
> resolvers that used UDP/53 as source port for queries, but is this the 
> case nowadays?
> 
> I know providers that have blocked UDP/53 towards customers as a 
> countermeasure to the amplification attacks. As far as I heard, there were 
> no customer complaints.

Because complaining is like talking to a brick wall most of the
time.  People work around the ISP idiocy by shifting ports, its
easier than trying to get through help desk hell.

> -- 
> Mikael Abrahamssonemail: swm...@swm.pp.se
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Thank you, Comcast.

[Mikael Abrahamsson]

On Thu, 25 Feb 2016, Jared Mauch wrote:


Make sure you permit TCP/53 for DNS queries so if TC=1 lookups work.


Speaking of which, historically ISPs have been blocking TCP/135, TCP/445 
and a few others towards customers (at least that's what I know). TCP/25 
seems to be blocked as well.


Why isn't UDP/53 blocked towards customers? I know historically there were 
resolvers that used UDP/53 as source port for queries, but is this the 
case nowadays?


I know providers that have blocked UDP/53 towards customers as a 
countermeasure to the amplification attacks. As far as I heard, there were 
no customer complaints.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: Thank you, Comcast.

[Jared Mauch]

SSDP, DNS and other amplification is a big issue for large consumer networks 
like Comcast.

This is something I’m hoping other vendors take seriously (eg: Netgear) when it 
comes to their usage of DNSMASQ and other tools on-box and iptables configs 
that promote spoofing by using IP ranges vs constraining rules with the 
ingress/egress interface.

It’s these simple amateur errors that can turn a port 53 redirect into a 
spoofing instance when it only passes the INPUT rule vs -t NAT rule.

Please block SSDP and Chargen on your networks.  Consider rate-limiting DNS & 
SNMP to 1% or something appropriate to avoid issues.

Make sure you permit TCP/53 for DNS queries so if TC=1 lookups work.

- Jared

> On Feb 25, 2016, at 10:52 PM, Paras Jha  wrote:
> 
> It's interesting that they'd call about DNS amplification... You don't
> typically see DNS amplified floods coming from home ISPs. I would imagine
> SSDP amplification is a far greater issue for any home ISP.
> 
> On Thu, Feb 25, 2016 at 10:46 PM, Mike Hammett  wrote:
> 
>> I know. It seems odd, doesn't it?
>> 
>> They're actually suspending people's accounts for DNS amplification. My
>> aunt got a call about it tonight. I had already firewalled that off on her
>> router before they called, but they're doing it. There's more that they
>> could do I'm sure, but they're doing it. Maybe it's flooding their upstream
>> causing other service issues but they're doing it.
>> 
>> So many others aren't doing much at all.
>> 
>> 
>> 
>> 
>> -
>> Mike Hammett
>> Intelligent Computing Solutions
>> http://www.ics-il.com
>> 
>> Midwest-IX
>> http://www.midwest-ix.com
>> 

Re: Thank you, Comcast.

[Roland Dobbins]

On 26 Feb 2016, at 10:52, Paras Jha wrote:


You don't typically see DNS amplified floods coming from home ISPs.


Actually, it's quite common, as a lot of CPE have abusable DNS 
forwarders running on their public interfaces.


DNS, SSDP, and SNMP reflection/amplification quite commonly emanate from 
broadband access networks due to abusable CPE.  Others, as well, of 
course, but those are generally the most prevalent.


---
Roland Dobbins 

Re: Thank you, Comcast.

[Paras Jha]

It's interesting that they'd call about DNS amplification... You don't
typically see DNS amplified floods coming from home ISPs. I would imagine
SSDP amplification is a far greater issue for any home ISP.

On Thu, Feb 25, 2016 at 10:46 PM, Mike Hammett  wrote:

> I know. It seems odd, doesn't it?
>
> They're actually suspending people's accounts for DNS amplification. My
> aunt got a call about it tonight. I had already firewalled that off on her
> router before they called, but they're doing it. There's more that they
> could do I'm sure, but they're doing it. Maybe it's flooding their upstream
> causing other service issues but they're doing it.
>
> So many others aren't doing much at all.
>
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>

Re: Thank you Comcast

[Mehmet Akcin]

+ Redmond, WA. Good job guys. 

mehmet

On Apr 17, 2014, at 7:28 PM, Michael T. Voity mvo...@uvm.edu wrote:

 To the Comcast v6 Team,
 
 Thank you for enabling my CMTS for v6 in Colchester, VT
 
 Works great!
 
 Thanks,
 
 -Mike
 
 Michael T. Voity
 Network Engineer
 University of Vermont
 
 
 

Re: Thank you Comcast

[Doug Barton]

Please don't reply to a message on the list and change the subject line. 
Doing so causes your new topic to show under the previous one for 
those using mail readers that thread properly, and may cause your 
message to be missed altogether if someone has blocked that thread.


Instead, save the list address and start a completely new message.

hope this helps,

Doug