30 Jul
2021
30 Jul
'21
2 p.m.
Dear Mario,
Indeed, yes. This is up to the operators of these services. We do not want to interfere
with what they do and how.
To be clear: 44.0/9 *cannot* directly to 44.128/10 and 44.128/10 *cannot* talk directly to
44.0/9 under our proposal. I believe that this is what we include in the proposal text as
well. For all intents and purposes, we treat 44.0/9 as any other IPv4 address on the
Internet when we talk to it from the Intranet. The same way a 10/8 host cannot talk to
1.1.1.1 a 44.128/10 address cannot talk to 44.0.0.1. The operators of the networks will
have to use NAT (like they do today), or they can also request a 44.0/10 space and do a
1:1 mapping of hosts, or anything else.
- You should never receive a packet in your 44.128/10 address from a non-44.128/10
address
- You should never receive a packet in your non-44.128/10 network from a 44.128/10
address
Yes, this is something we can do, and it’s a good idea.
We agree that this is what should happen. However, for any Internet-connected network,
there’s no guarantee it will always be true.
This is true, and a very common problem in community networks that I know of. People at
one point have a diverging vision and don’t agree anymore and then they stop exchanging
traffic. It is unfortunate to see in a network that’s supposed to connect people and it
can really slow down deployment efforts, but it can always happen. We even see parts of
that in the Internet too. I don’t think there’s anything ARDC can do to prevent this. The
only thing is to make sure there’s enough room for everyone and interconnecting is easy.
If some people want to be isolated or not talk to specific people, then I guess that’s
that..
This proposal aims to have ARDC continuously advertise 44.128/10 on the Internet, but as a
whole block to which all traffic is dropped and not forwarded. We don’t want to change
that. We have to keep advertising the space, for many reasons. Hopefully if we could get
RPKI we could publish a ROA that would cause people validating to drop all announcements
smaller than /10 in this space as well, so they are automatically discarded by filtering
ISPs.
As I have mentioned above, this problem is not simply solved by an ACL. It’s not a
firewall rule to drop all traffic and that’s it. If all want to be on the same routing
plane without causing massive packet loss and unreachable destinations, we have to find a
way to inform everyone else of our policy. And BGP cannot currently do this, especially
with the limitations of vendors like Ubiquiti and MikroTik. An ACL could solve this
problem if we had a very centralized network where everyone connects to the PoPs and it’s
mandatory, and interconnections between end users or networks is not allowed. If 44 Net
looked like this then applying any type of police would be much easier. But if you allow
for any use case, like hundreds of nodes connecting to each other, and only talk to the
PoPs from 3 points on the Internet, then things can get more complicated. “Simple ACL” is
easy on paper, but in reality it’s much more complicated than that.
Of course, I agree that there isn’t any mandate that I know of. However, all the policies
of each and every individual link in every single part of the network must be immediately
available to every single (at least “backbone”) router and must be used in the routing
decision making. If people have links visible through BGP that silently drop traffic this
will cause a lot of practical issues with unreachability like many we see in the network
today. And the people, no matter how much they want to fix them, won’t be able to.
Unfortunately mechanisms like uRPF that you mention only work to protect others from your
network. If anything is more than a hop away, especially in a scenario where a gateway has
a single transit provider / default route, then they can’t do anything. If you have a
default route on your Vultr VPS (or even a full table, doesn’t matter), you see the entire
Internet behind “eth0”. So everything coming that way will make it into your network just
fine. The only thing that uRPF will do is to not allow packets from your own network to
come via the Internet. Which you may have to allow eventually if e.g. your network is
connected to the Internet via 3 points, and you want to go over the Internet in the case
of a net split. So a lot of networks will end up disabling it (or choosing a more relaxed
version, or technically not enabling it as it’s off by default) in the first place because
it breaks legitimate use cases.
I would personally agree that people running more core parts of the network should have
more networking knowledge, and that would be expected, but I wouldn’t expect perfect,
state-of-the-art operational expertise and equipment support. I would still expect to see
operators like these to simply configure BGP and a few filters. And that’s fine. We’ve
learned from the Internet that any system that relies on everyone adopting it and playing
fair is far less likely to be useful.
If the network was more centralized and every 44 island required the PoPs to connect to
each other, and everything had to go through them, then you could argue that the ARDC
staff maintaining it would have to follow state-of-the-art procedures and since it’s only
a few points we could also have capable equipment, etc. So this becomes kinda better. But
still, this means a centralized network. Do we really want that?
Yes, and that’s exactly the problem! The control plane that BGP sees is different than the
data plane where the ACL drops the packets at. People using BGP see a valid path, but then
without telling anyone the operator(s) of the link drop the packets. There’s no way for
BGP to convey what firewall rules each link has attached to it and then take it into
account during path selection based on packet values. And there’s probably a good reason
for that, as you can’t accelerate any of that on hardware I imagine.
Yes, I agree.
Yes, this can easily be built. But isn’t building it easier if we guarantee that 44.128/10
does not appear on the Internet and should only be routed either on top of the Internet
(tunnels, VPNs, …) or other means (radio) ?
What I’m trying to say is that if every user of the network was competent and could easily
do such changes (like many people have claimed in this thread), then we wouldn’t have
cases where a single person is managing the network of 20 others. Everyone would probably
manage their own network. So it’s a point to make towards the fact that not even the
existing users are or want to be involved in all this routing.
We don’t really know to be honest as only a few people have participated in this
conversation out of the thousands that use the network. So our margin of error here is 99%
;)
We’re also not taking away anyone’s toys, if anything, we give them more.
I respect the people that have been doing this for decades, but I also understand that we
need to leave a lot of room for people that do this one decade, or 5 years, or 1 year, or
0 to grow as well and do what they want to achieve. Just because some people started this
25 years does not mean that this thing we have shouldn’t evolve to allow for more and more
users to participate.
I am not sure about that, but see, thats the thing. The decision of this
being illegal can not be made globally (and your intranet is consisting
of the current allocations for allmost all of the world) but it needs to
be made on a local / country basis, as it has been in the past.
There are certainly arguments for and against country-based vs use-case-based allocations.
I feel like if we do country-based allocations, as is evident from my e-mail above, we
will have a lot of trouble finding a way to represent the ACLs of each link on BGP (or any
other mechanism that can reconfigure all network routers). If this is not possible, then
we’ll need to have people maintain complex routing tables to go around entire countries
(if they even can) just to be able to deliver some traffic, because the BGP Best Path
drops it.
If we go with a system based on use case, then this is not needed, as people can easily
hardcode the two network policies that exist and easily route any way they want based on
them. This list of links is easy to aggregate: any link in 44.128/10 has policy X, and
each link in 44.0/9 has policy(ies?) Y.
Antonis
On 30 Jul 2021, at 17:11, Mario Lorenz
<ml(a)vdazone.org> wrote:
Dear Antonios,
Am 30. Jul 2021, um 15:32:26 schrieb Antonios Chariton (daknob):
The first reference of people is hams, the second is non-hams. So this sentence becomes:
That’s what hams want to do though. Hams want to use an amateur radio resource (44.0/10)
to talk to non-hams on the Internet (that are not licensed).
We do not want to restrict people on 44.0/10 and we want them to be able to speak to
anyone on the Internet. Of course, ARDC here may have some policies against e.g. spam,
piracy, etc. but that’s not relevant. They are responsible of figuring out though if their
communication is legal.
The proposal simply puts all the people that want to talk to the Internet in 44.0/10 and
leaves all the people that don’t want to talk to the Internet with a 44 address to
44.128/10.
That’s what people want to do though. They want
to use an amateur radio resource (44.0/10) to talk to people on the Internet that are not
licensed. Normally in RF you use a ham radio frequency to only talk to radio amateurs. In
the IP world, the src and dst can be different. People want to use an amateur radio
resource to talk to a commercial resource, and a commercial resource to talk to a ham
radio resource.
Please define "people". Are these radio amateurs ? If so, why do you
want to restrict communication with them ? What they have to say can go
over amateur radio airwaves. If not, why are they in 44.(0). in the
first place ? Here's the thing: If there are "people" that are not radio
amateurs but want IP space for non amateur communication, they can go
and get it somewhere else, and pay for the privilege.
If that needs any TAC resolution to propose at ARDC,
I think you would find much support on this list. These two
networks can interconnect. EchoLink now bridges the Internet with the amateur radio
spectrum. But we don’t use IP addresses on EchoLink, we use our callsigns, transmitted
over IP packets. And similarly, when we do IP / Internet connectivity over amateur radio
spectrum, we use IP addresses on top of callsigns.
In which case you need to differentiate between amateur radio and third
party traffic. We have
collected minutes of meetings that we did as the TAC, and they capture a part of the total
work that has been put through this. However, at this time, they are not public. Is there
something specific that you’re looking for? I could help provide more information on that.
As discussed before, the pdf statement contains contradictory, not
sufficiently specific language. Your explanations, as given in your role
as TAC speaker, appear to contradict the specific resolutions that
TAC wants to propose to ARDC. The specific example being whether 44.0/9
should be able to communicate with 44.128/10.
I'd like to resolve this obvious misunderstanding by looking at primary sources.
So far, we are not working on any such response, and all TAC members agree with the
responses provided by me.
They are inconsistent...
We only want to preserve some IP space that can
be used for ham-to-ham communication. How they communicate is up to them. If they want to
use radio-only, they can get an allocation off this space and build a radio-only network.
If they want to communicate with carrier pigeons only, they can get an allocation and
build a carrier-pigeon-only network. If they are okay with using tunnels *through* the
Internet, then they can do that.
OK, having established that, you would agree that any references to a
"radio-only networks" in the PDF should be reworded. We just want
to make sure that we have some space reserved for this type of communication. Going back
to the RF analogy, ALL amateur radio space is for ham-to-ham only. In our proposal SOME of
the space is for ham-to-ham, and the rest is for
ham-to-Internet-and-possibly-hopefully-some-hams-too. If anything, and we go by RF
standards, advertisement of 44/8 should be prohibited on the Internet as non-hams can
reach you.
Each packet bears a source and a destination IP. If we agree
that any packet originating from IP from either 44/9 or 44.128/10
are licensed ham radio amateurs (as stipulated by current ARDC AUP). If they are destined to a 44.destination via a radio
link, it can be
assumed they have sufficient authority to be passed on as ham-ham
communications.
What happens if they do not have sufficient authority to pass? Where will this be
reflected and how can users pick an alternative path?
If they are destined to non-44, or originate from
non-44
they *may* still be allowed as third-party communication, but this will
be jurisdiction-specific.
I guess this is up to the operators and the local laws they have for each link, as you
mention. However, how is it signaled and to whom that packets can or cannot pass from a
link so if they’ll be dropped I can avoid sending them and pick a different path. Can I as
an end-user pick a different path?
It seems to me that some paths on this global BGP network will only pass some forms of
traffic based on the source and the destination. Accounting for the destination is easy:
if no traffic should go there, remove / filter out the route. But what happens when you
want to filter by source a few hops down the network? How does my router know (and
everything else in the network) which *source* decision is also made? What happens with
combinations of (src, dst) and how will they be reflected on BGP? Do you plan to introduce
BGP Extended Communities that will have a global meaning and all users should alter their
path selection algorithm by using these and applying appropriate terms and rules in their
BGP peerings?
The problem here is how do I know which path I need to follow (and since I only control
the first hop, the path that everyone must route with, through 44/8) that will get me to a
given destination within 44/8? If I see 20 paths, but only 2 of them will forward my
traffic based on my use case (src, dst) how can I tell which ones are that, and how can I
affect the routing from my node to this one in order to ensure packet delivery? Do I just
have to rely that BGP will hopefully pick the path that doesn’t drop my packets instead of
the ones that does?
Will every router in the entire network apply source-based policy routing? How will this
be signaled? Will every have to manually maintain tables of “if src is x, use table y”?
Most routers today can do this as statically configured firewall rules + additional
routing tables. Is there a way to dynamically propagate this information to the entire
network? Is it safe to allow people to control your routing policy? Who can modify your
firewall rules to point to the “no radio” table?
Any station in the business of forwarding packets (ie.
not your "end
user") can and must make the decision whether he actually forwards those
packets. Therefore anyone implementing a ham-to-ham-only policy can do
so within his network, *without placing any undue burden on other
people* to do the same or leave.
You can’t just advertise routes on the single BGP control plane and then drop packets
based on firewall rules. If you do this, any connection becomes unpredictable, and whether
you get or not to your destination is a hit or miss, even if there are multiple valid
paths to this network. If we use simple BGP then you only control the routes you advertise
to your neighbors, and the AS Path. You can’t tell them “this route is available, but only
if you are from 44.154/16, and if not, it doesn’t exist”. It’s all or nothing. If you
advertise it, then for a correctly functioning network you must forward to this
destination all traffic you receive for it, unconditionally.
If for convenience (and thats strictly convenience)
several networks
want to partake on such a common strategy, it is *their* task to find
some unused IP range and renumber there. Precedent here is the original
HAMNET, which did this because it could not or did not want to use the
old 44.130 german network.
As you can see above, creating a single BGP control plane across the entire network, that
works with every use case people want can be a problem. Not only does it require advanced
BGP knowledge and configuration, but it may not even be possible with most common
hardware. For example MikroTik is known not to support Extended Communities in the first
place.
This is partly
true: there is not a “single 44.128/10” but anyone can create their own network within
this space. However, if some of these networks don’t want to talk to everything else, then
this is working as intended, and they are by design not reachable. We hope that most of
the networks there would want to be interconnected and they can do so through radio links,
VPNs, Internet tunnels, satellites, or any other technology they see fit. One of them (but
not a mandatory or the only one) will be the ARDC-provided PoPs. They will act as one of
the many methods people could use to make sure that these networks talk to each other.
Now if one such network does not want to take part in this, then what do
you do ? Networking is a mutual understanding. Apparently therer seem
some difficulties between the dutch network and HAMNET. As long as
they dont get resolved, there will be no traffic exchange. meaning I as
an end user would have to have some sort of separate routing. This is
independent of which IP space is used. This is an
important distinction and something we still allow: the ONLY thing we say is that
44.128/10 MUST NOT be reachable from a non-44.128/10 address. By definition, that means
that no part of this space may appear on the Internet. Of course, the exception here is
that ARDC will still advertise it to combat hijacking, etc. but will DROP ALL traffic sent
to it. It will be dropped at the edge and not forwarded anywhere.
You are making this decision on top and over that of the people who
built and have run their respective networks for 25+ years.
You want to build such a network ? Fine. You find some unused space
and build it, or convince some existing ones to adopt that policy.
You need to learn sandbox etiquette. I appreciate you want to build a
bigger castle, but if you do that by trampling over the small ones built
by the other kids, you will be the bully. Nobody wants to play with
bullies.
You also destroy the other ones completely unnecessarily, since your
isolationist approach can be solved by an ACL. Ultimately it will be
anyhow because ARDC will want to announce the space to prevent
hijacking.
And telling them that they can move to another sandbox isnt cutting it
either. We can’t be
certain, I agree with what you say. What we can do is make it much better than it is right
now. We think that even if we can’t provide a perfect solution, we should still make steps
to improve the situation.
If you are in this 44.128/10 network, it’s extremely less likely for non-hams to reach
you. If you are connected to the Internet, and you advertise your space with BGP, it is in
fact *guaranteed* for non-ham traffic to reach you.
I think your fundamental problem is that you confuse network nodes,
which are identified by IPs, and vertices, or links. The legal mandates
pertain to the links, not to the nodes. it is the responsibility of a
licensed ham to make sure only suitable stuff gets sent over a radio
link. There is no legal mandate not to communicate, using the radio ID,
over a non amateurradio link. You could
argue that you could deploy ACLs or Firewalls, or any measure like that, and this would
help you only accept 44/8 traffic. But this is still worse: packets on the Internet today
can be spoofed. A non radio amateur could send a spoofed packet appearing from 44/8 from a
commercial ISP, and it would get through your firewall and possibly over your RF links
just fine.
That was true more in the past than now due to reverse-path protection
and so on. It does not make a difference - you could tune a transmitter
to any frequency all the time. If you forward such packets, you have to
take certain responsibilities. Mind you, youre not an end user then.
You would employ things like route verification, checking if the packet
arrived via the correct tunnel etc. pp.
If you are not prepared to handle this, you should not be running a
gateway. Moreover, if two 44/8 networks connect with
intermediate hops over the Internet, e.g.:
Yes, exactly, the ACL would drop these packets, but how do nodes #1 and #6 know that this
path drops certain packets? How do they know which packets are dropped? Do they have to
manually set up routes to an alternative path to route around these links if they want to
send some types of packets? Will they maintain a separate table of static routes by hand?
How often will they update it? What if the policy of a link changes and suddenly more
packets are dropped than before? Will they have to notice packet loss and take action to
route around this region of the network?
1. 44.1.2.3
2. 44.3.2.1
3. 192.0.2.15
4. 193.5.16.50
5. 44.4.6.7
6. 44.7.6.5
(Which I assume is what you want to do if you want to be on the Internet BGP and block
all incoming traffic from non-44/8 hosts)
Then hosts #3 and #4 that are non-hams can easily modify any and all traffic and cause a
transmission in a ham band of packets that are not from a ham. This is much more common
than you can imagine, and not always done maliciously. If I am node #1 and I do a
traceroute to node #6, due to the way the traceroute utility works, nodes #3 and #4 will
generate a new packet themselves (TTL Exceeded) and send it back to #2, who will forward
it over a ham link to #1. Node #2 probably did something illegal, as they transmitted a
packet that was not generated by a radio amateur (it’s a non-manned station / router of
Cogent / Telia / Hurricane Electric, …) over a ham band.
Yes. And an ACL would block those packets, and I'd see * * * in the
traceroute. That is not unusual. Though they may not be illegal in all
jurisdictions with more liberal third party rules. Now for the
use case where you want to be on the Internet with 44.0/10 addresses, but don’t want to
drop all incoming traffic that is not sourced from 44/8, then it is normal to expect that
all these port scans that people do will reach all IPv4 addresses in your network. Since
you know this is going to happen, you cannot use any radio link in a non-ham band, as it
is guaranteed that these stations will transmit a message over an amateur radio band that
is not from a licensed user. Even with a stateful firewall that only allows outgoing
connections, all responses you get from Facebook, Netflix, Altavista, etc. will be from a
non-radio-amateur and you will be transmitting them over a band illegally.
They *might* qualify as valid third party traffic. Someone sending an
to a loved one, for example when only ham radio links are available. You
can not know. The operator of the radio must make that decision.
The control knob for such things is called an access control list. Thats
a different concept than that of a route. If this law
applies to you, then you cannot use the ham bands to “communicate with the open
Internet”.
I think that we both agree on that.
I can not use an amateur radio link as part of
that communication. I can
still identify as a ham radio operator. Now moving to
the case of “communicating through the Internet”. Let’s examine that.
If the network does not appear via BGP on the Internet, then everyone has to set up
tunnels to interconnect everything. You can’t just send traffic to a commercial ISP and
have it delivered. It will be dropped by ARDC. This guarantees that the traceroute problem
I described earlier (and any other similar case) won’t happen. The only routers and
equipment that participates in this network is (or must be) owned and operated legally by
hams. You don’t rely on Internet infra and expect any guaranteed. This means that it is
almost guaranteed to not break the law or at least it is much much much much much much
more certain that such a system would not break the law than talking transparently
“through the Internet”.
You can easily build such infrastructure. In fact it has been done that
way for all the 25+ years I am in this game. There are a
lot of people that would have to renumber e.g. 200 hosts that we saw earlier, or possibly
more. But I think this is a testament that the current network is not easy to use: you may
have 20 users, but a single person was managing it and has to renumber everyone. If anyone
participating was an expect, they would simply have to renumber their own hosts, that
would be less than 200 for a typical setup.
I do not follow this logic.
Your statement that one person renumbering 200 hosts is more work than
20 persons renumbering 10 each. That is certainly not true, in fact it
is the opposite, youd have to coordinate those 200 people, and you would
have to assume these 200 people are fully competent -- that is the
opposite of your assumption in the first place... And the
current users force their world view upon future users and also a large part of this
network. I don’t think that it’s about who wins and who gets forced to submission. The TAC
tries to create space for both use cases so we all win, and we are all happy. Like any
rule in any civilized society, some people will have to make some sacrifices to co-exist.
They will have to understand why they need to do this, and then they will have to give the
others space to grow and have fun as well.
Yes, and their demonstrated contributions over decades give them the
right to do that. And no, this is not a win-win solution. Youre taking
some peoples toys away and force them to expend work. .
If people voluntarily *agree* to move and make this sacrifice, that is
one thing. But this appears not to be the case here. I am aware
that the bands are different for different regions of the world, but I do not want to make
the example complicated. I thought that it was enough for people to understand my point,
even if it’s region-specific, and that you can easily replace those numbers with your
local ones. I did not see a benefit in being extremely precise in something that is not
related to the point I try to make when the audience can probably understand it.
If you did not get my point because of the fact that two digits are off, then I can
rephrase the sentence with these digits as they stand around the world.
Now if you
changed those digits, we would now have a transceiver
transmitting on 146..148 in Region 1, which in some jurisdictions can be
illegal.
Secondly,
why would I not be allowed to listen to that amateur radio
repeater using my commercial all-band radio receiver?
First of all, it may be illegal in some areas of the world, e.g. I think the U.K. or
Greece. But I think that’s not your point ;)