f how some
people will do anything to save $1 (a month) even if the tech is highly
beneficial.
Danny Messano
On Jan 15, 2024 at 14:12 -0500, Jay Hennigan , wrote:
> On 1/15/24 09:37, Abraham Y. Chen wrote:
>
> > 2) Allow me to share with you an almost parallel event in the
really change Internet interconnection dynamics to 3Cs operators in
US or adjustments in EU or Asia also ?
How about sub sea capacity into the US. Probably there are many cables owned by
consortium of Asian operators for many years ... ?
Danny
f prefixes received from peer-as to make ingress
filtering more dynamic and move away prefix filters from the routers?
Do you really want those things in soft-state and not with some giant
operational buffer to absorb all the brokenness that's sure to arise?
-danny
etermining that to be done.
Or a miscreant. [insert-least-favorite-rir] is now part of your attack
surface.
-danny
when necessary). Ideally, if applicable
your folks have already established those relationships in the event
that they need them.
-danny
On 2020-03-25 15:02, Matt Erculiani wrote:
The letters are not to be confused with hall passes.;they don't even
have an individual's name on it
!
Danny
Meister
Infrastructure Engineer
Atomic Data®
//
Safe. Simple. Smart.®
250 Marquette Avenue
Minneapolis, MN 55401
Main
//
612.466.2000
Direct
//
612.466.2071
corp culture Danny On Tue, 04
Jun 2019 20:00:54 +0530 Mehmet Akcin wrote hi there,Just
a general high-level question about Centurylink/Level3 post-merger, how is your
overall experience with CenturyLink? if you could be sitting with the CEO of
the company what is one thing you w
7;s just a matter of where and what the management/control
plane is. I agree with your intra-AS comment.
-danny
place for me to filter is at my
ingress. Of course I'd rather have something akin to inter-domain
pushback or FlowSpec, etc.. But you can't control how, or assume others
will act on that.
-danny
ng traffic when necessary. Just like destination and
source-based RTBH, FlowSpec is simply another evolution of automating
forwarding path configuration, where NFV/SDN are the newest incarnation
and can allows badness such as DDoS to be dropped implicitly rather than
explicitly, even...
-danny
ly scare the heck
out of them, the primitives of which surely extend to many of the
luminaries quoted in those articles.
YMMV,
-danny
oints Sandy, I agree they need to be resolved.
It's just that RPKI feels like a _really heavy solution to _that
problem. That said, if that problem were solved nearly all of what I
care about with regard to routing security (and inter-domain
anti-spoofing) could be addressed.
-danny
operations that exists and makes
the Internet resilient.
Thanks for that response, John.
-danny
..
I actually think it'd have been a challenge to design something _more
complicated than RPKI to address the problem space, but that's just me.
-danny
is, and in-addr.arpa, and..) for a
whole bunch of stuff just to keep the packets flowing then the height
limit to do basic and useful things just became that much higher, and
requires a lot more care and feeding then before RPKI (even absent all
the architectural aspects of RPKI that are "interesting").
-danny
ARIN board did what they did with the RPA
and I don't blame them -- it seemed well considered to me, but that's
just me.
Reminded of Taleb's "Fat Tony" quote [paraphrased]: If the pilot ain't
on the plane, you probably don't want to get on it,
-danny
nd other externalities at play these days.
Alas,
-danny
dynamic structure in an outside medium is only
going to cause problems down the road (e.g., especially with namespace
diffusion from the likes of new gTLDs, etc..).
While an unfortunate naming collision here (i.e., the "SOPA" RR), I think an
approach such as [1] has some merit - but mu
ctive complexity see [NormalAccidents], it's quite applicable to
today's networks systems, methinks.
-danny
[NormalAccidents] Perrow, Charles, "Normal Accidents: Living with
High-Risk Technologies", 1999.
quot; here:
<http://tools.ietf.org/html/draft-grow-irr-routing-policy-considerations-00>
If folks have comments, additions, etc.. email authors or g...@ietf.org.
-danny
c flows. This is _part of the point Roland was trying to
make.
-danny
t rely to much on the data for
routing, and if they do and something gets hosed, ARIN's not at fault -- but
I'll wait to read the actual agreement before speculating more.
-danny
add to the confusion in this area.
None of these implementations support "RPKI" today. What they support is a new
protocol for onboarding routing policy data (some call this a [VRP],
essentially prefix,origin bindings) into soft state in a router.
-danny
[VRP] https://ripe64.ripe
ed to read it.
I don't, actually -- as I haven't presupposed that "BGPSEC" is the
answer to all things routing security related, nor have I excluded it.
I didn't realize it was unacceptable to acknowledge a problem exists
without having solved already. I might have that backwards though.
-danny
omers and peers to use it,
and even then this still happened - WTF was the point?
This "leak" thing is a key vulnerability that simply can't be brushed
aside - that's the crux of my frustration with the current effort.
-danny
r this incident a threat is beyond me, particularly when it
happens by accident all the time. How we can justify putting all
that BGPSEC and RPKI machinery in place and not address this
"leak" issue somewhere in the mix is, err.., telling.
Alas, I suspect we can all agree that exp
ourced to do so, will eventually
recognize what I'm calling "leaks" is part of the routing security
problem.
-danny
r peers, and the peers went over
> prefix limits and dropped bgp.
Prefix limits are rather binary and indiscriminate, indeed.
-danny
Internet number resource certification and origin validation sure would be nice
here ;-)
-danny
On Jan 31, 2012, at 7:49 PM, Kelvin Williams wrote:
> I hope none of you ever get hijacked by a spammer housed at Phoenix NAP. :)
>
> We're still not out of the woods, annou
ould have traversed
those ASes in the first place -- so we still need something somewhere
to mitigate that threat.
See this draft for more information:
<http://tools.ietf.org/html/draft-foo-sidr-simple-leak-attack-bgpsec-no-help-01>
-danny
han envisioned in mad max.
I agree, it's important to analyze systemic cost/benefit and complexity
analysis and new operational impacts various standards work is introducing.
-danny
;one extra query", and it's not simply about
subsequent transaction attempts either - so conjecture aiming
to marginalize the impact isn't particularly helpful.
I.e., have that look, get back to us... :-)
-danny
place you can do this in the routing
system, as I'm sure some will observe, but it seems an ideal location
to me.
-danny
th
that particular issue, rather than being captive to the [s]lowest
common denominator of all involved parties, and dealing with
additional non-determinsitic failures or exposure in the interim.
Back to my earlier point, for *resilience* network layer integrity
techniques and secure routing infrastructure are the only preventative
controls here, and necessarily to augment DNSSEC's authentication and
integrity functions at the application layer. Absent these, rapid
detection enabling reactive controls that mitigate the issue are
necessary.
-danny
ll that's going to fix this. In the interim, the ability to detect such
incidents at some rate faster than the speed of mailing lists would be
ideal.
-danny
ansparency which can be employed to
inform measurement and detection systems. IF / how an operator
chooses to apply controls based on that information (e.g., drop
a prefix originated from an unauthorized origin AS or leaked via
a known bad path) that's certainly their prerogative.
-danny
nts of the forwarding path you
influence if you were an evildoer aiming to do such a thing.
-danny
people can point at
> and claim is a "best common practice" when it's neither best nor common.
'clueless people' wouldn't care which node they utilize, where
it resides, or what other attributes might exist and be associated
with it. Providing a discriminator in the control plane for the
consumer of critical network services might well be of utility to
some.
-danny
case might
have been a good idea I think contribute to the debate.
Nonetheless, I'd strongly urge anyone not to assume that activists and
journalists at physical risk in states like Iran assume that risk by
using specific tools, or that major (if temporary) failures in the PKI
structure d
ive to this discussion are provided in
the title: "Unique Per-Node Origin ASNs for Globally Anycasted
Services"
-danny
Hi ,
I saw 39.0.0.0/8 from AS273 on global table till last week .Was it a genuine
advertisement or some tests ongoing with 39.0.0.0/8 or any other previously
reserved spaces .
I am updating my bogons lists and want to know any experiments happening with
previous reserved spaces.
Thanks,
Dan
On Sun, Feb 13, 2011 at 5:01 AM, Joly MacFie wrote:
> Any confirmation of internet blocking?
>
> http://bikyamasr.com/wordpress/?p=26849
>
> As massive street demonstrations are met with widespread violence in
> Algeria, the country is reporting that many Facebook accounts have been
> deleted or
On Mon, Jan 31, 2011 at 2:14 PM, Marshall Eubanks wrote:
> As an update, BGP for Noor.net has been withdrawn. Even the Egyptian stock
> exchange - egyptse.com - now appears to be off the Internet.
>
>
Yep, Noor is now down.
Those on the ground with Noor DSL in Cairo contacted their front line
sup
On Thu, Jan 27, 2011 at 6:07 PM, Roy wrote:
> On 1/27/2011 3:47 PM, Danny O'Brien wrote:
>
>> Around 2236 UCT, we lost all Internet connectivity with our contacts in
>> Egypt, and I'm hearing reports of (in declining order of confirmability):
>>
>>
cense, there is some very
early work to provide emergency connectivity. Info at:
http://pastebin.com/fHHBqZ7Q )
Thank you,
--
dobr...@cpj.org
Danny O'Brien, Committee to Protect Journalists
gpg key: http://www.spesh.com/danny/crypto/dannyobrien-key20091106.txt
;t have an operational RPKI system, we
do have an operational DNS one.
It's most certainly NOT a bike shed discussion - at least with respect
to how I'd configure my routers.
I suspect I've sufficiently chummed the waters, I'll kick back and absorb
all the reasons this is a whack idea :)
-danny
number resource certification - are you suggesting
otherwise?
> if the latter, then you have the problem that the dns trust model is not
> congruent with the routing and address trust model.
That could be easily fixed with trivial tweaks and transitive trust/
delegation graphs that are, I suspect.
-danny
thought experiment, how would you see this working?
New prefix-based RRs? And perhaps even a new .arpa or
in-addr.arpa subdomain, the draft Randy referenced even
discussed the latter, IIRC.
-danny
#x27;t like the notion of deploying a brand new
system with data that at the end of the day is going to look an
awful lot like the existing in-addr.arpa delegation system that's
deployed, and introduce new hierarchical shared dependencies
that don't exist today. Keep it simple?
-danny
e) with RPKI at all.
-danny
ning to wonder why, with work like DANE and certificates in DNS
in the IETF, we need an RPKI and new hierarchical shared dependency
system at all and can't just place ROAs in in-addr.arpa zone files that are
DNSSEC-enabled.
--but very happy we have some progress for Internet number resource
certification.
-danny
Coincidentally, it's also why logging LSPs that trigger such errors is
important, whether
you ignore them or propagate them.
-danny
s IETF working groups, from IDR and GROW to
OPSEC and L3VPN, for those interested in having a gander...
-danny
cation with critical business
applications first via LAN-side rate-shaping functions - or AUPs, or
-danny
t's more useful and commonly employed when
intermediate facility failures happen - prioritized regrooming of critical
services is sometimes even automated, and often results in, err.. less critical
services being booted until full restoration has occurred.
-danny
alives such that the probability of
getting one through in times of instability rise. In particular,
congestion incurred outside of BGP, as update messages themselves
will serve as implicit keepalives, and with the amount of churn in BGP,
empty updates (keepalives) are rare for most speakers with a global BGP
view.
-danny
ta, we understand the vulnerability and the
risk (probability of a threat being used). Put that in your risk
management equation and consider what assets are most vulnerable
to your organization - I'd venture it's something to do with network,
and if routing ain't working, network ain't working...
-danny
t more symptoms
of the same underlying problem, no? And the "i root" incident was
plausibly a hybrid of error and intercept, so there's a nice hefty
gray area there as well.
I suspect no one missed that..
-danny
, and then some global inputs.
This basically helps people to make more informed decisions, methinks.
-danny
client software. At least irrtoolset compiles these
> days, but its front-end is very primitive. rpsltool provides some really
> nice templating functionality, but doesn't implement large sections of the
> rpsl standards.
Agreed, we need to do work here.
-danny
ery
quickly" then we're operating on different timescales.
> My gut instinct tells me that secure routing and the rpki venture well into
> the realm of negative returns.
I believe 'sucks less' falls into the realm of positive, so here
we disagree.
-danny
filters for reasons outlined here
and elsewhere many times before - and bogon addresses theoretically
don't have live clients and servers folks might be legitimately be
transacting with.
-danny
utting a bandaid on a headache - it's not going
to do much good in reality, and likely cause more harm than good in properly
secured networks - but it might make some folks feel a little better.
-danny
broken the current "routing by rumor" model continues to
be.
-danny
ch in their operating environment - they can have considerable impact.
-danny
udied and understand why this occurs, the
issue is that implementation optimizations seem to always win out today over
systemic state effects (i.e., that "be conservative in what you send" thing
doesn't seem to apply in practice, unfortunately).
-danny
more robust IP fabric would
evolve to be more resilient and robust from national Internet registry
allocation models or the Internet routing system rearchitecting that's
sure to follow.
Of course, if the ITU-T is serious about this, they should probably be
asking for a good chunk of 32-bit ASNs as well, but that's a bit more
difficult to do under the auspices of liberating IPv6.
-danny
e not signing anything -
do note that 'systemic' is the operative word above, as this
will impact you, whether you make any explicit changes in
your environment or not.
G'luck,
-danny
eally like to think people aren't
> opting not to use flow-based tools in favor or receiving customer calls :(
Yep, I think this is simply an artifact of a larger respondent pool
size, with many smaller respondents being represented.
-danny
ur cocnern..
Thanks Pekka (and several others) for pointing this out.
-danny
and everyone else) decide that _overriding
application-level DNS settings (e.g., for Chrome) are perfectly
reasonable -- not to mention the value they find in operation of
DNS infrastructure from a data mining (e.g., NXDOMAIN data ==
marketing intelligence/$$) that many other folks have long ago
realized...
-danny
ttp://www.arbornetworks.com/report>
Thanks in advance for your participation!
-danny
#x27;t the underlying TCP retry sooner than that?
I suspect that given update messages serve as implicit
keepalives, it's _extremely rare that an actual keepalive
message is needed in global routing environments.
-danny
effects with these as well..
- if I need to down core2, what is the quickest and easiest way to
ensure that all gear connected to the cores will *quickly* switch to
preferring core1?
Use your IGP mechanisms akin to IS-IS overload bit or OSPF
stub router (max metric) advertisement.
-danny
tf.org/html.charters/pwe3-charter.html>
HTH,
-danny
nline-kenya-latest-internet-routing-insecurity-casuality/
>
-danny
rse look
I've already had when I get some time. I suspect others
will be looking as well.
-danny
guments about infrastructure support, resources,
tools, etc.. I consider those argument no longer valid and
operators who don't implement ingress BCP 38 style filtering
remiss.
-danny
mitigation mechanism
on all customer ingress interfaces (note: uRPF *loose*
mode no-fixie these attacks) - as you should have had
in the first place such that you didn't have to trace
those spoof packets step-by-step back through your
network.
No more excuses, people..
-danny
s with rancid is that the code makes it hard to do
other things, e.g. compare the active and standby configs in our 6500s
I'd also like to add a feature that recognizes the significant blocks in
a config
and store in a database so you can do queries like "when was vlan777
modified"
Danny
nd
Aggregation Strategy
<http://tools.ietf.org/html/rfc1519>
Network Renumbering Overview
<http://tools.ietf.org/html/rfc2071>
A Framework for Inter-Domain Route Aggregation
<http://tools.ietf.org/html/rfc2519>
HTH,
-danny
oted, some have professed that adapting old
ships into data centers would provide eco-friendly secure
data center solutions. I wonder if "pirates" were listed
anywhere in their business plan...
-danny
ikely propagate much wider - and be detected much quicker.
-danny
erate if you'd like,
but to address the question in the subject line directly -
"Am I mistaken", I believe yes.
Also, please don't confuse discussion of what happened at
beer n gear with what happened at the BOF.
-danny
16.255.184.0/21 - 26769,19151
216.255.184.0/22 - 19151
216.255.188.0/22 - 19151
As for which of these prefixes seem to be associated with alleged
nefarious activities, I'll leave that as an exercise for the operator.
-danny
leap from
RPKI directly into a secure inter-domain routing protocol.
-danny
istence of the source as part of the attack
vector (e.g., DNS cache poisoning, BGP TCP RST attacks,
DNS reflective amplification attacks, etc..), and as a result, loose
mode gives folks a false sense of protection/action.
-danny
is is obvious -- the entire PKI effort
has been stalled (w.r.t. authority) because of this particular
issue.
Any thoughts on that?
See Randy et al's presentation here:
<http://www.nanog.org/mtg-0610/bush.html>
In short, the latter, which is precisely DRC's point.
-danny
paying attention to this.
-danny
ual BCP 38/uRPF numbers are likely
lower, and you're more clueful if you complete the survey :-)
-danny
-
Self-classified respondent network type (approaching 50
responses):
Tier 1: 13.33%
Tier 2: 28.89%
Pure Content Network: 11.11%
Hosting Provider: 8.89%
Education or Academic Network: 13.33%
rate-based DDoS attacks)
-danny
---
General Statistics
total_days 631
total_attacks 1137265
avg_attacks_day 1802
avg_collectors_day 47
avg_attacks_collector_day 38
total_good_attacks 727410 63.96%
---
Bogon Summary
bogon block attacks % of attacks
0.0.0.0/7 65
A sneak-peek at some (NOT FINAL) relevant data points from
the *ongoing* Infrastructure Security Survey related to this topic
(see below for participation information, if so inclined).
Draw your own conclusions, we'll make ours known in the final
report.
-danny
---
Self classified respo
m from
lesser
networks.
Tragedy of the commons...
-danny
e route is
learned via
some other location and it's bypassed your perimiter security and
infiltrated your BGP.
I agree, how many of you folks that use IRRs have
ever deleted an IRR object? Heck, some ISPs even
add them based on existence of advertised routes.
-danny
o be clear: IANA and RIRs allocate or assign address space
today, they don't control any routing on the Internet (and their
own internal ASNs and IPs don't count).
-danny
y) identifiable information will be shared in any
manner.
The 2007 edition of the survey is available here:
<http://www.tcb.net/wisp07.pdf>
Or on the Arbor web site (reg required):
<http://www.arbornetworks.com/report>
Thanks in advance for your participation!
-danny
significantly impact reverse dns
lookups as I think the dns is spread across other RIR's
seems there was a different type of issue in May
http://www.bauani.org/thinkings/2008/05/issue-with-apnic-dns-nameservers.html
Danny Thomas
# dig @I.GTLD-SERVERS.net apnic.net +norec
; <<>&g
Folks,
Here's the agenda for the ISP security BOF tomorrow
afternoon. There's still some space left on the agenda
so if there's something you'd like to discuss (or hear
someone else discuss) drop Stefan and I an email.
Thanks, see you in Brooklyn!
-danny & Stefan
--
ilable and accurate routing system.
IMO, the onus is on the operators to step up...
-danny
99 matches
Mail list logo
