31 Jul
2021
31 Jul
'21
5:13 p.m.
Dear Antonios,
Am 30. Jul 2021, um 20:00:47 schrieb Antonios Chariton (daknob):
It is difficult to protect from malice.
The packet will be
dropped, possibly with an ICMP
administratively-prohibited or similar packet.
You see, here is where you can improve.
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.
Good. And we are in agreement that is the status quo for both 44.0/9 and
44.128/10 at the moment - that all of them are hams, and want to
communicate amateur radio related topics (as required by the current
ARDC TOS) ?
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.
This would be perfectly valid if people were to make the choice over
their IP now. It is not for those who have made their allocations some
30+ years ago. That is why "grandfathering" is such an important concept.
It recognizes the value of the work that other people have done.
It keeps the peace.
It is this concept we still get to keep 44 in the first place.
If you changed your proposal such that no _new_ allocations/direct BGP
shall be made in 44.128/10, everyone would likely somewhat more relaxed.
That is not to say that such a restriction is necessary.
- 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
That can be enforced, for each single network, using ACLs.
>> 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.
Such a space could be useful. If you had some unallocated space, that
would be no problem.
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).
We agree that this is what should happen. However, for any Internet-connected network,
there’s no guarantee it will always be true. 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?
Nowhere. Users could pick an alternative path using source
routing.
This has however been deprecated for the very security reason you
illustrate - it potentially allows to route around firewalls. As such,
there are no end user applications allowing this option to be even set.
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?
Once we have a sound definition for "end-user", I possibly can answer that
question. Sit back and reread the abstract of your proposal to see
why.
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?
Are you discussing the Internet BGP side ?
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?
The internet is not built that way, so we can not change it. In theory,
the capabilities were there (TOS based routing) but the global internet
has not seen fit to standardize on QoS guarantees and ressource.
In the network you directly control you can implement something like
this. For others, youre out of luck.
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?
No, not on the internet. You might invent or adapt a routing protocol,
but it will not be of much use since it is unlikely to get adopted on
the internet side. MultiTopology Routing might fit your ticket tho.
You can’t just advertise routes on the single BGP
control plane and then drop packets based on firewall rules.
If you consider
nullroutes or lack of IPIP encap destinations to be
firewall rules, that has been done on amprgw or mirrorshades for ages.
In fact your proposal still envisions that..
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.
That is a simplification and not true in the real world.
By your logic, the amprgw at UCSD who announces 44/8 would be somehow
required to deliver them. Which is somewhat difficult if there is no
registered and operational gateway....
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.
Too bad. Everybody will commend you for writing software to do that.
Keep compatibility and honor what others have been done before.
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.
But you do. The current state is that ARDC
forwards this traffic to
registered gateways via the IPIP mesh.
Unfortunately mechanisms like uRPF that you mention
only work to protect others from your network.
And they protect you if you receive
packets from the wrong interface.
For example, not from the proper IPIP tunnel. You could also mandate an
AH header for any AMPRnet packet, but for this proposal to get traction
is somewhat difficult, too.
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?
Yet you take away the authority to define internet connection policy
from the individual networks, graciously offering them to renumber. Next
year a new proposal will come along. Youre going to ask them to renumber
again ?
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?
You see, valid questions. But too far reaching. You are trying to encode
things in the address. You'll never be able to do this in such a way.
Next year someone could propose a pure radio only link, now what ?
I plan running parts over the net via satellite. Latency will be very
harmful for Echolink. Do I get another set of possible IP space
combinations for that purpose ?
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) ?
see above.
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.
And they would have known someone to set this up for them. Otherwise
they wouldnt have got that mikrotic on the first place...
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.
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%
;) 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.
That is perfectly OK, but you have to make such room first, and not to
*decree* that there is such room available. Part of my beef with the
board over the sale of the IP space was their repeated public denial of
any, let alone meaningful use of this space, despite hamnetdb
documentation. It was completely unnecessary not to acknowledge that
HAMNET was there, given that mutually agreed provisions for renumbering
were made (which I understand they were, probably long before).
But this causes resentment and uncertainty --- if I invest lots of time
into an innovative IP setup tomorrow, what is the chance that in one years
time Ill be forced to renumber ?
I have this particular problem in a commercial setting right
now. They offer me a cheap replacement of the server hardware of my
rented server because they want to get rid of the old one for
reliability. The offer is financially advantagous for me. The downside
is I would get a new IP address. That forces me to change dozens of
ACLs, DNS entries and other configurations. Calculating the time to do
so *easily* outweights any financial advantage...
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.
Maybe AMPRnet should use a different IGRP then ?
One that still has to be invented ? You know, advancing the art and
stuff ?
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.
You force renumbering to match policy. You should offer that, but not
force it. In the meantime, maybe those policy attributes should be
collected when registering a gateway ?
73s,
Mario
--
Mario Lorenz Internet: <ml(a)vdazone.org>