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
On Sat, Jul 11, 2020 at 3:06 AM Clive Blackledge via 44Net 44net@mailman.ampr.org wrote:
Hello,
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).
If another non-AMPRnet site/host on the internet insists on speaking HTTPS/SSL there's no way around this - unless of course one proposes proxying on the edge. But if we were to do proxying on the edge then what's the point of using/assigning public IPs within AMPRnet to begin with?
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.
This *could* be done, in theory. In fact a number of people are currently running such overlay networks and some (such as myself) are announcing/routing 44/9,44.128/10 prefixes on their overlay networks. However, there are a few things that need to be kept in mind when it comes to such a proposal.
1. It would require AMPRnet to operate its own AS. While this is *may* be possible to convince different peers in different upstreams to announce 44/9,44.128/10 prefixes on AMPRnet's behalf, this would ultimately end up causing more trouble than it's worth (from a network management standpoint). That's why for multihomed networks, such as the one being proposed here, the only realistic approach would be for AMPRnet to become its own AS rather than relying on other ASes to announce AMPRnet space.
2. The edge routers on this overlay network would most likely need to be configured as a iBGP full mesh so that they would all share the same view of the internet. Now, there may be ways around this. I myself spent two years trying various alternatives in order to run an overlay network of the sort being proposed here without doing iBGP. However, iBGP proved to be the lowest maintenance/least time consuming approach (which is probably why iBGP is the preferred approach for sharing routes between multiple border routers within a multihomed AS/AS with multiple peers).
3. It would require that AMPRnet establish/maintain a 24/7 NOC rather than relying on USCD's NOC as is currently the case. After all, peers wouldn't like it if there was no one there to pick up the phone/respond promptly to the email should there be some routing issue (such as flapping or worse). Nor would they tolerate this for long before simply depeering. In a related note, there really is no "grandfathering" when it comes to peering on the Internet. If a network decides to take a stricter policy when it comes to ROAs, for example, they usually do not simply exempt existing peers from these requirements just because they are existing peers.
4. Considering that this new AMPRnet would be worldwide in scope and considering that AMPRnet's prefixes are already assigned along regional lines (i.e.44/9 for US, 44.76/16 for US/TX etc.), converting AMPRnet into one big overlay network without at the same time creating a whole lot of inefficient routing would entail creating a fairly sophisticated routing policy on the edge. It would need to be a bit more sophisticated than simply advertising 44/9 and 44.128/10 at every border router.
In short, what is being proposed here would entail a whole lot more BGP, not less. And it would require a great deal more maintenance and upkeep than is currently the case. It would mean less time for experimental activities and more time focused on upkeeping a massive global network.
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.
I think there is a bit of confusion here as to what an "SD-WAN" is. An "SD-WAN" generally refers to services that centralize and rationalize the management of network connections (including tunnels, LTE, MPLS - depending on the service being offered). They are usually provided by Tier 1s/larger Tier 2s who, IMHO, tend to use SD-WAN as a catch-all marketing term for all of their "modern" enterprise connectivity services which are not MPLS/DWDM/etc. and which can complement and/or serve as a replacement.
SD-WANs are generally not substitutes for layer 3 routing protocols. They certainly are not a replacement for BGP. If AMPRnet prefixes are to be visible on the public internet then a BGP speaker somewhere will have to be advertising these prefixes. Right now AMPRnet's 44/9 and 44.128/10 prefixes are being advertised by UCSD's border router(s) (AS7377). If AMPRnet were to move in the direction proposed above, then as already noted, this would require a lot more BGP (and most likely an IGP as well to complement it). SD-WANs would not be a substitute for this.
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.
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.
Rather than trying to turn AMPRnet into one big overlay ISP, I think the better approach would be to continue to assign /24+ prefixes to HAMs that have the resources to announce them and keep them on them on the internet - *but* to make these assignments with the clear understanding that these "BGP HAMs" will provide tunneling services to other regional/local HAMs (who are not doing BGP + far away from San Diego) - including carving out pieces (i.e. /27s, /28s etc) of their own /24+ prefixes and assigning them to "non-BGP HAMs", so to speak.
This I think would meet the goal as proposed above, but without needing to create a massive/high maintenance overlay network/ISP. It would also maintain the experimental ethos of AMPRnet. The big overlay net/ISP thing would take away from this as we spent more and more of our time on all the "housekeeping" that would be required to maintain ISPs and walled gardens.
-Clive KF6DMA _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
- Erik KE5SAI
My 2cents, that's too much to bite off and chew. Ham radio (not just this niche 44net area) needs more doers. (Which is a bigger leadership thing that should be addressed) Till then, you have to pick smaller things to work on in my opinion.
So here is a smaller thing that we have talked about before: A self service IPv4/IPv6 ham DNS that end users can be auto authenticated via the LoTW p12 certificate would be a good smaller project. From there whitelist exports via RIP or RSS. Perhaps that DNS uses the existing ampr.org domain or something else, perhaps a TLD. But from what I understand, open your wallet for that TLD.
Everything else I'd like to talk about involves regulatory changes to modernized data over the air. And short of tench coats and lots of lobbying that stuff is going to be slow to happen as it has.
In the grand scheme of things we need to move away from AX.25, but I understand the dilemma, so since everyone still loves that so much;
I guess a smaller vision would be to see a software TNC like direwolf that can natively support more than one over the air baud rate. Having to pick a standard baud rate, as to not alienate your station from everyone else has been a problem since the days of hardware TNCs. I software TNC should be able to be configured to decode and encode a few different over the air baud rates and be dynamic enough to reply at the rate it decoded, etc.
If I was up to snuff on coding skills these are things I'd be working on.
Steve, KB9MWR
On Sat, Jul 11, 2020 at 2:10 PM Erik Seidel via 44Net 44net@mailman.ampr.org wrote:
On Sat, Jul 11, 2020 at 3:06 AM Clive Blackledge via 44Net 44net@mailman.ampr.org wrote:
Hello,
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).
If another non-AMPRnet site/host on the internet insists on speaking HTTPS/SSL there's no way around this - unless of course one proposes proxying on the edge. But if we were to do proxying on the edge then what's the point of using/assigning public IPs within AMPRnet to begin with?
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.
This *could* be done, in theory. In fact a number of people are currently running such overlay networks and some (such as myself) are announcing/routing 44/9,44.128/10 prefixes on their overlay networks. However, there are a few things that need to be kept in mind when it comes to such a proposal.
- It would require AMPRnet to operate its own AS. While this is *may*
be possible to convince different peers in different upstreams to announce 44/9,44.128/10 prefixes on AMPRnet's behalf, this would ultimately end up causing more trouble than it's worth (from a network management standpoint). That's why for multihomed networks, such as the one being proposed here, the only realistic approach would be for AMPRnet to become its own AS rather than relying on other ASes to announce AMPRnet space.
- The edge routers on this overlay network would most likely need to
be configured as a iBGP full mesh so that they would all share the same view of the internet. Now, there may be ways around this. I myself spent two years trying various alternatives in order to run an overlay network of the sort being proposed here without doing iBGP. However, iBGP proved to be the lowest maintenance/least time consuming approach (which is probably why iBGP is the preferred approach for sharing routes between multiple border routers within a multihomed AS/AS with multiple peers).
- It would require that AMPRnet establish/maintain a 24/7 NOC rather
than relying on USCD's NOC as is currently the case. After all, peers wouldn't like it if there was no one there to pick up the phone/respond promptly to the email should there be some routing issue (such as flapping or worse). Nor would they tolerate this for long before simply depeering. In a related note, there really is no "grandfathering" when it comes to peering on the Internet. If a network decides to take a stricter policy when it comes to ROAs, for example, they usually do not simply exempt existing peers from these requirements just because they are existing peers.
- Considering that this new AMPRnet would be worldwide in scope and
considering that AMPRnet's prefixes are already assigned along regional lines (i.e.44/9 for US, 44.76/16 for US/TX etc.), converting AMPRnet into one big overlay network without at the same time creating a whole lot of inefficient routing would entail creating a fairly sophisticated routing policy on the edge. It would need to be a bit more sophisticated than simply advertising 44/9 and 44.128/10 at every border router.
In short, what is being proposed here would entail a whole lot more BGP, not less. And it would require a great deal more maintenance and upkeep than is currently the case. It would mean less time for experimental activities and more time focused on upkeeping a massive global network.
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.
I think there is a bit of confusion here as to what an "SD-WAN" is. An "SD-WAN" generally refers to services that centralize and rationalize the management of network connections (including tunnels, LTE, MPLS - depending on the service being offered). They are usually provided by Tier 1s/larger Tier 2s who, IMHO, tend to use SD-WAN as a catch-all marketing term for all of their "modern" enterprise connectivity services which are not MPLS/DWDM/etc. and which can complement and/or serve as a replacement.
SD-WANs are generally not substitutes for layer 3 routing protocols. They certainly are not a replacement for BGP. If AMPRnet prefixes are to be visible on the public internet then a BGP speaker somewhere will have to be advertising these prefixes. Right now AMPRnet's 44/9 and 44.128/10 prefixes are being advertised by UCSD's border router(s) (AS7377). If AMPRnet were to move in the direction proposed above, then as already noted, this would require a lot more BGP (and most likely an IGP as well to complement it). SD-WANs would not be a substitute for this.
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.
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.
Rather than trying to turn AMPRnet into one big overlay ISP, I think the better approach would be to continue to assign /24+ prefixes to HAMs that have the resources to announce them and keep them on them on the internet - *but* to make these assignments with the clear understanding that these "BGP HAMs" will provide tunneling services to other regional/local HAMs (who are not doing BGP + far away from San Diego) - including carving out pieces (i.e. /27s, /28s etc) of their own /24+ prefixes and assigning them to "non-BGP HAMs", so to speak.
This I think would meet the goal as proposed above, but without needing to create a massive/high maintenance overlay network/ISP. It would also maintain the experimental ethos of AMPRnet. The big overlay net/ISP thing would take away from this as we spent more and more of our time on all the "housekeeping" that would be required to maintain ISPs and walled gardens.
-Clive KF6DMA _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
- Erik
KE5SAI
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Just to chime in quickly here about the packet side:
I guess a smaller vision would be to see a software TNC like direwolf that can natively support more than one over the air baud rate.
This is already possible today with Direwolf using .asoundrc tricks. The problem is, all other stations on frequency won't necessarily recognize this faster mode as a valid signal and thus possibly double on that signal. As such, it's better to use other frequencies for newer modes. All that said, I do understand your desire to support a "transition" approach.
--David KI6ZHD
On Sat, Jul 11, 2020 at 1:29 PM Steve L via 44Net 44net@mailman.ampr.org wrote:
So here is a smaller thing that we have talked about before: A self service IPv4/IPv6 ham DNS that end users can be auto authenticated via the LoTW p12 certificate would be a good smaller project. From there whitelist exports via RIP or RSS. Perhaps that DNS uses the existing ampr.org domain or something else, perhaps a TLD. But from what I understand, open your wallet for that TLD.
I agree the scope of this project is very large, Maybe I am overestimating the amount of people and funding that would be available for this challenge.
If I was up to snuff on coding skills these are things I'd be working on.
This is a good time to start. 99% of this can be done in python.. or golang.. Or rust.. but probably python. :)
-Clive
How difficult would it be to get some basic level filtering at the gateway? Would be nice, to just open the few ports I actually respond to, and block ssh login attempts on port 22, stuff like that? Would help make the system more 'rf friendly' I think.
On Mon, Jul 13, 2020 at 6:54 PM Cathryn Mataga via 44Net < 44net@mailman.ampr.org> wrote:
How difficult would it be to get some basic level filtering at the gateway? Would be nice, to just open the few ports I actually respond to, and block ssh login attempts on port 22, stuff like that? Would help make the system more 'rf friendly' I think.
This could be done on multiple levels, but it wouldn't be difficult.
The challenge is to make firewall management something anybody can use. It would require a web interface and also an API so we avoid administration overhead of managing firewall rules.
Most people would prefer to run their own routers, and thus be in charge of their own rules, but I can see how others may want managed for them (especially over expensive links like satellite)
-Clive
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
-
Cathryn Mataga -
Clive Blackledge -
David Ranch -
Erik Seidel -
Steve L