[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
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
>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
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
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
>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
>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
>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
>I manage my systems, and all the HamBSD systems, with Ansible. Some API
>would need to be provided to allow me to check the current reverse DNS
>record (in the database explicitly, not just by performing a DNS lookup
>that may be influenced by caching etc.) and to update the record.
I have that fully working using a collection of scripts, but indeed it would
be convenient when there was an easier and more modern API for it.
As it is now, you can download the zonefiles from an FTP server (or of course
you can do lookups at the master server ampr.org at 44.0.0.1) and compile a
list of updates (using diff between the downloaded- and the desired info) and
then you can create an e-mail message to the ampraddr robot that will do the
updates.
For this to work you have to have your mail sender address whitelisted.
(it used to be an open service until it was abused)
Rob
>On 16/06/2020 18:23, Rob Janssen via 44Net wrote:
>>/Furthermore, I see that more and more subnets have arranged to delegate />>/DNS to their own servers. /
>I had no idea this was an option. Who do I speak to to do this? It'd be
>great to have actually up-to-date reverse DNS for my subnet.
Why can't you submit updates to the main DNS server? What would be required
for you to do so?
Rob
