Re: ARIN RPA updated (again) to address TAL distribution (Re: ARIN RPKI services terms/conditions - Change to Management of the Trust Anchor Locator for ARINʼs RPKI Service)
On Thu, Sep 29, 2022 at 03:30:55PM -0700, Randy Bush wrote:
> >> may i include the arin tal in my software product with neither i nor
> >> the user of the product being encumbered, signing anything, ... as
> >> with the other RIRs?
> > Yes.
>
> excellent. thank you.
>
> [ and arin might ask itself why and how it took O(decade) to come to
> this simple position; just in case there are other mis-matches between
> arin's positions and community needs ]
>
Randy, did you sign the RPA?
I did not sign the RPA.
Am I allowed to use rpki software like this?
And am I in any way restricted in the use of the produced work below
from this RP software?
> rpki-client -t /etc/rpki/arin.tal -d /tmp/a /tmp
rpki-client: https://rpki.sailx.co/rrdp/notification.xml: TLS handshake:
certificate verification failed: certificate has expired
rpki-client: https://rpki.sailx.co/rrdp/notification.xml: load from network
failed, fallback to rsync
rpki-client:
rpki-rps.arin.net/repository/8a848adf8143bf6201823bd454752be6/0/267181B0A5DD38D60BCC22881342C64FFC8CBC1F.mft:
no valid mft available
rpki-client:
rpki-rps.arin.net/repository/8a848ade7fb71aa9017fdd9c5dd324c7/0/EB1DD8AA3E2B6864E06379C751DBFFFCC6418350.mft:
no valid mft available
rpki-client:
rpki-rps.arin.net/repository/8a848ade7fb71aa90183287f4402/0/2BF7605B8927C87448B3B294A8B61D8E983248E0.mft:
no valid mft available
rpki-client:
rpki-rps.arin.net/repository/8a848adf7fb722e9017ffead9f534ac5/0/BFA2750976CA07F56A68976B0F01EB862F17C3B3.mft:
no valid mft available
openrsync: warning: connect timeout: 208.82.103.214, rpki.sailx.co
openrsync: error: cannot connect to host: rpki.sailx.co
rpki-client: rsync rsync://rpki.sailx.co/repo failed
rpki-client: .rsync/rpki.sailx.co/repo: load from network failed, fallback to
cache
rpki-client:
rpki.sailx.co/repo/Sail-Internet-Inc/0/DFC5509768EA587E638D20680032E0FF122BD25A.mft:
no valid mft available
Processing time 202 seconds (54 seconds user, 30 seconds system)
Skiplist entries: 0
Route Origin Authorizations: 56644 (0 failed parse, 0 invalid)
AS Provider Attestations: 0 (0 failed parse, 0 invalid)
BGPsec Router Certificates: 0
Certificates: 2878 (0 invalid)
Trust Anchor Locators: 1 (0 invalid)
Manifests: 2878 (5 failed parse, 0 stale)
Certificate revocation lists: 2873
Ghostbuster records: 0
Repositories: 16
Cleanup: removed 0 files, 2900 directories, 580 superfluous
VRP Entries: 81311 (75592 unique)
VAP Entries: 0 (0 unique)
# Processing time 202 seconds (54s user, 30s system)
# Route Origin Authorizations: 56644 (0 failed parse, 0 invalid)
# BGPsec Router Certificates: 0
# Certificates: 2878 (0 invalid)
# Trust Anchor Locators: 1 (0 invalid) [ /etc/rpki/arin.tal ]
# Manifests: 2878 (5 failed parse, 0 stale)
# Certificate revocation lists: 2873
# Ghostbuster records: 0
# Repositories: 16
# VRP Entries: 81311 (75592 unique)
roa-set {
3.0.0.0/15 source-as 16509 expires 1664683200
3.0.0.0/15 source-as 38895 expires 1664683200
3.0.0.0/10 maxlen 24 source-as 8987 expires 1664683200
3.0.0.0/10 maxlen 24 source-as 14618 expires 1664683200
3.0.0.0/10 maxlen 24 source-as 16509 expires 1664683200
3.2.1.0/24 source-as 16509 expires 1664683200
3.3.5.0/24 source-as 7224 expires 1664683200
3.4.1.0/24 source-as 7224 expires 1664683200
3.4.2.0/24 source-as 7224 expires 1664683200
3.4.4.0/24 source-as 7224 expires 1664683200
3.33.48.0/20 maxlen 24 source-as 7224 expires 1664683200
3.64.0.0/10 maxlen 24 source-as 8987 expires 1664683200
3.64.0.0/10 maxlen 24 source-as 14618 expires 1664683200
3.64.0.0/10 maxlen 24 source-as 16509 expires 1664683200
3.112.0.0/14 source-as 16509 expires 1664683200
3.128.0.0/10 maxlen 24 source-as 8987 expires 1664683200
3.128.0.0/10 maxlen 24 source-as 14618 expires 1664683200
3.128.0.0/10 maxlen 24 source-as 16509 expires 1664683200
3.192.0.0/10 maxlen 24 source-as 8987 expires 1664683200
3.192.0.0/10 maxlen 24 source-as 14618 expires 1664683200
3.192.0.0/10 maxlen 24 source-as 16509 expires 1664683200
4.128.0.0/12 source-as 8075 expires 1664769600
4.144.0.0/12 source-as 8075 expires 1664769600
4.160.0.0/12 source-as 8075 expires 1664769600
4.176.0.0/12 source-as 8075 expires 1664769600
4.192.0.0/12 source-as 8075 expires 1664769600
4.208.0.0/12 source-as 8075 expires 1664769600
4.224.0.0/12 source-as 8075 expires 1664769600
4.240.0.0/12 source-as 8075 expires 1664769600
8.2.120.0/24 source-as 20473 expires 1664683200
8.2.121.0/24 source-as 20473 expires 1664683200
8.2.122.0/24 source-as 20473 expires 1664683200
8.3.29.0/24 source-as 20473 expires 1664683200
8.6.8.0/24 source-as 20473 expires 1664683200
8.6.193.0/24 source-as 20473 expires 1664683200
8.7.233.0/24 source-as 20473 expires 1664683200
8.8.4.0/2
Re: [EXTERNAL] Re: Yet another BGP hijacking towards AS16509
On Tue, Aug 23, 2022 at 08:07:29PM +0200, Job Snijders via NANOG wrote: > On Tue, Aug 23, 2022 at 05:18:42PM +, Compton, Rich A wrote: > > I was under the impression that ASPA could prevent route leaks as well > > as path spoofing. This "BGP Route Security Cycling to the Future!" > > presentation from NANOG seems to indicate this is the case: > > https://youtu.be/0Fi2ghCnXi0?t=1093 > > I'm not sure how ASPA can prevent AS Path spoofing. Perhaps something > got lost in translation? > > ASPA records are published in the RPKI, from there a RPKI RP transforms > the ASN.1/X.509/crypto stuff into something 'plain text'. This 'plain > text' data is loaded into EBGP routers via RTR, which then compare the > *plain text* AS_PATH attribute to the table of plain-text ASPA records, > to determine if it came via an authorized upstream provider or not. > > In this sense, ASPA (just by itself) suffers the same challenge as RPKI > ROA-based Origin Validation: the input (the BGP AS_PATH) is unsigned and > unsecured; thus spoofable. ASPA enforces that the neighbor AS appears as first element in the ASPATH. It also disallows empty ASPATHs from eBGP sessions. Because of this spoofing becomes harder. The problem is that this only works for paths that are validated by ASPA (all AS hops have been verified). An ASPA-unknown path can still be spoofed. Spoofing will become much harder once a critical mass of infrastructure deployed ASPA. -- :wq Claudio
Re: Towards an RPKI-rich Internet (and the appropriate allocation of responsibility in the event an RIR RPKI CA outage)
On Mon, Oct 01, 2018 at 09:47:43AM +0200, Alex Band wrote: > Hello, > > To avoid any misunderstanding in this discussion going forward, I would > like to reiterate that an RPKI ROA is a positive attestation. An > unavailable, expired or invalid ROA will result in a BGP announcement > with the status NotFound. The announcement will *not* become INVALID, > thereby being dropped. > > Please read Section 5 of RFC 7115 that John linked carefully: > > Bush Best Current Practice [Page 7] > > RFC 7115 RPKI-Based Origin Validation OpJanuary 2014 > > > Announcements with NotFound origins should be preferred over those > with Invalid origins. > > Announcements with Invalid origins SHOULD NOT be used, but may be > used to meet special operational needs. In such circumstances, the > announcement should have a lower preference than that given to Valid > or NotFound. > > Thus, a continued outage of an RPKI CA (or publication server) will > result in announcements with status NotFound. This means that the > prefixes held by this CA will no longer benefit from protection by the > RPKI. However, since only *invalid* announcements should be dropped, > this should not lead to large scale outages in routing. > > It is important to be aware of the impact of such an outage when > considering questions of liability. This depends if the prefix in question is covered by another ROA. Because in that case it is well possible that the prefix is marked INVALID. This is especially an issue if a partial failure of a publication server is taking out the more specifics but leaves a large covering ROA (maybe even one with origin AS 0). In the end from a security standpoint it is probably better to fail closed because the alternative is no RPKI and then hijacks become possible and MITM attacks or DNS spoofing can be done leaving every Internet user at risk. Also consider that not using best common practice to protect a service is also putting you at risk for liability charges. So ignoring RPKI because of possible liability concerns may as fire back at you. -- :wq Claudio
Re: ARIN RPKI TAL deployment issues
On Wed, Sep 26, 2018 at 03:29:33AM -0400, Jared Mauch wrote: > > > > On Sep 26, 2018, at 3:13 AM, John Curran wrote: > > > > On 26 Sep 2018, at 2:09 AM, Christopher Morrow > > wrote: > >> > >> (I'm going to regret posting this later, but...) > >> > >> On Tue, Sep 25, 2018 at 10:57 PM John Curran wrote: > >> > >> The significant difference for ARIN is that we operate under a different > >> legal regime, and as a matter of US law, it appears that we cannot rely > >> only upon terms and conditions published in our website as evidence of > >> informed agreement; i.e. within the US legal framework, we need a specific > >> act of acceptance in order to have a binding agreement. > >> > >> how is arin's problem here different from that which 'lets encrypt' is > >> facing with their Cert things? > > > > Chris - > > > > The “Let’s encrypt” subscriber agreement (current version 1.2, 15 Nov 2018) > > includes "indemnify and hold harmless” clause, and parties affirmatively > > agree to those terms by requesting that ISRG issue a "Let’s Encrypt” > > Certificate to you. > > > > (I don’t know whether that process is particularly more or less onerous > > technically than the effort to download the ARIN TAL.) > > The process for lets encrypt is fairly straightforward, it collects some > minimal information (eg: e-mail address, domain name) and then does all the > voodoo necessary. If ARIN were to make this request of the developers of > RPKI software, it would seem reasonable to have that passed to ARIN via some > API saying “b...@example.com” typed “Agree” to the ARIN TAL as part of the > initial installation of the software. > > For me, this is about the friction involved in making it work and while the > click-through page may not seem like a barrier, there are active measurements > that demonstrate it is. It may take time to communicate to the existing set > of operators running RPKI validators they are missing the ARIN TAL, but I > would like to ensure that new deployments don’t make this same mistake. > > I think this thread/communication is part of that. “Don’t forget about the > extra step for ARIN”. It’s also “ARIN, please help make it easier to use > your service”. > > With Google Maps, etc.. I may have to create an API key, it comes in > multi-lingual systems in non-roman alphabet support, etc. Being part of this > global ecosystem and running an RIR comes with some extra effort compared to > running a corner mom & pop shop. Our actions and decisions have global > consequences to the safety and security of how your and my traffic is routed. > > Please work with the developers for a suitable method to include the ARIN TAL > by default. Come up with the click-accept legalese necessary. > > Since you asked, here’s what they did with the CertBot that’s commonly used > by Lets Encrypt: > > > (The first time you run the command, it will make an account, and ask for > an email and agreement to the Let’s Encrypt Subscriber Agreement; you can > automate those with --email and --agree-tos) > > If you want to use a webserver that doesn’t have full plugin support yet, > you can still use “standalone” or “webroot” plugins to obtain a certificate: > > ./certbot-auto certonly --standalone --email ad...@example.com -d > example.com -d www.example.com -d other.example.net > > If you/ARIN could work closer with the developers of RPKI software to help > make this happen that would be great. If you need introductions, I’m happy > to help make them. > This is the wrong side of the system. If you want to compare the ARIN TAL to anything related to letsencrypt then it is the TLS root certificates which are shipped by all OS and browsers. This discussion is not about the process to get a cerificate (or ROA entry signed) this is about shipping the trust anchor, which makes the system actually work. As an opensource developer what I need is to be able to ship the public key together with my software so that the verification works out of the box. Without the public key (TAL) none of the ARIN ROA entries can be validated. I do not understand why a public key is under a click-accept license. If fear of indemnification is an issue then how is it possible that so many US public keys are shipped with the TLS/SSL root certificates without any issue? ARIN can still use the same license for customers wanting to add entries to the ARIN RPKI database. It is just about the fact that a 3rd party that has nothing todo with ARIN needs to accept their licence to be able to verify that the ARIN signed ROA entry is acctually valid. No other validation system (DNSSEC, TLS/SSL) is doing that. It is actually in the interest of ARIN and all ARIN members that the TAL is as widely distributed as possible since only then adding a ROA actually gives you the intended benefit. -- :wq Claudio
Re: 32-bit ASes at routeviews
On Sun, Dec 16, 2012 at 11:48:13PM +0100, Iljitsch van Beijnum wrote: > Looking for 32-bit AS numbers, I get some strange results from routeviews: > > route-views>sh ip bgp regexp _23456_ > BGP table version is 2393809200, local router ID is 128.223.51.103 > Status codes: s suppressed, d damped, h history, * valid, > best, i - > internal, > r RIB-failure, S Stale > Origin codes: i - IGP, e - EGP, ? - incomplete > >Network Next HopMetric LocPrf Weight Path > * 31.177.16.0/22 128.223.253.10 0 3582 3701 3356 > 23456 3.1043 i > * 46.29.72.0/21129.250.0.11 285 0 2914 12389 12389 > 12389 12389 23456 3.627 i > * 46.243.96.0/21 154.11.11.1130 0 852 174 39704 > 39704 23456 3.787 i > * 91.208.62.0/24 154.11.11.1130 0 852 174 39704 > 39704 23456 3.787 i > * 91.217.87.0/24 194.85.40.15 0 3267 174 23456 > 3.661 i > * 91.230.169.0/24 208.51.134.254 13905 0 3549 29152 29152 > 29152 29152 23456 23456 23456 23456 3.1426 i > * 91.238.8.0/24194.85.40.15 0 3267 8220 23456 > 3.2040 i > * 111.235.148.0/22 194.85.40.15 0 3267 9498 9730 > 23456 i > * 141.0.176.0/21 129.250.0.11 285 0 2914 12389 12389 > 12389 12389 23456 3.627 i > > Unless I missed something, AS 23456 is supposed to show up as a stand-in for > 32-bit ASNs on 16-bit BGP implementations, not in _addition_ to 32-bit ASNs. > So the penultimate line would make sense if the other lines weren't there and > the others don't make sense period. > > Maybe a bug in the IOS they're running? > > route-views>sh ver > Cisco IOS Software, 7200 Software (C7200P-ADVENTERPRISEK9-M), Version > 12.4(24)T2, RELEASE SOFTWARE (fc2) > > Or is something else going on? This can happen when a old 2-byte only routers are doing prepends with the neighbor address (4-byte). Then the magic in the 4-byte AS RFC to fix up ASPATH has no chance to work and you will see 23456. -- :wq Claudio
Re: carping about CARP
On Fri, Nov 30, 2012 at 08:48:48AM -0800, David Conrad wrote: > On Nov 30, 2012, at 5:08 AM, Henning Brauer wrote: > > and re IANA, they made it clear they would not give us a proto number > > As they should have. IANA abides by the rules laid down for it by the > IETF/IESG/IAB. The openbsd folks couldn't be bothered to even write up a > draft and chose to squat on a protocol number. > > > no matter what; > > BS. If the openbsd folks followed the rules, they'd have gotten the > number(s) they requested (assuming they were justified). There is no > grand persecution here. There is management of a limited resource. > IETF already decided that VRRP was the way to go. So an alternative implementation would not have been accepted. The result would be a draft that would never be adopted and so it is back to start. Still carp packets can coexist with vrrp packets. They use a different version numbers. Also you need to use a different vhid but the same thing is true if you have 2 groups of vrrp on the same lan. If you configure something like VRRP you should run a quick tcpdump first and check if there are not unexpected packets showing up. This is especially important for any protocol that does a link local multicast or broadcast. This is basic network admin best practice (at least I expect that from a network engineer). > > we didn't have a choice but to ignore that industry-money-driven committee. > > Which 'industry-money-driven committee' would that be? Did you ever read any of the IETF mailing lists and looked at the email addresses of those people pushing the hardest? At least in the ones I'm subscribed to the bias is obvious. -- :wq Claudio
Re: IPv4 sunset date set for 2019-12-31
On Thu, Oct 21, 2010 at 10:59:38AM -0700, Majdi S. Abbas wrote: > On Thu, Oct 21, 2010 at 10:52:19AM -0700, Dave CROCKER wrote: > > But you aren't. No one is. > > > > The core requirement for such announcements is that there be a real > > enforcement arm. > > If a couple of large carriers set their own flag dates, and > turn off v4 at that point, it will be effectively enforced. Plenty > of people aren't particularly 'local' pockets of control. They would be out of business the day they turn IPv4 off. So it will not happen. > You don't need an enforcement arm -- it just needs to stop > making economic sense to support two parallel networks. Since it's > automatically wasteful, once enough of the traffic is v6, that may > come sooner than you realize. I doubt it. > Or, just start charging an arm and a leg for v4 transit until > people take the hint... and change the ISP. Before you can even start to think about moving away from v4 you need to ensure that everybody is reachable via v6. The problem is that the key organizations try everything to make this not happen. -- :wq Claudio
Re: Did your BGP crash today?
On Sun, Aug 29, 2010 at 10:12:35PM +0200, Thomas Mangin wrote: > > It would seem to me that there should actually be a better option, e.g. > > recognizing the malformed update, and simply discarding it (and sending the > > originator an error message) instead of resetting the session. > > > > Resetting of BGP sessions should only be done in the most dire of > > circumstances, to avoid a widespread instability incident. > > > I had the same thought before giving up on it. > > Negotiating a new error message could be a per peer option. BGP has > capabilities for this exact reason. > > However to make sense you would need to find a resynchronisation point > to only exclude the one faulty message. Initially I thought that the > last received KEEPALIVE (for the receiver of the error message) could do > - but you find yourselves with races conditions - so perhaps two > KEEPALIVE back ? Apart from one big vendor most BGP speaker only send KEEPALIVES when they need to. So on my full feeds I see sessions running for more then 1 month which received less then 300 KEEPALIVE packets. -- :wq Claudio
Re: Did your BGP crash today?
On Sat, Aug 28, 2010 at 02:51:17PM +0200, Thomas Mangin wrote: > We had ASN4, AS-PATH and this one. More or less we hit this session > reset problem once a year but nothing was done yet to change the RFC. You are mixing up three totaly different problems. Sure the result was the same (session drops). This time a IOS XR device was corrupting an attribute before sending it out. The corruption had to be in the header section of the attribute or the other side would not have detected it (since the neighbor did not know about this attribute either). Now if a system sends out corrupted BGP messages there is no way out, you need to close the session because not doing so may result in much bigger mayhem. It was not mentioned what the corruption was actually, was the lenght wrong or was the optional flag missing (makeing the attribute well known)? Unlike in the ASN4 issue this time the session to the faulty system was dropped and by doing so stopped further issues. > So I am to blame as much as every network engineer to not have pushed > for a change or at least a comprehensive explanation on the session > teardown behaviour is like it is and should not be changed. > > It is only our fault for not having dealt with the problem the first > time correctly, and will be next time if nothing is changed once more. > > I agree correctly framed invalid packet should be discarded without > tearing the session down. Great, corrupting your RIB and FIB and every of your peers RIB. Thanks a lot for routing loops and wrong announcements. The only thing you can drop without causing troubles are (tranistive) optional attributes. This is covered by draft-ietf-idr-optional-transitive and hopefully it will be adopted as RFC and implemented by vendors. If a well known attribute like AS-PATH is corrupted then there is no choice, the session needs to be reset. Which is bad when the AS-PATH validation code has a bug. -- :wq Claudio
Re: Did your BGP crash today?
On Sat, Aug 28, 2010 at 01:09:47PM +0200, Leen Besselink wrote: > On 08/28/2010 11:39 AM, Saku Ytti wrote: > > On (2010-08-28 18:20 +0900), Randy Bush wrote: > > > > > >> a bgp regression suite would not have caught this as it was not a > >> repeat. but it sure would be useful to implementors. > >> > > Naturally 'proving' that non-trivial software works is practically > > impossible. But stating what non-existing test-suite would or would not > > have covered is not a topic I'm particularly interested to engage. > > > > > > > I suggest the test-tool has 2 bgp-sessions and tests if what it put in > did or did not come out on the otherside and in what shape or form. > > There are already atleast 2 projects which have BGP-code which could > probably be adapted: > http://code.google.com/p/exabgp/ > http://code.google.com/p/bgpsimple/ > > Can I suggest a fuzzer as wel ? > > There was once cert-bgp-testcases-28may03-final.tar.gz which did some testing (including expected responses). I use it from time to time. >From the README: For more information see the NANOG 28 (http://www.nanog.org) presentation ... "BGP Vulnerability Testing: Separating Fact from FUD" by Sean Convery (s...@cisco.com) and Matthew Franz (mfr...@cisco.com) But my quick googeling failed to locate a link to it. -- :wq Claudio
Re: Did your BGP crash today?
On Sat, Aug 28, 2010 at 04:56:05PM +0900, Randy Bush wrote: > imiho, researchers injecting data into the control plane are responsible > to have tested it at least against major bgp speakers. and, considering > its placement in the net (big core), i consider ios xr to be a major > speaker. > > i suspect that these folk will test better next time. i sure hope so. > I think you blame the wrong people. The vendor should make sure that their implementation does not violate the very basics of the BGP protocol. This bug in the IOS XR BGP implementation was a ticking time bomb and it was just a matter of when it would blow up. I suspect that Cisco will test better next time when they release a new version of their software. I sure hope so. -- :wq Claudio
Re: Did your BGP crash today?
On Fri, Aug 27, 2010 at 04:57:17PM -0400, valdis.kletni...@vt.edu wrote: > On Fri, 27 Aug 2010 13:43:39 PDT, Clay Fiske said: > > > If -everyone- dropped the session on a bad attribute, it likely wouldn't > > make it far enough into the wild to cause these problems in the first > > place. > > That works fine for malformed attributes. It blows chunks for legally formed > but unknown attributes - how would you ever deploy a new attribute? > This is covered by the RFC. Unknown attributes are either dropped or passed on depending on the attribute flags. The problem as in AS4 was that there where illegally formed unknown attributes that got passed around and made RFC compliant routers, which already handled AS4, further down the chain fail. This problem was addressed in "Error Handling for Optional Transitive BGP Attributes" but for some reasons people think it is necessary to make something simple more and more complex so this draft is still pending. -- :wq Claudio
Re: Mikrotik RouterOS
On Fri, Apr 23, 2010 at 09:26:10AM +0200, Thomas Habets wrote: > On Wed, 21 Apr 2010, Chris Cappuccio wrote: > >OpenBSD post-4.7 (current) is about to get a full BGP MPLS VPN > >implementation and has ldp working too. Yeah baby > > I wouldn't run MPLS with OpenBSD in production quite yet though. > Until I sent in a patch earlier this month it sent out implicit null > (label 3) over the wire, for example. > Yes, there are still issues, any help sending in bug reports or diffs is welcome. The plan is to have a good MPLS stack in the next release. Still lot to do... > There are other bugs still there, but CVS doesn't exactly invite > outside help. Hint hint, BSD folks. > Common, cvs checkout, modify file, test and when happy cvs diff | mail -s "mpls diff for this and that" t...@openbsd.org isn't too hard. There is a good reason we only have one tree instead of a jungle of unfinished and halfway done stuff. There is no need to figure out which branch or developer flavor you want to test today. Makes testing a hell of a lot simpler. -- :wq Claudio
