Re: "Is BGP safe yet?" test

On 2020-04-22 12:51, Andrey Kostin wrote: BCP38 website doesn't proclaim anybody in person to be unsafe, but if it would be possible to make such test it'd be more useful than that RPKI test. BTW, has anybody yet thought/looked into extending RPKI-RTR protocol for validation of prefixes receiv

Re: "Is BGP safe yet?" test

On 2020-04-21 12:36, Rubens Kuhl wrote: On Tue, Apr 21, 2020 at 1:10 PM Matt Corallo via NANOG wrote: That’s an interesting idea. I’m not sure that LACNIC would want to issue a ROA for RIPE IP space after RIPE issues an AS0 ROA, though. And you’d at least need some kind of time delay to give o

Re: CISA critical infrastructure letters

Indeed, many folks are developing letters summarizing the specific company mission, employee role & authorization, and tethering that to the DHS access letter(s) with more information to inform / better enable anyone that may need to assess. You should also be aware of any local / state req

Re: BGP FlowSpec

On 2016-05-02 09:16 AM, Martin Bacher wrote: I mainly agree on that. However, I have not found evidence of inter-AS S-RTBH deployments as of now. This would really require, at least in my understanding, a lot of hacks in order to implement it properly and avoid blackholing of the wrong traffic

Re: BGP FlowSpec

On 2016-05-02 09:48 AM, Martin Bacher wrote: So filtering as precise as possible and as close as possible to the attack source is maybe the best option we have at the moment. That was precisely my point! If an upstream isn't filtering at their ingress (or their egress) the optimal place fo

Re: BGP FlowSpec

On 2016-04-28 02:31 AM, Martin Bacher wrote: Literally the only people who were interested in it at the time was one of the spec's co-authors. :-) That’s how it usually starts. ;) Given that I may be the guilty one here, I thought it might be worth chiming in. Inter-AS FlowSpec larg

Re: Routing Insecurity (Re: BGP in the Washington Post)

On 2015-06-01 22:07, Mark Andrews wrote: If you have secure BGP deployed then you could extend the authenication to securely authenticate source addresses you emit and automate BCP38 filter generation and then you wouldn't have to worry about DNS, NTP, CHARGEN etc. reflecting spoofed traffic.

Re: ARIN / RIR Pragmatism (WAS: Re: RADB)

On 2014-10-25 06:57, Sandra Murphy wrote: Other RIR based RIRs have the same ability to protect prefixes in their realm of control. (See RFC 2725 RPSS)(*) (I think that APNIC is doing pretty much as RIPE is.) Even RIPE is not secure for prefixes outside their region. (There's one maintainer t

Re: ARIN / RIR Pragmatism (WAS: Re: RADB)

On 2014-10-25 08:25, John Curran wrote: With respect to IRR support, the same answer applies. If the community is clear on direction, ARIN can strengthen the current IRR offerings, phase them out and redirect folks to existing solutions, or any other direction as desired. The hardest part is

Re: ARIN / RIR Pragmatism (WAS: Re: RADB)

On 2014-10-24 15:24, Christopher Morrow wrote: it seems to me that there are a couple simple issues with IRR data (historically): 1) no authority for it (really, at least in the ARIN region) 2) no common practice of keeping it updated 3) proxy-registration issues (probably part of cleanup

Re: ARIN / RIR Pragmatism (WAS: Re: RADB)

On 2014-10-23 15:02, Sandra Murphy wrote: IRR usage, training, tools, and better hygiene, perhaps expressly validated from resource certification from either RPKI You might be interested in the draft-ietf-sidr-rpsl-sig-05.txt, which suggests using RPKI to protect RPSL objects. Yep, I'm aware

Re: ARIN / RIR Pragmatism (WAS: Re: RADB)

On 2014-10-23 12:33, Christopher Morrow wrote: Sounds like you want to see the rirs make sure they get rpki work dine and widely available with the least encumbrances on the network operator community as possible. Or focus on more short/intermediate term returns like fortifying all the existi

ARIN / RIR Pragmatism (WAS: Re: RADB)

I think the routing system would be in a much happier [less bad] place if only had a minor amount of the energy and resources that USG (and RIRs) have been put towards RPKI and BGPSEC (i.e., IETF SIDR work) would have been redirected to lower hanging fruit and better recognizing / leveraging

Re: What do people use public suffix for?

On Apr 15, 2013, at 5:34 PM, Geoffrey Keating wrote: > > CAs use it as part of a procedure to determine whether it's safe to > issue a wildcard domain (as in, if it's on the list, it's not safe). See > , section 11.1.3. > > They'd reall

Re: How are operators using IRR?

On Jan 17, 2013, at 9:44 AM, Michael Hallgren wrote: > Hi, > > Some of the networks close to me, use IRR based AS_PATH and > prefix filters at customer-route import. > > Needless to say that running periodic diffs between what's found in > IRR and what's received in RW and discuss the results

Re: Real world sflow vs netflow?

On Sep 23, 2012, at 12:43 AM, Peter Phaal wrote: > In both cases the router is generating the telemetry, in the netflow > case, packets are sampled on the router, the router builds flow > records based on the contents of the sampled packets, and the flow > records are exported. In the sFlow case,

Re: RPKI Pilot Participant Notice

On Sep 5, 2012, at 3:32 PM, Gary Buhrmaster wrote: > > My interpretation was what Randy implied, and that ARIN > wants an agreement with everyone who gets a (presumably > unique to the agreement) TAL to protect ARIN. That would > seem like a lot of overhead to maintain to me (since as I recall >

Re: rpki vs. secure dns?

On Apr 28, 2012, at 6:34 AM, Alex Band wrote: > All in all, RPKI has really good traction and with native router support in > Cisco, Juniper and Quagga, this is only getting better. We should be more careful with statements such as this, they're conflating important things that add to the co

Re: do not filter your customers

On Feb 24, 2012, at 2:49 PM, Richard Barnes wrote: > You seem to think that there's some extension/modification to BGPSEC > that would fix route leaks in addition to the ASPATH issues that > BGPSEC addresses right now. Have you written this up anywhere? I > would be interested to read it. I do

Re: do not filter your customers

On Feb 24, 2012, at 2:29 PM, Christopher Morrow wrote: > > I think if we asked telstra why they didn't filter their customer some > answer like: > 1) we did, we goofed, oops! > 2) we don't it's too hard > 3) filters? what? > > I suspect in the case of 1 it's a software problem that needs more >

Re: do not filter your customers

On Feb 24, 2012, at 1:10 PM, Steven Bellovin wrote: > But just because we can't solve the whole problem, does that > mean we shouldn't solve any of it? Nope, we most certainly should decompose the problem into addressable elements, that's core to engineering and operations. However, simply bec

Re: do not filter your customers

On Feb 23, 2012, at 10:42 PM, Randy Bush wrote: > the problem is that you have yet to rigorously define it and how to > unambiguously and rigorously detect it. lack of that will prevent > anyone from helping you prevent it. You referred to this incident as a "leak" in your message: "a customer

Re: do not filter your customers

On Feb 23, 2012, at 1:44 AM, Randy Bush wrote: > a customer leaked a full table to smellstra, and they had not filtered. > hence the $subject. Ahh, this is I think the customer "leak" problem I'm trying to illustrate that an RPKI/BGPSEC-enabled world alone (as currently prescribed) does NOT pr

Re: [#135346] Unauthorized BGP Announcements (follow up to Hijacked Networks)

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, announcing /24s and working

Re: Why not to use RPKI (Was Re: Argus: a hijacking alarm system)

On Jan 20, 2012, at 8:08 AM, Yang Xiang wrote: > > I think network operators are only careless, but not trust-less, > so black-hole hijacking is the majority case. This is aligned with the discussion on route leaks at the proposed interim SIDR meeting just after NANOG. Even with RPKI and BGPS

Re: RIS raw data

On Jan 19, 2012, at 7:52 AM, Randy Bush wrote: > of course, taking anything from the IRR literally is naïve at best. Unfortunately, if the BGPSEC, RPKI and SIDR work stays course in the IETF, we're still going to need IRR-esque policy capabilities (outside of route server and prefix origin bin

Re: F.ROOT-SERVERS.NET moved to Beijing?

On Oct 3, 2011, at 1:34 PM, Leo Bicknell wrote: > > I'm asking the BIND team for a better answer, however my best > understanding is this will query a second root server (typically > next best by RTT) when it gets a non-validating answer, and assuming > the second best one validates just fine the

Re: F.ROOT-SERVERS.NET moved to Beijing?

On Oct 3, 2011, at 1:09 PM, Christopher Morrow wrote: > Given that in the ISC case the hostname.bind query can tell you at > least the region + instance#, it seems plausible that some system of > systems could track current/changes in the mappings, no? and either > auto-action some 'fix' (SHUT DO

Re: F.ROOT-SERVERS.NET moved to Beijing?

On Oct 3, 2011, at 11:20 AM, Leo Bicknell wrote: > > Thus the impact to valid names should be minimal, even in the face > of longer timeouts. If you're performing validation on a recursive name server (or similar resolution process) expecting a signed response yet the response you receive is e

Re: F.ROOT-SERVERS.NET moved to Beijing?

On Oct 3, 2011, at 7:29 AM, Tony Finch wrote: > > If you are running BIND 9.8 there is really no reason not to turn on > DNSSEC validation, then you won't have to worry about anycast routes > leaking from behind the great firewall. User Exercise: What happens when you enable integrity checking

Re: Suspecious anycast prefixes

On May 5, 2011, at 11:58 AM, David Miller wrote: > > IF things are not functioning properly and the operator of the service is > depending on end consumers of the service to notify them of which node is > malfunctioning, then it is time for the operator of the service to go back to > the drawi

Re: Suspecious anycast prefixes

On May 5, 2011, at 9:43 AM, David Miller wrote: > In a properly functioning system - folks that consume the service don't need > to know which node they are utilizing. Right, it doesn't matter IF things are functioning properly. If they're not, however... > Providing the capability for well

Re: Suspecious anycast prefixes

On May 3, 2011, at 6:17 AM, Bill Woodcock wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > On May 2, 2011, at 12:35 PM, Joe Abley wrote: >> It's perhaps worth noting that there is work in the IETF to recommend that >> every prefix originated as part of an anycast cloud uses a uni

Re: Regional AS model

On Mar 24, 2011, at 5:45 PM, David Conrad wrote: > On Mar 24, 2011, at 11:08 AM, Jeffrey S. Young wrote: >> Multiple AS, one per region, is about extracting maximum revenue from >> your client base. In 2000 we had no technical reason to do it, I can't see >> a technical reason to do it today.

Re: [arin-announce] ARIN Resource Certification Update

On Jan 24, 2011, at 9:21 PM, Richard Barnes wrote: > The more you have to invent, though, the more this sounds like a > bike-shed discussion. > s/DNSSEC/X.509/g > s/delegating reverse "prefix" zone/signing RPKI delegation certificate/g The difference is that we don't have an operational RPKI syst

Re: [arin-announce] ARIN Resource Certification Update

On Jan 24, 2011, at 9:14 PM, Randy Bush wrote: > > you want certificates etc? or did you plan to reuse dns keys? I suspect the former, reusing much of the SIDR machinery perhaps, although > if the former, than all you are discussing is changing the transport to > make routing security rel

Re: [arin-announce] ARIN Resource Certification Update

On Jan 24, 2011, at 9:02 PM, Joe Abley wrote: > > In this case the DNS delegations go directly from RIR to C; there's no > opportunity for A or B to sign intermediate zones, and hence no opportunity > for them to indicate the legitimacy of the allocation. > > As a thought experiment, how would

Re: [arin-announce] ARIN Resource Certification Update

On Jan 24, 2011, at 8:48 PM, Randy Bush wrote: >> And now that DNSSEC is deployed > > and you are not sharing what you are smoking root and .arpa are signed, well on the way, particularly relative to RPKI. Incremental cost of signing in-addr.arpa using a deployed DNS system as opposed to con

Re: [arin-announce] ARIN Resource Certification Update

On Jan 24, 2011, at 8:32 PM, Randy Bush wrote: > let's wind the wayback machine to 1998 > >http://tools.ietf.org/html/draft-bates-bgp4-nlri-orig-verif-00 Yep, read that way back when it was posted initially, and again a short while back, makes good sense, methinks. And now that DNSSEC is

Re: [arin-announce] ARIN Resource Certification Update

On Jan 24, 2011, at 7:16 PM, Randy Bush wrote: > > i understand fearing holding others' private keys and critical data. no > blame there. > > > but out of curiousity, how reality based are arin's general liability > fears? in the last few years, how many times has arin been a named > defendan

Re: Using crypto auth for detecting corrupted IGP packets?

On Sep 30, 2010, at 11:34 PM, Manav Bhatia wrote: > > I would be interested in knowing if operators use the cryptographic > authentication for detecting the errors that i just described above. Additionally, one might venture to understand the effects of such mechanisms and why knob's such as IS-

Re: Standard for BGP community lists

On Jul 20, 2010, at 1:26 AM, Saku Ytti wrote: > On (2010-07-19 23:45 -0500), Brad Fleming wrote: > > Hey, > >> : for local rtbh >> : for local + remote rtbh >> >> I didn't have much reason for selecting other than it was easy >> to identify visually. And obviously, I have

Re: Rate Limiting on Cisco Router

On Jul 8, 2010, at 4:05 PM, Alan Bryant wrote: > Thanks again for all the responses to my previous post. > > We have a Cisco 7206VXR router with IOS of 12.4(12) and a PA-POS-1OC3 > card ofr our OC3. > > The problem we have now is that we are only paying for 80 MB/s of the > OC-3, and the ISP is

Re: U.S. Plans Cyber Shield for Utilities, Companies

On Jul 8, 2010, at 9:26 AM, valdis.kletni...@vt.edu wrote: >> >> I'm not familiar with cable break splicing procedures, but is it even >> possible to pay extra to have your splice done first? I would think >> that the logistics of splicing are such that the guy down in the hole >> doesn't kn

Re: BGP and convergence time

On May 12, 2010, at 9:40 AM, Jay Nakamura wrote: > > I just tested this and, yes, with Cisco to Cisco, changing the setting > won't reset the connection but you have to reset the connection to > have the value take effect. I need to look up what happens when two > sides are set to different val

Re: Securing the BGP or controlling it?

On May 11, 2010, at 7:32 AM, Nick Hilliard wrote: > Risk analysis is ass covering without the theatre. You collect data, make > a judgement based on that data, and if it turns out that the judgement says > that signed bgp updates constitute more of a stability risk to network > operations than t

Re: Securing the BGP or controlling it?

On May 10, 2010, at 2:31 PM, Anton Kapela wrote: > Interestingly, the article misses interception and other non-outage > potentials due to (sub) prefix hijacking. I think it captures it in such a way that my grandmother might be more likely to grok it. Regardless, those are just more symptoms

Re: Securing the BGP or controlling it?

On May 10, 2010, at 2:52 PM, Larry Sheldon wrote: > At the risk of seeming to be a conspiracy theorist, I am worried that > with "Central Authority" we might not have "hijacking" but "rerouting > for inspection and correction". Building a database (i.e,. RPKI) aligned with the Internet number re

Re: Securing the BGP or controlling it?

On May 10, 2010, at 10:48 AM, Nick Hilliard wrote: > There are a lot of problems associated with using IRRDB filters for inbound > prefix filtering. We used them over 15 years ago near ubiquitously and stopped mostly because: 1) there was nothing akin to route refresh so you had to bounce bes

Re: Securing the BGP or controlling it?

On May 10, 2010, at 9:52 AM, Nick Hilliard wrote: > > this is a matter of risk analysis. No secure routing means we'll continue > to see the occasional high profile outage which is dealt with very quickly. If 3 weeks (e.g., the recent 'i root w/China incident) is "very quickly" then we're ope

Re: BGP hijack from 23724 -> 4134 China?

On Apr 8, 2010, at 8:35 PM, Brielle Bruns wrote: > > More harm then good is a matter of opinion. Denying all of mainland China > reduces the amount of attacks on my network. If you consider that masking > security problems rather then fixing them, then *shrugs*. Its just one of > many layer

Re: BGP hijack from 23724 -> 4134 China?

On Apr 8, 2010, at 8:05 PM, Brielle Bruns wrote: > > Since there's been alot of requests for the ACLs, i've gone ahead and put the > info on our wiki for easy access. > > http://wiki.sosdg.org/sosdg:internal:chinafilter > > Hope it comes in handy, and please let me know if i'm missing anything

Re: China prefix hijack

On Apr 8, 2010, at 11:45 AM, Martin A. Brown wrote: > Just a note of confirmation that 23724 originated as many as 31847 > prefixes during an 18 minute window starting around 15:54 UTC. > They were prepending their own AS, and this is several orders of > magnitude more prefixes than they norm

Re: BGP Update Report

On Mar 30, 2010, at 9:30 PM, Randy Bush wrote: > might some of this be that the implementations use router-id to fill in > an unconfigured rr cluster-id? Yep! So intermediate nodes in an iBGP topology with varying cluster IDs per RR with a common client set can certainly result in duplicate e

Re: BGP Update Report

On Mar 28, 2010, at 12:00 PM, Anton Kapela wrote: > I guess what I'm hinting at is precisely something finer-grained (path not > prefix), as you suggest. Per-neighbor enabled, versus "entire bgp RIB" would > be preferred. I'm also interested in the *chronic* nature of these apparent > instabil

Re: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group]

On Feb 26, 2010, at 4:41 PM, Steven M. Bellovin wrote: > > I think that "PTT" is the operative token here, but for reasons having > nothing to do with competition. If all they wanted was competition, > the easy answer would be to set up more registries -- or registrars > -- not bounded by geogr

DURZ published in root - you ready?

Figured I'd drop a note here reminding folks of the signed root zone publication timeline, which calls for L root to begin serving a 'DURZ' the "week of 1/25/2010" -- which is now - depending on what timezone you're in: If yo

Re: 2009 Worldwide Infrastructure Security Report available for download.

On Jan 20, 2010, at 8:32 AM, Stefan Fouant wrote: > > > I'm wondering if you can clarify why 'Figure 1' only goes up to 2008 and > states in key findings "This year, providers reported a peak rate of only 49 > Gbps". I happen to personally recall looking at ATLAS sometime last year > and seein

Re: 2009 Worldwide Infrastructure Security Report available for download.

On Jan 21, 2010, at 4:34 AM, Pekka Savola wrote: > Thanks to Arbor for collecting the report and your observations. > > One thing I found extremely strange is that almost 50% report they use > BCP38/Strict uRPF at peering edge, yet only about 33% use it in customer > direction. (Figure 13, p20

Re: news from Google

I think one of the things that concerns me most with Google validating and jumping on the DNS "open resolver" bandwagon is that it'll force more folks (ISPs, enterprises and end users alike) to leave DNS resolver IP access wide open. Malware already commonly changes DNS resolver settings to

OT: 2009 Infrastructure Security Survey

Folks, We're in the process of collecting feedback for this years infrastructure security report, the fifth edition of the report. The 2008 Infrastructure Security Survey is up and available for input. You can register to complete the survey at this URL:

Re: Multi-homed clients and BGP timers

On May 25, 2009, at 11:33 AM, Florian Weimer wrote: * Iljitsch van Beijnum: 30 60 isn't a good choice because that means that after 30.1 seconds a keepalive comes in and then after 60.0 seconds the session will expire while the second one would be there in 60.1 seconds. Wouldn't the und

Re: Multi-homed clients and BGP timers

On May 22, 2009, at 5:15 PM, Steve Bertrand wrote: neighbor xxx.xx.xx.x timers 30 60 Make sure that this is communicated to your peer as well so that their timer setting are reflected the same. Thankfully at this point, we manage all CPE of any clients who peer with us, and so far, the

Re: Pseudowire Problem

On May 22, 2009, at 6:20 AM, Shivlu Jain wrote: I have seen a weird behaviour in case of pseudo wire termination, it keeps on polling the destination ip even if the interface mapped to pseudo wire is down. Is it the normal behaviour? Shivula, You probably need to address your query to eit

Re: Great outage of 1997 - Does anyone recall?

On Feb 22, 2009, at 10:10 PM, Christopher Morrow wrote: On Mon, Feb 23, 2009 at 12:06 AM, Paul Wall wrote: On Sun, Feb 22, 2009 at 2:57 AM, Gadi Evron wrote: What was that story with an African routes some years back, any memories anyone? I am looking for a reference. 146.20.0.0/16?

Re: massive routes hijack at AS48400, up to 6000 AS affected?

On Jan 24, 2009, at 9:47 PM, AKK wrote: Hi all, Jan 24 23:20 - Jan 25 01:45 UK time, from LINX peers I have seen major performance degradation on unusually strange route to some eastern Europe countries - see MTR at the bottom of this email. If this is true, it is exactly what few people

Re: Are we really this helpless? (Re: isprime DOS in progress)

On Jan 23, 2009, at 10:06 PM, David Conrad wrote: Sad fact is that there are zillions of excuses. Unfortunately I suspect the only way we're going to make any progress on this will be for laws to be passed (or lawsuits to be filed) that impose a financial penalty on ISPs through which t

Re: Are we really this helpless? (Re: isprime DOS in progress)

On Jan 23, 2009, at 9:10 PM, Christopher Morrow wrote: On Fri, Jan 23, 2009 at 10:31 PM, wrote: On Fri, 23 Jan 2009 18:33:14 PST, Seth Mattinen said: Back to my original question: is there really not a better solution? Well, we *could* hunt down the perpetrators, pool some $$, and hire

Re: What is the most standard subnet length on internet

On Dec 18, 2008, at 9:43 PM, 정치영 wrote: Suresh, Yes, I guess my concern is close to the second meaning. It seems so simple. Currently annoucement of /24 seems to be okey, most upstream providers accept this. However I wonder if there is any ground rule based on any standard or official re

Re: an over-the-top data center

On Nov 28, 2008, at 6:34 AM, Steven M. Bellovin wrote: http://royal.pingdom.com/2008/11/14/the-worlds-most-super-designed-data-center-fit-for-a-james-bond-villain/ (No, I don't know if it's real or not.) I recall visiting something of this sort a couple years back.. On a related noted, some

Re: Prefix Hijack Tool Comaprision

On Nov 13, 2008, at 1:05 PM, Todd Underwood wrote: as such, i don't count it as a hijacking or leak of any great significance and wouldn't want to alert anyone about it. that's why i recommend that prefix hijacking detection systems do thresholding of peers to prevent a single, rogue, unrepres

Re: The DDOS problem & security BOF: Am i mistaken?

Scott, Given that I both co-moderated the ISP security BOF AND gave a ~9 minute presentation covering *empirical* data and stats of observed attack vectors across 100 ISP networks over 640 days, and shared a slide or two with stats from an infrastructure security survey we've been doing and shari

Re: only WV FIBER now peering with Atrivo / Intercage

I'm not sure where that 58.65.238.0/24 prefix with AS3549 in the path came from. I *currently* see no BGP RIB entries with AS "3549_27595" (GBLX Intercage) in the path. A query for the past 6 hours yields 32 AS 27595 originated prefixes, here are each with their associated upstream ASN(s) (26769

Re: Revealed: The Internet's well known BGP behavior

On Aug 28, 2008, at 3:47 PM, Deepak Jain wrote: We can go into lots of reasons why the Internet runs this way. I think we can all agree 1) Its amazing it runs as well as it does, and 2) No one has clearly articulated a financial reason for any large organizations to significantly change t

Re: Is it time to abandon bogon prefix filters?

On Aug 18, 2008, at 6:33 AM, Jared Mauch wrote: On a router with full routes (ie: no default) the command is: Router(config-if)#ip verify unicast source reachable-via any Go ahead and try it out. you can view the resulting drop counter via the 'show ip int ' command.

Re: Public shaming list for ISPs announcing other ISPs IP space by mis take

On Aug 14, 2008, at 11:37 PM, Paul Ferguson wrote: Okay, I admit I haven't paid the closest attention to RPKI, but I have to ask: Is this a two-way shared-key issue, or (worse) a case where we need to rely on a central entity to be a key clearinghouse? The reason why I mention this is obvious

Re: Public shaming list for ISPs announcing other ISPs IP space by mistake

On Aug 14, 2008, at 10:59 PM, David Conrad wrote: Yep. IANA does indeed have a limited operational role in the DNS (in that currently IANA directly operates .int, ip6.arpa, urn.arpa, uri.arpa, and iris.arpa) and no direct operational role in routing. Of course, the statement was about th

Re: Is it time to abandon bogon prefix filters?

On Aug 6, 2008, at 12:01 PM, Sean Donelan wrote: Attacks or misconfigured leaks? Leaks of RFC1918 stuff is pretty common, just ask any of the root server operators how many packets they see from RFC1918 leaking networks or do a traceroute across several residential cable network backbones

Re: Is it time to abandon bogon prefix filters?

On Aug 6, 2008, at 9:01 AM, Randy Bush wrote: serious curiosity: what is the proportion of bad stuff coming from unallocated space vs allocated space? real measurements, please. and are there longitudinal data on this? are the uw folk, gatech, vern, ... measuring? Some data from our an

Re: Public shaming list for ISPs announcing other ISPs IP space bymistake

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 respondent n

Re: Public shaming list for ISPs announcing other ISPs IP space bymistake

On Aug 14, 2008, at 8:42 PM, Jean-François Mezei wrote: Pardon my ignorance here, but wouldn't it be much simpler if the so called "tier 1" networks were to do the filtering work so that none of downstream BGP peers would see the bad announcements ? If some network in italy sends out some bogu

Re: Public shaming list for ISPs announcing other ISPs IP space by mistake

On Aug 14, 2008, at 1:09 PM, Jared Mauch wrote: You're missing a step: janitor. No really, the reason for some leaks isn't because so-and-so was never a customer, they were. 5 years ago. nobody removed the routes from the IRR or AS-SET or and now the route is le

Re: Public shaming list for ISPs announcing other ISPs IP space by mistake

On Aug 14, 2008, at 11:30 AM, David Conrad wrote: On Aug 14, 2008, at 9:47 AM, brett watson wrote: We're lacking the authority and delegation model that DNS has, I think? If one were to ignore layer 9 politics, it could be argued the authority/delegation models between DNS and address sp

[OT] 2008 Infrastructure Security Survey

Folks, The 2008 Infrastructure Security Survey is up and available for input. You can register to complete the survey at this URL: I've added many questions this time from past participants of the survey, this should be evidenced through

ISP Security BOF: NANOG 43

- Sunday, June 1 - 4-530 P Salon F/G ISP Security BOF: NANOG 43 http://www.nanog.org/mtg-0806/abstracts.php?sp=Fouant Moderators: Stefan Fouant/Neustar Danny McPherson/Arbor ISC SIE Update http://sie.isc.org/ Paul Vixie/ISC ICANN SSAC Update http://www.icann.org/committees/secur

Re: YouTube IP Hijacking

On Feb 26, 2008, at 1:07 PM, Steve Gibbard wrote: As far as I can piece together from what's been reported and argued here, there were three responsible parties: The Pakistani Government who ordered YouTube blocked, Pakistan Telecom who implemented a lawful order but overshot their gover