Re: A study on community-triggered updates in BGP
> IOS-XR has duplicate update suppression logic for EBGP sessions as, i believe, do most all implementations, to protect best path computation costs. randy
Re: Ingress filtering on transits, peers, and IX ports
term blocked-ports {
from {
protocol [ tcp udp ];
first-fragment;
destination-port
[ 0 sunrpc 135 netbios-ns netbios-dgm netbios-ssn 111 445 syslog
11211];
}
then {
sample;
discard;
}
}
and i block all external access to weak devices such as switches, pdus,
ipmi, ...
randy
dfw equinix back door
would love to get to our racks through a back door through equnix exchange in the informart. our router is at ipv4 address 206.223.118.94 255.255.254.0 ipv6 address 2001:504:0:5::4128:1/64 asn 4128 thanks! randy
Re: dfw equinix back door
> would love to get to our racks through a back door through equnix > exchange in the informart. our router is at > > ipv4 address 206.223.118.94 255.255.254.0 > ipv6 address 2001:504:0:5::4128:1/64 > asn 4128 solved randy
plea for comcast/sprint handoff debug help
tl;dr: comcast: does your 50.242.151.5 westin router receive the announcement of 147.28.0.0/20 from sprint's westin router 144.232.9.61? details: 3130 in the westin announces 147.28.0.0/19 and 147.28.0.0/20 to sprint, ntt, and the six and we want to remove the /19 when we stop announcing the /19, a traceroute to comcast through sprint dies at the handoff from sprint to comcast. r0.sea#traceroute 73.47.196.134 source 147.28.7.1 Type escape sequence to abort. Tracing the route to c-73-47-196-134.hsd1.ma.comcast.net (73.47.196.134) VRF info: (vrf in name/id, vrf out name/id) 1 r1.sea.rg.net (147.28.0.5) 0 msec 1 msec 0 msec 2 sl-mpe50-sea-ge-0-0-3-0.sprintlink.net (144.232.9.61) [AS 1239] 1 msec 1 msec 0 msec 3 * * * 4 * * * 5 * * * 6 * * * this would 'normally' (i.e. when the /19 is announced) be r0.sea#traceroute 73.47.196.134 source 147.28.7.1 Type escape sequence to abort. Tracing the route to c-73-47-196-134.hsd1.ma.comcast.net (73.47.196.134) VRF info: (vrf in name/id, vrf out name/id) 1 r1.sea.rg.net (147.28.0.5) 0 msec 1 msec 0 msec 2 sl-mpe50-sea-ge-0-0-3-0.sprintlink.net (144.232.9.61) [AS 1239] 1 msec 0 msec 1 msec 3 be-207-pe02.seattle.wa.ibone.comcast.net (50.242.151.5) [AS 7922] 1 msec 0 msec 0 msec 4 be-10847-cr01.seattle.wa.ibone.comcast.net (68.86.86.225) [AS 7922] 1 msec 1 msec 2 msec etc specifically, when 147.28.0.0/19 is announced, traceroute from 147.28.7.2 through sprint works to comcast. withdraw 147.28.0.0/19, leaving only 147.28.0.0/20, and the traceroute enters sprint but fails at the handoff to comcast. Bad next-hop? not propagated? covid? magic? which is why we wonder what comcast (50.242.151.5) hears from sprint at that handoff note that, at the minute, both the /19 and the /20 are being announced, as we want things to work. so you will not be able to reproduce. so, comcast, are you receiving the announcement of the /20 from sprint? with a good next-hop? randy
Re: plea for comcast/sprint handoff debug help
> tl;dr: > > comcast: does your 50.242.151.5 westin router receive the announcement > of 147.28.0.0/20 from sprint's westin router 144.232.9.61? tl;dr: diagnosed by comcast. see our short paper to be presented at imc tomorrow https://archive.psg.com/200927.imc-rp.pdf lesson: route origin relying party software may cause as much damage as it ameliorates randy
Re: Apple Catalina Appears to Introduce Massive Jitter
> Most folk from various fora suggested Location Services were to > blame. I turned all of mine off, no joy. you only *think* you turned off location services. as they are a vital component of providing a good user experience ... :(
Re: plea for comcast/sprint handoff debug help
>>> tl;dr: >>> >>> comcast: does your 50.242.151.5 westin router receive the announcement >>> of 147.28.0.0/20 from sprint's westin router 144.232.9.61? >> >> tl;dr: diagnosed by comcast. see our short paper to be presented at imc >> tomorrow https://archive.psg.com/200927.imc-rp.pdf >> >> lesson: route origin relying party software may cause as much damage as >> it ameliorates >> >> randy > > To clarify this for the readers here: there is an ongoing research > experiment where connectivity to the RRDP and rsync endpoints of > several RPKI publication servers is being purposely enabled and > disabled for prolonged periods of time. This is perfectly fine of > course. > > While the resulting paper presented at IMC is certainly interesting, > having relying party software fall back to rsync when RRDP is > unavailable is not a requirement specified in any RFC, as the paper > seems to suggest. In fact, we argue that it's actually a bad idea to > do so: > > https://blog.nlnetlabs.nl/why-routinator-doesnt-fall-back-to-rsync/ > > We're interested to hear views on this from both an operational and > security perspective. in fact, has found your bug. if you find an http server, but it is not serving the new and not-required rrdp protocol, it does not then use the mandatory to implement rsync. randy
Re: plea for comcast/sprint handoff debug help
i'll see your blog post and raise you a peer reviewed academic paper and two rfcs :) in dnssec, we want to move from the old mandatory to implement (mti) rsa signatures to the more modern ecdsa. how would the world work out if i fielded a validating dns cache server which *implemented* rsa, because it is mti, but chose not to actually *use* it for validation on odd numbered wednesdays because of my religious belief that ecdsa is superior? perhaps go over to your unbound siblings and discuss this analog. but thanks for your help in getting jtk's imc paper accepted. :) randy
Re: plea for comcast/sprint handoff debug help
> If there is a covering less specific ROA issued by a parent, this will > then result in RPKI invalid routes. i.e. the upstream kills the customer. not a wise business model. > The fall-back may help in cases where there is an accidental outage of > the RRDP server (for as long as the rsync servers can deal with the > load) folk try different software, try different configurations, realize that having their CA gooey exposed because they wanted to serve rrdp and block, ... randy, finding the fort rp to be pretty solid!
Re: plea for comcast/sprint handoff debug help
>- Randy says: "finding the fort rp to be pretty solid!" I'll say that >if you loaded a fresh Fort and fresh Routinator install, they would both >have your ROAs. >- The sense of "stickiness" is local only; hence to my mind the >protection against "downgrade" attack is somewhat illusory. A fresh install >knows nothing of history. fort running enabled rrdp on server router reports r0.sea#sh ip bgp rpki table | i 3130 147.28.0.0/2020 3130 0 147.28.0.84/323 147.28.0.0/1919 3130 0 147.28.0.84/323 147.28.64.0/19 19 3130 0 147.28.0.84/323 147.28.96.0/19 19 3130 0 147.28.0.84/323 147.28.128.0/19 19 3130 0 147.28.0.84/323 147.28.160.0/19 19 3130 0 147.28.0.84/323 147.28.192.0/19 19 3130 0 147.28.0.84/323 192.83.230.0/24 24 3130 0 147.28.0.84/323 198.180.151.0/24 24 3130 0 147.28.0.84/323 198.180.153.0/24 24 3130 0 147.28.0.84/323 disabled rrdp on server added new roa 198.180.151.0/25 waited a while router reports r0.sea#sh ip bgp rpki table | i 3130 147.28.0.0/2020 3130 0 147.28.0.84/323 147.28.0.0/1919 3130 0 147.28.0.84/323 147.28.64.0/19 19 3130 0 147.28.0.84/323 147.28.96.0/19 19 3130 0 147.28.0.84/323 147.28.128.0/19 19 3130 0 147.28.0.84/323 147.28.160.0/19 19 3130 0 147.28.0.84/323 147.28.192.0/19 19 3130 0 147.28.0.84/323 192.83.230.0/24 24 3130 0 147.28.0.84/323 198.180.151.0/25 25 3130 0 147.28.0.84/323 <<<=== 198.180.151.0/24 24 3130 0 147.28.0.84/323 198.180.153.0/24 24 3130 0 147.28.0.84/323 as i said, fort seems solid randy
Re: plea for comcast/sprint handoff debug help
> r0.sea#sh ip bgp rpki table | i 3130 > 147.28.0.0/2020 3130 0 147.28.0.84/323 > 147.28.0.0/1919 3130 0 147.28.0.84/323 > 147.28.64.0/19 19 3130 0 147.28.0.84/323 > 147.28.96.0/19 19 3130 0 147.28.0.84/323 > 147.28.128.0/19 19 3130 0 147.28.0.84/323 > 147.28.160.0/19 19 3130 0 147.28.0.84/323 > 147.28.192.0/19 19 3130 0 147.28.0.84/323 > 192.83.230.0/24 24 3130 0 147.28.0.84/323 > 198.180.151.0/25 25 3130 0 147.28.0.84/323 <<<=== > 198.180.151.0/24 24 3130 0 147.28.0.84/323 > 198.180.153.0/24 24 3130 0 147.28.0.84/323 note rov ops: if you do not see that /25 in your router(s), the RP software you are running can be damaging to your customers and to others. randy
Re: plea for comcast/sprint handoff debug help
> cc.rg.net was unavailable over rsync for several days this week as > well. sorry. it was cb and cc. it seems some broken RPs did not have the ROA needed to get to our westin pop. cf this whole thread. luckily such things never happen in real operations. :) randy
Re: Technology risk without safeguards
> The fact that we haven't been able to identify a factual relationship, > does not mean that there isn't any. just wow and, for all we know, the back side of the moon is green cheese
Re: plea for comcast/sprint handoff debug help
> Admittedly someone (randy) injected a pretty pathological failure > mode into the system really? could you be exact, please? turning an optional protocol off is not a 'failure mode'. randy
Re: plea for comcast/sprint handoff debug help
>> really? could you be exact, please? turning an optional protocol off >> is not a 'failure mode'. > I suppose it depends on how you think you are serving the data. > If you thought you were serving it on both protocols, but 'suddenly' > the RRDP location was empty that would be a failure. not necessarily. it could merely be a decision to stop serving rrdp. perhaps a security choice; perhaps a software change; perhaps a phase of the moon. > One of my points was that it appeared that the software called 'bad > tls cert' (among other things I'm sure) a failure, but not 'empty > directory' (or no diff file). It's possible that ALSO 'no diff' is > considered a failure what the broken client software called what is not my probem. every http[s] server in the universe is not necessarily an rrdp server. if the client has some belief, for whatever reason, that it should be is a brokenness. > I don't think alex is wrong in stating that 'ideally the operator > monitors/alerts on health of their service' i do. i run clients. > My suggestion is that checking the alternate transport is helpful. as i do not see rrdp as a critical service, after all it is not mti, but i am quite aware of whether it is running or not. the problem is that rotinator seems not to be. randy
Re: plea for comcast/sprint handoff debug help
i may understand one place you could get confused. unlike a root CA which publishes a TAL which describes transports, a non-root CA does not publish a TAL describing what transports it supports. of course, rsync is mandatory to provide; but anything else is "if it works, enjoy it. otherwise use rsync." randy
Re: FCC: Staff Report on T-Mobile Outage on June 15 2020
> The larger story here is... > > "7. Routing. Routers connect T-Mobile’s LTE towers to T-Mobile’s LTE > network. These routers utilize a routing protocol called Open > Shortest Path First." you can blow it with is-is, just as you can with ospf, just as you can with pretty much any dynamic [routing] protocol. though i am an is-is fanboy, i would not blame the protocol. and if they can not manage the currently deployed protocol, i am not sure i would recommend they try a delicate transition. randy
Re: Re[2]: Disney+ Geolocation (again)
< advertisement > https://datatracker.ietf.org/doc/draft-ymbk-opsawg-finding-geofeeds/ there is a draft-ietf-opsawg-finding-geofeeds as soon as draft submission opens randy
Re: Apple Catalina Appears to Introduce Massive Jitter - SOLVED! - Update!
> “Saw the same” after installing yesterday Big Sur and suddenly > received a notification “this version of little snitch is no longer > supported by macOS. It’s looks like I have to pay 25€ for a new > compatible version. and big slur bypasses it for some nefarious uses, e.g. [un]trustd i am sticking with catatonic randy
Re: A letter from the CEO
> Our key differentiator is that we encrypt our backbone links. care to give detail of the tech used? randy
Re: Are the days of the showpiece NOC office display gone forever?
> In the traditional sense, by "showpiece NOC" I mean a room designed for the > purpose of having large situational awareness displays on a wall, network > weathermaps and charts, alerting systems, composed of four or more big flat > panel displays. Ideally configured to be actually useful for NOC purposes > and also something impressive looking for customer tours. though your message has a current date, its content seems to be at least 15 years old randy
Re: Parler
> In article <474fe6a6-9aa8-47a7-82c6-860a21b0e...@ronan-online.com> you write: >> When I actively hosted USENET servers, I was repeatedly warned by in-house >> and external counsel, not to moderate which groups I hosted >> based on content, less I become responsible for moderating all groups, >> shouldn’t that same principal apply to platforms like AWS and >> Twitter? > > If this was in the US and it was after the CDA was passed in 1996, > your lawyers were just wrong. it is really annoying that you leave not the slightest clue to who the hell you are replying randy
Re: the tiny domain business, not a utility, was Parler
> By comparison, that's about what Google makes every 10 days or what > Apple makes every week. Verisign is a highly profitable fish in a tiny > pool. by a very late stage capitalism definition of 'tiny' randy
opportunistic email encryption by the MTA (not MUA)
email from a friend who uses protonmail as their MTA suddenly started to be opportunistically encrypted with pgp; i.e. the sender's MUA did nothing to cause the encryption. i believe this started when i provided my pgp public key over WKD [0]. i have a guess. i suspect that protonmail opportunistically tests for a WKD for the recipient and, if found, uses it. i do see protonmail queries to my WKD service /var/log/httpd-access.log:185.70.40.57 - - [14/Jan/2021:08:44:41 +] "HEAD /.well-known/openpgpkey/policy HTTP/1.1" 200 - "-" "GuzzleHttp/6.5.5 curl/7.29.0 PHP/7.4.11" /var/log/httpd-access.log:185.70.40.57 - - [14/Jan/2021:08:44:42 +] "GET /.well-known/openpgpkey/hu/pbe8wr5gm5b4gf43adj411yrreqyib6u?l=randy HTTP/1.1" 200 26027 "-" "GuzzleHttp/6.5.5 curl/7.29.0 PHP/7.4.11" /var/log/httpd-access.log:185.70.40.57 - - [14/Jan/2021:10:49:44 +] "HEAD /.well-known/openpgpkey/policy HTTP/1.1" 200 - "-" "GuzzleHttp/6.5.5 curl/7.29.0 PHP/7.4.11" /var/log/httpd-access.log:185.70.40.57 - - [14/Jan/2021:10:49:45 +] "GET /.well-known/openpgpkey/hu/pbe8wr5gm5b4gf43adj411yrreqyib6u?l=randy HTTP/1.1" 200 26027 "-" "GuzzleHttp/6.5.5 curl/7.29.0 PHP/7.4.11" /var/log/httpd-access.log:185.70.40.57 - - [14/Jan/2021:15:02:49 +] "HEAD /.well-known/openpgpkey/policy HTTP/1.1" 200 - "-" "GuzzleHttp/6.5.5 curl/7.29.0 PHP/7.4.11" /var/log/httpd-access.log:185.70.40.57 - - [14/Jan/2021:15:02:49 +] "GET /.well-known/openpgpkey/hu/pbe8wr5gm5b4gf43adj411yrreqyib6u?l=randy HTTP/1.1" 200 26027 "-" "GuzzleHttp/6.5.5 curl/7.29.0 PHP/7.4.11" my interest is whether WKD publication is triggering opportunistic encryption; if anything else might be using it opportunistically, and if this can actually scale. i really do not want to discuss if pgp encryption is a good thing, if opportunistic encryption is the spawn of the frog goddess, or if there are viable alternatives to emacs. anyone with protonmail clue or contact(s)? randy [0] - https://git.rg.net/randy/randy/src/master/pgp-WKD.md
Re: opportunistic email encryption by the MTA (not MUA)
fyi, i was contacted by a clue holder from protonmail. my guess was correct. they pointed me to the wkd section of https://protonmail.com/blog/security-updates-2019/ as i responded to them: i am definitely wondering how well it scales. it adds query burden, often toward a server different than the smtp target. e.g. the wkd server could have sucky performance. randy
Re: DoD IP Space
> due to it being so massive and unused for so long, certain large > corporations that have run out of RFC1918, etc. space have started > using it internally. i first saw that on a traceroute from my hotel at ripe bologna in 2001. i was told i was lng late to finding it. randy
Re: DoD IP Space
> I’m sure we all remember Y2k (well, most of us, there could be some > young-uns on the list). That day was happening whether we wanted it to > or not. It was an unchangeable, unmovable deadline. but i thought 3gpp was gong to force ipv6 adoption
Re: DoD IP Space
>> I’m sure we all remember Y2k (well, most of us, there could be some >> young-uns on the list). That day was happening whether we wanted it to >> or not. It was an unchangeable, unmovable deadline. > > but i thought 3gpp was gong to force ipv6 adoption let me try it a different way why should i care whether you deploy ipv6, move to dual stack, cgnat, ...? you will do whatever makes sense to the pointy heads in your c suite. why should i give them or some tech religion free rent in my mind when i already have too much real work to do? randy
public open resolver list?
is there a list of public resolvers? e.g. 1.1.1.1, 4.4.4.4, 8.8.8.8, etc.? we have a measurement set which contains a list of resolvers, some of which we suspect are intentionally open, some unintentionally open, and some not open. we are trying to filter that first set, the intentionally open. the open resolver finders would seem not to meet our need. but, yes, it would be nice if they documented the intentional public open resolvers. randy
Re: public open resolver list?
>> is there a list of public resolvers? e.g. 1.1.1.1, 4.4.4.4, 8.8.8.8, >> etc.? > > https://public-dns.info/ interesting, but probably too broad. but i suspect my question was too broad. >> we have a measurement set which contains resolvers, some of which we >> suspect are intentionally open, some unintentionally open, and some >> not open. we are trying to filter that first set, the intentionally >> open. i suspect it hinges on what one thinks of as 'public'. i.e. dtag's servers for its customers is not what i think of as public. maybe i mean globally public or something. randy, who clearly needs to think a bit more
Re: DoD IP Space
i must say i am impressed that the ipv6 must be deployed now and it solves it all religion is still being shouted from the street corner 25 years on. it is as if the shouters think they will convince any body or change anything. folk will deploy X when they perceive that the cost:benefit is in X's favor. and 25 years on, we are not changing people's perceptions. it's only been a quarter of a century; have some patience. randy
Re: DoD IP Space
>> i must say i am impressed that the ipv6 must be deployed now and it >> solves it all religion is still being shouted from the street corner >> 25 years on. it is as if the shouters think they will convince any >> body or change anything. folk will deploy X when they perceive that >> the cost:benefit is in X's favor. and 25 years on, we are not >> changing people's perceptions. it's only been a quarter of a >> century; have some patience. > > We'll carry on. > > Those who want to join will join, when they join. iij joined in '97. and helped others who asked. but i'm from the rainy pacific northwest (of the states). we don't try to push water uphill. randy
Re: DoD IP Space
> Perhaps it's time that we made good friends with the folk accelerating > pr0n, and did a deal with them where someone's fetish was only > available over IPv6. hint: that idea is from the late '90s. the next bright idea for what would help ipv6 take over the internet was 3gpp. it's been a long line of things which would make ipv6 take off. and at least ten million messages on mailing lists such as this. and the adoption rate has crawled up slowly; the first derivative remaining fairly flat. of course, if you measure it at the right place, it can have steep points. when goog tured it up for youtube, the proportion of their v6 traffic went up nicely; no surprise. but when i want to measure a real rate of change, i like a mid-stream sample at some isps' borders or ixp, away from eyeballs or eye candy. if we all spent as much time deploying, or helping others deploy as opposed to screaming at them that they must do it asap, we might get that first derivative up a wee bit. but i fear that, at this point, patience is what is most useful. randy
Re: DoD IP Space
> it’s unclear if there’s been any systematic look-back or institutional > learning coming out of the entire experience. i am always impressed by optimism in the face of cold reality
Re: Infomart Dallas is on generator
> From the latest update it sounds like rolling power outages in Dallas as > most places in Texas https://www.texastribune.org/2011/02/08/texplainer-why-does-texas-have-its-own-power-grid/
Re: Famous operational issues
actually, the 129/8 incident was as damaging as 7007, but folk tend not to remember it; maybe because it was a bit embarrassing and the baltimore tunnel is a gift that gave a few times and the quake/mudslides off taiwan the tohoku quake was also fun, in some sense of the word but the list of really damaging wet glass cuts is long
Re: Famous operational issues
> actually, the 129/8 incident a friend pointed out that it was the 128/9 incident > but folk tend not to remember it qed, eh? :)
Re: Famous operational issues
when employer had shipped 2xJ to london, had the circuits up, ... the local office sat on their hands. for weeks. i finally was pissed enough to throw my toolbag over my shoulder, get on a plane, and fly over. i walked into the fancy office and said "hi, i am randy, vp eng, here to help you turn up the routers." they managed to turn them up pretty quickly.
Re: LOAs for Cross Connects - Something like PeeringDB for XC
> But it looks like a "crypto sign and publishes" anything related to an > organization. that is the problem with this discussion. it does not. it allows one to show ownership of an AS or prefix. it does not show ownership or authority over an organization. keep your trust model straight. randy
Re: LOAs for Cross Connects - Something like PeeringDB for XC
> are you asking about something like this: > https://datatracker.ietf.org/doc/draft-spaghetti-sidrops-rpki-rsc/ > > Which COULD be used to, as an AS holder: > "sign something to be sent between you and the colo and your intended peer" > > that you could sign (with your rpki stuffs) and your peer could also > sign with their 'rpki stuffs', and which the colo provider could > automatically validate and action upon final signature(s) received. chris, way back, the rirs were very insistant that their use of rpki authority was most emphatically not to be considered an identity service. this permeated the design; e.g., organization names were specifically forbidden in certificate CN, Subject Alternative Name, etc. aside: of course a few rirs thought that *their* names should be in their certs as exeptions. i remember the laughter. randy --- ra...@psg.com `gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com` signatures are back, thanks to dmarc header mangling
Re: LOAs for Cross Connects - Something like PeeringDB for XC
>> way back, the rirs were very insistant that their use of rpki authority >> was most emphatically not to be considered an identity service. this >> permeated the design; e.g., organization names were specifically >> forbidden in certificate CN, Subject Alternative Name, etc. >> > > yup, I agree... though the b2b stuff George/Geoff have written up LOOKS like > it could be useful for this LOA type discussion. The spaghetti draft appears > to also fill this niche... > > Neither are particularly rooted in the RPKI except that the CA certs are being > used as a method to attest that a 'thing' exists, and that something signed > that 'thing' as proof of knowledge (I guess, really). Effectively this is: > 1) I am 'ca-foo' in a tree that you can trust knows I am 'foo'. > 2) I signed this blob (LOA) > 3) I asked jane at bar.com to sign as well > 4) you can verify me (because rpki tree) and you can verify Jane because > she's > also using her RPKI ca cert. > > this may be a little cumbersome to sort through, especially if all parties > here > aren't party to the RPKI (did equinix plumb the RPKI into their customer > portal > and all of the things required to make a x-connect work in this manner?), but > I > imagine that if this gets wings it could be automated and it could be reliable > and all parties (except the colo folks perhaps?) may already have incentives > in places to use their RPKI goop for this function. this would work only if the LOA is being sent to someone with whom my contract is signed with a key validating through the same hierarchy, or the credential was associated contractually. i do not think equinix is up to this yet. randy
Re: LOAs for Cross Connects - Something like PeeringDB for XC
>> What if PeeringDB would be the CA for the Facilities? >> Supposedly this solves the CA problem of the "Colo Folks". > > I think pushing your security identification out (as the notional > equinix) to a third party where you can't revoke/change/etc is asking > for dangerous things to happen. there are a few examples of industry associations with simple, strong, and formal ties sufficient to allow forms of trust automation. folk such as karen o'donoghue, lucy lynch, and heather flanagan would be able to speak vastly more knowledgeably in this space than i. > again, that draft is a... draft still and I"m sure we'll have a bunch > of chatter/discussion/changes before done, but it smells like it might > help. you might notice that we use it in draft-ietf-opsawg-finding-geofeeds. but that application is specifically to use rpki data to attest to ip address ownership. the problem there is that the draft is a cool proof of concept, but is not operationally easy to use. randy --- ra...@psg.com `gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com` signatures are back, thanks to dmarc header mangling
Re: STOP USING FONT SIZE SMALL Was: Re: LOAs for Cross Connects - Something like PeeringDB for XC
> Really, does anyone here think that it is good form to send email with > font size *SMALL*? rofl! randy --- ra...@psg.com `gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com` signatures are back, thanks to dmarc header mangling
Re: LOAs for Cross Connects - Something like PeeringDB for XC
> you can sign over something which ways "the person identified by the > following public key is to be permitted to ..." you mean the fraudlent attacker who owned that INR seems to have signed this request for a €1.000.000,49 wire transfer to their iban. a person is not identified by that signature. randt
Re: LOAs for Cross Connects - Something like PeeringDB for XC
>>> you can sign over something which ways "the person identified by the >>> following public key is to be permitted to ..." >> >> you mean the fraudlent attacker who owned that INR seems to have signed >> this request for a €1.000.000,49 wire transfer to their iban. a person >> is not identified by that signature. > > If someone has a valid CA cert/key from the RIR, it's very hard to > argue 'fraudulent'. > It's, however, "easy" for the RIR to reverse the error, right? :) sorry. by 'fraudulent' i meant that they have no authority to request the funds. you just know they own some INR. and if they request it again, you might be confident it is at least the same attacker :) now, you and i could agree formally, i.e. provably, out of band say using pgp or whatever, that ownership of some INR identifies you. or we could use some arbitrary other PKI entirely, e.g., X.400 was meant for this. but, as i said, karen, heather, and lucy know the personal and organisational identity space far better than i. i just know enough about the rpki that it is very intentionally not in that identity space. but think about the dance that prudent folk do to accept pgp keys, and pgp has fingerprints to make it a bit easier to do oob verification. but that verification uses an external identity provider, e.g. passport or whatever makes you comfortable. now infer what we would need to do to accept an rpki INR key as a proof of identity. randy --- ra...@psg.com `gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com` signatures are back, thanks to dmarc header mangling
Re: Famous operational issues
maybe late '60s or so, we had a few 2314 dasd monsters[0]. think maybe 4m x 2m with 9 drives with removable disk packs. a grave shift operator gets errors on a drive and wonders if maybe they swap it into another spindle. no luck, so swapped those two drives with two others. one more iteration, and they had wiped out the entire array. at that point they called me; so i missed the really creative part. [0] https://www.ibm.com/ibm/history/exhibits/storage/storage_2314.html randy --- ra...@psg.com `gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com` signatures are back, thanks to dmarc header mangling
Re: Famous operational issues
anyone else have the privilege of running 2321 data cells? had a bunch. unreliable as hell. there was a job running continuously recovering transactions off of log tapes. one night at 3am, head of apps program (i was systems) got a call that a tran tape was unmounted with a console message that recovery was complete. ops did not know what it meant or what to do. was the first time in over five years the data were stable. wife of same head of apps grew more and more tired of 2am calls. finally she answered one "david? he said he was going in to work." ops never called in the night again. randy --- ra...@psg.com `gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com` signatures are back, thanks to dmarc header mangling
Re: AW: OVH datacenter SBG2 in Strasbourg on fire 🔥
the conjecturbation is only surpassed by the vitrol
Re: AW: OVH datacenter SBG2 in Strasbourg on fire 🔥
> No, French Superheroes flew in from Le Café du Peintre near the > Bastille in under 30 nanoseconds. However, it was still futile. jingoism does not deter fires
Re: OVH datacenter SBG2 in Strasbourg on fire ????
>> Statement (in French) from Octave Klaba, containing some discussion >> of the development of the fire (starts at ~ 4:30): >> https://www.ovh.com/fr/images/sbg/index-fr.html > English: > https://www.ovh.com/fr/images/sbg/index-en.html and a few hundred of us hoping we never have to stand in front of that camera to explain a similar incident a few things stood out: where backups are located, the ability to build a lot of new servers and the supporting infra, ... but in a week or two i hope he can tell us results of more analysis. randy --- ra...@psg.com `gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com` signatures are back, thanks to dmarc header butchery
Re: OVH datacenter SBG2 in Strasbourg on fire ????
> It surprises that important sites don't do mirroring. depends on what you mean by 'mirroring.' think latency. randy --- ra...@psg.com `gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com` signatures are back thanks to dmarc header mangling
Re: OVH datacenter SBG2 in Strasbourg on fire ????
>>> It surprises that important sites don't do mirroring. >> depends on what you mean by 'mirroring.' think latency. > Though a best effort to mirror would be acceptable. Maybe not up to > the minute but at least a recovery. depends on if the writer has to wait for it to hit the spinning oxide 1,000km away. as i said, depends on what you mean by 'mirroring.' i would not recommend raid, drbd, ... maybe periodic rsync, or an app level sync designed for latency. randy --- ra...@psg.com `gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com` signatures are back, thanks to dmarc header butchery
Re: Saudi Arabia
> https://www.itc.sa/en/ mehmet, you actually answered rod's question. that is not allowed on the nanog list. you need to start a 20 message thread excoriating him for asking for actual operational help finding a circuit in a difficult place. what is this world coming to? sheesh! randy --- ra...@psg.com `gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com` signatures are back, thanks to dmarc header butchery
Re: Perhaps it's time to think about enhancements to the NANOG list...?
i do not find the volume or diversity on the nanog list problematic. in fact, i suspect its diversity and openness are major factors in it being the de facto global anything-ops list. perhaps we do not need to fix that. randy --- ra...@psg.com `gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com` signatures are back, thanks to dmarc header butchery
Re: Perhaps it's time to think about enhancements to the NANOG list...?
> Agreed. Don't fix what isn't broken. ryuu.rg.net:/Users/randy> whois oldnog.org GeekTools Whois Proxy v5.0.6 Ready. Checking access for 162.195.241.81... ok. Checking server [whois.publicinterestregistry.net] Results: NOT FOUND >>> Last update of WHOIS database: 2021-03-20T20:51:13Z <<< hmmm randy --- ra...@psg.com `gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com` signatures are back, thanks to dmarc header butchery
Re: Perhaps it's time to think about enhancements to the NANOG list...?
> ...not to mention that all mature networks are moving more towards GUI > front ends for their automated network. As the complexity of a network > increases, CLI access becomes considerably more risky. > > The idea that "real engineers use the CLI" is dinosaur thinking that will > eventually land those with that philosophy out of a job. Just my personal > $.02 (though I'm certainly not alone in my opinion). real engineers write code to do it. and gooeys get in the way something awful. remember cascade?
Re: IP reputation lookup (prefix not single IP)
> I think you will find that most SMTP / anti-spam focused RBL tools > give a very similar result for IP reputation on a per /24 block basis got cites? this got me curious the other day. randy --- ra...@psg.com `gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com` signatures are back, thanks to dmarc header butchery
internet futures
in 2010, the internet society made some videos on possible internet futures ten years out, i.e. nowish. nothing spot on, but themes can be seen for sure. https://www.youtube.com/watch?v=PB4zfGwctGc randy --- ra...@psg.com `gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com` signatures are back, thanks to dmarc header butchery
Re: Best practice for ptp/loopback numbering for "small" enterprise multihome setup
> tl;dr - If I only have a /24 PI - is there any way to use this and not > “chop it up / deagg” to use for ptp/loopbacks ? i take real addresses out of the /24 for p2p i take 1918 addresses for ibgp loopbacks randy --- ra...@psg.com `gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com` signatures are back, thanks to dmarc header butchery
Re: Malicious SS7 activity and why SMS should never by used for 2FA
> I'd add to that that people probably shouldn't treat phones as a > significant increase in security, it's not really the out-of-band > device that it used to be/was in the 1990s. Today, it basically > equates to a second computer and the probability that the second > computer is also compromised isn't overly unrealistic. by the same attacker? raises the bar a bit. it's just a second factor, not a guarantee. i am a fan of the google token and don't like having to carry a different hw token for everyone who wants to hw 2fa me. but i think $ubject is correct. sms 2fa is roadkill. randy --- ra...@psg.com `gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com` signatures are back, thanks to dmarc header butchery
Re: DoD IP Space
john, my altzheimer's device tells me that some years back there was a documented written agreement between arin and the dod along the lines of dod getting a large swath of ipv6 space[0] in exchange for agreeing to return[1] or otherwise put into public use a half dozen ipv4 /8s. could you refresh my memory, e.g. with the document, please? thanks. randy -- [0] which they are still trying to figure out how to use; bit isn't half the internet in a similar pinch. :) [1] since the dod probably did not get the space from arin, 'return' is probably not a good term. --- ra...@psg.com `gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com` signatures are back, thanks to dmarc header butchery
Re: DoD IP Space
anyone seeing roas in 11/8? i am not. randy --- ra...@psg.com `gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com` signatures are back, thanks to dmarc header butchery
Re: DoD IP Space
>> anyone seeing roas in 11/8? i am not. > am not either, I would be curious to know if the RPKI discussion came up > for the prefixes in the run up to turning up this new service. what i hope is that they publish the results of their experiment. a bit more depth in discussion in ripe community. --- From: Randy Bush Subject: Re: [anti-abuse-wg] AS8003 and U.S. Department of Defense routing To: Brian Nisbet Cc: Anti Abuse WG Date: Tue, 27 Apr 2021 08:22:16 -0700 interesting wg to do routing security analysis. as i do really not know the dod's or their proxy's motive(s), i can not say much about their tactics let alone strategy. i do know, and have actually seen and experienced, part of 11/8 being used as if it was 1918 space; ripe bologna was the first time. and the food in that town was fantastic! a /8 telescope would pick up leakage patterns as well as the current shotgun blast of announcements (i presume folk have looked at the actual announcements). i would naïvely think that the /8 might be slightly more easily analyzed than the pieces. maybe, as the telescope analysis shows focused leaks, they are trying to disrupt those focused uses with these focused announcements. but, if an op is using 11.12.666.0/23 internally, would they be careless enough to accept an exogenous announcement of that space? i guess i should not underestimate carelessness. is some random (small, i hope) isp using my address space internally as 1918 equivalent abusive, beyond their customers maybe not be able to reach my network? if so, maybe the vigilantes are looking in the wrong direction. randy --- ra...@psg.com `gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com` signatures are back, thanks to dmarc header butchery
Re: DoD IP Space
>> what i hope is that they publish the results of their experiment. a >> bit more depth in discussion in ripe community. > > https://bgp.he.net/AS8003#_prefixes those are not results of an experiment. those are some visible artifacts of (possibly part of) an experimental setup. what i meant was the *results* of their measurements and the insights gained. < snark > ( and when i wanted to know what prefixes were being announced, i looked at my own router(s). neither cisco, juniper, nor arcos seemed to have the equivalent of `show ip bgp regexp _8003$ insight` though i have been asking for years :) randy --- ra...@psg.com `gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com` signatures are back, thanks to dmarc header butchery
Re: Arin taking down raking
> 1) unreachable publication point / CA == 'ok, see you in 30 mins on my > next cycle through the world' (no real changes) yup. much ado about nothing > b) revoking some portion of their claimed resources in various forms of > CA == 'ideally a bunch of routes suddenly go unknown' == 'ok' > iii) making a bunch of validatable changes to ROA/certs/content == 'worse > possible outcome, likely to make a bunch of routes invalid' if the CA's pub point is available and the data have been modified, which includes removal, then all sorts of wild things can happen. but there is no need for arin to formally test that last as each of the RIRs has untentionally done so at least once; sometimes for over a day. randy
Re: A survey on BGP MRAI timer values in practice
> We already know how to make DFZ convergence really fast (or at least > orders of magnitude faster than it is), that information exists, but > that isn't deployed because customers are not asking for it, so > providers are not aware that there is room for improvements. are we confident that in the global context, not just within an isp, there is negligible, well acceptable, oscillation? randy --- ra...@psg.com `gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com` signatures are back, thanks to dmarc header butchery
Re: irrd 4.1.2 deployed at NTT
> this change means that NTT's IRR mirror service will now use RPKI > Validated ROAs to filter out invalid IRR objects! This filtering > strategy is similar to RIPE-731. > > Creation of RPKI ROAs will trigger deletion of conflicting IRR > objects, this helps clean up stale objects. Existing RPKI ROAs help > prevent future creation of unauthorized IRR objects. cool! what stands between my current world and when i can remove my irrd instance and when i can remove (which) objects from the ripe whois? < psa > 15-20 years back, when designing early rpki deployment, folk wanted the irr to be equally if not more authoritative than the rpki. trust what you are already familiar with. some where downright rabid about irr / whois rulz. the pendulum swings. while i confess to helping to create this rpki origin validation thingie, i would warn that it is pretty rigid. notice how many xnog threads we see about broken dnssec or just dns meaning my.mtv is mot reachable? this is analogous, except it is at the routing layer. recommended actions: get your roas correct and monitor their correctness use an external service which ensures your roa data are propagating correctly globally use reliable and correct relying party softweare; there is crap out there monitor your routers to ensure that they are getting current relying party data familiarize your noc and engs with a toolset to provide assurance of and debug all of the above i am sure there are more things to do; and hope that wiser folk will expand, comment, and correct. randy --- ra...@psg.com `gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com` signatures are back, thanks to dmarc header butchery
Re: irrd 4.1.2 deployed at NTT
>> i am sure there are more things to do; and hope that wiser folk will >> expand, comment, and correct. > > Stay far away from AS0... one of 42 ways, invented by clever people, to shoot yourself in the foot randy
Re: Can somebody explain these ransomwear attacks?
> Finding vulnerabilities and how to exploit them to run malware > in closed source code is nigh on impossible. which explains why it never happens randy --- ra...@psg.com `gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com` signatures are back, thanks to dmarc header butchery
Re: FreeBSD's ping Integrates IPv6
> I just noticed (although it appears to have come in version 13.0) that > FreeBSD's "ping" app now defaults to IPv6, i.e., no need for ping6: pola breakage. especially fun if you have tools which run on both sides of the koolaid. randy --- ra...@psg.com `gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com` signatures are back, thanks to dmarc header butchery
Re: A crazy idea
> Well, for SLAAC you need a /64 this is not true randy --- ra...@psg.com `gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com` signatures are back, thanks to dmarc header butchery
Re: A crazy idea
On Mon, 19 Jul 2021 09:27:13 -0700, Nathan Angelacos wrote: > > On Mon, 2021-07-19 at 08:51 -0700, Randy Bush wrote: > > > Well, for SLAAC you need a /64 > > > > this is not true > > > > randy > > > That is cool! Can you point me to the correct RFC please? > from the war zone, draft-classless6/draft-nbourbaki-6man-classless-ipv6 said The length of the Interface Identifier in Stateless Address Autoconfiguration [RFC4862] is a parameter; its length SHOULD be sufficient for effective randomization for privacy reasons. For example, 48 bits might be sufficient. But operationally we recommend, barring strong considerations to the contrary, using 64-bits for SLAAC in order not to discover bugs where 64 was hard- coded, and to favor portability of devices and operating systems. Note that OpenBSD ships with SLAAC for lengths longer than /64. Nonetheless, there is no reason in theory why an IPv6 node should not operate with different interface identifier lengths on different physical interfaces. Thus, a correct implementation of SLAAC must in fact allow for any prefix length, with the value being a parameter per interface. For instance, the Interface Identifier length in the recommended (see [RFC8064]) algorithm for selecting stable interface identifiers [RFC7217] is a parameter, rather than a hard-coded value.
Re: 1G/10G BaseT switch recommendation
[ uncloak: i work at arrcus, but at the far back of the company ] > I'd reach out to Arrcus as well. They are a NOS house, but they can > also provide hardware options that suit what you want. thanks, mark. while arrcus provides stunning world class layer three: bgp, is-is, ospf, evpn, srv6, blah blah blah, we don't really so much exciting at layer two switching. randy
Re: Global Akamai Outage
> Very often the corrective and preventive actions appear to be > different versions and wordings of 'dont make mistakes', in this case: > > - Reviewing and improving input safety checks for mapping components > - Validate and strengthen the safety checks for the configuration > deployment zoning process > > It doesn't seem like a tenable solution, when the solution is 'do > better', since I'm sure whoever did those checks did their best in the > first place. So we must assume we have some fundamental limits what > 'do better' can achieve, we have to assume we have similar level of > outage potential in all work we've produced and continue to produce > for which we exert very little control over. > > I think the mean-time-to-repair actions described are more actionable > than the 'do better'. However Akamai already solved this very fast > and may not be very reasonable to expect big improvements to a 1h > start of fault to solution for a big organisation with a complex > product. > > One thing that comes to mind is, what if Akamai assumes they cannot > reasonably make it fail less often and they can't fix it faster. Is > this particular product/solution such that the possibility of having > entirely independent A+B sides, for which clients fail over is not > available? If it was a DNS problem, it seems like it might have been > possible to have entirely failed A, and clients automatically > reverting to B, perhaps adding some latencies but also allowing the > system to automatically detect that A and B are performing at an > unacceptable delta. formal verification
Re: Anycast but for egress
we, verio, did anycast tcp streaming (hour long) of the tony awards in about '96. solid. randy --- ra...@psg.com `gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com` signatures are back, thanks to dmarc header butchery
russian prefixes
https://www.businessinsider.com/russia-cuts-self-off-from-global-internet-tests-defenses-rbc-2021-7 says "Russia disconnected itself from the rest of the internet, a test of its new defense from cyber warfare, report says" did this show up in bgp? e.g. rv/ris? randy
Re: russian prefixes
> Looks like it did shown on news only. :) i wondered
Re: Abuse Contact Handling
> One thing I've been thinking for long time is to consider policy > proposals to enforce the usage of the abuse mailbox together with > X-ARF/RFC5965/RFC6650. That will automate probably a so big % of abuse > handling that makes sense even if you need to make some programming, > even if there are already today open source tools for that. i try to minimize telling other operators how to run their networks, and hope they treat me similarly. educate, facilitate, don't legislate. why is it that many ops feel the need to wrap/defend abuse reporting mechanisms? my guess, and it is just a guess, is volume, and the volume of false positives, automated over-reaction (you pinged my server!!!), or trivial whining. my experience is that, once i got past the spam/whining defenses, ops are quite cooperative. perhaps my trying to be polite helps. i do not assume i know how to run your network better than you do. perhaps if we figured out how to stop DoSsing abuse systems, they would evolve back to being easier to use. though it is hard to wind back defenses. so it goes. randy --- ra...@psg.com `gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com` signatures are back, thanks to dmarc header butchery
happy birthday, jon
Re: Where to get IPv4 block these day
>> It was intended to be an IPv4 replacement to provide connectivity.
>> Do majority of smart handsets OS today support v6?
> Actually, yes. Many mobile networks are all v6 internally with NAT to
> external v4 sites.
what i love most about the why ipv6 {has not deployed | does not work
for me | must be used immediately if not sooner | ...} is that it
provides such a rich field for posting to nanog etc. and folk think of
new brilliant discussion points every day.
randy
---
ra...@psg.com
`gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com`
signatures are back, thanks to dmarc header butchery
Re: happy birthday, jon
> He'd be 78 today. yes, being a year senior, he used to give me a hard time about his being older and wiser. i think it was just his way of pulling rank :) > Still miss him, he was a great mentor and human being. indeed. still at usc; cool! patience and perseverance. randy
Re: Fort 1.5.1 Released..
have you looked at the validation log report at the warning and error levels? not pretty. not a very pleasing picture of the state of the RPKI repos out there. randy --- ra...@psg.com `gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com` signatures are back, thanks to dmarc header butchery
Re: "Tactical" /24 announcements
hi jakob,
i am confused between
> There is no expansion to prefix-set.
and your earlier
>> We have introduced the scalable as-set into the XR route policy language.
>> as-path-set does not scale well with 1000's of ASNs.
>> Now, you don't need to expand AS-SET into prefix-set, just enter it directly.
expanding AS-SET into prefix filters is exactly what we do.
```
% peval -s RIPE AS-RG-SEA
({198.180.153.0/24, 198.180.151.0/24, 147.28.8.0/24, 147.28.9.0/24,
147.28.10.0/24, 147.28.11.0/24, 147.28.12.0/24, 147.28.13.0/24, 147.28.14.0/24,
147.28.15.0/24, 147.28.4.0/24, 147.28.5.0/24, 147.28.6.0/24, 147.28.7.0/24,
147.28.2.0/24, 147.28.3.0/24, 147.28.0.0/23, 45.132.188.0/24, 45.132.189.0/24,
45.132.190.0/24, 45.132.191.0/24})
```
i do not see how to get around this. clue bat please
randy
Re: "Tactical" /24 announcements
> Somewhat related, when JNPR implemented RTR the architecture was > planned so that the RTR implementation itself isn't tightly coupled to > RPKI validity. It was planned day1 that customers could have multiple > RTR setups feeding prefixes and the NOS side could use these for other > purposes too. back in the day, the developing RP-rtr spec assumed multiple sources, RPKI, IRR, ... there was also an open-ended operator defined Color 0 8 16 2431 .---. | Protocol | PDU| | | Version | Type |Color| |0 |4 | | +---+ | | | Length=20 | | | +---+ | | Prefix | Max| Data| | Flags | Length | Length | Source | | | 0..32 | 0..32 | RPKI/IRR | +---+ | | |IPv4 prefix| | | +---+ | | | Autonomous System Number | | | `---' until, at ietf maastricht (2010), the unfortunate actions of a bully who wanted more and more caused us to walk away, give up, and fall back to the simpler basic we have today. 0 8 16 2431 .---. | Protocol | PDU| | | Version | Type |reserved = zero | |0 |4 | | +---+ | | | Length=20 | | | +---+ | | Prefix | Max| | | Flags | Length | Length | zero | | | 0..32 | 0..32 | | +---+ | | |IPv4 Prefix| | | +---+ | | | Autonomous System Number | | | `---' randy
Re: "Tactical" /24 announcements
for junos, i build the prefix list externally and push config. sad to
say, the code is so old ('90s) that it's pearl and uses `peval`. i
should fix but (copious spare time) == 0.
originally i tried to also build and push for cisco ios classic, but it
died in the push. breathe on the router and it reset bgp sessions. i
gather from heas that things are better these years.
i guess i really should have a go at doing it for arcos, but ...
> It's all open source, available at
> https://github.com/wolcomm/eos-prefix-list-agent
very cool.
randy
Re: PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]
> Currently RPKI can only validate origin, not paths. not exactly you ar speaking of route origin validation RPKI The RPKI is an X.509 based hierarchy [RFC 6481] which is congruent with the internet IP address allocation administration, the IANA, RIRs, ISPs, ... It is just a database, but is the substrate on which the next two mechanisms are based. It is currently deployed in all five administrative regions. RPKI-based Origin Validation (ROV) RPKI-based Origin Validation [RFC 6811] uses some of the RPKI data to allow a router to verify that the autonomous system originating an IP address prefix is in fact authorized to do so. This is not crypto checked so can be violated. But it should prevent the vast majority of accidental 'hijackings' on the internet today, e.g. the famous Pakistani accidental announcement of YouTube's address space. RPKI-based origin validation is in shipping code from AlcaLu, Cisco, Juniper, and possibly others. BGPsec RPKI-based Path Validation, AKA BGPsec, a future technology still being designed [draft-ietf-sidr-bgpsec-overview], uses the full crypto information of the RPKI to make up for the embarrassing mistake that, like much of the internet BGP was designed with no thought to securing the BGP protocol itself from being gamed/violated. It allows a receiver of a BGP announcement to cryptographically validate that the autonomous systems through which the announcement passed were indeed those which the sender/forwarder at each hop intended. Sorry to drone on, but these three really need to be differentiated.
Re: PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]
> The difference is, if you are able to use PeeringDB as a single > source of truth, it is a lot easier to grab the data you need. < pushing the analogy to the absurd > great idea! please tell me when i can use peeringdb as the single source of truth for my bank balance? how about i can learn your bank balance? < / > peeringdb has a mission, public exchange point documentation. please don't get creepy. randy
netflow in the core used for surveillance
https://www.vice.com/en/article/jg84yy/data-brokers-netflow-data-team-cymru used to get dissidents, activists, and journos killed at&t, comcast, ... zayo, please tell us you do not do this. randy
Re: An update on the AfriNIC situation
lotta words. i put my money where my mouth was days ago. you should too. randy
breakout
i am not a fiber/sfp/... geek, so clue bat please on my left, i have a delta 9020SL running arcos, female 40g qsfp on my right, i have incoming 10g 1310nm single mode from the seattle internet exchange. it is currently into a redstone 10g sfp NAMEVALUE - SwPort 1 Status PRESENT Valid True Vendor FiberStore Model SFP-10GLR-31 Serial-Number G1804021292 TypeSFP Module-Type 10G_BASE_SX Media-Type FIBER Module-Capability F_10G Length 255 Length-Description which i am swapping out for the delta 9020 so i am look at something such as https://www.fs.com/products/30900.html except i do not understand active/passive, AOC1M, etc thanks in advance randy
Re: breakout
> I believe that these (and the AOC option) require that the switch > understand / supports splitting the 40G interface into 4x10s arcos does what i expect, sub units as i have no problem wasting ports on the delta box (there are 48 and i only need two :) i think ben's https://www.fs.com/products/72582.html looks to be the simplest solution. thank you all! randy
Re: breakout
> However, if you just need to use 10g of the 40g port, you can do it > much cheaper and easier with just this part: > > https://www.fs.com/products/72582.html we will test to be sure this appears as one port of a breakout randy
Re: Jenkins amplification
>>> good golly, so glad everyone's enterprise is a hard candy version of same. >>> no need for these remote workers, or discontiguous offices, or >>> 'internet centric workforces'. >> >> VPN. > > I love it when my home network gets full access to the corporate network! make things simpler and L2 tunnel so it's the same LAN.
Re: Has Anyone managed to get Delegated RPKI working with ARIN
> I recently figured it out and posted it on the NLNetLabs RPKI mailing list. > https://lists.nlnetlabs.nl/pipermail/rpki/2020-February/000124.html nice. thank you. randy
large path attr
Feb 7 05:30:12 rpd[1752]: Prefix Send failed ! 103.148.40.0/24 bgp_rt_trace_too_big_message:1209 path attribute too big. Cannot build update. anyone else seen this one? another kiddie? randy
Re: large path attr
responding to private email > Yes, something was up, as seen at the AS22211 openbgpd logger "flight > recorder". I only looked near the time stamp you had. > > # mrt2bgpdump /pool0/var/log/bgpd/all-in-2020-02-07-05-26 |grep 103.148.40 > BGP4MP|02/07/20 05:30:15|A|66.79.132.1|22211|103.148.40.0/24|12182 174 > 132602 10075 134371 140076 140076 140076 140076 140076 140076 140076 140076 > 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 > 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 > ... > 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 > 140076 140076 140076 140076 140076|IGP > > BGP4MP|02/07/20 05:30:42|A|66.79.132.1|22211|103.148.40.0/24|12182 2914 174 > 132602 10075 134371 140076 140076 140076 140076 140076 140076 140076 140076 > 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 > ... and so on as140076 is Mir Internet Service in Dhaka microtik prepend gl!tch? randy
Re: large path attr
> I feel like I saw this once with large communities, but memory is a > bit fuzzy. yes, with this large an ops community, the clue distribution will likely be long tailed :)
Ubiquiti EdgeRouter Infinity and IS-IS
am i correct that the only option to drop a ubiquiti infinity into an IS-IS LAN and have RPKI-based ROV too is FRR? if so, would someone who has been to the movie care to share some clue off-list? thanks. randy
Re: Hi-Rise Building Fiber Suggestions
> We use plenty of multi-mode, but only in the data centre, between our > own kit, for racks within the same cage. so you have to stock both single and multi? hmmm randy
