> We are in the process of creating an RPKI ROA for our prefixes Thanks for taking the extra steps to create a RPKI ROA to reduce the impact of BGP routing attacks on your prefixes. Extra points for doing RPKI-based Route Origin Validation on your BGP routers.
I hope to convince everyone with such a high concentration of tor network capacity to make use of tor's OfflineMasterKey mode to safeguard your relay identity keys even in the event of a system compromise. Which basically implies automation because no one wants to handle (renew) more than 3 keys manually. I'm also encouraging you to use separate IP addresses for exit traffic [1] because that helps eliminate the impact on relay-to-relay communication when ISPs are ordered to BGP blackhole some exit IP addresses (as we have seen recently in the news). > 40 new uncapped and unfiltered exit relays I would suggest to not run uncapped tor instances but to set a per-instance limit of around 80-90% what a single core is able to handle, to avoid poor performance for the user. With growing bandwidth the CPU will spend considerable amount of resources just handling packets (kernel). > This work is part of our efforts to saturate our new unmetered 10Gbps > transit link As teor usually says, saturated links is not what we should be aiming for if we like performance. Thanks for adding such a significant amount of exit capacity. [1] https://2019.www.torproject.org/docs/tor-manual.html.en#OutboundBindAddressExit -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-relays mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
