Curtis Spangler, N6ECT, has kindly created an archive of documents and
photos from amateur radio packet networking history. The Pacific Packet
Radio Society was a small group of hams in the San Francisco Bay Area,
led by Hank Magnuski, KA6M, in the 1980s. Hank's KA8M-1 repeater talked
half duplex at 1200 bits/sec with VADCG Terminal Node Controllers
throughout the Bay Area. A good chunk of the history is here, including
how Hank originally requested and received the 44net IP address
allocation:
http://www.pprs.org/
In particular, in this page, Hank wrote on 1981-06-10 to Paul Rinaldo,
W4RI, thanking him for information about the INTERNET protocols, and
reported:
http://www.pprs.org/bulletin/pages/page003.html
"In looking over this document the application of the standard is
fairly straightforward except for one area, and that concerns
addressing. A four byte source or destination address is specified,
and that does not meet our needs. The first byte of this four byte
field represents a network, and about 40 of the possible 256
combinations are already assigned. I attempted to contact the author
of the document to see if a number could be assigned to an amateur
radio experimental network, or to see if there already was a number
for personal computing networks, but John [sic] Postel was out of town,
and I didn't get an answer to my question. It seems clear that 256
networks is somewhat limiting, and that some future revision of the
standard will have to expand this field."
(As we now know, figuring out how to allocate network addresses, and
route packets among them, is not as simple as it seemed back then!)
Page 13 reports, in a 1981-12-06 page of notes about how to build
packet repeaters and networks:
http://www.pprs.org/bulletin/pages/page013.jpg
"Direct connect stations using IP protocol can use "NET 00 00 00" as
the network node address. NET is decimal 44."
John Gilmore, W0GNU
Hi there
My gateway (44.138.1.1) tunnel get the commercial IP host name from no-ip.com and the UCSD router use this name to resolve the IP and make tunnel to it since it use dynamic IP
every time that this hos is in some reason not resolvable the UCSD takes it out from the routing table and i get no route to it anymore
Even when the host is resolvable again
the only solution is to write Chris and ask him to fix it for me
Has anyone seen this thing at his system ?
Is there any thing i can do to make the route back ?
Or (prefered) can any mechanism be add to ucsd that when a certain host get resolved again the route will come back without any intervention by human ?
Any help welcome ..
Regards
Ronen - 4Z4ZQ
http://www.ronen.org
Sorry, I just realized that I broke threading when I replied to you Pierre,
Now we really are getting to where there should be layer4 and Layer5
firewalls. Looking at this your proposal actually gives a false sense of
security by segregating. Why do I say that? Modern web browsers will
attempt to use https first if not explicitly told to. This was
determined by their coders to be a good thing because it encourages
privacy on the Internet, and few places of the world limit encryption.
Of course most if not all amateur radio operators are prohibited from
"obscuring the meaning" and therefore using encryption. We could walk
down that rabbit hole, but lets not.
Instead lets walk down the handshaking rabbit hole. If I want to do SSL
with a website I access it at port 443. If I don't I access it at port
80. Therefore if I do a L4 firewall rule at the gateway that feeds rf
link that rejects any traffic to or from port 443 I've prevented the
handshake and no encryption will follow.
SMTP can be a little trickier if I have enabled the libraries on my
device for SSL, it's possible that it could issue a start tls command
and negotiate a encrypted feed over what would normally be a unencrypted
port.
There are two solutions to this. One is to install a application aware
next generation firewall (Palo Alto makes the one I use), which looks
inside the packets at the actual data flows and classifies what the
actual protocol being used is rather than just the port (socket address)
that is being passed. With a Palo Alto I can drop or reject all traffic
that uses encrypted protocols. Once dropped I'm safe.
But many don't have these firewalls, and that's understandable. Instead,
as the licensed radio operator, who knows the rules, they should learn
how to disable the encrypted protocols running on their devices that
will be problematic for these reasons.
There is no universal solution, because if I just say "oh this network
is unencrypted" doesn't mean that if I have setup a web server with a
ssl port that someone else on the network won't access it over chrome
and accidentally end up with a encrypted feed.
Being on the network is only the first step, administrating our devices
to comply with the rules is a ongoing and important thing.
Fortunately, most devices either have limited packet filtering built in,
or can have features like SSL/TLS disabled in their settings. Which
makes this a moot point.
For my RF devices I make sure that their backhaul link blocks known
points of encryption. Because that is the purpose of a firewall, and
proper network stewardship.
Just like I filter Bogons and known bad actors at the edge of my network
connections.
Sorry for the novel, but I believe in trying for a universal solution,
many are missing why the solution won't cure the problems.
Best regards,
Bill Buhler - AF7SJ
On 8/17/2021 12:30 PM, pete M wrote:
> Bill, yes making rules like you just told will get rid of all the
> traffic that is not 44.
>
> But it does not fix some issue that ham will have with the normal ham
> to the world exchange of data.
>
> There are 2 use case that we seen. One being ham talking to ham and
> the world and earing from ham and the world.
>
> The second use case is ham talking to ham, end ham earing from ham only.
>
> In the explanation you gave this would fit only the first use case and
> the local guys would firewall what he want or not.
>
> But when we come to the ham to ham only use case we fall short. On
> many network we cannot allow to have encryption on RF. Now let's say
> someone put a web site on a 44 address and enable https. The ham on RF
> want to connect to it. He open his browser and he is now actively
> passing encrypted data over the air.
>
> What will the 44.128/10 segment will provide is to make sure that
> everyone on that segment won't encrypt anything and won't put someone
> else into a bad situation
>
> Pierre
> VE2PF
>
Fellow radio amateurs, I am writing to you on behalf of the ARDC TAC, which I represent.
Those of you that were on our Community Call last Saturday may remember that I promised you we would share our first proposal with the community. A few days after that, I am happy to send that to you for your review, feedback, comments, questions, and information!
You can find our 5-page PDF here: https://pdf.daknob.net/ardc/tac128.pdf <https://pdf.daknob.net/ardc/tac128.pdf>
The title is "ARDC 44.128/10 Allocation Proposal” and it briefly explains what we propose to do with the IPv4 space of ARDC. It is based on careful consideration, planning, and actual research[1] performed on the IP network and the Portal allocations.
Since the TAC does not have any authority on the IP (or any other) resources of ARDC, and we only have an advisory role, we end this document with a proposed resolution we intend to submit soon to the ARDC Board of Directors, where we urge them to vote and approve some key things required for us to be able to achieve what is described.
We believe that the TAC represents the community and the 44 Net users, so we created this document and post it here in advance, with the purpose of being able to answer your questions, collect your feedback, and hear from you. This is why we briefly explain the situation in about 4 pages, and then we end with the resolution we want the ARDC Board of Directors to approve.
I hope you like it, and I remain at your disposal for anything you may need.
Antonis
Links:
[1] - https://blog.daknob.net/mapping-44net/ <https://blog.daknob.net/mapping-44net/>
Pierre,
Coming from twenty years helping various companies connect to the
Internet, I find your view of firewalls to not match my own. A firewall
can filter at any layer of the network stack (depending on the
firewall), but layer 2 and layer 3 firewalls are extremely common...
Therefore I look back on you're trying to firewall off a bunch of
machines at L3 from the internet at large, while allowing them to speak
to the other 44 net machines.
I believe we would be better served if that is your goal to write the
following rules in whatever ACL / Firewall language your platform allows
at the network ingress:
Source address 44.0.0.0/9 to any (or more specifically 44.0.0.0/9 &
44.128.0.0/10 if you want those extra rules).
Source Address 0.0.0.0/0 drop to any
There now your input doesn't allow non 44 net traffic to propagate
through your network....
OK, I'm being a little bit simplistic here, but this is what we do in
the real world. It is a pure L3 solution. Just like I would do L2
filtering (MAC address level) if I was connected to a ISP on a broadcast
medium and only wanted to talk with my upstream provider.
In the commercial space groups will publish their addresses mutually
with each other to whitelist at the firewalls. I think if there are
substantial groups who want to form private networks AMPR being a
clearing house of that information is totally appropriate, but it should
be up to those groups to control their ingress and egress points, not
the network itself. Its job should be to build the backbone and enable
connectivity between hams without conflicting address spaces.
I have come to view this as a issue a premature optimization. We know
where we are now, we know some of the struggles that certain groups are
having. But top down solutions tend to have unintended consequences, and
become rapidly brittle. Letting groups design their own ingress / egress
rules allows them to rapidly iterate. Providing them out of band
additional information such as lists of networks that only want to speak
to hams, or lists of un-allocated blocks will give them the flexibility
to design their rules, and the rest the ability to keep doing what they
need to do.
Finally, we are still seeing memory and processing power increase with
each generation of devices, so we are in no danger of our ham radio
network exceeding the basic capacity of most consumer devices, even ones
that are on the used market.
Best regards,
Bill - AF7SJ
On 8/16/2021 1:00 PM, 44net-request(a)mailman.ampr.org wrote:
> Send 44Net mailing list submissions to
> 44net(a)mailman.ampr.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mailman.ampr.org/mailman/listinfo/44net
> or, via email, send a message with subject or body 'help' to
> 44net-request(a)mailman.ampr.org
>
> You can reach the person managing the list at
> 44net-owner(a)mailman.ampr.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of 44Net digest..."
>
> Today's Topics:
>
> 1. Re: A new era of IPv4 Allocations : Agree (pete M)
> 2. Re: A new era of IPv4 Allocations : Agree - No I don't (pete M)
> 3. Re: A new era of IPv4 Allocations : Agree - No I don't (pete M)
> 4. Network layer easy explaination. A must read. (pete M)
> 5. Re: A new era of IPv4 Allocations : Agree (Rob PE1CHL)
>
> _______________________________________________
> 44Net mailing list
> 44Net(a)mailman.ampr.org
> https://mailman.ampr.org/mailman/listinfo/44net
https://insights.profitap.com/osi-7-layers-explained-the-easy-way
There are a lot of people comming with solution to the problem that the TAC want to fix.
They are comming with solution that are not at the same layer level. This break networking communication.
Using a layer 4 software to fix a layer 3 problem wont work. Same as using a layer 3 software wont fix a layer 4 problem.
All the layer need to work as intended for a full network to work.
TCP and UDP are at level 4 Firewall acts on layer 3 and up.
IP is at layer 3 only. routing is a layer 3 task. You can use a firewall to slect what packet pass or not pass up to a point. But at the routing level if you are a link for multiple links. how can you firewall something and not brake routing? how do you make sure that the netwokr you filter with the firewall is really not ok to pass? Judgement call?
But at the same time what if the user ask you to do it. One thing is clear, on an open network architecture the local node that pass 3rd party traffic is not to filter any traffic. this woudl break the routing and prevent actual data that to pass on the route that the layer 2 and 3 decided to be the best. But again how to fix a demand of a use that want to have some traffic filtered from the begining?
By creating a non open network. And that is the ONLY REAL solution to prevent the breaking of any route at the layer 3 and make sure that the trafic is ligit. All the route are pointing to the non open network and all the node pass all the traffic that need to pass trough them. Client at the end put firewall to prevent some traffic to reach them but they are end of lines not transporting data to 3rd party.
I hope this will help removing some of the fog that flow all over the networking talk.
Pierre
VE2PF
Hi Everyone,
I was running a JNOS BBS a few months ago and I was able to connect to
other nodes on the 44net. I had to take JNOS offline for a few months while
some changes to the network were made. No changes were made to the JNOS
node, though. The gateway IP did change and it was updated on the AMPR
gateway. I have brought the JNOS back up, but now I am not able to ping any
44net node. I am able to ping other servers like google.com.
I performed a packet capture and I see that the ICMP request is being sent
from JNOS, but the ICMP response is not being received.
jnos> ping 44.135.92.10
jnos> Resolving 44.135.92.10...
jnos>
jnos>
jnos> ping google.com
jnos> Resolving google.com... 172.217.14.110: rtt 21
It is the same story with other nodes as well.
Any recommendations?
73, de KG7UJH
Christopher Kelley
Greetings,
I have been a ham for over 50 years (though not recently active), and have
been involved with networks for about 20, so I am following the recent
discussions with great interest.
While I can understand in general terms what might be done with hybrid
Internat-ham radio links, I would find it very useful to see examples of
what other hams are currently doing with them. Would it be possible to have
a few hams do short write-ups on what they are doing, and put them on the
ARDC home page? Right now, it seems heavily skewed towards how to set up
the networking end of things (which, of course, is very important, and
something that hams new to networking could use some help with), with not
much attention given to "Why would I want to do this?"
Thanks, and 73,
Lynn Grant
N8AF / V31LK
