I'm wondering how many operators don't have systems in place to
quickly and efficiently filter problem host systems.
I see a lot of talk of ACL usage, but not much about uRPF and black
hole filtering.
There are a few white papers that are worth a read:
You mean, like Bcp38(.info)?
On February 28, 2014 9:02:03 AM EST, Ray Soucy r...@maine.edu wrote:
I'm wondering how many operators don't have systems in place to
quickly and efficiently filter problem host systems.
I see a lot of talk of ACL usage, but not much about uRPF and black
hole
When I was looking at the website before I didn't really see any
mention of uRPF, just the use of ACLs, maybe I missed it, but it's not
encouraging if I can't spot it quickly. I just tried a search and the
only thing that popped up was a how-to for a Cisco 7600 VXR.
Hi Royce,
Le 23/02/2014 20:48, Royce Williams a écrit :
Newb question ... other than retrofitting, what stands in the way of
making BCP38 a condition of peering?
Good point ! And simple answer : most peers wouldn't support the hassle
yet, thus reducing peering density and interest.
I operate
* ra...@psg.com (Randy Bush) [Thu 27 Feb 2014, 06:10 CET]:
is there any modern utility in chargen?
No. But as we're not Apple, we don't get to decide what's good for
the end user.
Who knows, when CGNs become commonplace we'll start to run out of
ephemeral ports and we'll have to start
- Original Message -
From: Ray Soucy r...@maine.edu
When I was looking at the website before I didn't really see any
mention of uRPF, just the use of ACLs, maybe I missed it, but it's not
encouraging if I can't spot it quickly. I just tried a search and the
only thing that popped up
is there any modern utility in chargen?
Who knows, when CGNs become commonplace we'll start to run out of
ephemeral ports and we'll have to start using ports 1024 too.
Would be a shame if their use were impeded by old ACLs lying around.
woah! i did not suggest acls. i was assuming that
is there any modern utility in chargen?
Who knows, when CGNs become commonplace we'll start to run out of
ephemeral ports and we'll have to start using ports 1024 too.
Would be a shame if their use were impeded by old ACLs lying
around.
* ra...@psg.com (Randy Bush) [Fri 28 Feb 2014, 17:23
On Fri, Feb 28, 2014 at 9:02 AM, Ray Soucy r...@maine.edu wrote:
If you have uRPF enabled on all your access routers then you can
configure routing policy such that advertising a route for a specific
host system will trigger uRPF to drop the traffic at the first hop, in
hardware.
note that
+1 in my experience uRPF get’s enabled, breaks something or causes confusion
(usually related to multi-homing) and then get’s disabled.
On Feb 28, 2014, at 11:49 AM, Christopher Morrow morrowc.li...@gmail.com
wrote:
On Fri, Feb 28, 2014 at 9:02 AM, Ray Soucy r...@maine.edu wrote:
If you have
On Mar 1, 2014, at 9:14 AM, Keegan Holley no.s...@comcast.net wrote:
+1 in my experience uRPF get’s enabled, breaks something or causes confusion
(usually related to multi-homing) and then get’s disabled.
Enabling loose-check - even with allow-default - is useful solely for S/RTBH,
if
On Feb 26, 2014, at 12:44 PM, Brandon Galbraith brandon.galbra...@gmail.com
wrote:
On Wed, Feb 26, 2014 at 6:56 AM, Keegan Holley no.s...@comcast.net wrote:
More politely stated, it’s not the responsibility of the operator to decide
what belongs on the network and what doesn’t. Users
It depends on how many customers you have and what sort of contract you have
with them if any. A significant amount of attack traffic comes from
residential networks where a “one-size-fits-all” policy is definitely best.
On Feb 26, 2014, at 4:01 PM, Jay Ashworth j...@baylink.com wrote:
-
a
particular port number.
Malcolm Staudinger
Information Security Analyst | EIS
EarthLink
E: mstaudin...@corp.earthlink.com
-Original Message-
From: Blake Hudson [mailto:bl...@ispn.net]
Sent: Tuesday, February 25, 2014 8:58 AM
To: nanog@nanog.org
Subject: Re: Filter NTP traffic
On Wed, Feb 26, 2014 at 6:56 AM, Keegan Holley no.s...@comcast.net wrote:
More politely stated, it’s not the responsibility of the operator to
decide what belongs on the network and what doesn’t. Users can run any
services that’s not illegal or even reuse ports for other applications.
That
- Original Message -
From: Brandon Galbraith brandon.galbra...@gmail.com
On Wed, Feb 26, 2014 at 6:56 AM, Keegan Holley no.s...@comcast.net
wrote:
More politely stated, it’s not the responsibility of the operator to
decide what belongs on the network and what doesn’t. Users can run
On Wed, 26 Feb 2014 11:44:55 -0600, Brandon Galbraith said:
Blocking chargen at the edge doesn't seem to be outside of the realm of
possibilities.
What systems are (a) still have chargen enabled and (b) common enough to make
it a viable DDoS vector? Just wondering if I need to go around and
On Feb 26, 2014, at 5:33 PM, valdis.kletni...@vt.edu wrote:
On Wed, 26 Feb 2014 11:44:55 -0600, Brandon Galbraith said:
Blocking chargen at the edge doesn't seem to be outside of the realm of
possibilities.
What systems are (a) still have chargen enabled and (b) common enough to make
it
On 2/26/2014 5:33 PM, valdis.kletni...@vt.edu wrote:
On Wed, 26 Feb 2014 11:44:55 -0600, Brandon Galbraith said:
Blocking chargen at the edge doesn't seem to be outside of the realm of
possibilities.
What systems are (a) still have chargen enabled and (b) common enough to make
it a viable
Most of what I've seen are reset configs on network gear, standalone devices
(printers), and the occasional win 98 box with network addons.
We put blocks in place for ntp, SNMP for a short time to get things under
control. Chargen was so small it was easier to just alert folks directly.
HTH.
On Tue, Feb 25, 2014 at 11:22 AM, Staudinger, Malcolm
mstaudin...@corp.earthlink.com wrote:
Why wouldn't you just block chargen entirely? Is it actually still being
used these days for anything legitimate?
Long term blocking based on port number is sure to result in problems.
It's more
I only ran the scan once, but had ~130k devices respond.
is there any modern utility in chargen?
On 2/26/2014 11:03 PM, Jimmy Hess wrote:
The well known port assignments are advisory or recommended, for use by
other unknown processes. the purpose of well known port
assignments is for service location; the port number is not a sequence of
application identification bits.
The QUIC
On 2/27/2014 8:09 AM, Randy Bush wrote:
I only ran the scan once, but had ~130k devices respond.
is there any modern utility in chargen?
I know of none, maybe I'm too young.
So we could conclude we don't need that service running.
But some folk use ports for services other than the intended
On Wed, Feb 26, 2014 at 11:09 PM, Randy Bush ra...@psg.com wrote:
I only ran the scan once, but had ~130k devices respond.
is there any modern utility in chargen?
Does ne'er-do-wells hitting IRC users with DCC CHAT requests targeted to
trick the victim into connecting to port 19/tcp count
I talked to one of our upstream IP transit providers and was able to
negotiate individual policing levels on NTP, DNS, SNMP, and Chargen by
UDP port within our aggregate policer. As mentioned, the legitimate
traffic levels of these services are near 0. We gave each service many
times the
: Tuesday, February 25, 2014 8:58 AM
To: nanog@nanog.org
Subject: Re: Filter NTP traffic by packet size?
I talked to one of our upstream IP transit providers and was able to negotiate
individual policing levels on NTP, DNS, SNMP, and Chargen by UDP port within
our aggregate policer. As mentioned
On 25/02/2014 17:22, Staudinger, Malcolm wrote:
Why wouldn't you just block chargen entirely?
While we're at it, why not just block everything except for tcp port 80 and
dns? Isn't that the only legitimate traffic on the interweb these days?
Nick
| EIS
EarthLink
E: mstaudin...@corp.earthlink.com
-Original Message-
From: Blake Hudson [mailto:bl...@ispn.net]
Sent: Tuesday, February 25, 2014 8:58 AM
To: nanog@nanog.org
Subject: Re: Filter NTP traffic by packet size?
I talked to one of our upstream IP transit providers and was able
On Tue, Feb 25, 2014 at 8:58 AM, Blake Hudson bl...@ispn.net wrote:
I talked to one of our upstream IP transit providers and was able to
negotiate individual policing levels on NTP, DNS, SNMP, and Chargen by UDP
port within our aggregate policer. As mentioned, the legitimate traffic
levels of
We have had pretty good success in identifying offenders with simple
monitoring flow data for NTP flows destined for our address space with
packet counts higher than 100; we disable them and notify to correct
the configuration on the host. Granted we only service about 1,000
different customers.
On Feb 23, 2014, at 4:39 PM, James Braunegg james.braun...@micron21.com
wrote:
Dear All
I released a bit of a blog article last week about filtering NTP request
traffic via packet size which might be of interest !
So far I known of an unknown tool makes a default request packet of 50
Ive talked to some major peering exchanges and they refuse to take any action.
Possibly if the requests come from many peering participants it will be taken
more seriously?
On Feb 22, 2014, at 19:23, Peter Phaal peter.ph...@gmail.com wrote:
Brocade demonstrated how peering exchanges can
On Sun, 23 Feb 2014, Chris Laffin wrote:
Ive talked to some major peering exchanges and they refuse to take any action.
Possibly if the requests come from many peering participants it will be taken
more seriously?
If only there was more focus on the BCP38 offenders who are the real root
What is the business model for the IX? Unauthorized filtering of
incoming traffic risks collateral damage and outing exchange members
seems problematic.
The business model seems clearer when offering filtering as a service
to downstream networks, the effects are narrowly scoped, and members
have
The business model seems clearer when offering filtering as a service
to downstream networks, the effects are narrowly scoped, and members
have control over the traffic they accept from the exchange, e.g. I
don't want to accept NTP traffic to any destination that exceeds
1Gbit/s, or is
On 23 Feb 2014, at 18:29, sth...@nethelp.no wrote:
Speaking only for myself: No. The L2 IXes I connect to should use their
resources for packet switching, not filtering. Way too many things that
could go wrong if we go down the filtering path…
Indeed. Most of the L2 IXes run on very
On Sun, 23 Feb 2014, Lukasz Bromirski wrote:
To do some additional checks would require extensive testing, platforms
capable of doing this in predictable manner (stability, performance) and
obviously - a lot more work than it costs today.
A lot of IXes already do sFlow so all the work I
On Feb 23, 2014, at 9:50 AM, Lukasz Bromirski luk...@bromirski.net wrote:
To do some additional checks would require extensive testing, platforms
capable of doing this in predictable manner (stability, performance)
and obviously - a lot more work than it costs today.
What are the costs and
Newb question ... other than retrofitting, what stands in the way of
making BCP38 a condition of peering?
Royce
On Sun, Feb 23, 2014 at 10:48 AM, Royce Williams ro...@techsolvency.com wrote:
Newb question ... other than retrofitting, what stands in the way of
making BCP38 a condition of peering?
In other words ... if it's a problem of awareness, could upstreams
automate warning their downstreams? What
On 2/23/14, 12:11 PM, Royce Williams wrote:
On Sun, Feb 23, 2014 at 10:48 AM, Royce Williams ro...@techsolvency.com
wrote:
Newb question ... other than retrofitting, what stands in the way of
making BCP38 a condition of peering?
Peering is frequently but harldy exclusively on a best effort
your computer.
-Original Message-
From: joel jaeggli [mailto:joe...@bogus.com]
Sent: Monday, February 24, 2014 7:31 AM
To: Royce Williams; nanog@nanog.org
Subject: Re: Filter NTP traffic by packet size?
On 2/23/14, 12:11 PM, Royce Williams wrote:
On Sun, Feb 23, 2014 at 10:48 AM, Royce
What is the business model for the IX? Unauthorized filtering of
incoming traffic risks collateral damage and outing exchange members
seems problematic.
I never proposed for them to filter.
What is missing is filtering at IXP not by IXP.
Most transits have blackhole communities so you
Ive talked to some major peering exchanges and they refuse to take any
action. Possibly if the requests come from many peering participants
it will be taken more seriously?
i have talked to fiber providers and they have refused to take action.
perhaps if requests came from hundreds of the
On 22 Feb 2014, at 08:47, Saku Ytti s...@ytti.fi wrote:
I'm surprised MinimaLT and QUIC have have not put transport area people in
high gear towards standardization of new PKI based L4 protocol, I think its
elegant solution to many practical reoccurring problem, solution which has
become
On Sat, Feb 22, 2014 at 12:38 AM, Carsten Bormann c...@tzi.org wrote:
On 22 Feb 2014, at 08:47, Saku Ytti s...@ytti.fi wrote:
I'm surprised MinimaLT and QUIC have have not put transport area people in
high gear towards standardization of new PKI based L4 protocol, I think its
elegant solution
(Just be careful not to try to fight yesterday's war”.)
yesterday's war = don't bring up that operators are having a real
problem with UDP,
No, you don’t.
You are having a problem with applications that enable strongly amplified
reflection.
(Yes, after the days of smurf passed, these are
On 22/02/2014 09:07, Cb B wrote:
Summary IETF response: The problem i described is already solved by
bcp38, nothing to see here, carry on with UDP
udp is here to stay. Denying this is no more useful than trying to push
the tide back with a teaspoon.
It's worth bearing in mind that any open
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2/22/2014 7:06 AM, Nick Hilliard wrote:
On 22/02/2014 09:07, Cb B wrote:
Summary IETF response: The problem i described is already solved
by bcp38, nothing to see here, carry on with UDP
udp is here to stay. Denying this is no more
Has anyone talked about policing ntp everywhere. Normal traffic levels are
extremely low but the ddos traffic is very high. It would be really cool if
peering exchanges could police ntp on their connected members.
On Feb 22, 2014, at 8:05, Paul Ferguson fergdawgs...@mykolab.com wrote:
The obvious solution for a new protocol is to make sure that it
doesn’t have that problem, whether it is layered on UDP or something
else.
i'll settle for configured by default not to welcome amplification
queries with open arms.
let's not throw the baby out with the bathwater (excuse the
Brocade demonstrated how peering exchanges can selectively filter
large NTP reflection flows using the sFlow monitoring and hybrid port
OpenFlow capabilities of their MLXe switches at last week's Network
Field Day event.
http://blog.sflow.com/2014/02/nfd7-real-time-sdn-and-nfv-analytics_1986.html
Dobbins, Roland writes:
Operators are using this size-based filtering to effect without
breaking the world.
As a reality check, with this filtering in place does ntptrace still
work?
H
On Thu, Feb 20, 2014 at 2:12 PM, Damian Menscher dam...@google.com wrote:
On Thu, Feb 20, 2014 at 1:03 PM, Jared Mauch ja...@puck.nether.net wrote:
On Feb 20, 2014, at 3:51 PM, John Weekes j...@nuclearfallout.net wrote:
On 2/20/2014 12:41 PM, Edward Roels wrote:
Curious if anyone else
On Feb 22, 2014 5:30 AM, Damian Menscher dam...@google.com wrote:
On Fri, Feb 21, 2014 at 1:22 PM, Cb B cb.li...@gmail.com wrote:
On Thu, Feb 20, 2014 at 2:12 PM, Damian Menscher dam...@google.com
wrote:
On Thu, Feb 20, 2014 at 1:03 PM, Jared Mauch ja...@puck.nether.net
wrote:
You may also
Isn't UDP 80 still technically registered to HTTP?
~Seth
On (2014-02-21 14:37 -0800), Cb B wrote:
QUIC can do what it wants. Like anyone else, they pay their money and take
their chances. But, the data point that UDP is polluted is clearly
documented with several folks on this list suggesting tactical fixes that
involve limiting UDP, especially
Curious if anyone else thinks filtering out NTP packets above a certain
packet size is a good or terrible idea.
From my brief testing it seems 90 bytes for IPv4 and 110 bytes for IPv6 are
typical for a client to successfully synchronize to an NTP server.
If I query a server for it's list of
On 2/20/2014 12:41 PM, Edward Roels wrote:
Curious if anyone else thinks filtering out NTP packets above a certain
packet size is a good or terrible idea.
From my brief testing it seems 90 bytes for IPv4 and 110 bytes for IPv6 are
typical for a client to successfully synchronize to an NTP
On Feb 20, 2014, at 3:51 PM, John Weekes j...@nuclearfallout.net wrote:
On 2/20/2014 12:41 PM, Edward Roels wrote:
Curious if anyone else thinks filtering out NTP packets above a certain
packet size is a good or terrible idea.
From my brief testing it seems 90 bytes for IPv4 and 110 bytes
Filtering will always break something. Filtering 'abusive' network traffic is
intentionally difficult - you either just let it be, or you filter it along
with the 'good' network traffic that it's pretending to be. How can you even
tell it's NTP traffic - maybe by the port numbers? What if
On Feb 20, 2014, at 4:05 PM, Laszlo Hanyecz las...@heliacal.net wrote:
Filtering will always break something. Filtering 'abusive' network traffic
is intentionally difficult - you either just let it be, or you filter it
along with the 'good' network traffic that it's pretending to be. How
On 2/20/14, 3:41 PM, Edward Roels edwardro...@gmail.com wrote:
Curious if anyone else thinks filtering out NTP packets above a certain
packet size is a good or terrible idea.
From my brief testing it seems 90 bytes for IPv4 and 110 bytes for IPv6
are
typical for a client to successfully
On Feb 21, 2014, at 3:41 AM, Edward Roels edwardro...@gmail.com wrote:
From my brief testing it seems 90 bytes for IPv4 and 110 bytes for IPv6 are
typical for a client to successfully synchronize to an NTP server.
Correct. 90 bytes = 76 bytes + Ethernet framing.
Filtering out packets this
On Feb 21, 2014, at 9:55 AM, Dobbins, Roland rdobb...@arbor.net wrote:
Filtering out packets this size from UDP/anything to UDP/123 allows time-sync
requests and responses to work, but squelches both the level-6/-7 commands
used to trigger amplification as well as amplified attack traffic.
On Feb 21, 2014, at 9:55 AM, Dobbins, Roland rdobb...@arbor.net wrote:
Filtering out packets this size from UDP/anything to UDP/123 allows time-sync
requests and responses to work, but squelches both the level-6/-7 commands
used to trigger amplification as well as amplified attack traffic.
Type Enforcement in the OS Kernel is the place to do that.
Todd
On 2/20/2014 2:12 PM, Damian Menscher wrote:
On Thu, Feb 20, 2014 at 1:03 PM, Jared Mauch ja...@puck.nether.net wrote:
On Feb 20, 2014, at 3:51 PM, John Weekes j...@nuclearfallout.net wrote:
On 2/20/2014 12:41 PM, Edward Roels
On Feb 21, 2014, at 11:40 AM, Harlan Stenn st...@ntp.org wrote:
As a reality check, with this filtering in place does ntptrace still work?
No, it will not.
In order to minimize overblocking of this nature, filtering of this nature
should be used with the highest possible degree of
69 matches
Mail list logo
