44net July 2020

44net@mailman.ampr.org

20 participants
8 discussions

GL.iNet openWRT Rip44 support?
by Tracy Markham 30 Dec '20

30 Dec '20

I had reached out to the good people at GL.iNet and asked for help getting one of their openWRT routers to run my 44 net assignment. I referred them to the page explaining openWRT setup ( wiki.ampr.org/wiki/Setting_up_a_gateway_on_OpenWRT) and requested they compile an executable for the processor in the router. Apparently they did it. It will be a bit before I can try to configure it but its a one click installation. It's available to anyone with a GL.iNet router product, just navigate to Applications -> Plugins and Update, then navigate to the R section. I have a screencap of all the dependencies it installed if anyone is interested. I reached out to them because I've failed on my previous attempts to set up an EdgerouterX for my assignment... I am by no means a network engineer, this is my foray into getting a gateway going. If anyone could confirm this works that would be great. If you're willing to help me get mine going that would be even better. Tracy N4LGH

7 10

AMPRNet VPN TLS Error
by Chris Brougham 25 Jul '20

25 Jul '20

Hi List, I'm trying to setup the VPN using my LotW cert and followed the instructions on the Wiki for Windows. There was a security issue at first but I added the tls-cipher "DEFAULT:@SECLEVEL=0" line in the .ovpn file and made some progress until I got this: Wed Jul 22 20:14:59 2020 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Searching the archives here I've tried a few things such as editing the authorities file to show the last block only as was suggested by another list member. I also edited the authorities file to show the first block only, but to no avail. Now the user and authorities certs are concatenated as per the WIki instructions, so it's all stock. Any tips for further investigation? 73 Chris VE7YSF aka VA7CAB

2 2

Routing Help (linux/ubuntu)
by Ian Redden 22 Jul '20

22 Jul '20

Hi Everyone! I have a Ubuntu 20.04 LTS box installed with the following network configuration: *Internet/ISP* ens160: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 209.249.157.70 netmask 255.255.255.248 broadcast 209.249.157.71 inet6 fe80::250:56ff:feb7:eeb6 prefixlen 64 scopeid 0x20<link> ether 00:50:56:b7:ee:b6 txqueuelen 1000 (Ethernet) RX packets 7916 bytes 544678 (544.6 KB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 975 bytes 184556 (184.5 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 *HAM Network* ens192: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 44.135.100.10 netmask 255.255.255.248 broadcast 44.135.100.15 inet6 fe80::250:56ff:feb7:57ba prefixlen 64 scopeid 0x20<link> ether 00:50:56:b7:57:ba txqueuelen 1000 (Ethernet) RX packets 35 bytes 2558 (2.5 KB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 37 bytes 3152 (3.1 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 1000 (Local Loopback) RX packets 104 bytes 8024 (8.0 KB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 104 bytes 8024 (8.0 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 *AMPRNet IPIP* tunl0: flags=4289<UP,RUNNING,NOARP,MULTICAST> mtu 1480 inet 44.135.100.9 netmask 255.255.255.255 tunnel txqueuelen 1000 (IPIP Tunnel) RX packets 37 bytes 17484 (17.4 KB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 5 bytes 260 (260.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 Machines on my "ham" network (44.135.100.8/29 - interface ens192) can only communicate within the routes I receive via rip44. Is this normal? For example, from a machine on the ham network (ens192), I can connect to va3emt-1.ampr.org (44.135.87.1) but cannot ping 8.8.8.8 (google dns). A tcpdump shows its going out the wrong interface (ens160). Also, from my ISP, I can ping 44.135.87.1 (and retrieve the web page) but I cannot ping or access 44.135.100.9,10,11,etc .... Here are my commands I'm using to connect: ip tunnel add tunl0 mode ipip local 209.249.157.70 ttl 255 ip link set dev tunl0 up ifconfig tunl0 up 44.135.100.9 netmask 255.255.255.255 multicast ip rule add to 44.0.0.0/9 table 44 priority 44 ip rule add to 44.128.0.0/10 table 44 priority 44 ip rule add from 44.135.100.8/29 table 44 priority 45 ip route add default dev tunl0 via 169.228.34.84 onlink table 44 ip route add 44.135.100.8/29 dev ens192 table 44 /usr/sbin/ampr-ripd -s -r -t 44 -i tunl0 -a 44.135.100.8/29 -d -v Any ideas? Ian. Some debug: root@ampr-router:~# ip rule 0: from all lookup local 44: from all to 44.0.0.0/9 lookup 44 44: from all to 44.128.0.0/10 lookup 44 45: from 44.135.100.8/29 lookup 44 32766: from all lookup main 32767: from all lookup default root@ampr-router:~# ip route show default via 209.249.157.65 dev ens160 proto static 44.135.100.8/29 dev ens192 proto kernel scope link src 44.135.100.10 209.249.157.64/29 dev ens160 proto kernel scope link src 209.249.157.70 root@ampr-router:~# ip route show table 44 | more default via 169.228.34.84 dev tunl0 onlink 44.0.0.1 via 169.228.34.84 dev tunl0 proto 44 onlink window 840 44.2.0.1 via 191.183.136.1 dev tunl0 proto 44 onlink window 840 44.2.0.2 via 98.20.210.138 dev tunl0 proto 44 onlink window 840 44.2.0.3 via 36.83.94.245 dev tunl0 proto 44 onlink window 840 44.2.2.0/24 via 216.218.207.198 dev tunl0 proto 44 onlink window 840 44.2.7.0/30 via 73.116.117.178 dev tunl0 proto 44 onlink window 840 44.2.10.0/29 via 104.49.12.130 dev tunl0 proto 44 onlink window 840 44.2.11.8/29 via 47.33.29.119 dev tunl0 proto 44 onlink window 840 44.2.50.0/29 via 50.63.202.93 dev tunl0 proto 44 onlink window 840 44.4.0.48/28 via 107.3.166.19 dev tunl0 proto 44 onlink window 840 44.4.2.152/29 via 173.167.109.217 dev tunl0 proto 44 onlink window 840 ..... alot of routes here ..... 44.185.66.0/24 via 89.106.108.151 dev tunl0 proto 44 onlink window 840 44.185.69.0/24 via 80.80.140.38 dev tunl0 proto 44 onlink window 840 44.185.80.0/24 via 213.91.190.32 dev tunl0 proto 44 onlink window 840 44.185.92.0/24 via 213.91.190.32 dev tunl0 proto 44 onlink window 840 44.185.96.0/24 via 213.91.190.32 dev tunl0 proto 44 onlink window 840 44.185.103.0/24 via 89.190.200.249 dev tunl0 proto 44 onlink window 840 44.185.104.0/24 via 178.254.198.205 dev tunl0 proto 44 onlink window 840 44.185.105.0/24 via 91.139.210.119 dev tunl0 proto 44 onlink window 840 44.185.106.0/24 via 95.158.166.222 dev tunl0 proto 44 onlink window 840 44.185.107.0/24 via 77.70.122.201 dev tunl0 proto 44 onlink window 840 44.185.108.0/27 via 78.83.56.107 dev tunl0 proto 44 onlink window 840 44.185.109.0/24 via 91.92.93.15 dev tunl0 proto 44 onlink window 840 44.188.1.1 via 70.80.196.6 dev tunl0 proto 44 onlink window 840 44.188.192.222 via 176.67.24.190 dev tunl0 proto 44 onlink window 840 44.224.0.0/15 via 141.75.245.225 dev tunl0 proto 44 onlink window 840

2 2

Trying to reach N2NOV
by G1FEF 19 Jul '20

19 Jul '20

If anyone is able to contact Charles - N2NOV please could they advise him that emails to his @n2nov.net address is bouncing. Please ask him to get in touch with me: <n2nov(a)n2nov.net <mailto:n2nov@n2nov.net>>: host mx.spamexperts.com <http://mx.spamexperts.com/>[130.117.53.188] said: 550 Your country is not allowed to connect to this server. (in reply to RCPT TO command) Thanks, Chris - G1FEF

2 1

My view to 44net's future
by Clive Blackledge 14 Jul '20

14 Jul '20

cc: 44ngn Greetings 44net, KF6DMA checking in. Thank you for letting me join the group. I’ve been licensed since 1996 or so, but I’ve rarely spent time on the air talking. Instead, the internet seemed much more my speed at 2400 baud at the time. There seemed to be a rather insurmountable generational gap when I started, but that has become narrower as the years progressed. I now have my own health ailments I can talk about in detail. :) I’ve been into packet radio and played with radio meshes, but a majority of my time was spent on the internet. My assortment of jobs I’ve held since high school have all prepared me for the job I have today working as a systems engineer for a large company, and I love it. I bring this up, as I was reading the archives to see the challenges with AMPRnet and ARDC in general, and thought I’d throw in my 2c from an outsiders systems engineering view (although hopefully not an outsider for too long). >From the surface, it seems like AMPRnet needs a ‘one country, two systems’ approach. An external system that interfaces with the public internet and deals with the trends there (RPKI, Domain keys, firewalls, etc.) and another that the ham community prefers (open, encryption-free communication). The two are pretty much at odds with each other, especially now ‘ssl everywhere’ has become a thing on the internet. Bridging both systems becomes difficult, but not impossible. What I propose is getting the internet-side figured out first. Initially I would see what it would take to get a .ham TLD. With that, we can run our own DNS registry, free to anybody licensed. It could include DNSSEC, and possibly our own internal trust registry, maybe working with LOTW to expand how they use PKI and certificate management. Next I’d look to see how we can give address space to communities that need it without requiring BGP. It seems people fall into various buckets when it comes to requesting address space here. Some use cases that I can think of: • Static IPs for services accessed via the internet like echolink, IRLP, etc. • Provide amateur services with multiple ISPs address space to announce • Bridge unencrypted services between the internet and something like broadband hamnet, etc. One challenge is announcing 44net space on the internet when filtering becomes more common and LoAs aren’t enough anymore. The use of tunnels today bridges this gap, but it doesn’t scale very well. My proposal is to look into datacenter space in some of the major IXs (not just UCSD) today and announce large chunks of 44net far and wide. The anticipation is to get grandfathered to avoid filtering that is likely to happen increasingly in the coming years. Hopefully the nonprofit status of ARDC can get us some goodwill/discounts with network operators and datacenters, but it’s like finding the perfect repeater location… it will still cost money for hardware and rent, even with the most generous landlord. For those who wish to use BGP, that’s still an option. I would recommend most people join an overlay network (sd-wan) solution that can provide the same benefits of BGP (multiple paths, static IPs, etc) but is easy enough to assign IP blocks and route IPs without BGP. Some solutions today that are open source and create a managed VPN mesh that can be managed from a centralized location. It’s like IP-IP tunneling used today, except it abstracts away the need for a static IP tunnel endpoint, and auto-routes away from links that have bad connectivity. Using an SD-WAN also provides the ability to do malware checking, firewalling, and other features that would be normal in a network like this. People can choose if nodes can only talk to other 44net nodes or expand access to the internet as a whole. Once the internet side is sorted out, the “internal” side of 44net could implement open services for everyone, including packet gateways, DNS, etc. The anticipation is to be able to access these services without needing to leave 44net. This affords us a few things. For example, replication of the .ham TLD I mentioned above can potentially be updated over RF, so everyone can have a copy of the complete DNS zone. The idea here is while we do invest heavily on the internet side, we also invest in the ability to run 44net without the internet. By using inherent multicast abilities of RF, plus anycast, we have our own replicated decentralized internet-free DNS infrastructure. For things like mail, winlink has had a head start here. We may need to borrow a lot of technology used here or invent our own. Satellites are getting cheaper to provide IP-based communication and they have potential to avoid terrestrial internet. Could we partner with Space-X Starlink? With an overlay network, packets can go satellite, internet, cellular, or all three. >From there, the rest of services can fall in line as needed. Need a replicated wiki knowledgebase? Done. Near-time speed chat? Sure. APRS gateway without the internet? Yup. Partner with AREDN to mesh the meshes more securely and redundantly? It's possible. We can become the ISP for amateur radio and create our own walled garden while also interfacing with the wild west of the internet to protect our interests there. -Clive KF6DMA

5 6

Re: [44net] My view to 44net's future
by Rob Janssen 14 Jul '20

14 Jul '20

It is about a year ago that I tried to discuss such a proposal. My view was like this: let's establish routers at datacenters around the world, in addition to the existing UCSD router and some others that already handle /16 networks on internet. I was thinking about around 10 routers globally. They interconnect using BGP on private AS numbers (the 32-bit AS numbering scheme we already use) over a mesh of tunnels between them, to exchange routing information for 44Net subnets, but on internet the announcing remains as it is (i.e. the whole network is announced at UCSD, and regional subnets are, but do not need to be, announced at those global routers). The "users" connect to those routers using a (small) variety of tunnel protocols to match the restrictions they face from their internet providers, e.g. forcibly being behind a NAT router, having a dynamic IP address, maybe having some enforced firewalling, etc. I was thinking of standard tunneling protocols like GRE, GRE/IPsec, L2TP/IPsec, etc. The tunnels would be operated in a point-to-point fashion by default (/30 or /31 subnets on the tunnel), and the users would use BGP to announce their own routable subnet over that. They can setup redundant tunnels to multiple global routers when they desire to do so. They can also setup tunnels directly to other users when desired, and run a BGP session with them. And of course, radio links can be incorporated in the scheme. Users could use the widely available inexpensive routers available today that can use these standard protocols without special tinkering with scripting, locally compiled executables, etc. E.g. the inexpensive models available from MikroTik, Ubiquiti, etc. More technically inclined users could install software on their own Linux system or -board. I see this as a solution for the following problems: - more and more users struggle with getting IPIP routed on their internet connection, due to them being behind ISP-managed routers, CGNAT, having dynamic addresses, etc. - non-technical users struggle to get our special IPIP mesh operational on their routers, where using industry-standard protocols would be much easier as their router config interface already knows about those. - some users requested to have redundant IPIP tunnels (multiple internet routers serving the same 44Net subnet(s) in a redundant way, which the IPIP mesh cannot do. - the IPIP mesh does not really allow to check the status of the configured gateway routers, so routers that have not been operational for a long time just remain in the tables. I expected enthousiasm from the users, but unfortunately I was met with a lot of resistance to change, e.g. from people who believed that such a system would rob them from their direct tunnel to their buddies on the other side of the world and force them to go via established and centrally managed hubs (incorrect, of course). As I see this as a hobby and not as a struggle to be right and convince those that do not want to be convinced, I did not pursue it further. I don't know if the attitude an scepticism has gone away now. We would have to see in a new discussion. Maybe some of the opponents have realized by now that it would be better to have a more flexible mechanism like this instead of going on with the IPIP mesh forever. Maybe not. I don's see the need of routing the entire 44Net from internet to all those routers. When everyone routes only their own regional subnet(s), it remains more manageble and we do not face the raised issues. Furthermore, some of us have our ISP announce the relevant regional subnet on their redundant border routers under their AS, and then route it to our "gateway" router. That relieves us from being responsible for that announcement, and we use the ISP NOC services. But of course it also means we are less integrated with the internet routing, e.g. we cannot allow that subnets from our announcement are routed to others. Of course everyone can decide if they want to announce their subnet on internet directly or via an ISP, but I would suggest that the internet side of things be kept separate from our internal routing (2 BGP instances, the 44Net one using a private AS number) W.r.t. the .ham TLD: I don't see what advantage that would bring, we already have the .ampr.org domain and we run the DNS for it. It should offer the same capabilities as a dedicated TLD, I think, at a much lower cost. Rob

10 20

Update on ARDC Board activities
by Phil Karn 03 Jul '20

03 Jul '20

I want to provide an update on what ARDC's nonprofit board has been doing since Brian's sudden passing last November. Our three priorities have been: 1) Sustainability and continuity of the AMPRnet infrastructure. As I reported to the list 30 Dec 2019, Chris Smith, G1FEF (chris(a)g1fef.co.uk) has taken over AMPRnet portal management among other sysadmin tasks. Chris is now working under paid contract with ARDC, rather than as a volunteer. Besides keeping the infrastructure going, he is also dedicating some paid time to improving the Portal and other software. The process of contracting made us aware that we had never adopted a GDPR-compliant privacy policy, so we've engaged lawyers to write one -- as simple as they'll let us make it, given that we do actually keep personal data about hams who apply for net44 allocations, write for the mailing list or wiki, etc. Actually following this policy then requires us to make staff policies to match it (Record Retention and Data Destruction, Data Custodianship and Access), plus a Terms of Use for the website, which we are still actively trying to shorten and simplify. (I hate this legal stuff as much as anybody, but it has to be done.) 2) Gathering administrative, financial and legal records, investing our funds responsibly, and preparing for our first financial audit. Brian was a meticulous record-keeper, and we do have all his records, but clearly he had no intention of passing so soon. So this was not trivial. The audited financials and our 2019 tax return will be published on the website and announced on the mailing list. 3) Establishing processes for accepting and reviewing grant applications, awarding grants and following up on how our grants are spent. We are steadily adding process and documentation. The board appointed five volunteers to the Grants Advisory Committee for 2020 and it's up and running. They meet (virtually) every two weeks to review, discuss and evaluate the proposals that are now flowing in. The Committee (and the Board) do approve a few grants as originally submitted, but most involve some negotiation. Typically we'll ask an applicant to divide a single request into well-defined sub-projects, each with a clear objective and cost. Although ARDC did fully fund the UCSD Turing Memorial Scholarship in Brian's memory, in general we want to avoid funding other organizations' endowments. So we'll ask applicants to request only what they can usefully spend in one year, and come back next year for more. Then we can see what they've accomplished as we decide whether to grant more. For more information, see: https://www.ampr.org/giving/ Here is a list of all grants made. They total more than a million US dollars so far. https://www.ampr.org/grants/ As the Giving page describes, there is a lot more to do. We hope to increase the pace this year, but we are trying hard to get everything right, or at least not terribly wrong. I never expected to become ARDC President. Brian was a close personal friend and you can't believe how much I wish he still had this job. I have health problems of my own slowing me down, and while I've avoided Covid (so far) the pandemic certainly isn't helping. My original plans to promote ARDC at major ham gatherings like Dayton and Friedrichshafen evaporated months ago. But the entire Board remains committed to realize Brian's vision and honor his long commitment to the AMPRnet infrastructure and community, and to the Internet community. Brian stood at the intersection of both, and ARDC will continue to do the same. 73, Phil Karn, KA9Q ARDC President

2 1

RPKI, BGP security, and possible paths forward
by k claffy 03 Jul '20

03 Jul '20

[written by two ARDC Board members kc claffy and John Gilmore] Along with all the other activities Phil mentioned in his mail, the ARDC board is talking about RPKI, catalyzed by the mailing list thread last month. Although John (W0GNU) sent some of his personal thoughts to the list, he emphasized that he was not communicating a Board position. As others noted in the thread, it is a complicated issue that admits no easy solution. There are unknown but presumably small amounts of BGP hijacking that occur in the wild. (Well, it doesn't matter how small the amount is if it's your prefix..) Current systems diagnose these mistakes after they occur; RPKI is an attempt to stop them before they occur. But it isn't clear to everyone that having that solution, in the political and litigious economies in which it is embeded, is better than having the problem it's trying to solve. Some incorrect assumptions have appeared on this thread, most importantly regarding the status of the AMPRnet address space, which is, without a doubt, legacy IP address space. This status has implications for trying to integrate into an RPKI system that is "rooted" in 5 roots run by RIRs that don't (always) trust each other. The idea of establishing a new independent RPKI Trust Anchor is -- as Job points out -- not something that has much precedent. A comparison to the web's PKI does not lend confidence in the trustworthiness of the ecosystem. Any organization that operated a new Trust Anchor would also be subject to tremendous liability. ARIN's response to that is tremendous indemnification (denying its RPKI users the right to successfully sue them), even in a hypothetical situation when ARIN were judged to be clearly at fault. This self-defensive behavior, plus some policy problems, are limiting RPKI uptake in the ARIN region. (For data geeks: https://rpki-monitor.antd.nist.gov/ ) Further complicating the issue, ARIN and the other RIRs decided to use routing certification as a wedge to require legacy users to sign contracts that both financially support the RIRs (maintaining high integrity databases is not cheap), and increase the RIRs' control over the legacy users' address space. At a deeper level, we recognize the architectural (not to mention sociopolitical) concerns John raised regarding inserting centralized cryptographic chokepoint(s) into the truly distributed BGP protocol. Questions we have heard in the debate, which we assume many amateur radio operators are sympathetic to, include: Who'll watch the watchers when they control the ability to block or allow users to be part of the routable Internet? And who will be able to effectively protest the RIRs' mistakes or overreaches when they can forcibly take anyone who disagrees with them off the Internet? We recognize the importance, magnitude, and sociotechnical depth of the problem. We admit that at this time we do not see a clear path forward that the whole AMPRnet community would stand behind. Since our mission is focused on network research, experimentation, and education, we would welcome one or more serious proposals in the area of BGP routing security. Approaches that do not require a hierarchical root of trust would be most consistent with the nature of our mission and the distributed nature of the Internet. Solutions that expose ARDC to the liability that ARIN has tried so diligently to avoid are much less likely to be adopted. We are also aware that routing security is a decades-old problem, and IETF working groups have argued over solutions for many years without resolution. We understand that RPKI as currently deployed is a compromise that has grown out of this history of tension and debate. Besides trying to solve the routing security problem for the world, we would also welcome ideas about merely solving it for 44net. If someone (or two) is inclined to (co)chair a working group on this topic, we could support workshops (virtual for now) to discuss AMPRnet-specific measures. https://www.ampr.org/giving/ kc and jg, on behalf of ARDC Board

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net July 2020