On Nov 28, 2012, at 12:32 PM, Nigel Stepp wrote:
So there's one data point with the promise of others.
You are atypical in comparison the the legions of ordinary developers within
enterprise organizations, in terms of your skillset, your breadth of
perspective, and your ability to effectuate
On Nov 26, 2012, at 5:57 PM, Randy Bush wrote:
almost all ip traffic is unintentional.
Sure. But my point is the notion that observed IPv6 traffic volumes are due to
deliberate migration is not correct.
when the average consumer (real) broadband connection becomes v6 capable,
about 40%
On Nov 26, 2012, at 7:10 PM, Arturo Servin wrote:
Users do not care and they will never have a deliberate migration.
I understand this. However, the way that IPv6 migration is discussed in most
contexts seems to be predicated upon the notion that there is some industry
imperative to
On Nov 26, 2012, at 8:33 PM, Mikael Abrahamsson wrote:
Why is that a significant question?
It is significant because it provides some rough measure of the relative
*importance* of IPv6 connectivity to the users and to the content/app/services
networks.
We are not yet at the point where
On Nov 26, 2012, at 10:36 PM, Cameron Byrne wrote:
Ipv6 is not important for users, it is important for network operators who
want to sustain their business.
I agree with the first part; not sure I agree with the second part.
Nope. Nobody will leave money on the table by alienating users.
On Nov 27, 2012, at 3:37 AM, Owen DeLong wrote:
If you don't think that the need to sustain the growth in the number of
devices attached to the network (never mind the number of things causing that
rate to accelerate[1]) makes IPv6 inevitable at this point, you really aren't
paying
On Nov 27, 2012, at 12:15 AM, Cameron Byrne wrote:
NAT is bad.
I agree wholeheartedly with this sentiment. I'm unsure whether or not this is
the prevalent view amongst those who control the pursestrings within network
operators, however.
On Nov 27, 2012, at 3:37 AM, Owen DeLong wrote:
CGN does not scale and cannot scale. At best, it's a hack that might allow us
to cope with a few years of transition while there are still devices in homes
that are IPv4-only, but it certainly doesn't reduce or remove the imperative.
I agree
On Nov 27, 2012, at 12:38 AM, Tony Hain wrote:
Unfortunately most people that actually deploy and support applications can't
make the math come out right when the access providers don't provide a
path to 99% of the paying customers, then do just about everything they can
to hobble bypass
On Nov 27, 2012, at 6:56 AM, Michael Thomas wrote:
Er, uh, huh? v6 has been available forever on the usual suspect host
operating systems, and most server side apps don't need to do much to support
lighting
v6 support up that I can think of.
Where are the *deployments*, though?
And
On Nov 27, 2012, at 7:12 AM, Carsten Bormann wrote:
We have seen your kind of thinking.
You totally mischaracterize my 'kind of thinking'. My entire career arc has
been that of a technological evangelist. Yes, I think there's a lot that's
wrong with IPv6, but it appears that it's the only
On Nov 27, 2012, at 7:35 AM, Michael Thomas wrote:
Not on the server side that I can see. It's a network problem first and
foremost, and starts by having the excuse that they can't get v6 upstream
from their ISP's.
It's hugely problematic to accomplish internally, never mind for external
On Nov 27, 2012, at 7:27 AM, Cutler James R wrote:
Have you looked at the current Apple software? It pretty much just works
on IPv6.
Yes, but it doesn't do or enable anything via IPv6 that it doesn't do or enable
via IPv4.
This also automatically brings along IPv6 capabilities.
On Nov 27, 2012, at 7:53 AM, Michael Thomas wrote:
If they don't commit, the game of chicken continues.
Right - so, what new capabilities/economies of scale/essential conveniences are
made possible by IPv6 but not IPv4, pour encourager les autres?
This is not a rhetorical question. I
On Nov 27, 2012, at 8:15 AM, Owen DeLong wrote:
Interesting. All the IPv6 capable carriers I talk to are only
gatewaying/proxying to IPv4 for things unreachable via IPv6.
Which is pretty much everything on the Internet.
If you've got an IPv6 capable cell phone on an IPv6 capable mobile
On Nov 27, 2012, at 8:07 AM, Cutler James R wrote:
Those content/services/applications will only be reachable via IPv6 because
that is all that can be deployed without truly horrendous and costly
mismanagement of IPv4 address space.
Our views differ in that it is my belief that said truly
On Nov 27, 2012, at 11:57 AM, Mikael Abrahamsson wrote:
The problem is that CGN and NAT444 works with todays devices, whereas IPv6
does not (thinking mobile devices and residential CPEs).
Yet everyone (except you) insist that it does work with everything, and that
all this CGN and 444 stuff
On Nov 25, 2012, at 10:09 AM, joel jaeggli wrote:
from goeff huston's data they have more v6 at home.
And not purposely, either - because it's enabled by default on recent client
OSes. My guess is that a non-trivial fraction of observed IPv6 traffic today
is unintentional.
On Nov 7, 2012, at 5:56 PM, Mohamed Al-fateh wrote:
Could you please share them with us or direct us to other good resources for
that
https://www.box.com/s/4h2l6f4m8is6jnwk28cg
---
Roland Dobbins rdobb...@arbor.net //
On Nov 6, 2012, at 6:32 PM, Tassos Chatzithomaoglou wrote:
Do you consider them infrastructure addresses or customer addresses?
They're infrastructure addresses.
Do you put them in your IGP or in BGP?
You should treat them as you do your other infrastructure addresses (i.e., if
you're
On Nov 6, 2012, at 7:31 PM, Tassos Chatzithomaoglou wrote:
Only specific types of icmp messages?
That, plus the routing session (if any) with your customer, plus anything else
that's situationally-specific (GRE tunnel termination, etc.).
On Oct 25, 2012, at 8:40 PM, Scott Howard wrote:
Same from here.
dig www.facebook.com.
; DiG 9.7.3-P3 www.facebook.com.
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 41039
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2
On Oct 25, 2012, at 8:50 PM, Jeroen Massar wrote:
www.facebook.com. 120 IN 2a03:2880:2050:1f01:face:b00c::
I found this to be rather amusing.
;
Note that is 2110 != 2050.
Right.
But now indeed to the c10r one... thus there are at least a couple of
clusters it seems
On Oct 23, 2012, at 5:24 AM, Templin, Fred L wrote:
Since tunnels always reduce the effective MTU seen by data packets due to the
encapsulation overhead, the only two ways to accommodate
the tunnel MTU is either through the use of path MTU discovery or through
fragmentation and reassembly.
On Oct 16, 2012, at 8:57 AM, Ryan Malayter wrote:
10G+ forwarding with minimum packet sizes is possible on a single core using
optimized kernels (see Intel DPDK and PF_RING DNA).
Of course it isn't. You can *approach* 10gb/sec with multiple cores and
minimum packet sizes, granted.
You
On Oct 14, 2012, at 4:48 PM, Shahab Vahabzadeh wrote:
Does any body know what kind of attack can be come to port 0?
If it's protocol 0, instead of port 0, it's likely a packet-flooding DDoS
attack.
If it's port 0, you may be incorrectly blocking non-initial fragments.
Alternately, it could
On Oct 15, 2012, at 2:59 AM, Shahab Vahabzadeh wrote:
I think it act like a warm or some attacks which cause high CPU load in some
IOS.
i.e., a DDoS attack.
You should configure iACLs at your edge so that random sources on the Internet
can't packet your routers. Hopefully, you have
On Oct 15, 2012, at 3:57 AM, Nick Hilliard wrote:
If you haven't already configured CoPP on your BRASs, you might want to look
at deploying it.
CoPP is pretty much a wash on software-based boxes; it only really helps on
hardware-based boxes. And iACLs is easier/a bigger win, anyways
On Oct 4, 2012, at 9:26 PM, Sander Steffann wrote:
The closer you get to the edge the more common it might become...
iACLs should be implemented at the network edge to drop all IPv4 and IPv6
traffic - including non-initial fragments - directed towards point-to-point
links, loopbacks, and
On Oct 4, 2012, at 9:58 PM, joel jaeggli wrote:
Likewise with the acl I have the property that the initial packet has
all the info in it while the fragment does not.
For iACLs, just filter non-initial fragments directed to infrastructure IPs.
Cisco Juniper ACLs have ACL matching criteria
On Sep 23, 2012, at 7:55 PM, Danny McPherson wrote:
If the *flow generation process is not performed on the router (or otherwise
conveyed by some metadata outside of raw [sampled] packet headers) then you
lose visibility to ingress and egress ifIndex (interface) information --
information
On Sep 23, 2012, at 11:23 PM, Peter Phaal wrote:
The difference between packet oriented or flow oriented export is an
implementation detail if your only requirement is to obtain layer IP flow
records, but becomes significant if you want to create customized flow
records or create packet
On Sep 23, 2012, at 1:51 AM, Peter Phaal wrote:
Here are some comments and links to additional information that address each
of your concerns:
You have misinterpreted what I said. I was saying that flow telemetry of any
variety must be exported from edge devices, which in most cases are
On Sep 22, 2012, at 12:40 AM, Peter Phaal wrote:
However, moving the flow generation out of the router gives a lot of
flexibility.
Actually, moving it out of the router creates huge problems and destroys a lot
of the value of the flow telemetry - it nullifies your ability to traceback
On Aug 20, 2012, at 5:24 PM, Patrick W. Gilmore wrote:
But I do not think returning multiple A records for multiple datacenters is
as useful as lowering the TTL.
Some folks do this via various GSLB mechanisms which selectively respond with
different records based on the assumed relative
On Aug 20, 2012, at 5:56 PM, Patrick W. Gilmore wrote:
My question above is asking Mark how you guarantee the user/application
selects the A record closest to them and only use the other A record when the
closer one is unavailable.
I understand - my point was that folks using a GSLB-type
On Jul 25, 2012, at 12:08 PM, Jimmy Hess wrote:
The packet is a non-initial fragment if and only if, the fragmentation
offset is not set to zero. Port number's not a field you look at for that.
I understand all that, thanks.
NetFlow reports source/dest port 0 for non-initial fragments.
On Jul 25, 2012, at 1:13 PM, sth...@nethelp.no wrote:
No, routers normally do *not* reassemble fragments.
Absolutely correct. I missed this in the rest of the reply, good catch!
---
Roland Dobbins rdobb...@arbor.net //
On Jul 25, 2012, at 9:52 PM, Joel Maslak wrote:
In addition to the fragments, these packets might also be non-TCP/UDP (ICMP,
GRE, 6to4 and other IP-IP, etc).
NetFlow will report the correct protocol number.
---
Roland
On Jul 25, 2012, at 10:27 PM, Frank Bulk wrote:
Can netflow _properly_ capture whether a packet is a fragment or not?
No.
If not, does IPFIX address this?
Yes.
But this is all a distraction. We are now down in the weeds.
Your customers were victims of a DNS reflection/amplification
On Jul 26, 2012, at 5:13 AM, Drew Weaver wrote:
Another nice emerging tool [I say emerging because it's been around forever
but nobody implements it] to deal with this is Flowspec, using flowspec you
can instruct your Upstream to block traffic with much more granular
characteristics.
On Jul 19, 2012, at 3:50 PM, Måns Nilsson wrote:
No, reusing somebody's prefix is A Very Bad Idea.
Concur 100%. There is no security value to doing this whatsoever - quite the
opposite, given the possible negative consequences to reachability and, thus,
availability.
On Jun 18, 2012, at 10:50 AM, Jonathon Exley wrote:
APNIC has a web based whois form that is pretty easy to drive.
Yes, but data-entry tools which are viewed as secondary to the task at hand -
i.e., address allocations - and which require interactive human participation
to perform
On Jun 18, 2012, at 11:23 AM, Mark Andrews wrote:
APNIC has B2B over email. It should be possible to totally automate updating
APNIC.
That's a much better option than the Web form.
---
Roland Dobbins rdobb...@arbor.net //
On Jun 11, 2012, at 10:13 PM, Jay Ashworth wrote:
Or are spoofed-source-address attacks not, as Vix suggests, significant and
trending upwards?
They're enjoying a renaissance because of attackers leveraging spoofing in
order to enable DNS, SNMP, and ntp reflection/amplification DDoS
On Jun 11, 2012, at 11:09 PM, Jay Ashworth wrote:
So, are the knobs actually on? (I'm guessing clearly, not)
In many cases, no, or we wouldn't be seeing many spoofed packets, would we?
;
---
Roland Dobbins
On Jun 9, 2012, at 2:09 AM, Joe Maimon wrote:
Google and Level3 manage to run open resolvers, why cant I?
Because they have probably have opsec resources you don't. If you can't defend
it/keep it from being abused, don't do it.
;
On Jun 5, 2012, at 9:29 PM, David Hubbard wrote:
security practices
http://www.ciscopress.com/bookstore/product.asp?isbn=1587055945
http://www.ciscopress.com/bookstore/product.asp?isbn=1587053365
---
Roland Dobbins
On Apr 28, 2012, at 5:05 AM, Paul Vixie wrote:
is anybody taking it seriously?
It's hard to take seriously any proposal which is predicated upon recursive
dependencies.
---
Roland Dobbins rdobb...@arbor.net //
On Apr 28, 2012, at 5:17 PM, Saku Ytti wrote:
People might scared to rely on DNS on accepting routes, but is this really an
issue?
Yes, recursive dependencies are an issue. I'm really surprised that folks are
even seriously considering something like this, but OTOH, this sort of thing
On May 1, 2012, at 8:18 PM, David Conrad wrote:
Do you mean the need to be able to use rsync to fetch the data to enable you
to use rsync?
A lot more than just rsync is necessary in order to allow rsync transactions to
work. But, you know this already.
;
Or the need to be able to use
On May 1, 2012, at 10:31 PM, John Kristoff wrote:
As Radia says in her book, we're probably stuck with BGP forever, but I
frequently wonder if she is right in suggesting we could have done
better by having a link state protocol instead.
At the time, link-state protocols weren't practical
On May 2, 2012, at 12:46 AM, Russ White wrote:
There are situations where it won't work (mostly thinking high mobility
environments, or complete system failures), but these don't seem to be big
stoppers, to me
Within the next 10 years, everything/everywhere is going to become a
On Mar 10, 2012, at 7:02 PM, Robert E. Seastrom wrote:
there are four gtlds
Aren't there actually seven?
---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com
Luck is the residue of opportunity and
On Feb 26, 2012, at 5:39 AM, Dongting Yu wrote:
you drop updates, which would lead to inconsistent views on the two sides of
the session.
Views are inconsistent by design - there is no state synchronization. All a
sender knows is that he sent the updates, not what (if anything) was done
On Feb 26, 2012, at 7:55 AM, Christopher Morrow wrote:
I'm not sure... here's a few ideas though to toss on the fire of thought:
Concur with this general approach, which is a longer-term effort - but it would
be nice if there was some discrete, limited-scope knob which could conceivably
be
On Feb 25, 2012, at 7:49 AM, Randy Bush wrote:
i would love to see progress on the route leak problem. i do not confuddle
it with security.
Availability is a key aspect of security - the most important one, in many
cases/contexts. The availability of the control plane itself (i.e., being
On Feb 25, 2012, at 8:59 AM, Christopher Morrow wrote:
max-prefix already exists... sometimes it works, sometimes it's a burden.
Some sort of throttle - i.e., allow only X number of routing updates within Y
number of [seconds? milliseconds? BGP packets?] would be more useful, IMHO.
If the
On Feb 25, 2012, at 9:39 AM, Christopher Morrow wrote:
it seems to me that most of the options discussed for this are .. bad, in one
dimension or another :(
Concur.
X prefixes/packets in Y seconds/milliseconds doesn't keep the peer from
blowing up your RIB,
How so? If the configured
On Feb 25, 2012, at 2:15 PM, Christopher Morrow wrote:
if the rate is 1/ms ... I can fill the rib in 2million ms ... ~30mins? Rate
alone isn't the problem :( size matters.
Sure; the idea is that some sort of throttling, coupled with overall size
limitations, might be useful.
People
On Feb 24, 2012, at 9:00 AM, Danny McPherson wrote:
Prefix limits are rather binary and indiscriminate, indeed.
AS-PATH filters and max-length filters, OTOH, are not.
Also, it's important that network operators understand that flap-dampening has
been iatrogenic for many years, now.
On Feb 8, 2012, at 2:56 PM, bas wrote:
The big drawback with S/RTBH is that it is a DoS method in itself.
I'm not an advocate of *automated* S/RTBH, and I am an advocate of whitelisting
various well-known 'golden networks/IPs' via prefix-lists in order to avoid
this issue in part; also, note
On Feb 8, 2012, at 8:07 PM, bas wrote:
As far as I see it S/RTBH is in no way a solution against smart attackers, of
course it does help against all the kiddie attacks out
there.
Once again, I've used S/RTBH myself and helped others use it many, many times,
including to defend against
[Apologies if you've already seen this announcement in other forums.]
We've just posted the 2011 Worldwide Infrastructure Security Report for
download at this URL:
http://www.arbornetworks.com/report
This year's WWISR contains responses and data from 114 network operators in all
major
On Feb 8, 2012, at 10:20 AM, Ryan Rawdon wrote:
Assuming it is not a futile/wasted effort, where is the current best
place/resource to report an active botnet CC to?
Probably the abuse contact for the network in question, if contact info is
available.
On Feb 7, 2012, at 1:37 PM, Peter Ehiwe wrote:
What is the best way to mitigate DOS attack against the bgp process of a
router ,
iACLs and CoPP:
https://files.me.com/roland.dobbins/prguob
---
Roland Dobbins
On Feb 6, 2012, at 7:21 AM, Keegan Holley wrote:
There aren't very many ways to combat DDOS.
Start with the various infrastructure/host/service BCPs, and S/RTBH, as
outlined in this preso:
https://files.me.com/roland.dobbins/dweagy
On Feb 6, 2012, at 8:10 AM, Keegan Holley wrote:
An entire power point just to recommend ACL's, uRPF, CPP, DHCP snooping, and
RTBH?
Actually, no, that isn't the focus of the preso.
The first four will not work against a DDOS attack
This is incorrect - suggest you read the preso.
and the
On Feb 6, 2012, at 8:20 AM, Dobbins, Roland wrote:
Actually, no, that isn't the focus of the preso.
More info here:
https://files.me.com/roland.dobbins/l53gjr
---
Roland Dobbins rdobb...@arbor.net // http
On Feb 6, 2012, at 8:37 AM, Keegan Holley wrote:
Source RTBH often falls victim to rapidly changing or spoofed source IPs.
S/RTBH can be rapidly shifted in order to deal with changing purported source
IPs, and it isn't limited to /32s. It's widely supported on Cisco and Juniper
gear
On Feb 6, 2012, at 8:50 AM, Keegan Holley wrote:
Yes but assuming everything discussed at a conference is instantly adopted by
the entire industry gives one false hope no?
I'm certainly not making that assumption - hence the presos.
;
On Jan 18, 2012, at 2:45 AM, Leigh Porter wrote:
The firewall is significant because the attacks killed the firewall as it is
rather under specified (not my idea..).
DNS servers (nor any other kind of server, for that matter) should never be
placed behind stateful firewalls - the largest
On Dec 30, 2011, at 9:34 PM, Cameron Byrne wrote:
The state of the industry is the support of nomadic mobility from cellular to
/ from Wi-Fi , there is nearly no support of mobile IP that I have seen.
Concur. This .pdf preso may also be of interest:
On Dec 27, 2011, at 6:47 PM, Joe wrote:
is there any overview on current technology or method dealing with DDoS
attack ?
https://files.me.com/roland.dobbins/prguob
https://files.me.com/roland.dobbins/k4zw3x
https://files.me.com/roland.dobbins/dweagy
On Dec 8, 2011, at 1:04 AM, Gregory Croft wrote:
Just investigating to see if there is a reason I shouldn't use a firewall at
the edge versus a dedicated router
You should only use a dedicate router if you want your network to remain
available.
;
On Dec 8, 2011, at 1:36 AM, Leo Bicknell wrote:
I don't think you're looking at defense in depth in the right way,
Actually, it sometimes seems as if nobody in the industry understands what
'defense in depth' really means, heh.
'Defense in depth' is a military term of art which equates to
On Dec 7, 2011, at 6:20 AM, Robert Brockway wrote:
This is completely separate to whether servers should even have a firewall or
IPS in front of them. That's another (interesting) discussion :)
http://www.nanog.org/meetings/nanog48/presentations/Monday/Kaeo_FilterTrend_ISPSec_N48.pdf
On Nov 28, 2011, at 5:31 PM, Owen DeLong wrote:
Making it harder to spread misinformation and FUD is good.
Making it harder to share information is bad.
Unfortunately, it's often quite difficult to distinguish between the two when
formulating policies, regulations, legislation, and so forth.
On Nov 26, 2011, at 10:14 AM, Jay Ashworth wrote:
traveling in Russia on personal business.
I've noticed that in general, when there isn't an actual attack taking place,
but rather some kind of misconfiguration or other issue, there's all too often
a tendency to run around shouting about the
On Nov 24, 2011, at 11:41 AM, Jonathon Exley wrote:
I have a personal hate of text based menus and binary config backup files.
So, the obvious solution is to buy the products of vendors whose CLIs one finds
least offensive, is it not?
;
[Apologies if you've already seen this message in other forums.]
We'd be grateful if folks who've yet to do so would take a few minutes to
participate in the 2011 WISR opsec survey - responses will be tabulated on
Sunday, 20Nov11, and input from the operational community is greatly
On Nov 13, 2011, at 10:36 PM, Jason Lewis wrote:
I don't want to start a flame war, but this article seems flawed to me.
The real issue is interconnecting SCADA systems to publicly-routed networks,
not the choice of potentially routable space vs. RFC1918 space for SCADA
networks, per se.
On Nov 14, 2011, at 6:29 AM, Jay Ashworth wrote:
SCADA networks should be hard air-gapped from any other network.
Concur, GMTA. My point is that without an airgap, the attacker can jump from a
production network to the SCADA network, so we're in violent agreement.
;
On Nov 14, 2011, at 9:24 AM, Joe Greco wrote:
Getting fixated on air-gapping is unrealistically ignoring the other threats
out there.
I don't think anyone in this thread is 'fixated' on the idea of airgapping; but
it's generally a good idea whenever possible, and as restrictive a
On Nov 8, 2011, at 5:56 PM, bmann...@vacation.karoshi.com wrote:
how would a sidr-enabled routing infrastructure have fared in yesterdays
routing circus?
The effects of large amounts of route-churn on the auth chain - perhaps DANE? -
might've been interesting . . .
On Nov 9, 2011, at 1:14 AM, bmann...@vacation.karoshi.com wrote:
that was/is kindof orthoginal to the question... would the sidr plan for
routing security have been a help in this event?
SIDR is intended to provide route-origination validation - it isn't intended to
be nor can it possibly
On Nov 9, 2011, at 1:22 AM, Dobbins, Roland wrote:
Validation storm-control is something which must be accounted for in
SIDR/DANE architecture, implementation, and deployment. But at the end of
the day, vendors are still responsible for their own code.
To be clear, I was alluding to some
On Nov 9, 2011, at 4:22 AM, Christopher Morrow wrote:
the routers have (in some form of the plan) a cache
A cache that's persistent across reboots?
---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com
On Nov 9, 2011, at 5:19 AM, Nick Hilliard wrote:
One solution is to have directly-connected rpki caches available to all your
bgp edge routers throughout your entire network.
They don't have to be directly-connected - they could be on the DCN, which
ought to have at least some static
On Nov 7, 2011, at 1:14 PM, David Hubbard wrote:
Hi all, I am looking at cellular-based devices as a higher speed alternative
to dial-up backup access methods for
out of band management during emergencies.
Some of the lower-end Cisco routers have '3G' interfaces available as an
option, I
On Nov 1, 2011, at 1:28 PM, Jack Bates wrote:
I'm confused as to the 6to4 gateway state. Last I checked, all my 6to4 is
stateless.
Depends upon the technology being used. I probably should've used a different
term.
My load balancers are also stateless.
Most are not, or aren't configured
On Nov 1, 2011, at 11:44 AM, Cameron Byrne wrote:
Unfotunately ISPs are deploying many middle boxen, frequently in series, for
various reasons...cough cough cgn.
This AusNOG presentation touches upon the topic:
http://www.ausnog.net/images/ausnog-05/presentations/7-2-stateofdanger.pdf
[Apologies if you've already seen this announcement in other forums.]
Request for participation - Arbor 2011 Worldwide Infrastructure Security
Report.
-
Folks,
We're in the process of collecting survey responses for the 2011 Worldwide
Infrastructure Security Report (WWISR); this is the
On Oct 14, 2011, at 10:43 PM, Bill Woodcock wrote:
404
I just saw that, thanks - it seems that DDoS attacks are comparatively easy to
handle, compared to niggling little details such as URL redirects.
;
Apologies for the inconvenience, the link will be active RSN!
On Oct 14, 2011, at 10:43 PM, Bill Woodcock wrote:
The page you requested cannot be found.
Fixed, thanks!
---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com
The basis of optimism is sheer
On Oct 10, 2011, at 7:46 PM, Nick Hilliard wrote:
if it's wifi that's causing the trouble, the usual causes are:
Don't forget RFI and various forms of spoofing used for MITM.
;
---
Roland Dobbins rdobb...@arbor.net //
On Sep 30, 2011, at 9:45 PM, Christopher Morrow wrote:
enough is enough please stop doing this.
Yes, but keep in mind that this particular issue has to do with an ASIC which
is several years old and which contains other significant handicaps as well
(viz. NetFlow caveats, no per-interface
On Sep 30, 2011, at 11:44 PM, Christopher Morrow wrote:
this is exactly why punting anything NOT management and/or routing-protocols
should be banned. Thanks for making that point explicitly.
And this is the requirement which should be placed in RFPs, along with other
specific requirements
On Sep 17, 2011, at 3:01 AM, Charles N Wyble wrote:
One aspect of my network, will be operational transparency. So as much as
possible will be viewable in real time. This includes v4/v6 traffic
statistics.
These books are required reading, IMHO:
On Sep 13, 2011, at 1:42 AM, Ben Albee wrote:
Does anybody currently use vyatta as a bgp router for their company?
The days of public-facing software-based routers were over years ago - you need
an ASIC-based edge router, else you'll end up getting zorched.
201 - 300 of 561 matches
Mail list logo
