44net

44net@mailman.ampr.org

3188 discussions

Start a nNew thread

ampr.org tls cert expired

by Scott Nicholas

Look's like the Let's Encrypt cert on ampr.org isn't running on a crontab :) -Scott

5 years, 5 months

Re: [44net] NSP bugging me to use RPKI for my /24 grant

by Erik Seidel

Tom, It sounds like you're referring to delegated RPKI: https://www.arin.net/resources/manage/rpki/delegated/ I assume this could be done, but it would still have to be set up through ARIN first - just as in the case of hosted RPKI. Regards, Erik KE5SAI On Wed, Jun 10, 2020 at 11:26 AM Erik Seidel <erik(a)znsl.us> wrote: > > Tom, > > It sounds like you're referring to delegated RPKI: > > https://www.arin.net/resources/manage/rpki/delegated/ > > I assume this could be done, but it would still have to be set up > through ARIN first - just as in the case of hosted RPKI. > > Regards, > > Erik > KE5SAI > > On Wed, Jun 10, 2020 at 11:21 AM Tom Cardinal via 44Net > <44net(a)mailman.ampr.org> wrote: > > > > Cynthia, > > > > I only listed them as an example, my point was a having our own CA > > signed by a signing org that is trusted by RIRs. If that be ARIN then > > so be it. More importantly though, as you know, we have a legacy > > allocation. In my opinion we are equal to an RIR but with the ability > > to make global allocations from the 44.0/9 and 44.128/10 space. > > > > --ton/n2xu 44.98.63.0/29. > > > > > > On 6/10/20 7:38 AM, Cynthia Revström via 44Net wrote: > > > Tom, > > > > > > As Q already mentioned, Thawte or Comodo (now called Sectigo) are for Web > > > PKI, not RPKI, they have nothing to do with this. > > > And not to mention the huge requirements something like that would have, > > > and enormous fees. > > > > > > Not entirely sure what you mean by "act as an IR"? > > > > > >> They would have to accept it much like ARIN and RIPE trust each other > > > In the context of RPKI, ARIN and RIPE NCC do not trust each other, they > > > have their own Root CAs (TALs), which are independent of each other. > > > An RPKI validator has to use both of them. > > > > > > - Cynthia > > > > > > > > > On Wed, Jun 10, 2020 at 2:33 PM Q Misell via 44Net <44net(a)mailman.ampr.org> > > > wrote: > > > > > >> CA's like Thawte or Comodo won't work for this, they're for web PKI not > > >> resource PKI. > > >> The 44.0.0.0/9 cert would have to be signed by one of the RIR's trust > > >> anchors (probably ARIN since they have 44.0.0.0/8 assigned to them) > > >> > > >> Thanks, > > >> Q > > >> > > >> > > >> On Wed, 10 Jun 2020 at 13:28, Tom Cardinal via 44Net < > > >> 44net(a)mailman.ampr.org> > > >> wrote: > > >> > > >>> I've been monitoring this discussion. Since our space was allocated by > > >>> Jon Postel, initially around 1981 (ish), why can't we create our own > > >>> trust model (CA signed by a CA signing agency like Thawte or Comodo as > > >>> examples) and act as an IR for the 44.0/9 and 22.128/10 space ourselves > > >>> and publish that trust model to the RIRs? They would have to accept it > > >>> much like ARIN and RIPE trust each other. Then RPKI would work for > > >>> AMPRNet and AMPRNet would control it's own destiny. > > >>> > > >>> --tom/n2xu 44.98.62.0/29 > > >>> > > >>> > > >>> On 6/2/20 2:34 PM, Jonathan Lassoff via 44Net wrote: > > >>>> I can sympathize with the sentiment that RPKI and widespread RPKI > > >>>> adoption in its current form will really lock out and disenfranchise > > >>>> smaller network operators. > > >>>> > > >>>> Now, *more than ever*, we need to enable an Internet that any > > >>>> organization (a natural person, a registered entity, a hackerspace, > > >>>> etc.) can connect to, uniquely address itself, and begin exchanging > > >>>> traffic. > > >>>> > > >>>> In order to enable such an open system to function, we also need ways > > >>>> of ensuring that unicast addresses are unique and that there is some > > >>>> public, verifiable way of claiming ownership of IP space. Without > > >>>> this, the entire network is open to disruption and abuse by almost any > > >>>> operator. It's amazing we have gotten so far on the good will of most > > >>>> operators. > > >>>> > > >>>> The RIR model of lawyers, paperwork, and public databases works for a > > >>>> lot of people and organizations. IRR was the first step, but it was > > >>>> complex and a bit clunky to use. I see RPKI for Origin Validation as > > >>>> just the first/next step of extending this model of trust and > > >>>> numbering resource ownership into the routing protocol space more > > >>>> directly. > > >>>> From a technical standpoint, this logical extension of systems makes a > > >>>> lot of sense and I don't have a problem with it. > > >>>> > > >>>> For commercial network operators, a RIR registration is just the cost > > >>>> of doing business. > > >>>> But for many small nonprofits, regional amataur radio/network > > >>>> operators, or individuals, a few thousand dollars/euros a year is a > > >>>> lot of money that makes Internet independence out of reach. > > >>>> They end up having to resort to the hegemony of their local incumbent > > >>>> monopoly and chain themselves to the whims of their upstreams and > > >>>> regulators. > > >>>> > > >>>> I suspect many legacy resource holders find themselves in a similar > > >>>> limbo-state of not wanting to participate in the RIR model and pay > > >>>> money for essentially nothing. > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> Echoing some similar earlier sentiments to want to create a CA for > > >>>> legacy address holders: How feasible would it be to create something > > >>>> RIR-like, but noncommercial? > > >>>> A place for legacy address holders to coordinate and register > > >>>> resources seems like a natural fit. If we're going to operate a > > >>>> database of ROAs, we're going to need some database of address space > > >>>> ownership. > > >>>> For 44net use cases, this seems really straightforward, since we have > > >>>> the Portal to draw from. But for other organizations, it gets a bit > > >>>> more complicated to do properly. Given some random email > > >>>> address/account in some hypothetical legacy RIR, how can we really > > >>>> validate that they're authorized to take actions on behalf of some > > >>>> organization? > > >>>> To take some random examples from the IANA IPv4 list: DISA, USPS, > > >>>> AT&T, Apple, etc. Doing this right is going to take some process, > > >>>> record keeping, and well.... work. > > >>>> With this context, I can see how a lot of RIRs go commercial. However, > > >>>> with a bit of automation, good documentation and records, and some > > >>>> dedicated volunteers, this seems like a really doable/achievable thing > > >>>> in the netops community. > > >>>> > > >>>> I would be curious to know if anyone else shares these views/dreams > > >>>> and would like to chat about it. > > >>>> > > >>>> Stay safe and sane out there. > > >>>> > > >>>> Cheers, > > >>>> jof > > >>>> > > >>>> On Tue, 2 Jun 2020 at 08:18, Job Snijders via 44Net > > >>>> <44net(a)mailman.ampr.org> wrote: > > >>>>> Thomas, > > >>>>> > > >>>>> You say > > >>>>> > > >>>>> On Tue, Jun 2, 2020, at 04:17, Thomas Jones - KG5ZI /8 via 44Net > > >> wrote: > > >>>>>> DO NOT participate in RPKI! > > >>>>> And ... > > >>>>> > > >>>>>> We should be protecting our Internet!! Just saying... > > >>>>> What are you really saying? These statements seem at odds with each > > >>> other. > > >>>>> How do you protect your internet? Maybe I can learn some tricks from > > >>> you? > > >>>>> Kind regards, > > >>>>> > > >>>>> Job > > >>>>> _________________________________________ > > >>>>> 44Net mailing list > > >>>>> 44Net(a)mailman.ampr.org > > >>>>> https://mailman.ampr.org/mailman/listinfo/44net > > >>>> _________________________________________ > > >>>> 44Net mailing list > > >>>> 44Net(a)mailman.ampr.org > > >>>> https://mailman.ampr.org/mailman/listinfo/44net > > >>> > > >>> _________________________________________ > > >>> 44Net mailing list > > >>> 44Net(a)mailman.ampr.org > > >>> https://mailman.ampr.org/mailman/listinfo/44net > > >>> > > >> _________________________________________ > > >> 44Net mailing list > > >> 44Net(a)mailman.ampr.org > > >> https://mailman.ampr.org/mailman/listinfo/44net > > >> > > > _________________________________________ > > > 44Net mailing list > > > 44Net(a)mailman.ampr.org > > > https://mailman.ampr.org/mailman/listinfo/44net > > > > > > _________________________________________ > > 44Net mailing list > > 44Net(a)mailman.ampr.org > > https://mailman.ampr.org/mailman/listinfo/44net

5 years, 5 months

Modem

by Ken Adams

Hi Guys Looking for a UK compatible modem/router/DSL to use with TalkTalk. I can then switch off ALL firewall nat and filtering and pass ALL traffic through to my pfSense router/firewall and allow the usual 4 and 93 and ICMP. Waiting with hope in the heart 73 de Ken (G7OAH)

5 years, 5 months

NSP bugging me to use RPKI for my /24 grant

by Jeremy Cooper

Hello all, In 2018 I requested and received a /24 allocation and permission to announce it via BGP. My ISP/NSP, MonkeyBrains.net, very graciously agreed to route it to my house as part of my normal residential service. (Quite amazing!) Now, however, they’ve sent me an unusual request (but they are excited about it): can I please setup RPKI for my IP allocation, authorizing them (MonkeyBrains) permission to advertise the block? Full quote below: > Hi Jermy, > > We advertise a /24 for AMPRNET. Please setup a ROA record on ARIN authorizing us to advertise that block. (We just learned how to do this for our IPs yesterday and are exctied about RPKI. > > > > If you haven't set up RPKI for your IP allocations, here are the steps in a nutshell: > > create SSL key > upload to ARIN > Create ROA (image below) > Thanks, > > Rudy > > HOW-TO on ARIN: > https://www.arin.net/resources/manage/rpki/hosted/#roarequestkeypair <https://slack-redir.net/link?url=https%3A%2F%2Fwww.arin.net%2Fresources%2Fm…> > I don’t think this is going to work as I don’t _OWN_ my block. It is licensed to me for a 5 year period. As such, there’s no record of my allocation with ARIN, and hence, nothing that I can assign. Do any of you network gurus have a sufficiently technically advanced response I can give the ISP for their request? 73, -Jeremy Cooper

5 years, 5 months

pfSense

by Ken Adams

Has anyone got ampr 44net ipencap working.? I have a node running Linux/uronode/ax25/netrom/fbb and ampr-ripd. This then feeds into the pfsense box. AX25/Netrom/fbb are all working fine. I think I have IPENCAP on the firewall directed to the Node 198Lan address. All help very happily received. Rgds Ken (G7OAH)

5 years, 5 months

Re: [44net] 44Net Digest, Vol 9, Issue 54

by Rob Janssen

> That vulnerability sounds quite like what alot of us have been saying for years....hummm...73,- Lynwood KB3VWG True! I have mentioned many times that it is best to filter incoming protocol-4 based on a list of valid gateway addresses, and also to filter traffic from those tunnels with filters allowing only AMPRnet addresses (except from amprgw when you use that to receive traffic from internet). We can only hope that this "discovery" and CERT registration will not lead to broad "protocol 4 blocks" by ISPs and transit providers, as has happened with NTP traffic when that was the topic. Maybe another motivation to move from the IPIP mesh to something more modern? Rob

5 years, 6 months

Internet access

by Edward Young

Charles, thank you for confirming muy membership in the group. I am very interested in using a ham radio to connect to the internet. What equipment do I need and what do I need to do?

5 years, 6 months

Mailing list

by Edward Young

I seem to be on the mailing list but I cannot post anything. Can you send me a link to confirm my membership? Edward Young

5 years, 6 months

Re: [44net] 44Net Digest, Vol 9, Issue 54

by lleachii

That vulnerability sounds quite like what alot of us have been saying for years....hummm...73,- Lynwood KB3VWG null

5 years, 6 months

CERT Vulnerability Note VU#636397: IP-in-IP protocol routes arbitrary traffic by default

by Chris KE2A

Reference: https://kb.cert.org/vuls/id/636397 OVERVIEW IP Encapsulation within IP (RFC2003 IP-in-IP) can be abused by an unauthenticated attacker to unexpectedly route arbitrary network traffic through a vulnerable device. Description IP-in-IP encapsulation is a tunneling protocol specified in RFC 2003 that allows for IP packets to be encapsulated inside another IP packets. This is very similar to IP GRE VPNs and IPSEC VPNs in tunnel mode, except in the case of IP-in-IP, the traffic is unencrypted at all times. As specified, the protocol unwraps the inner IP packet and forwards this packet through IP routing tables, potentially providing unexpected access to network paths available to the vulnerable device. An IP-in-IP device is considered to be vulnerable if it accepts IP-in-IP packets from any source to any destination without explicit configuration between the specified source and destination IP addresses. This unexpected Data Processing Error (CWE-19) by a vulnerable device can be abused to perform reflective DDoS and in certain scenarios used to bypass network access control lists. Because the forwarded network packet may not be inspected or verified by vulnerable devices, there are possibly other unexpected behaviors that can be abused by an attacker on the target device or the target device's network environment. IMPACT An unauthenticated attacker can route network traffic through a vulnerable device, which may lead to reflective DDoS, information leak and bypass of network access controls. -- 73, Chris KE2A

5 years, 6 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net