20 Nov
2021
20 Nov
'21
5:59 p.m.
On 20 Nov 2021, at 21:56, Keaton VE5LPL via 44Net
<44net(a)mailman.ampr.org> wrote:
Ok, there is something you might not realize, I was aware of that, however when I wrote
my message I forgot. I've asked around what the terms are with ARIN that are so
unpalatable and have not gotten an actual response, could you clarify on that?
I am not personally able to quote specific clauses for you, but board members have looked
into this in some detail and their response was a most resounding “no” to ARIN membership.
Whilst RIPE membership was a “definite possibility”. I can ask for specifics if you are
particularly interested, or perhaps a board member could respond…?
I'm real skeptical of RIPE in regards to AMPRnet
switching over to registration with them. ARDC would be potentially be beholden to which
ever LIR has sponsored AMPRnet and to my knowledge ARDC cannot become an LIR as ARDC is an
American (non-profit). In addition to that I've heard rumors of RIPE being worse when
it comes to maintaining legacy status. Unless there are more specifics that could be
elaborated on, I would strongly encourage ARDC to go with ARIN.
Ok, so IF we moved to RIPE, we would not be signing an agreement with any LIR. We ARE able
to join RIPE ourselves and become an LIR - this has already been confirmed. It’s not about
where an organisation is registered so much, rather more where the address space will be
used, i.e. will it be used in the RIPE region. For example, the European HAMNET is the
single largest user of our address space I do not believe we would have any problem
convincing RIPE to let us become members.
73,
Chris - G1FEF
To my knowledge of the ARIN NRPM, It specifies ARIN
IPv6 as not the property of the organization that holds ARIN IPv6 space. No such clause
applies to IPv4 and the language which the NRPM uses in regards to IPv4 tacitly encourages
the presumption of IPv4 (and more so legacy IPv4) as the property of the organization that
holds it. Whereas as far as I'm aware no such clause or presumption exists.
Sincerely,
Keaton VE5LPL
A Saskatchewian ham who does stuff and things
https://kagl.me me(a)kagl.me
On 11/20/21 3:30 PM, Chris Smith via 44Net wrote:
Hi Keaton,
You make some valid points, however you are missing some critical information:
- We cannot create objects in ARIN’s IRR database as we don't have membership with
them.
- As we don’t have membership with ARIN we cannot participate in RPKI.
- Same issue using ARIN's API.
Our address space is legacy space, it has to be registered “somewhere” to work, i.e. with
one of the 5 RIR’s, and it happens to be with ARIN, but we are not ARIN members, therefore
we get non of the resources available to ARIN members. Nor do we want to sign an agreement
with ARIN as their terms are rather restrictive and could even result in us losing our
legacy status.
We (ARDC) have been looking into these issues, and we have some ideas as to how we may be
able to resolve them. One suggestion we have been investigating is to move our address
space to a different RIR, e.g. RIPE as their terms are far more palatable and we wouldn’t
have to sign away our legacy status.
BTW, the whois server isn’t faulty as such, it’s an intentional throttling mechanism,
however it could be handled a bit better and is on my TODO list.
73,
Chris - G1FEF
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net On 20 Nov 2021, at 20:56, Keaton VE5LPL via 44Net
<44net(a)mailman.ampr.org> wrote:
I think there are a few things that could be done in terms of BGP subnets.
Adding a property to Allocations and Assignments in the AMPRnet Portal that adds a column
to the table when browsing with the authorized ASN.
The fixing of whois.ampr.org
The addition of origin: properties, similar to regular RPSL (RFC2622) route records to
the aforementioned whois server using the ASN property.
Additionally in future with that property in the portal creating an ROA for the subnet
automatically. With that/those ASN(s) being added to the origin property in the whois as
mentioned. Making BGP routing of 44net more secure cause of the ROAs.
Note: for those not familiar with RPKI ROAs, it's a system of cryptography that allow
verifiable authorization of BGP announcements. Since none of the data ever sent is
encrypted, but simply signed with all the public keys, no data is not readable. It would
to my knowledge at least comply with Canadian amateur regulations in regards to
cryptography for over the air amateur transmissions.
Further using that same data to automatically generate route records in ARIN.
The addition of an ASN property to the portal with automatic ARIN route records and ROAs
could make significant strides in helping ensure announcements are consistent with
ARDC's goals. Whilst it won't fix abuse and commercial usage of AMPRnet. It will
help in the enforcement of policies and eliminate hijacking of AMPRnet space, where I have
several times reported such hijacks as I've come across them. As more and more
networks and internet backbones reject routes that have invalid ROAs with more doing so
over the years makes prefixes routable across the internet effectively impossible with an
ROA that mismatches.
In terms of the automation of this, I am not aware of how the backend of the portal
functions but no doubt it wouldn't require a massive overhaul to implement the
automatic ROA and route record functions I've mentioned. ARIN provides a method for
organizations to use an API to submit ROAs and route records automatically. I have used
the API myself and am working on an automated system for some of my other networks.
I would suggest that once the system has been put into place, that all allocatees that
hold a /24 or more receive an email stating they must submit the authorized ASN(s) by
$date via the portal. And at such time an AS0 (or UCSD's AS7377) ROA for 44.0.0.0/9
and 44.128.0.0/10 will be issued making their announcement invalid without submitting an
ASN and thus an ROA issued having their address space un-announceable via BGP.
I have mainly kept silent on this mailing list however I think that the addition of these
changes are the best way to go all things considered. I thought this would be relevant
considering the talk about abuse and how to control unauthorized announcements. And these
changes would make revoking BGP announcements on unresponsive parties possible, easy and
efficient for ARDC. Please be easy on me, I'm not that comfortable talking on mailing
lists. Just some suggestions that could help.
Thought this was going to be a shorter email. woops.
Sincerely,
Keaton VE5LPL
A Saskatchewian ham who does stuff and things
https://kagl.me me(a)kagl.me
On 11/20/21 12:01 PM, Steve L via 44Net wrote:
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net I know many of the BGP subnets are not listed on
the portal's network list.
I'm not sure if there is a reason for this or if it's some sort of
technical oversight. And on that note, perhaps if they can/should be
included, perhaps they can be noted as BPG?
On Sat, Nov 20, 2021 at 9:32 AM Chris Smith via 44Net
<44net(a)mailman.ampr.org> wrote:
>
>> On 20 Nov 2021, at 15:05, Ruben ON3RVH via 44Net <44net(a)mailman.ampr.org>
wrote:
>>
>> It is true that the 44.144 reverse zone is almost empty, however it - currently -
is only updated at end user's request.
>> There - currently - is no filtering on valid PTR records for internet access at
our border, however we are designing a new connectivity system for our users and can
incorporate that.
>>
>> Whether or not everyone should do that is up for debate imo and if the majority
should decide that and UCSD follows and makes it a rule of thumb then indeed everyone
should do that. Maybe discussion to be held with the TAC?
>
> I don't personally think it matters whether all allocated addresses have reverse
PTR records, so long as:
>
> 1) Anyone suspecting a violation of our terms of service reports it to abuse(a)ardc.net
<mailto:abuse@ardc.net> then it can be investigated and dealt with accordingly, and
>
> 2) Every individual responsible for using an IP address from ARDC is registered with
us, so we know who to contact.
>
> It is 2) that we have the problem with:
>
> When a group or organisation (or in some cases individuals) registers a block of
addresses then sub-allocates those addresses, often there is poor, or in some cases no
audit trail to an individual user. I’ve had to deal with issues, for example, with folk
setting up VPN servers then letting anyone use it without any vetting procedure or logs
being kept.
>
> This is a problem!
>
> There is a new API being developed that will allow user registration and
authentication, I would like to invite all parties that currently (or plan to)
sub-allocate ARDC space to contact me so we can discuss integration of the API with their
systems. We need a verifiable audit trail for users of our address space, this has to end
with the Responsible Person for any allocated IP address.
>
> 73,
> Chris - G1FEF
>
>
>
> _________________________________________
> 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