44net December 2020

44net@mailman.ampr.org

45 participants
33 discussions

Inviting you to ARDC Grantmaking Survey + Community Jitsi Call
by Rosy Wolfe 12 Mar '21

12 Mar '21

Hello 44net! Hope you are healthy and well wherever you are. I'm writing to invite you to a couple of things. 1. ARDC Grantmaking Survey The first is an invitation to take this survey about ARDC grant making, which you can find here: https://www.mysurveygizmo.com/s3/5789610/ARDC-Grantmaking-Feedback-Survey The survey covers our existing granting goals and some of the kinds of projects that we've funded so far. What do you think? What other grants would you like to see? Do you know of organizations, either in the US or abroad, that you'd like to see us fund? Let us know - it shouldn't take more than 5 minutes, more if you decide to give some longer written-out answers. 2. 44net + ARDC Community Video Call We'll go over the results together in a community video call, happening Saturday Oct. 10, 2020, at 17:00 UTC (10am PT / 1pm ET / 6pm BST / 7pm CEST). On this call, we'll introduce ARDC Board members, grants advisory committee members, and staff; go over the survey results together; talk about our grants made to date; and talk about any questions you have. If there's anything in particular you'd like ARDC to cover in the call, please let us know by responding to this mail or sending me a message directly: rosy(a)ampr.org. Here is the link to the call: https://meet.jit.si/ardc-44net-community-meeting-oct-10-2020 A note on the times: I realize that the times listed are more convenient for folks in the Americas, Africa, and Europe. If enough people from Asia and Australia wish to join but can't for timing reasons, we may do another group call for those time zones. Part of this exercise is also learning about 44net's distribution - where is everyone located? I'm looking forward to finding out. I'm also looking forward to better getting to know 44net and the greater ham community, and to use what I learn to help shape ARDC's 2021 grantmaking strategy. We are in a fortunate position to do a lot of good in the world - so let's do it! All the best, Rosy -- Rosy Wolfe Executive Director Amateur Radio Digital Communications (ARDC) ampr.org

13 20

BGP/openvpn finally all ok.
by pete M 16 Jan '21

16 Jan '21

I want to thanks all that helped with the setup of my vultr vps with BGP and openvpn to distribute the /24 that was assigned to me. I played a lot with the openvpn and wireguard software up to a point I had to redo the whole install of the VPS. here is the receipy I have been able to use for the task. I am running a Debian10 that was updated to the latest software First I have use the tutorial at https://www.vultr.com/docs/configuring-bgp-on-vultr Be aware that on my version of bird I was not able to open the "/var/log/bird.log" files because of a propriatary right. the file belongned to root and it was supposed to belong to bird it is a known bug that I hope will be fixed soon. this helped me create that information into my bird.conf ------------------------------------------------------------------------------ log "/var/log/bird.log" all; router id xxx.xxx.xxx.xxx ; use the ipv4 address assigned to your vps protocol device { scan time 60; } protocol static { route 44.xxx.xxx.0/24 via xxx.xxx.xxx.xxx ; use your assigned /24 from ampr and the ipv4 from your vps } protocol bgp vultr { local as yyyyyyyyyyy; this is the private asn given to you by vultr and availble on your dashboard on myvultr.com for your vps source address xxx.xxx.xxx.xxx; import none; export all; graceful restart on; next hop self; multihop 2; neighbor 169.254.169.254 as 64515; password "YourSecretPassword" ; } ------------------------------------------------------------------------------ On the openvpn side of thing I have use the install script from angristan available at https://github.com/angristan/openvpn-install just followed the instruction and all was good. from there I changed some things on my network at etc/network/interfaces -------------------------------------------------------------------------- # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). #source /etc/network/interfaces.d/* auto lo iface lo inet loopback auto ens3 allow-hotplug ens3 iface ens3 inet dhcp iface ens3 inet static address 44.135.59.1/32 --------------------------------------------------------------------- the last line point at the first address of my /24 put yours into your file. then on the openvpn server I changed into the server.conf file only one line the file is at /etc/openvpn/server.conf i switched the server line from server 10.8.0.0 255.255.255.0 to server 44.135.59.0 255.255.255.0 the 44 address is my /24 put yours if you follow my exemple. that's it! it was not that complicated. But I had to dig a bit to understand the whole thing. My next step will be to split my /24 in parts. one section will be for the single connections like now, but I want to have connection that are like blocks of /28 or /29. I know I will have to make another instence of the openvpn server That is the part that is the less clear for me yet. The conf file is more clear. As I want to strat and stop each instence easily I will have to make a new starting script for systemd And that is where I will need to read more. If this helps someone I will be happy! If you see a problem with my setup please let me know! Pierre VE2PF

7 27

Re: [44net] ipencap routing question
by Rob Janssen 02 Jan '21

02 Jan '21

> If we replaced the IPIP mesh with a collection of geographically > distributed VPN servers (OpenVPN?) which advertised routes for /24 (or > larger) subnets, and dual homed each subnet to two or more VPN servers we > would have pretty good redundancy and could end the distribution of IPIP > endpoints and just let the Internet route between subnets. That, or alternatively we could setup a number of routers across the globe with a tunnel mesh between them (similar to what is now done on IPIP, but probably better to use something like GRE/IPsec tunnels), with BGP talking between all those routers, and let users connect their router to one or more of them as they desire. When one, they could use a VPN with static routing of their subnet, when they use 2 or 3 connections they could use BGP as well to advertise their own subnet plus maybe local people's subnets they have routed over radio. (in the above, with BGP I mean BGP on private AS with only AMPRNet routes, not full internet BGP) In such a setup, a single router failing would have little or no impact on the network as a whole. And everyone can participate with simpler or more complex setups without having to forcibly deal with a 600-tunnel mesh (that still does not allow redundancy of the internet connection, i.e. the current IPIP tunnel mesh cannot handle redundant internet connections that present a different internet IP to the tunnel system). Routers in this system could also announce, directly or via their ISP, subnets from AMPRnet directly to internet. That would just mean there is a more direct path between AMPRNet users and internet users in that region. But it is not a firm requirement to do so. But well, it has all been discussed several times already. In the beginning, the counter-argument was "it would cost money and who is going to pay that??". I think that is resolved now. The next one was "but we won't have a full mesh, traffic to my buddy is going to take 2 or 3 tunnel hops instead of one". Well, not really true, one can always setup a direct tunnel to someone else, and a BGP session over that, and direct traffic will take that path because it has less visible hops. So then we usually end up in the "it has always been done this way (IPIP mesh) and I am not going to change". Where the discussion usually stops until the next new user turns up that has difficulty getting connected to the mesh, e.g. because they are behind a NAT router they cannot change, their address is very dynamic, they want to use an off-the-shelf router, etc etc. By now it appears to be the classical "it was difficult for me should it should be difficult for everyone else trying to join" that has also been abused for so long in the battle to get rid of CW exams when obtaining a ham radio license... Rob

16 38

Re: [44net] ipencap routing question -> What about the future ?
by Rob Janssen 31 Dec '20

31 Dec '20

> I don't really agree. IMHO, the key for mass adoption is the > availability of ready-to-use images for tiny computers such as Raspberry > Pi. Such images can be made as a by-product of a new network design, but please understand that the main objective of the network changes should be that such special images should become unnecessary to get a working network connection. It should work with a normal router. "normal" in the sense that it requires a little more than basic home NAT router functionality, but any commercial router that is able to setup a VPN like L2TP/IPsec, SSTP, PPTP etc should be able to join the network just using its standard configuration interface. And when it supports BGP, it should be able to participate in routing towards others. So, no special tricks required like we now have multipoint tunnels, ampr-ripd, etc and which would require preparation of an image for a newbie to be able to join. Sure it can be done as one of the options, as a project for someone who likes to make such images (with an initial configuration dialog etc) and loves to keep such things uptodate. A simple router like the MikroTik RB750Gr3 is in the same price class as a Raspberry Pi (when SD card, housing and power supply are included) and it conveniently provides 5 ethernet ports and a USB connector. For such a router, just an example configuration is required and the software is kept uptodate by someone else. Rob

10 22

Re: [44net] ipencap routing question -> What about the future ?
by Rob Janssen 31 Dec '20

31 Dec '20

> Yes, a 44 BGP network would do the trick, but I am certainly not willing > to pay hundreds of USD per month for such an endeavor. BGP peering is > not cheap and not readily available in the whole wide world unless it is > not piggy backed on another preexisting AS for a select few working in > the network business. Aside from the discussion "what it really costs", this is one reason why I think the deployment of access routers around the world should be coordinated by ARDC instead of being an individual effort by hams around the world each serving only their local region. Certainly there should be room for that, but it should not be the only option. ARDC can investigate and find one or more VPS providers where they can order a number of VPS including BGP announcement of a subnet at several datacenters, for some fixed price which should be within the ARDC budget. In the network structure as I see it, there would be routers connected by tunnels and serving a VPN service for the users, but they would not all need to have BGP announced subnets. When it is too expensive to have that in some country, that can be done in a nearby country instead. The private-AS internal BGP routing of all AMPRnet addresses will handle that. Of course one usually would want a country subnet to be announced somewhere nearby, to reduce latency for the users not connected to AMPRnet. With a well-connected router mesh in good datacenters, the latency will be in the millisecond region, and not like the values we now see for traffic going via amprgw. Rob

6 9

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

Re: [44net] - > What about the future ?
by Rob PE1CHL 30 Dec '20

30 Dec '20

> Previously, we were talking about network topology. Here, we are talking > about applications. This is one of the drawbacks of the current 44net : > lots of applications are installed on 44net addresses, but there's no > current catalog, and no way to find them. > Maybe an idea of a project that can be handled by ARDC : a search engine > / catalog of all existing applications on 44net. I have been thinking about that before. My idea was to setup a search site which has a database of existing services, where a visitor could search by different attributes of an entry, where possible with a user interface that suggests valid values. So not a "google" style textbox where you can only search for things of which you already know the name, but also can "explore" and find new unknown things (e.g. a service type is a dropdown list or there is a page with all known types and links that you can click to search them). Now the major problem is "how do we keep this uptodate". It is quite common that someone newly active on the Dutch network experiments and installs something like a "HamServer Pi" and would register it in the database. But maybe after a couple of weeks he reprograms the Pi for something else and that entry would remain in the database and people trying to visit it would encounter a timeout. As I also do not really like systems that are constantly probing and scanning to find new services, my idea was to devise some way where a service would automatically refresh its entry by re-submitting it, and the search engine would only display entries that have been recently refreshed. (e.g. once per week or so) With such a system, the risk of stale entries is a lot less. But I have not yet devised a way to refresh entries without limiting the platform on which they can run (a Linux or Windows system can easily schedule a job that runs some program to post a form, but I do not want to limit too much what platforms can provide and auto-refresh services) Rob

3 8

Re: [44net] ipencap routing question -> What about the future ? (many messages in 44Net Digest, Vol 9, Issue 139)
by Stuart W. Card 30 Dec '20

30 Dec '20

On 12/29/2020 3:00 PM, 44net-request(a)mailman.ampr.org wrote: > > Today's Topics: > ... > 7. Re: ipencap routing question -> What about the future ? > (Toussaint OTTAVI) I would like to comment briefly on several points made in this thread. Has the 44NGN list been shut down? Concurrently with it being mentioned in this thread on this list, I received a message indicating I had been unsubscribed from that list. If lurkers like myself, who post very rarely, only when we feel we really have something to add, are welcome on the TAC, I will apply. Please take a look at the Host Identity Protocol (HIP) as one way of providing a persistent identity with a reputation (like a call sign) on the Internet, and dynamically establishing tunnels as needed to the corresponding IP addresses (despite changes due to DHCP or mobility). _Inter alia_, this would obviate moving from a resilient flat mesh to a fragile, congestion-prone hierarchy. It would also facilitate using 44 and non-44 addresses as needed. It uses strong crypto to mutually authenticate endpoints. Yes, HIP enables encryption, automagically establishing IPsec ESP tunnels, but it does not force encryption to be used _over the air_. See these IETF documents (neither experimental nor obsoleted) on HIP: RFC 4423 architecture RFC 5207 NAT firewall issues RFC 7401 HIPv2 protocol specification RFC 7402 ESP RFC 8002 certificates RFC 8003 registration extension RFC 8004 rendezvous extension RFC 8005 DNS extension RFC 8046 mobility RFC 8047 multicast a draft addressing how to deal with the issues in RFC 5207 https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/ and especially the draft update to the 1st doc above https://datatracker.ietf.org/doc/draft-ietf-hip-rfc4423-bis/ I have a ton of other materials I am willing to share explaining how HIP deconflates identities ("names") from logical locations (IP addresses used for actual packet routing) in the Internet, and naturally integrates cryptographic authentication of said identities, thereby solving many of the problems with current practice that motivated the "clean slate Internet redesign" hype several years ago. Our company has used it for lots of things, military and commercial, including mesh WANs. Currently I am working with various standards development organizations, government agencies, commercial product and service providers, _et al_, to standardize/promote its use to identify observed [unmanned] aircraft (and other cyber-physical systems) in a trustworthy manner, enabling authorized observers to immediately establish mutually authenticated communications with the parties responsible for their safe operation. There is 1 commercial product line that explicitly admits to being HIP based (some others formerly admitted that but no longer disclose the basis of their secret sauce): Tempered Networks https://discover.tempered.io/webinars/how-tempered-uses-hip-to-achieve-zero… There are 2 arguably usable open source implementations, one of which is being updated to HIPv2 and enhancements currently being standardized: OpenHIP https://bitbucket.org/openhip/openhip/branches/ 73, AC2WH (long ago WB2IEP) -- Stuart W. Card, PhD: VP & Chief Scientist, Critical Technologies Inc. * Creativity * Diversity * Expertise * Flexibility * Integrity * Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501 315-793-0248 x141 FAX -9710 <Stu.Card(a)critical.com> www.critical.com

2 1

Re: [44net] ipencap routing question
by lleachii＠aol.com 30 Dec '20

30 Dec '20

Roland, I guess the best way to answer this is, what Network Operating System are you using? - Windows - unknown (I last attempted in 2012) - *nix - only one tunnel need to be enumerated - Cisco - multiple tunnels are needed You can see this from the relevant Wikis. 73, - Lynwood KB3VWG

5 17

Re: [44net] ipencap routing question -> What about the future ?
by Rob Janssen 30 Dec '20

30 Dec '20

> I think Rob, PE1CHL, had some approach to offer 44net VPN access using > LOTW certificate for authentication if I remember correctly... Maybe he > could tell us more on how people where attracted to it. No, that is not me. I think it is a Finnish ham who is doing that. Over here we have OpenVPN access with locally issued certificates, not connected to any officially trusted source. When a Dutch amateur wants to use OpenVPN, they request a certificate (usually via me) and there is a script which generates a certificate for the requested callsign and makes an OpenVPN config file containing the correct parameters, the user certificate, and the CA certificate. When the user uses this to connect to the OpenVPN server, their IP address is retrieved from DNS (based on the certificate name which is their callsign), so they get their fixed IP address. A route is distributed via BGP to route the traffic to their OpenVPN connection from anywhere within the network, as long as the connection is up. While such a system could be used to "give all amateurs their own fixed IP address" (either via this locally issued certificate or with something like LOTW) I agree that there is little point in doing that "to make use of our IP space". Such a bank of allocated but rarely ever used addresses should not be considered "used" just for sake of "use it or lose it". Rob

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net December 2020