Re: Strange IPSEC traffic

[Dobbins, Roland via NANOG]

On Nov 14, 2023, at 00:12, Shawn L via NANOG  wrote:

The destination address is always one of our customer's ip addresses.


Attackers will sometimes use synthetic ESP, AH, GRE, or other protocols in DDoS 
attacks, because organizations often only think about TCP/UDP/ICMP in terms of 
ACLs, DDoS defense mechanisms, etc.



Roland Dobbins 

Re: FastNetMon Usage in the wild

[Dobbins, Roland via NANOG]

On 18 Oct 2023, at 19:49, Adam Thompson  wrote:

Sightline *Insight* is the piece the sales team won't sell me, and TAC won't 
support me, for deployment in our private-cloud environment

Insight isn’t used for first-order DDoS 
detection/classification/traceback/mitigation; Sightline/TMS provides those 
functions.

Insight is a forensics, peering analysis, and traffic-engineering tool.

I am using Sightline/TMS virtually and it's fine there.

Thanks for the clarification!

[Full disclosure:  I am an employee of NETSCOUT.]

Re: FastNetMon Usage in the wild

[Dobbins, Roland via NANOG]

On 11 Oct 2023, at 01:50, Adam Thompson  wrote:

you need to buy a moderately-expensive hardware server (they don’t let you 
virtualize it)

To clarify, Sightline has supported virtualization for many years, FYI.

 I’m not aware of any anti-DDoS products at ISP scale that aren’t SFlow + 
Flowspec, possibly including “scrubbing” (diverter box);

 I don’t know if it’s an in-band appliance, or a “scrubber”-on-a-stick

In addition to flow telemetry, D/RTBH, S/RTBH, and flowspec, Sightline/TMS 
supports intelligent DDoS mitigation directly in-line or via 
diversion/reinjection.

[Full disclosure:  I am an employee of NETSCOUT.]

Latest NETSCOUT DDoS Threat Intelligence Report published, no registration required.

[Dobbins, Roland via NANOG]

This issue covers 1H2023, and the full report is available online:



We make these findings freely available as a service to the operational 
community; feedback welcome.

Again, no registration is required to view the full report online.  A .pdf 
summary is available for download; registration is required to download the 
.pdf.

[Full disclosure: I am employed by NETSCOUT and am a contributor to this 
report.]


Roland Dobbins mailto:roland.dobb...@netscout.com>>

Re: Traffic being directed at random infrastructure with pornhub.com host header (?)

[Dobbins, Roland via NANOG]

On Sep 13, 2023, at 20:38, Drew Weaver  wrote:
Has anyone else recently seen a spike of port 80 traffic being sent at 
seemingly random IP addresses that include the Pornhub host header?

It may be related to this:


[what-is-a-reflection-amplification-ddos-attack-blog-header_1600x900.jpg]
HTTP Reflection/Amplification via Abusable Internet Censorship 
Systems
netscout.com




Roland Dobbins 

Re: AKAMAI, Re: Apple blocking all AS29852 iCloud traffic, residential gigabit last mile provider in NYC.

[Dobbins, Roland via NANOG]

On 18 Aug 2023, at 08:28, Eric Kuhnke  wrote:

Additionally this appears to have a strong correlation with everything that is 
hosted by Akamai Edge. Akamai, we are a fairly mundane last mile operator…

It might be a good idea to analyze your outbound traffic in order to determine 
if you/your customers have DDoS-capable bots and/or abusable 
reflectors/amplifiers on your/their networks which are being leveraged in 
attacks.

Re: Standard DC rack rail distance, front to back question

[Dobbins, Roland via NANOG]

On 27 Apr 2023, at 20:51, Chuck Church 
mailto:chuckchu...@gmail.com>> wrote:

  Is there a ‘standard’ distance between front and back rails that devices 
usually adhere to?

There isn’t a standard for rack depth, AFAIK, but one typically sees anywhere 
from 27in/69cm – 50in/127cm, in my experience.  42in/106.7cm & 48in/122cm are 
quite common depth dimensions.

Others here may have more specific information.

Re: Flow Tools AS-Path

[Dobbins, Roland via NANOG]

On 4 Apr 2023, at 21:48, Peter Phaal 
mailto:peter.ph...@gmail.com>> wrote:

Export of destination AS-Path is supported in the sFlow extended_gateway 
structure.

As a consumer of sFlow, [as well as NetFlow, IPFIX, etc.] I haven’t run into 
the use of this option in production, FWIW.

In addition to BGP, there are a number of MPLS, tunnel encap/decap etc. sFlow 
extended structures.

Some of these options are encountered fairly frequently; others, not so much.  
As you note, they have different applications.

Also optical interface metrics, dropped packet notifications, and more:

Dropped traffic is pretty much universally supported and utilized, in my 
experience.  Other options, again, not very often.

Some flow telemetry implementations support packet export, to one degree or 
another; and, of course, there’s PSAMP, which utilizes IPFIX as its transport.  
AFAIK, these aren’t observed very often in production, to date.


Roland Dobbins mailto:roland.dobb...@netscout.com>>

Re: Flow Tools AS-Path

[Dobbins, Roland via NANOG]

On 4 Apr 2023, at 20:04, Mike Hammett 
mailto:na...@ics-il.net>> wrote:

2) I have seen flow tools that show the entire AS path. Are they just cherry 
picking which platforms they showcase for the best marketing, or are they 
enriching the data they receive from "lesser" platforms from an outside source?

Full AS-path information isn’t typically included in flow telemetry records.  
One typically receives origin-AS and destination-AS from exporting devices, 
along with BGP next-hop information.

Tools which provide the detailed type of information you’re describing 
typically provide combinatorial analysis of both flow telemetry received from 
edge routers and either live or offline BGP routing information.

[Full disclosure: I work for a vendor of such tools.]


Roland Dobbins mailto:roland.dobb...@netscout.com>>

Re: Scanning activity from 2620:96:a000::/48

[Dobbins, Roland]

> On 6 Jul 2021, at 16:53, Tore Anderson  wrote:
> 
> I was just curious to hear if anyone else is seeing the same thing, and also
> whether or not people feel that this is an okay thing for this «Internet
> Measurement Research (SIXMA)» to do (assuming they are white-hats)?

Scanning is part of the ‘background radiation’ of the Internet, and it’s 
performed by various parties with varying motivations.  Of necessity, IPv6 
scanning is likely to be more targeted (were your able to discern any rhyme or 
reason behind the observed scanning patterns?).

iACLs, tACLs, CoPP, selective QoS for various ICMPv6 types/codes, et. al. 
should be configured in such a manner that 600pps of anything can’t cause an 
adverse impact to any network functions.  Because actual bad actors are 
unlikely to voluntarily stop, even when requested to do so.


Roland Dobbins 

Re: Layer 2 based anycast - Kind like GLBP - Research

[Dobbins, Roland]

> On 2 Jul 2021, at 01:04, Douglas Fischer  wrote:
> 
> Answering suggestions in advance:

As others have pointed out, what you’re describing isn’t anycast, nor anything 
directly to do with high availability.

There are multiple well-understood frameworks which can be used to do what 
you’re describing.

This is strictly a layer-7 issue, nothing to do with layer-2 nor anycast.  
There’s no need to get down into the networking weeds to accomplish what you 
appear to be trying to accomplish.

Just do it all at layer-7.


Roland Dobbins 

Re: RTBH and Flowspec Measurements - Stop guessing when the attack will over

[Dobbins, Roland]

On Feb 3, 2021, at 17:01, Douglas Fischer  wrote:

It should be announced to another box, running other software than that one on 
the Perimeter, and filtering and refiltering should be done on both layers.

This is how the inter-operator implementations of which I'm aware function, via 
a  policy broker.




Roland Dobbins 

Re: RTBH and Flowspec Measurements - Stop guessing when the attack will over

[Dobbins, Roland]

On Feb 2, 2021, at 00:34, Douglas Fischer  wrote:

Or even know if already there is a solution to that and I'm trying to invent 
the wheel.

Many flow telemetry export implementations on routers/layer3 switches report 
both passed & dropped traffic on a continuous basis for DDoS 
detection/classification/traceback.

It's also possible to combine the detection/classification/traceback & flowspec 
trigger functions.

[Full disclosure: I work for a vendor of such systems.]




Roland Dobbins 

Re: Unexplainable router log entries mentioning IPSEC from Yahoo IPs

[Dobbins, Roland]

On Dec 19, 2020, at 01:19, Frank Bulk  wrote:

Curious if someone can point me in the right direction. In the last three
days our core router (Cisco 7609) has logged the following events:

Dec 16 19:04:59.027 CST: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC
packet has invalid spi for destaddr=, prot=50,
spi=0xEF7ED795(4018067349), srcaddr=68.180.160.18, input interface=Vlan20

It should be noted that attackers will sometimes generate non-TCP/-UDP/-ICMP 
DDoS attack traffic which is intended to bypass ACLs, firewall rules, etc. 
which only take the more common protocols into account. They'll often pick ESP 
(protocol 50, AH (protocol 51), or GRE (protocol 47) in order to try & 
masquerade the attack traffic as legitimate VPN or tunneled traffic.

And the source IPs of this attack traffic are frequently spoofed, as well.




Roland Dobbins 

Re: Ingress filtering on transits, peers, and IX ports

[Dobbins, Roland]

> On 15 Oct 2020, at 05:43, Brian Knight via NANOG  wrote:
> 
> I think that's good for an enterprise network, but as an SP, I'm very 
> hesitant to include this.  Is this included in anyone else's transit / peer / 
> IX ACL?

This must not be done on peering links and on transit networks generally, as it 
breaks EDNS0, & everything that depends upon it, as well as some games, VoIP 
applications, etc.

For consumer eyeball access networks only, making use of flow telemetry to 
analyze non-initial fragments destined for *those networks only, and excepting 
both one’s own recursive DNS server farms and well-known/well-operated public 
DNS recursive farms*, one can determine the normal rate of non-initial 
fragments in that very specific context and utilize QoS to police it down, 
leaving plenty of headroom for upticks in legitimate traffic.

And with regards to disallowing one’s own address space except in special 
topological circumstances, it’s great to see that this initial topic has 
sparked renewed interest in both ingress and egress filtering.  It’s highly 
laudable, and some good example are being posted and useful discussion taking 
place.

It should be noted, however, that filtering one’s own prefixes at one’s peering 
edge in the more general cases isn’t a new concept; this has been a BCP 
recommendation for more than 20 years.  For example, it’s referenced on p.75 of 
this .pdf slide deck on the topic of infrastructure self-protection, which was 
last revised 11 years ago:



From the way this ’new’ set of findings has been promulgated, it sounds as if 
the authors of the paper didn’t necessarily understand that this is a 
longstanding recommendation.  That doesn’t in any way detract from the value of 
their study, mind; and perhaps they were aware, and that information simply 
hasn’t been communicated in this context.

Also, a more proximate risk than DNS cache-poisoning or the specific, 
impractical, never-seen-in-the-wild DNS DDoS attack methodology cited, is for 
operators who aren’t filtering their own prefixes on ingres, and  who’re also 
relying solely on iACLs to prevent off-net access to their recursive DNS server 
farms, thus allowing their abuse in DNS reflection/amplification attacks 
against their own infrastructure and access customers from outside their 
network.

Filtering one’s own prefixes on ingress whenever possible and to the degree of 
granularity possible, along with making use not only of iACLs but on-server 
configurations to disallow off-network abuse of recursive DNS servers, are 
highly recommended.


Roland Dobbins 

Re: TCP and UDP Port 0 - Should an ISP or ITP Block it?

[Dobbins, Roland]

> On 25 Aug 2020, at 18:13, Douglas Fischer  wrote:
> 
> With some analysis of what is running over our network, ISP or ITP, we will 
> be able to see some TCP/UDP(mostly UDP) packets with source or destination to 
> port 0.

Are you certain that the UDP packets exhibit port 0, or is this flow telemetry 
reporting non-initial fragments as port 0 (they don’t actually have ports).


Roland Dobbins 

Don Smith, RIP.

[Dobbins, Roland]

It is with a heavy heart that I must relate the news that Don Smith, formerly 
of CenturyLink and more lately of Netscout Arbor, passed away in his sleep last 
night.

Don was a colleague, friend, and mentor to many; he was a mainstay of the 
operational community, and tirelessly worked to make the Internet safer and 
more resilient for us all.  His intellect, wit, and generosity of spirit were 
well-known to those who were privileged to have the opportunity to work with 
and learn from him.

Don’s contributions to the industry were manifold.  While we are all diminished 
by his loss, his legacy abides; and we can honor him by continuing to build 
upon that foundation, for the betterment of the Internet community as a whole.

Once Don’s family have established plans for his memorial, they will be posted 
here.

Roland Dobbins 

Re: Reaching out to Sony NOC, resolving DDoS Issues - Need POC

[Dobbins, Roland]

On 28 Jan 2020, at 18:15, Octolus Development wrote:

> The problem is that they are spoofing our IP, to millions of IP's 
> running port 80.

So that does in fact sound like a TCP reflection/amplification attack.

If you have the relevant information, as it seems that you do, you can 
ask operators to perform traceback (they'll likely need timestamps).

Hopefully, some operators will read this thread and begin looking into 
it, as well.


Roland Dobbins 

Re: Reaching out to Sony NOC, resolving DDoS Issues - Need POC

[Dobbins, Roland]

On Jan 28, 2020, at 11:40, Dobbins, Roland  wrote:

And even if his network weren't on the receiving end of a 
reflection/amplification attack, OP could still see backscatter, as Jared 
indicated.

In point of fact, if the traffic was low-volume, this might in fact be what he 
was seeing.




Roland Dobbins 

Re: Reaching out to Sony NOC, resolving DDoS Issues - Need POC

[Dobbins, Roland]

On Jan 28, 2020, at 07:39, Mike Hammett  wrote:

If someone is being spoofed, they aren't receiving the spoofed packets. How are 
they supposed to collect anything on the attack?

OP stated that *his own network* was being packeted with a TCP 
reflection/amplification attack.

This means that if he's collecting flow telemetry from his edge routers, he 
sees the details of the resultant attack traffic, & since that attack traffic 
isn't spoofed from his perspective, he can ask the networks on which the abused 
reflectors/amplifiers reside, & their peers/transits he can infer, to perform 
traceback, & work it network-by-network.

And even if his network weren't on the receiving end of a 
reflection/amplification attack, OP could still see backscatter, as Jared 
indicated.

Instrumenting one's network in order to achieve visibility into one's traffic 
is quite beneficial.  It's easy & inexpensive to get started with open-source 
tools.




Roland Dobbins 

Re: Reaching out to Sony NOC, resolving DDoS Issues - Need POC

[Dobbins, Roland]

On Jan 28, 2020, at 04:12, Octolus Development  wrote:

I don't have an exact timestamp, because the attacks are really difficult to 
see as well.

If you implement an open-source flow telemetry collection system & export flow 
telemetry from your edge routers to it, this becomes trivial.

See this .pdf preso (it's my standard telemetry preso):



[Full disclosure: I work for a commercial vendor of such systems.]




Roland Dobbins 

Re: Reaching out to Sony NOC, resolving DDoS Issues - Need POC

[Dobbins, Roland]

On Jan 28, 2020, at 04:12, Octolus Development  wrote:

It is impossible to find the true origin of where the spoofed attacks are 
coming from.

This is demonstrably untrue.

If you provide the requisite information to operators, they can look through 
their flow telemetry collection/analysis systems in order to determine whether 
the spoofed traffic traversed their network; if it did so, they will see where 
it ingressed their network.

With enough participants who have this capability, it's possible to trace the 
spoofed traffic back to its origin network, or at least some network or 
networks topologically proximate to the origin network.

That's what Damian is suggesting.




Roland Dobbins 

Re: DDoS Mitigation Survey

[Dobbins, Roland]

On 20 Jan 2020, at 23:34, Jean | ddostest.me wrote:

> so one of the best option to fight DDoS is not available through 
> public information.

I just posted a link to a public presentation which describes how to 
enable it on one's own network.

Giving end-customers the ability to block using S/RTBH on an upstream 
transit network can be challenging because of the risk of overblocking.  
It's easy to constrain D/RTBH to the end-customer's own prefixes.


Roland Dobbins 

Re: DDoS Mitigation Survey

[Dobbins, Roland]

On 20 Jan 2020, at 22:49, Jean | ddostest.me wrote:

> uRPF loose or strict.

Either.

> Which ISP supports it?

Some operators use it themselves.  I don't know of any who allow 
customer-triggered S/RTBH; several offer customer-triggered D/RTBH.


Roland Dobbins 

Re: DDoS Mitigation Survey

[Dobbins, Roland]

On 20 Jan 2020, at 19:59, Jean | ddostest.me via NANOG wrote:

> Where can we find public information on how to use S/RTBH

This .pdf preso on mitigation techniques describes how it works:




Roland Dobbins 

Re: DDoS Mitigation Survey

[Dobbins, Roland]

On 15 Jan 2020, at 6:37, Lumin Shi wrote:

> What we meant by "may not have necessary capacity" is that routers do 
> not
> have enough CAM/TCAM space to deploy/install ACLs, BGP FlowSpec rules
> against large-scale DDoS attacks without 1) incurring major collateral
> damage (e.g., deploy /16 source-based rules instead of /32 so that 
> more
> DDoS traffic can be filtered while using less CAM/TCAM space), or 2)
> performance penalties that are introduced by deploying more filters 
> than a
> router's data plane can support (i.e., data plane to control plane I/O
> limitation).

We can agree that nothing is infinite, nothing is free. TANSTAAFL.

Nevertheless, despite the fact that TCAM space is neither infinite nor 
free, and while they aren't free in terms of performance, ACLs — 
whether installed statically or dynamically via flowspec rules — are 
used every second of every minute of every hour of every day to mitigate 
large-scale DDoS attacks on large networks.

Features do indeed contend for TCAM space, and of course operators want 
as much as is practicable. LOU expansion can affect how much TCAM space 
a given ACL consumes on a given ASIC/linecard/platform.  On hardware 
platforms from major vendors, TCAM space can often be carved to allocate 
features, and operators do this in order to allocate more space for ACL 
stanzas, or flowspec rules, or whatever.

However, as demonstrated above, your thesis as stated is overbroad and 
directly contradicted by operational reality.

A key point is that operators must understand the performance envelopes 
and characteristics of their infrastructure gear, so that they can avoid 
causing issues by overtaxing it.

Here is a particular .pdf presentation which discusses issues of this 
nature:



You are not wrong to posit that hardware capacity and capabilities are 
neither infinite nor free.  But that has been well-understood in the 
operational community for a long time, and is neither novel nor 
particularly insightful.  It certainly isn't a topic that one would 
imagine merits formal academic investigation, given that it's a 
commonplace amongst those involved in the operational community.

It just isn't an interesting topic, in and of itself.  Something broader 
in terms of operator perception of gaps across the gamut of required 
DDoS mitigation capabilities at scale would potentially be of more 
value.

Please feel free to contact me 1:1 to discuss further, if you like.


Roland Dobbins 

Re: DDoS Mitigation Survey

[Dobbins, Roland]

On 14 Jan 2020, at 1:56, Lumin Shi wrote:

> We believe that many routers on the Internet
> today may not have the necessary capacity to perform fine-grained 
> traffic
> filtering, especially when facing a large-scale DDoS attack with or 
> without
> IP spoofing.

There are literally decades of information on these topics available 
publicly.  Router and switch ACLs (both static and dynamically-updated 
via flow spec), D/RTBH, S/RTBH, intelligent DDoS mitigation systems 
(IDMSes; full disclosure, I work for a a vendor of such systems), et. 
al. are all used to mitigate DDoS attacks.

Your comments about routers not having the 'capacity' (I think you mean 
capability) to filter traffic due to a lack of granularity are 
demonstrably inaccurate.  While it's always useful to be able to parse 
into packets as deeply as practicable in hardware, layer-4 granularity 
has been and continues to be useful in mitigating DDoS attacks on an 
ongoing basis.  Whether or not the traffic in question is spoofed is 
irrelevant, in this particular context.

Here are some .pdf presentations on the general topic of DDoS 
mitigation:



There are lots of write-ups and videos of presentations given at 
conferences like NANOG which address these issues; they can easily be 
located via the use of search engines.


Roland Dobbins 

Re: Seeking Feedback on Mitigation of New BGP-driven Attack

[Dobbins, Roland]

On 11 May 2019, at 11:29, Job Snijders wrote:

> The paper contained new information for me, if I hope I summarize it 
> correctly: by combining AS_PATH poisoning and botnets, the botnet’s 
> firing power can be more precisely aimed at a specific target.

That's my takeaway; it's utilizing illicit traffic engineering 
mechanisms to explicitly steer DDoS traffic, and peer-locking would 
frustrate this goal.

The authors of the paper should be aware that in large volumetric 
attacks, the natural topological convergence of attack traffic as it 
progresses towards the intended target can fill up peering links, core 
links, et. al., greatly increasing the collateral damage of such attacks 
as bystander traffic traversing those links is crowded out.

We've seen this happen many times over the last couple of decades, it 
isn't new or rare or unique as the paper seems to imply (apologies if 
that is not what the authors intended to convey).  It's such a common 
aspect of DDoS attacks that overloading 'LFA' to try and invent an 
acronym for it (in network engineering terminology, 'LFA' = 'loop-free 
alternate'; see RFCs 5286 & 8518) isn't really necessary or helpful; 
it's actually confusing.

Sometimes attackers consciously choose this as a tactic, sometimes they 
just hurl as much traffic as they can at the target and don't really 
care about the details, as long as it works — which all too often is 
the case when the defenders aren't adequately prepared.

Quantity has a quality all its own. DDoS attacks are attacks against 
capacity and/or state; in this very common scenario, link capacity is 
adversely affected.

The authors of the paper should also understand that commercial DDoS 
mitigation centers are not necessarily topologically adjacent to the 
properties being protected, as they seem to be asserting in the paper 
(again, apologies if this interpretation is incorrect); this is true in 
some models, but in other models they are topologically distant, 
sometimes being one or more ASNs away from said protected properties.

We've observed what appeared to be the deliberate use of relatively 
topologically-adjacent bots and/or reflectors/amplifiers on a couple of 
occasions. We speculate that the attackers in those instances were 
attempting to maximize the amount of traffic-on-target; seeking to avoid 
detection/classification/traceback by avoiding crossing instrumented 
macro-level administrative boundaries (i.e., peering edges, the 
incorrect assumption on the part of the attacker being that all 
operators only instrument said peering edges); and/or to complicate 
diversion into peering edge- or topologically-distant DDoS mitigation 
centers.  To date, we've not encountered illicit traffic engineering 
utilized during an attack, as described in the paper.

While it's recently become trendy in the confidentiality and integrity 
arenas to give various exploits somewhat abstract names, this sort of 
thing isn't really helpful in the availability space, where the specific 
mechanisms and techniques employed matter a great deal to operators 
working in real time to defend against DDoS attacks.  Rather than 
calling this a 'Maestro' attack, which carries no useful intrinsic 
meaning, perhaps an appellation such as 'topological forcing' or 
'traffic steering' would be more appropriate.  As in, 'a 
topologically-forced volumetric DDoS attack' or 'a traffic-steered 
volumetric DDoS attack'.

n.b. — neological acronyms such as as TFVDDoS or TSVDDoS should be 
avoided, as this further unhelpfully fragments the terminology space.


Roland Dobbins 

Re: FB?

[Dobbins, Roland]

On 14 Mar 2019, at 19:17, Mike Hammett wrote:

> I saw one article quoting Roland saying it was a route leak, but I 
> haven't seen any other sources that aren't just quoting Roland.

That was the result of a miscommunication; a clarification has been 
issued, FYI.


Roland Dobbins 

Larry Roberts, RIP.

[Dobbins, Roland]

Roland Dobbins 

Re: Proxying NetFlow traffic correctly

[Dobbins, Roland]

On Jun 7, 2017, at 06:32, Sami via NANOG 
> wrote:

My goal is to centralize NetFlow traffic into a single machine and then proxy 
some flows to other destinations for further analysis



Or nprobe, as was already mentioned.

---
Roland Dobbins >

Re: Getting pretty close to default IPv4 route maximum for 6500/7600 routers.

[Dobbins, Roland]

On May 9, 2014, at 2:48 PM, Vitkovský Adam adam.vitkov...@swan.sk wrote:

 With 6500/7600 I can understand they've been around for ages and no one 
 anticipated the 512k limit back then. 

Actually, it *was* anticipated.  It's just that those who designed the ASIC 
didn't necessarily envision that it would still be in service, having gone 
through successive additional minor variations, for quite so long.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: About NetFlow/IPFIX and DPI

[Dobbins, Roland]

On May 7, 2014, at 8:11 PM, Antoine Meillet antoine.meil...@gmail.com wrote:

 Should those protocols be considered as tools to perform DPI ?

No - they're flow telemetry exported by routers and switches, and they provide 
layer-4 information.

It's possible with Cisco Flexible NetFlow and with PSAMP exported over IPFIX to 
get packet contents; however, few if any collection/analysis systems utilize 
either extended telemetry format, to date.  I've never seen either implemented 
in a production network.

NetFlow and IPFIX are primarily used for security purposes such as DDoS 
detection/classification/traceback and botnet CC identification; for traffic 
engineering analysis; capacity planning analysis; for troubleshooting; and for 
billing purposes.  Flow telemetry is an essential tool that ISPs and larger 
enterprises utilize in order to get a view into their network traffic, because 
it scales for large networks - and it does so because it doesn't typically 
include packet payloads, just the layer-4 information.  It's sort of like a 
near-time mobile phone bill for the network.

'DPI' generally (but not always) refers to devices which are placed inline and 
perform full multi-packet payload reassembly and inspection.  The term has been 
used (and misused) so broadly as to becoming essentially meaningless.

NetFlow and IPFIX are merely telemetry formats used by network engineers for 
the purposes noted above.  

This presentation talks about how NetFlow is used by network operators:

https://app.box.com/s/mnshn99c13uekrggy99b

Network neutrality is largely an issue of policy and of economics, not of 
technology, per se.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: About NetFlow/IPFIX and DPI

[Dobbins, Roland]

On May 7, 2014, at 10:45 PM, Paolo Lucente pl+l...@pmacct.net wrote:

 This model is supported on the export side by Cisco with their NetFlow/NBAR 
 integration and on the collection side by some
 collector. 

As you'll note in reading that report, NBAR didn't seem to work very well for 
them; I haven't run across its use in any ISP network, on ISP-grade hardware 
(i.e., not a small software-based router like a 7200), or even in a large-scale 
enterprise environment.

Again, I haven't yet run across anyone actually using this on a production 
network.  It would be very interesting to hear from someone with first-hand 
experience with NBAR exported over Flexible NetFlow in a production environment.

Also, it's important to note that this sort of thing doesn't scale across 
networks of any real size/speed.  There's a great deal of potential utility in 
the security, troubleshooting, and traffic engineering arenas for on-demand 
triggered packet sampling of this nature, but so far, the control-plane hooks 
aren't really there to do this in a programmatic manner (one presumes that SDN 
of one flavor or another might provide these capabilities).  That was my 
biggest gripe about Flexible NetFlow when I was at Cisco, and one which I felt 
ensured the technology wouldn't make it into production networks - no organic 
control-plane interface.

So, perhaps now we can de-conflate flow telemetry and 'DPI', since the 
real-life export, collection, and analysis of anything other than layer-4 
information via flow telemetry isn't at all commonplace (if it in fact exists 
at all) on production networks), at this juncture.

'DPI' generally alludes boxes positioned at points of ingress/egress symmetry 
(either natural or purposely engineered) within a network.  Flow telemetry per 
se is not really within the rubric of 'DPI'.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: oss netflow collector/trending/analysis

[Dobbins, Roland]

On May 2, 2014, at 9:36 PM, Matthew Galgoci mgalg...@redhat.com wrote:

 A few folks here really seem to like
 nfsen/nfdump.

The good thing about nfdump/nfsen is that you can customize it and do a lot 
with it, and it's easy to get set up and running.

This is the canonical list of open-source NetFlow tools:

http://www.switch.ch/network/projects/completed/TF-NGN/floma/software.html

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: Question for service providers regarding tenant use of public IPv4 on your infrastructure

[Dobbins, Roland]

On Apr 28, 2014, at 3:18 PM, Cliff Bowles cliff.bow...@apollo.edu wrote:

 Or do ISPs put some level of security between their tenants and the internet 
 to prevent this? I've been told that the majority do not have any intelligent 
 filtering beyond bogon-lists.

Flow telemetry export/collection/analysis for 
detection/classification/traceback (there are several open-source tools), 
S/RTBH or flowspec to squelch outbound badness.  Plus all the usual BCPs:

https://app.box.com/s/4h2l6f4m8is6jnwk28cg

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: Requirements for IPv6 Firewalls

[Dobbins, Roland]

On Apr 20, 2014, at 1:47 PM, Eugeniu Patrascu eu...@imacandi.net wrote:

 Just go watch government at work :) 

Precisely.

;

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: Requirements for IPv6 Firewalls

[Dobbins, Roland]

On Apr 20, 2014, at 8:52 PM, Seamus Ryan s.r...@uber.com.au wrote:

 Similarly if most of the time I just need to protect my relatively simple 
 network by implementing a few separate zones I will get a firewall, im not 
 going to deploy expensive stateless devices that can push a billion pps 
 everywhere and send flow stats to expensive DDoS mitigation hardware *cough* 
 arbor *cough* just so I can protect against an attack that many only happen a 
 few times a year.

I'm talking about stateless ACLs on hardware-based routers and switches for 
enforcing network access policies - nothing to do with Arbor.  Arbor doesn't 
make routers or switches.

Stateful firewalls make servers far more vulnerable to DDoS (and to compromise, 
for that matter; they broaden the attack surface amazingly) than they would be 
without deploying stateful firewalls.  Vendors of commercial DDoS mitigation 
solutions [full disclosure:  I work for a vendor of such solutions] who wish to 
drum up business should be *encouraging* organizations to deploy stateful 
firewalls, not discouraging them from doing so.  

Anyone who knows me knows that I do *not* violate NANOG rules (or the rules of 
any other community list) by pushing commercial solutions.  What I advocate is 
for folks to avoid spending extra money and time and effort in order to 
negatively impact their security posture, and instead utilize their existing 
investments in network infrastructure devices to enforce network access 
policies via stateless ACLs, as well as to deploy reaction/mitigation tools 
such as S/RTBH and flowspec.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: Requirements for IPv6 Firewalls

[Dobbins, Roland]

On Apr 20, 2014, at 10:15 PM, Seamus Ryan s.r...@uber.com.au wrote:

 It was more a friendly stab at the way DDoS mitigation providers push their 
 products; stateless router + ddos appliance = problem solved, throw 
 everything else out

http://mailman.nanog.org/pipermail/nanog/2010-January/016747.html

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: Requirements for IPv6 Firewalls

[Dobbins, Roland]

On Apr 20, 2014, at 2:32 AM, George William Herbert george.herb...@gmail.com 
wrote:

 I have 20-30,000 counterexamples in mind that I worked with directly in the 
 last decade.

People do stupid things all the time - but generally, it's hard to do them at 
scale.

;

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: Requirements for IPv6 Firewalls

[Dobbins, Roland]

On Apr 19, 2014, at 1:20 AM, William Herrin b...@herrin.us wrote:

 There isn't much a firewall can do to break it.

As someone who sees firewalls break the Internet all the time for those whose 
packets have the misfortune to traverse one, I must respectfully disagree.

;

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: Requirements for IPv6 Firewalls

[Dobbins, Roland]

On Apr 19, 2014, at 9:04 AM, Jeff Kell jeff-k...@utc.edu wrote:

 It's how we provide access control.

Firewalls  'access control'.

Firewalls are one (generally, very poor and grossly misused) way of providing 
access control.  They're often wedged in where stateless ACLs in hardware-based 
routers and/or layer-3 switches would do a much better job, such as in front of 
servers:

https://app.box.com/s/a3oqqlgwe15j8svojvzl

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: Requirements for IPv6 Firewalls

[Dobbins, Roland]

On Apr 19, 2014, at 10:29 AM, Jeff Kell jeff-k...@utc.edu wrote:

 I call BS...

You can 'call' it all you like - but people who actually want to keep their 
servers up and running don't put stateful firewalls in front of them, because 
it's very easy to knock them over due to state exhaustion.  In fact, it's far 
easier to knock them over than to knock over properly-tuned naked hosts.

Also, you might want to search the NANOG email archive on this topic.  There's 
lots of previous discussion, which boils down to the fact that serious 
organizations running serious applications/services don't put stateful 
firewalls (or 'IPS', or NATs, et. al.) in front of their servers.

The only way to secure hosts/applications/service against compromise is via 
those hosts/applications/services themselves.  Inserting stateful middleboxes 
doesn't actually accomplish anything to enhance confidentiality and integrity, 
actually increases the attack surface due to middlebox exploits (read the 
numerous security notices for various commercial and open-source stateful 
firewalls for compromise exploits), and has a negative impact on availability.

Again, take a look at this preso:

https://app.box.com/s/a3oqqlgwe15j8svojvzl

And take a look at pp. 17-18 of this preso:

https://app.box.com/s/ko8lk4vlh1835p36na3u

I've seen 3mb/sec of spoofed SYN-flooding take down a supposedly 20gb/sec 
stateful firewall due to state exhaustion in about 2 minutes; I've seen 6kpps 
of HOIC take down a supposedly 10gb/sec load-balancer due to state-table 
exhaustion in 60 seconds.  Each of those devices required an ~30-minute hard 
reboot - and those are just two of too many examples to keep track of, heh.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: Requirements for IPv6 Firewalls

[Dobbins, Roland]

On Apr 17, 2014, at 7:35 PM, Dustin Jurman dus...@rseng.net wrote:

 - packets per second
   - Firewall Level
   - Hosts level

This is getting into QoS territory . . .

 - packet size information

Concur - packet-length.

   - Average for FW of all Network hosts

This isn't very operationally useful, IMHO.

   - Negotiated Between Hosts  

I'm not sure what this means?

But classifiers for everything in the IP, TCP, UDP, and ICMP headers, along 
with packet length, makes a lot of sense.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: Requirements for IPv6 Firewalls

[Dobbins, Roland]

On Apr 17, 2014, at 10:26 PM, David Newman dnew...@networktest.com wrote:

 For firewalls handling TCP traffic, upper-layer traffic metrics such as HTTP 
 object size, concurrent connection capacity, and connection setup rate are a 
 lot more meaningful.

I'm referring here to the ability to use packet-length as a classifier in a 
policy, not about bps/pps/tps/cps, et. al., apologies for being unclear.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: Requirements for IPv6 Firewalls

[Dobbins, Roland]

On Apr 18, 2014, at 1:04 AM, Dustin Jurman dus...@rseng.net wrote:

 - the approach is from an end user than service provider. The firewall 
 operator would be more interested in identifying PPS for attacks / 
 compromised hosts VS QOS but I supposed it could be used for QOS as well.  
 (Not my intent) So today we have NAT'd firewalls that overload a particular 
 interface, IMHO since properly implemented V6 should not use NAT I would want 
 my FW vendor to allow me to see what's going on PPS wise via the dashboard 
 function.  Most V4 firewalls do this today at an interface level. 

This is a telemetry function (separately, I noted IPFIX functionality should be 
included).

 - Average packet size for all hosts would allow operator to make a 
 determination and set thresholds for new forms of attacks and exploits.  
 (Thinking forward once applications take advantage of V6)  

Again, this is a telemetry function, not a policy function.

 - MTU Negotiated Between Hosts - Since this happens between endpoints in v6 
 this could be help identify tunnels in the network / changes in WAN 
 topology.. Not like we haven't seen that before.  While a change in flight 
 should create a drop.. when the session reestablishes it could resize.  

Yet again, a telemetry function.  The MTU negotiation itself is irrelevant; the 
resultant packet-size is relevant, from a classification point of view. 

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: Outgoing traffic problem on Citrix Netscaler Load Balancer

[Dobbins, Roland]

On Mar 31, 2014, at 7:17 PM, Anil KARADAG akara...@netas.com.tr wrote:

 However, we need the source port to be the same on the destination servers.

Out of curiosity, why?

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: Link Layer Filtering not supported on popular equipment?

[Dobbins, Roland]

On Mar 26, 2014, at 11:08 PM, hasser css hasserva...@gmail.com wrote:

 Any insight? 

I don't know about Dell switches, but Cisco switches have DHCP Snooping, IP 
Source Guard, PACLs, VACLs, and so forth at layer-2.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: IPv6 Security [Was: Re: misunderstanding scale]

[Dobbins, Roland]

On Mar 24, 2014, at 6:37 AM, Timothy Morizot tmori...@gmail.com wrote:

 You'll pardon my skepticism over claims that unspecified security weaknesses 
 make it impossible to do what we have done and are continuing to
 do.

All this unfilterable ICMP makes for interesting times - I've already run 
across ND storms caused remotely (deliberately, IMHO).  Insane policies such as 
/64s for p2p link addresses don't help, either.

And the consonance of the English letters 'B', 'C', 'D',  'E' when spoken 
aloud is quite likely to prove a major security issue, IMHO.  Time for folks to 
adopt the phonetic alphabet, if they absolutely must communicate verbally.

IPv6 has all the security issues associated with IPv4, plus a few new ones 
which are unique to IPv6.  Denying the latter doesn't make them go away.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: How to catch a cracker in the US?

[Dobbins, Roland]

On Mar 12, 2014, at 5:10 PM, Vitkovský Adam adam.vitkov...@swan.sk wrote:

 Though it's 100% correct would this withstand in the court? 

TIINAL - The Internet Is Not A Lawyer.

;

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: How to catch a cracker in the US?

[Dobbins, Roland]

On Mar 11, 2014, at 2:00 PM, Markus unive...@truemetal.org wrote:

 Any advice?

Start with CERT-BUND, maybe?

Although it's questionable whether or not it's possible to remotely absolutely 
ascertain whether the attacking machine in question was being operated by 
miscreants unbeknownst to its actual owner.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: Managing ACL exceptions (was Re: Filter NTP traffic by packet size?)

[Dobbins, Roland]

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

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: NTP DRDos Blog post

[Dobbins, Roland]

On Feb 20, 2014, at 11:14 PM, Niels Bakker niels=na...@bakker.net wrote:

 Don't invent new terms like DrDos.

+1

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: NTP DRDos Blog post

[Dobbins, Roland]

On Feb 20, 2014, at 11:23 PM, Brian Rak b...@gameservers.com wrote:

 That's not a new term.

It isn't used by folks involved in operational security.  It's a marketing term.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: NTP DRDos Blog post

[Dobbins, Roland]

On Feb 20, 2014, at 11:29 PM, antoine.meil...@orange.com 
antoine.meil...@orange.com wrote:

 Yes, it was also used here 
 https://www.sans.org/reading-room/whitepapers/intrusion/summary-dos-ddos-prevention-monitoring-mitigation-techniques-service-provider-enviro-1212

That's still meaningless.  The term of art is 'reflection/amplification 
attack', as in 'ntp reflection/amplification attack' or 'DNS 
reflection/amplification attack'.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: NTP DRDos Blog post

[Dobbins, Roland]

On Feb 21, 2014, at 2:37 AM, John j...@nuclearfallout.net wrote:

 This is not a new term (certainly 12yo) 

Actually, it's much more recent than that (in this context; as others have 
mentioned, DR-DOS was the acronym for Digital Research's MS-DOS clone).

But I'm going to stop posting about this, now, as Jared suggested.  

;

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: NTP DRDos Blog post

[Dobbins, Roland]

On Feb 21, 2014, at 2:51 AM, John j...@nuclearfallout.net wrote:

 I know how much Gibson is hated in some circles,

He isn't/wasn't part of the operational community.  

It sure looks like you're right, he coined it then - as a marketing term, for 
marketing himself, heh.  Maybe that's one of the reasons it's so disliked.

;

 I read that in 2002, did other research about it in 2002, saw reflected 
 attacks in 2002.

I saw reflected/amplified attacks in 2002, too, and that's what I called them.  
So did everyone else I worked with to mitigate them, heh.

And I'm really going to shut up about this, now.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: Filter NTP traffic by packet size?

[Dobbins, Roland]

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

Operators are using this size-based filtering to effect without breaking the 
world.  

Be sure to pilot this first, and understand whether packet-size classification 
on your hardware of choice includes framing or not.

Also, note that this filtering should be utilized to mitigate attacks, not as a 
permanent policy.  

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: Filter NTP traffic by packet size?

[Dobbins, Roland]

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.

Also, the reverse - UDP/123 - UDP/anything, for the amplified attack traffic.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: Filter NTP traffic by packet size?

[Dobbins, Roland]

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.

That should read, filtering out packets  NOT  that size.

Lack of sleep, apologies.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: Filter NTP traffic by packet size?

[Dobbins, Roland]

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 granularity, and the minimal 
necessary scope.  One way to accomplish this is to divert traffic towards 
destinations in question into a mitigation/center sinkhole, applying this 
filtering on the coreward interfaces of the mitigation center/sinkhole gateway 
(some re-injection mechanism such as GRE, VRF, selective filtering of the 
diversion route announcements coupled w/PBR, etc. must be used to re-inject 
non-matching traffic towards the destinations in question) or via other 
mitigation mechanisms.

In emergencies, the concept of partial service recovery may dictate temporary 
filtering of coarser granularity in order to preserve overall network 
availability; we've run into situations in the past week-and-a-half where 
networks were experiencing severe strain due to the sheer volume of ntp 
reflection/amplification attack traffic, and it was necessary to start out with 
more general filtering, then work towards more specific filtering once the 
network was stabilized.

But you raise a very important point which should be re-emphasized - general 
filtering of traffic is to be avoided whenever possible in order to avoid 
breaking applications/services.  

However, the converse notion that emergency situations sometimes entail 
necessary restrictions should also be taken into account.  Operators should use 
their best judgement as to the scope of any filtering, and should always pilot 
any proposed mitigation methodologies prior to wider deployment.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: random dns queries with random sources

[Dobbins, Roland]

On Feb 19, 2014, at 10:57 PM, Beeman, Davis davis.bee...@integratelecom.com 
wrote:

 I am late to this train, but it appears no one else has brought this up.  It 
 is a DNS tunneling setup, not an attack. 

This makes a lot of sense - good insight, will look into this further!

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: Changing the way we talk about BCP38 [Was: Re: Everyone should be deploying BCP 38! Wait, they are ....]

[Dobbins, Roland]

On Feb 19, 2014, at 2:43 AM, Paul Ferguson fergdawgs...@mykolab.com wrote:

 This is why I am now using the phrase anti-spoofing when talking about this 
 in public.

+1

It's also more semantically correct, in many cases.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: Everyone should be deploying BCP 38! Wait, they are ....

[Dobbins, Roland]

On Feb 19, 2014, at 4:52 AM, Tony Tauber ttau...@1-4-5.net wrote:

 maybe we should conclude that most of the spoofing is coming from somewhere 
 else; perhaps including colo and cloud providers.

My theory - not yet backed by data - is that probably most spoofed traffic 
these days does in fact emanate from IDC networks, and that a non-trivial 
proportion of same emanates from a relatively small number of such networks.

In many cases, it's possible to put 'naked' hosts on home broadband 
connections, however - and how common that is, and what proportion of those 
broadband access networks don't run any form of anti-spoofing, is an open 
question.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: random dns queries with random sources

[Dobbins, Roland]

On Feb 19, 2014, at 10:08 AM, Joe Maimon jmai...@ttec.com wrote:

 What is the purpose of this?

Resource-exhaustion attack against the recursive DNS?

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: random dns queries with random sources

[Dobbins, Roland]

On Feb 19, 2014, at 10:32 AM, Joe Maimon jmai...@ttec.com wrote:

 How is this any more effective then sending it direct?

If they're attacking the authoritative DNS servers for 5kkx.com, just 
reflecting gives them indirection and presumably makes traceback harder for 
5kkx.com (at least, in the minds of the attackers).

Or maybe they're trying to game 5kkx.com into blocking requests from the 
recursive servers in question, for some reason.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: random dns queries with random sources

[Dobbins, Roland]

On Feb 19, 2014, at 10:44 AM, Dobbins, Roland rdobb...@arbor.net wrote:

 Resource-exhaustion attack against the recursive DNS?

Fat-finger, sorry - should also state 'Or against the authoritative servers for 
5kkx.com?'

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: random dns queries with random sources

[Dobbins, Roland]

On Feb 19, 2014, at 10:48 AM, Christopher Morrow morrowc.li...@gmail.com 
wrote:

 apologies. both chl.net and chl.com ... which appear to be parts of ttec ... 
 which is joe.

Premature send - I meant to add 'Or against the authoritative servers for 
5kkx.com?'

We've been seeing a spate of reflected (not amplified) DNS attacks against 
various authoritative servers in Europe for the past week or so, bounced 
through some type of consumer DSL broadband CPE with an open DNS forwarded on 
the WAN interface (don't know the make/model, but it was supplied by the 
broadband operators to the customers), on some European broadband access 
networks.  

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: random dns queries with random sources

[Dobbins, Roland]

On Feb 19, 2014, at 12:44 PM, Joe Maimon jmai...@ttec.com wrote:

 Get back to me when the same cant be done with auth servers.

There are ways to deal with it on authoritative servers, like RRL.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: random dns queries with random sources

[Dobbins, Roland]

On Feb 19, 2014, at 12:48 PM, Joe Maimon jmai...@ttec.com wrote:

 What I cant figure out is what is the target and how this attack method is 
 any more effective then the others.

The target appears to be the authoritative servers for the domain in question, 
yes?

The attacker may consider it more effective because it provides a degree of 
obfuscation, or maybe he has some reason to game the operators of the 
authoritative servers in question into denying requests from your recursors.

Most (not all) attackers don't know that much about TCP/IP, DNS, et. al, and 
they tend to copycat one another and do the same things due to magical thinking.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: random dns queries with random sources

[Dobbins, Roland]

On Feb 19, 2014, at 1:07 PM, Joe Maimon jmai...@ttec.com wrote:

 There are ways to deal with it on resolvers as well, like RRL and IDS and 
 iptables

None of these things work well for recursive resolvers; they cause more 
problems than they solve.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: OpenNTPProject.org

[Dobbins, Roland]

On Feb 17, 2014, at 10:14 PM, Pete Ashdown pashd...@xmission.com wrote:

 Does not having nopeer contribute to DDoS amplification?

No:

http://www.kb.cert.org/vuls/id/348126

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: BCP38 (was: Re: Why won't providers source-filter attacks? Simple.)

[Dobbins, Roland]

On Feb 8, 2014, at 3:37 AM, John Curran jcur...@arin.net wrote:

 It's also true that if a sizable group of network operators were to actually 
 deploy source address validation (thus proving that it really is a reasonable 
 approach and doesn't carry too much operational or vendor implications), then 
 it would be quite reasonable for those operators to bring the results to 
 NANOG and get it recognized as a best current operating practice for networks 
 of similar design/purpose.

Many already do - including operators of very large networks.  There are 
operational, vendor, and topological considerations which mean that it's 
achieved utilizing various mechanisms in different scenarios.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: BCP38 (was: Re: Why won't providers source-filter attacks? Simple.)

[Dobbins, Roland]

On Feb 8, 2014, at 4:25 AM, Chris Grundemann cgrundem...@gmail.com wrote:

 Documenting those various mechanisms which are actually utilized is the key 
 here. =)

Yes, as well as the various limitations and caveats, like the wholesale/retail 
issue (i.e., customers of my customer).

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: BCP38.info

[Dobbins, Roland]

On Feb 3, 2014, at 2:55 PM, Dobbins, Roland rdobb...@arbor.net wrote:

 It would be useful to know whether there are in fact NATs, or are 'DNS 
 forwarders' . . .

Another question is whether or not it's possible that in at least some cases, 
MITMing boxes on intermediary networks are grabbing these queries and then 
spoofing the scanner source IP as they redirect the queries . . . . if this is 
taking place, then it would be the network(s) with the MITMing box(es) which 
allow spoofing, irrespective of whether or not the intended destination 
networks do, yes?

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: BCP38.info, RELATING: TWC (AS11351) blocking all NTP?

[Dobbins, Roland]

On Feb 3, 2014, at 3:24 PM, Michael DeMan na...@deman.com wrote:

 I meant mostly that with IPv6 NAT goes away,

I don't know if this is true or not - and even if it is true, it's going to be 
a long, long time before the IPv4 Internet goes away (like, maybe, pretty much 
forever, heh).

 An NTPv5 solution that could be done with NTP services already, and would be 
 more of a 'best practices of how this shit starts up and what it can do' and 
 educating vendors to have reasonable behavior in the first place?

Yes, but that's many years away, and doesn't address legacy issues.

 And an NTPv6 solution/RFC/guideline that was similar, could help?

Again, many years away, and doesn't address legacy issues.

 I disagree that 'filtering' or 'blocking' any kind of IPv4 or IPv6 protocol 
 to 'protect the end user' is the wrong way to go when compared to just having 
 things work in a secure manner.

Yes, but since the latter part of this statement is unattainable in the 
foreseeable future, the idea is actually to protect *the rest of the Internet* 
from misconfigured CPE.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: TWC (AS11351) blocking all NTP?

[Dobbins, Roland]

On Feb 3, 2014, at 4:55 PM, Stephane Bortzmeyer bortzme...@nic.fr wrote:

 I agree with you but I'm fairly certain that most ISP who deny their users 
 the ability to do DNS requests directly
 (or to run their own DNS resolver) have no such opt-out (or they make it 
 expensive and/or complicated).

There are some who do it, though, with a user-friendly portal - I've seen it in 
action.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: TWC (AS11351) blocking all NTP?

[Dobbins, Roland]

On Feb 4, 2014, at 12:42 AM, Peter Phaal peter.ph...@gmail.com wrote:

 Real-time analytics based on measurements from switches/routers 
 (sFlow/PSAMP/IPFIX) can identify large UDP flows and integrated hybrid
 OpenFlow, I2RS, REST, NETCONF APIs, etc. can be used to program the 
 switches/routers to selectively filter traffic based on UDP port and
 IP source / destination. By deploying a DDoS mitigation SDN application,  
 providers can use their existing infrastructure to
 protect their own and their customers networks from flood attacks, and 
 generate additional revenue by delivering flood protection as a value
 added service.

This is certainly a general capability set towards which many operators are 
evolving (and it's always amusing how you leave out NetFlow, which many 
operators use, but include sFlow, which very few operators use, heh), but it's 
going to be quite some time before this sort of thing is practical and 
widely-deployale.

Believe me, I've been working towards this vision for many years.  It isn't 
going to happen overnight.

 Specifically looking at sFlow, large flood attacks can be detected within a 
 second.

And with NetFlow, and with IPFIX - the first of which is widely deployed today, 
and the second of which will be widely deployed in future.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: TWC (AS11351) blocking all NTP?

[Dobbins, Roland]

On Feb 4, 2014, at 12:11 AM, Brian Rak b...@gameservers.com wrote:

 You can disable these quite easily, and still run a NTP server that provides 
 accurate time services.

Concur 100% - although it should be noted that 1:1 reflection without any 
amplification is also quite useful to attackers.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: TWC (AS11351) blocking all NTP?

[Dobbins, Roland]

On Feb 4, 2014, at 3:09 AM, Brian Rak b...@gameservers.com wrote:

 It's pretty much the same issue with DNS, even authoritative-only servers can 
 be abused for reflection.

They are, every minute of every day - and they provide amplification, too.

;

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: TWC (AS11351) blocking all NTP?

[Dobbins, Roland]

On Feb 4, 2014, at 5:38 AM, John Kristoff j...@cymru.com wrote:

 I do realize in practice there are ways to discover systems, but the change 
 in address architecture could change things, not perfectly, but I'll venture 
 to suggest noticeably in some not so difficult to imagine
 scenarios.

I know you're aware of the work in this area, so I'll just note for the record 
that the 'IPv6 makes scanning impossible!' has already been exploded.

;

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: TWC (AS11351) blocking all NTP?

[Dobbins, Roland]

On Feb 3, 2014, at 10:49 AM, Geraint Jones gera...@koding.com wrote:

 We block all outbound UDP for our ~200,000 Users for this very reason

Actually, you could've (and should've) been far more selective in what you 
filtered via ACLs, IMHO.

What about your users who play online games like BF4?

I'm a big believer in using ACLs to intelligently preclude 
reflection/amplification abuse, but wholesale filtering of all UDP takes 
matters too far, IMHO.

My suggestion would be to implement antispoofing on the southward interfaces of 
the customer aggregation edge (if you can't implement it via mechanisms such as 
cable ip source verify even further southward), and then implement a default 
ingress ACL on the coreward interfaces of the customer aggregation gateways to 
block inbound UDP destined to ntp, chargen, DNS, and SNMP ports only.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: TWC (AS11351) blocking all NTP?

[Dobbins, Roland]

On Feb 3, 2014, at 10:58 AM, Dobbins, Roland rdobb...@arbor.net wrote:

 I'm a big believer in using ACLs to intelligently preclude 
 reflection/amplification abuse, but wholesale filtering of all UDP takes 
 matters too far, IMHO.

I also think that restricting your users by default to your own recursive DNS 
servers, plus a couple of well-known, well-run public recursive services, is a 
good idea - as long as you allow your users to opt out.

This has nothing to do with DDoS, but with other types of issues.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: TWC (AS11351) blocking all NTP?

[Dobbins, Roland]

On Feb 3, 2014, at 12:45 PM, Michael DeMan na...@deman.com wrote:

 From a provider point of view, given the choices between contacting the 
 end-users vs. mitigating the problem, if I were in TW position if I was 
 unable to immediately contact the numerous downstream customers that were 
 affected by this, I would take the option to block NTP on a case-by-case 
 basis (perhaps even taking a broad brush) rather than allow it to continue 
 and cause disruptions elsewhere.

Per my previous post in this thread, there are ways to do this without blocking 
client access to ntp servers; in point of fact, unless the ISP in question 
isn't performing antispoofing at their customer aggregation edge, blocking 
client access to ntp servers does nothing to address (pardon the pun) the issue 
of ntp reflection/amplification DDoS attacks.

All that broadband access operators need to do is to a) enforce antispoofing as 
close to their customers as possible, and b) enforce their AUPs (most broadband 
operators prohibit operating servers) by blocking *inbound* UDP/123 traffic 
towards their customers at the customer aggregation edge (same for DNS, 
chargen, and SNMP).

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: TWC (AS11351) blocking all NTP?

[Dobbins, Roland]

On Feb 3, 2014, at 1:02 PM, Dobbins, Roland rdobb...@arbor.net wrote:

 b) enforce their AUPs (most broadband operators prohibit operating servers) 
 by blocking *inbound* UDP/123 traffic towards their customers at the customer 
 aggregation edge

Actually, this can cause problems for ntpds operating in symmetric mode, where 
both the source and destination ports are UDP/123.  Allowing inbound UDP/123 - 
UDP/123 and then rate-limiting it would be one approach; another would be to 
block outbound UDP/123 emanating from customers based upon packet size, if 
one's hardware allows matching on size in ACLs.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: TWC (AS11351) blocking all NTP?

[Dobbins, Roland]

On Feb 3, 2014, at 1:54 PM, Michael DeMan na...@deman.com wrote:

 I certainly would not want to provide as part the AUP (as seller or buyer), a 
 policy that fundamentals like NTP are 'blocked' to customers.  Seems like too 
 much of a slippery slope for my taste.

The idea is to block traffic to misconfigured ntpds on broadband customer 
access networks, not to limit their choice of which ntp servers to use.

 In regards to anti-spoofing measures - I think there a couple of vectors 
 about the latest NTP attack where more rigorous client-side anti-spoofing 
 could help but will not solve it overall.

Rigorous antispoofing would solve the problem of all reflection/amplification 
DDoS attacks.  My hunch is that most spoofed traffic involved in these attacks 
actually emanates from compromised/abused servers on IDC networks (including 
so-called 'bulletproof' miscreant-friendly networks), but I've no data to 
support that, yet.

  Trying to be fair and practical (from my perspective) - it is a lot easier 
 and quicker to patch/workaround IPv4 problems and address proper solutions 
 via IPv6 and associated RFCs?

There's nothing in IPv6 which makes any difference.  The ultimate solution is 
antispoofing at the customer edge.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: BCP38.info

[Dobbins, Roland]

On Jan 29, 2014, at 3:03 AM, Jared Mauch ja...@puck.nether.net wrote:

 Sure, but this means that network is allowing the spoofing :)
 
 What I did last night was automated comparing the source ASN to the dest ASN 
 mapped to and reported both the IP + ASN on a single line for those that were 
 interested.

This is pretty slick, relying upon broken CPE NAT implementations.  It's the 
only way I've heard of to remotely infer whether or not a given network allows 
spoofing.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: BCP38.info

[Dobbins, Roland]

On Jan 29, 2014, at 4:47 AM, Nick Olsen n...@flhsi.com wrote:

 After a quick phone conversation with Jared. We concluded that at least in 
 the specific case I was speaking about, I was correct in that nothing was 
 Spoofed. 

Forgive me for being slow, but doesn't this seem to imply that there isn't any 
antispoofing taking place at the GRE tunnel ingress?

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: BCP38.info

[Dobbins, Roland]

On Feb 3, 2014, at 2:22 PM, Dobbins, Roland rdobb...@arbor.net wrote:

 This is pretty slick, relying upon broken CPE NAT implementations.  It's the 
 only way I've heard of to remotely infer whether or not a given network 
 allows spoofing.

It would be useful to know whether there are in fact NATs, or are 'DNS 
forwarders' . . .

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: Google causes 40% drop in traffic?

[Dobbins, Roland]

On Jan 25, 2014, at 6:07 AM, Jay Ashworth j...@baylink.com wrote:

 I wonder what percentage of large website operators whose site designs have 
 such external dependencies have had it occur to them to include those
 external services in their monitoring systems?

This presupposes that they actually have monitoring systems which actually 
perform useful checks.  All too often, this isn't the case.

;

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: OpenNTPProject.org

[Dobbins, Roland]

On Jan 15, 2014, at 12:05 AM, Saku Ytti s...@ytti.fi wrote:

 (We do BCP38 on all ports and verify programmatically, but I know it's not at 
 all practical solution globally for access).

Anti-spoofing is eminently practical for most types of access network 
topologies using even slightly modern equipment; uRPF, ACLs, cable IP source 
verify, DHCP Snooping (which works just fine with fixed-address hosts), 
PACLs/VACLs, et. al. are some of the more prevalent mechanisms available.

In point of fact, anti-spoofing is most useful and most practical at the 
access-network edge, or as close to it as possible.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: OpenNTPProject.org

[Dobbins, Roland]

On Jan 16, 2014, at 9:56 PM, Saku Ytti s...@ytti.fi wrote:

 It is not going to happen, the most suspect places are places where it's 
 going to be most difficult to get, either fully on autopilot with no technical
 personnel capable or having the power to make the change or ghetto gear with 
 no capability for it.

That may well be the case, unfortunately; my point was that at or near the 
access edge is the most *technically* and *topologically* feasible place to 
implement antispoofing mechanisms, as you indicated in your reply.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: best practice for advertising peering fabric routes

[Dobbins, Roland]

On Jan 15, 2014, at 9:18 PM, Leo Bicknell bickn...@ufp.org wrote:

 However, a good engineer would know there are drawbacks to next-hop-self, in 
 particular it slows convergence in a number of situations.  There are 
 networks where fast convergence is more important than route scaling, and 
 thus the traditional design of BGP next-hops being edge interfaces, and edge 
 interfaces in the IGP performs better.

A good engineer also knows that there are huge drawbacks to having a peer's 
network infrastructure DDoSed, routes flapping, core bandwidth consumed by tens 
and hundreds of gb/sec of attack traffic, et. al., too.

;

 By attempting to force IX participants to not put the route in IGP, those IX 
 participants are collectively deciding on a slower converging network for 
 everyone.  I don't like a world where connecting to an exchange point forces 
 a particular network design on participants.

Concur.  But that's the world we live in, unfortunately.

It's just another example of the huge, concentric nature of the collateral 
damage arising from DDoS attacks, both from the attacks themselves, and from 
the compromises folks have to make in order to increase resilience against such 
attacks.

 That's some circular reasoning.

Not really.  What I'm saying is that since PMTU-D is already broken on so many 
endpoint networks - i.e., where traffic originates and where it terminates - 
that any issues arising from PMTU-D irregularities in IXP networks are trivial 
by comparison.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: best practice for advertising peering fabric routes

[Dobbins, Roland]

On Jan 15, 2014, at 10:31 PM, Leo Bicknell bickn...@ufp.org wrote:

 I am approaching it from a different perspective, 'where is PMTU-D broken for 
 people who want to use 1500-9K frames end to end?' 

I understand that perspective, absolutely.

But what I'm saying is that that whether or not they want to use jumbo frames 
for Internet traffic, it doesn't matter, because PMTU-D is likely to be broken 
either at the place where the traffic is initiated, the place where the traffic 
is received, or both - so any nonsense in the middle, especially on IXP 
networks in particular, isn't really a significant issue in and of itself.

If we could get things optimized and remediated to the point where potential 
PMTU-D breakage in IXP networks were a significant issue of iteself, the 
Internet would be much improved.  But I don't see any likelihood of that 
happening anytime soon.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: best practice for advertising peering fabric routes

[Dobbins, Roland]

On Jan 15, 2014, at 10:52 PM, Leo Bicknell bickn...@ufp.org wrote:

 (Business class) ISP's don't break PMTU-D, end users break it with the 
 equipment they connect.

Concur 100%.  That's my point.

  So a smart user connecting equipment that is properly configured should be 
 able to expect it to work properly.

In my deployment experience, many (most?) end-user organization break PMTU-D 
to/through their LANs outside of their IDCs, much less to the Internet, for 
themselves, and for everyone who wishes to communicate with them across the 
Internet.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: best practice for advertising peering fabric routes

[Dobbins, Roland]

On Jan 15, 2014, at 11:41 AM, Patrick W. Gilmore patr...@ianai.net wrote:

 I repeat: NEVER EVER EVER put an IX prefix into BGP, IGP, or even static 
 route. An IXP LAN should not be reachable from any device except those 
 directly attached to that LAN. Period.

+1

Again, folks, this isn't theoretical.  When the particular attacks cited in 
this thread were taking place, I was astonished that the IXP infrastructure 
routes were even being advertised outside of the IXP network, because of these 
very issues.

IXPs are not the problem when it comes to breaking PMTU-D.  The problem is 
largely with enterprise networks, and with 'security' vendors who've propagated 
the myth that simply blocking all ICMP somehow increases 'security'.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: EIGRP support !Cisco

[Dobbins, Roland]

On Jan 9, 2014, at 12:30 AM, Nick Olsen n...@flhsi.com wrote:

 Any thoughts?

http://tools.ietf.org/html/draft-savage-eigrp-01

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: EIGRP support !Cisco

[Dobbins, Roland]

On Jan 9, 2014, at 12:50 AM, Nick Hilliard n...@foobar.org wrote:

 IGP migration is quite do-able, even for large networks, and all cisco 

+1

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: EIGRP support !Cisco

[Dobbins, Roland]

On Jan 9, 2014, at 12:52 AM, Nick Olsen n...@flhsi.com wrote:

 But this is needed to integrate into an existing network. 

Route redistribution?

cringe

or eBGP?

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: NSA able to compromise Cisco, Juniper, Huawei switches

[Dobbins, Roland]

On Jan 1, 2014, at 2:07 AM, Randy Bush ra...@psg.com wrote:

 it's weasel words (excuse the idiom).  shoveling kitty litter over a big 
 steaming pile.

Clayton is responding to the ability that he's allowed, and he's using words 
very precisely.

Here's Cisco's official responses, so far.

http://blogs.cisco.com/news/comment-on-der-spiegel-articles-about-nsa-tao-organization/

http://tools.cisco.com/security/center/content/CiscoSecurityResponse/cisco-sr-20131229-der-spiegel

I know both Clay and jns quite well, and they're both straight-shooters. 

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton



signature.asc
Description: Message signed with OpenPGP using GPGMail