44net

44net@mailman.ampr.org

2 participants
3201 discussions

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

TA2T Coordinator for Turkey SK
by G1FEF 29 Jun '20

29 Jun '20

I have been informed of some more sad news: TA2T, the coordinator for Turkey is SK. Baris, TA7W has offered to step up as coordinator, unless anyone else is interested or has any objections? 73, Chris - G1FEF

2 1

Re: [44net] Reverse DNS and access to DNS info
by Rob Janssen 17 Jun '20

17 Jun '20

>Email servers for instance need to be on addresses with a reverse DNS >pointing to the same name. To fight a spam, otherwise won't be accepted >by majority of other email servers. >How can we achieve something like this? > mail44.hamradio.si 44.150.0.10 > 44.150.0.10 mail44.hamradio.si That is true, but you do not need to run your mailserver under the hamradio.si domain even when you handle mail for that domain. It would work perfectly fine with a domainname like mail44.s57nk.ampr.org (both forward and reverse) and then in hamradio.si an MX record with that name. For this kind of thing we use "club callsigns" like pi9noz or pi4nos. Rob

1 0

Reverse DNS and access to DNS info
by Rob Janssen 17 Jun '20

17 Jun '20

I notice that more and more 44net traffic originates from addresses that are not registered in DNS. To identify an amateur radio transmission, it is required in most countries that the callsign is included in transmissions. Up to now I have considered traffic from a net44 address to be identified by the reverse name that can be looked up in DNS, and that has the basic structure of "hostname.callsign.ampr.org" (with of course some variations, but always the callsign of the responsible station is part of the name). I think everyone should be encouraged (or even required) to register all used addresses in DNS. There may have been some hurdles to do that in the past (e.g. the never completed DNS part of the portal, the unavoidable restrictions of the ampraddr robot to accept only updates from coordinators). Everyone who has e.g. a number of hosts in the 44.190 or other not nationally registered parts of the network can send a list of their IP addresses and corresponding hostnames (with names like the above, i.e. a callsign embedded in them) to me, then I can submit them to the robot and they get registered in the ampr.org main DNS service. Otherwise please register your hosts through your local coordinator, even when you have been allocated an entire subnet. Furthermore, I see that more and more subnets have arranged to delegate DNS to their own servers. I think it would have been better to keep everything in a single list and then run a secondary zone within the own network (we do that here), instead of this split. Maybe a more convenient API for updating the main DNS should be (or would have had to be) added to avoid this? Or are there other reasons for operating this way? Given that we now have this situation, I think there should be a general policy of allowing AXFR and preferably also IXFR zone-transfers of these zones between net44 addresses. We should not have "dark and secret" zones that are inaccessible to others, I think, especially for the reverse (PTR) zones. Rob

11 10

why and Wiki
by Dave Wade 17 Jun '20

17 Jun '20

Folks, Being marooned in that back water that is the UK I wonder what TCPIP packet activity there is in the UK and on what frequencies and how this would be supplemented by using 44net over the internet? I though I would read the Wiki but that seems to be un-availble.. Dave Wade G4UGM & EA7KAE

2 2

Re: [44net] Reverse DNS and access to DNS info
by Rob Janssen 17 Jun '20

17 Jun '20

>I'm replying to the main thread, as Rob still insists with posting using his >broken MUA which breaks threading, making it impossible to follow his >ramblings. Thanks Rob. It is not convenient for me either! But I don't want to forward this list as separate mails as sometimes there are frantic discussions about topics that do not interest me at all (like RPKI) and I don't want my mail bell to ring all day (and load amsat.org with forwarding all those messages). So I am subscribed to the digest only, I sometimes watch the archives for quicker responses, and I cannot reply with the proper threading. I think I have mentioned it before: this list should be a newsgroup on an NNTP server. If only to honor Brian Kantor. Accessing it via a usenet news reader would be so much more convenient, you can just read it when you like and kill uninteresting threads. Or otherwise just use a forum. >Having reverse DNS with a callsign in it doesn't meet identification >requirements in the ITU or FCC rules, assuming the packet is traversing an RF >link on amateur frequencies. Under FCC rules (and I'm aware you may be under >a different legal authority), the control operator is the required ID, not the >originator of the packet. It is not only about regulatory ID requirements but also about identifying who is behind some traffic. Many places have "relaxed firewall rules" for traffic originating from within AMPRnet. This already requires revision due to the sale of the upper block (I think that lots of firewall rules still mention 44.0.0.0/8) but also with more and more blocks being routed directly and having no transparency about the actual use of that space, I would like to know if some address is really an amateur or if someone has lend it out to shodan.io or stretchoid.com. And if so, at least know who is responsible for that. When that is not feasible, we will have to become more and more closed and more like the general internet (default drop everything). Rob

2 1

Re: [44net] Reverse DNS and access to DNS info
by Rob Janssen 17 Jun '20

17 Jun '20

>I am not sure what you mean by feared, but no, my allocations are not supporting the AMPRnet per se. If by AMPRnet you mean the legacy BBS style network of gateways and tunnels. I don't. With AMPRnet I mean what is described on the ARDC pages, not a set of applications and an old way to implement tunnels. So, the net44 address space and its use for amateur radio communications. Use for IRLP would be part of that. But in that case it should be possible to have reverse entries pointing to the callsigns involved. Rob

1 0

Re: [44net] Reverse DNS and access to DNS info
by Rob Janssen 17 Jun '20

17 Jun '20

>The reason I did this was because I needed PTR records in something other than ampr.org. I already feared that it was to conceal non-AMPRnet usage... This makes it all the more important to have zone transfer capability so the data can be used to validate against local policies. Rob

3 2

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net