On Sun, Jan 31, 2021 at 2:55 PM G1FEF chris@g1fef.co.uk wrote:
On 31 Jan 2021, at 14:09, Nat Morris nat@nuqe.net wrote:
Which blocks did you report?
I don’t really want to go into specific details on an open mailing list. Suffice to say that keeping an eye on these and responding to problems keeps me busy enough!
Why not? what is to hide? hijack discussions happen on other mailing lists in the public.
So no more comment from yourself as the BGP co-ordinator on the prefixes in the report?
https://docs.google.com/spreadsheets/d/1nb4cTYVG1tm4HpxgPp7TAcgZ_qOlcej1whdv...
If you really do have the details on all these prefixes, there should be no reason you can't provide a statement on each, if it is an expected announcement, misconfiguration or hijackk
Without you being slightly more forthcoming in public, in my eyes it puts the whole integrity of co-ordinating AMPRnet BGP announcements in doubt.
Any explanation for these prefixes announced in the UK by AS61337, along side your portal prefixes, they are not documented at all in the portal:
Not all allocations appear in the public listing on the portal, for various reasons. Try the Whois server if you want by check specific prefixes.
Where is this publicly documented?
RADB is ok, but not sufficient for the future. A better investment would be for the ARDC to negotiation with one of the 5 RIRs for prefixes to be registered there, so we could all benefit from use of their RPKI trust anchors.
I can’t see that happening anytime soon I’m afraid, if ever, unless they drastically change their terms. We won’t do anything that risks losing our legacy status.
Have the ARDC approached each RIR and discussed this?
Having prefixes in RADB will not provide trust anchor functionality.
Agreed, and RPKI is something we understand is desirable, there are several ways it could be achieved and will be the focus for the TAC at some point in the future.
Which repo is this development taking place in?
The development is taking place currently and will be open sourced when it’s ready. In the meantime, if you want to have input on any features you would like to see, feel free to contact Rosy and/or myself.
I'd like to see planning for this taking place in the open, not closed.
I noticed the github.com AMPRnet Portal repo has been removed.
There was no point in it being there, we tried that route a couple of years ago and didn’t get anywhere.
Nat,
-- Nat
https://nat.ms +44 7531 750292
Sorry for the top post, I'm on my mobile.
The announcements and RPKI are both things I've looked at once and just sort of lost much care.. hopefully some people like yourself have submitted resumes and joined the TAC.
I do believe RIPE has a fair deal that would allow amprnet to stay legacy and do RPKI for perhaps their standard LIR fees if I'm remembering correctly.
The announcements for rather selfish reasons after being denied a wider prefix to announce more-specific as a way to steer traffic to a primary site in multihome setup (all still just experimental but your list shows some do get /22 even with experimental in their names). No hard feelings. I just play my NetOps games elsewhere.
The new portal is probably already in the works. I'd like that it allowed IRR entries for advanced users or a simple view with just description, AS, prefix. Our whois server should be registered at ARIN to allow clients to be referred to it. Our portal records can become IRR at the source..
Regards,
Scott
On Sun, Jan 31, 2021, 10:05 AM Nat Morris via 44Net 44net@mailman.ampr.org wrote:
On Sun, Jan 31, 2021 at 2:55 PM G1FEF chris@g1fef.co.uk wrote:
On 31 Jan 2021, at 14:09, Nat Morris nat@nuqe.net wrote:
Which blocks did you report?
I don’t really want to go into specific details on an open mailing list.
Suffice to say that keeping an eye on these and responding to problems keeps me busy enough!
Why not? what is to hide? hijack discussions happen on other mailing lists in the public.
So no more comment from yourself as the BGP co-ordinator on the prefixes in the report?
https://docs.google.com/spreadsheets/d/1nb4cTYVG1tm4HpxgPp7TAcgZ_qOlcej1whdv...
If you really do have the details on all these prefixes, there should be no reason you can't provide a statement on each, if it is an expected announcement, misconfiguration or hijackk
Without you being slightly more forthcoming in public, in my eyes it puts the whole integrity of co-ordinating AMPRnet BGP announcements in doubt.
Any explanation for these prefixes announced in the UK by AS61337, along side your portal prefixes, they are not documented at all in the portal:
Not all allocations appear in the public listing on the portal, for
various reasons. Try the Whois server if you want by check specific prefixes.
Where is this publicly documented?
RADB is ok, but not sufficient for the future. A better investment would be for the ARDC to negotiation with one of the 5 RIRs for prefixes to be registered there, so we could all benefit from use of their RPKI trust anchors.
I can’t see that happening anytime soon I’m afraid, if ever, unless they
drastically change their terms. We won’t do anything that risks losing our legacy status.
Have the ARDC approached each RIR and discussed this?
Having prefixes in RADB will not provide trust anchor functionality.
Agreed, and RPKI is something we understand is desirable, there are
several ways it could be achieved and will be the focus for the TAC at some point in the future.
Which repo is this development taking place in?
The development is taking place currently and will be open sourced when
it’s ready. In the meantime, if you want to have input on any features you would like to see, feel free to contact Rosy and/or myself.
I'd like to see planning for this taking place in the open, not closed.
I noticed the github.com AMPRnet Portal repo has been removed.
There was no point in it being there, we tried that route a couple of
years ago and didn’t get anywhere.
Nat,
-- Nat
https://nat.ms +44 7531 750292
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
On 31 Jan 2021, at 19:05, Scott Nicholas via 44Net 44net@mailman.ampr.org wrote:
Sorry for the top post, I'm on my mobile.
The announcements and RPKI are both things I've looked at once and just sort of lost much care.. hopefully some people like yourself have submitted resumes and joined the TAC.
I do believe RIPE has a fair deal that would allow amprnet to stay legacy and do RPKI for perhaps their standard LIR fees if I'm remembering correctly.
RPKI isn’t really the one and only solution to this problem, but it can certainly help a lot. It’s just that for various reasons, there’s no RPKI yet on the network. And even if there was, there are some decisions that could be made on how it’s deployed, that can affect whether it would work like this or not. IRR and other things can help as well, but like everything, it relies on people checking it.
A thing that can be done to prevent this retroactively is monitoring. There are some tools that can help in this, but most are created with the typical network in mind: I have some prefixes and an ASN (or more), and I want to see if some other AS advertises my IPs. What 44Net has is more like an RIR: I have a very large IP space, I allocate/assign/… parts of it to various entities that do stuff with it, and I just want to make sure that no “unallocated” space is being squatted. Of course, in this case, there’s a clear intervention path for hijackings, etc. but the thread tries to combat squatting: use of “unallocated” IP space that’s unauthorized.
I did a quick survey of the available tools and whether they can be used for something like that, despite not being the primary use case, and I even had a quick chat with the creators of ARTEMIS ( https://bgpartemis.org/ https://bgpartemis.org/ ) and it seems that some can be used for things like that: here’s a list of all “allocations”, and if you see anything else under 44/8 (or 44/9+44.128/10) that’s not in your config file, please alert me. I’ll also try to reach out to RIRs maybe to see how they all deal with that problem. It seems that we’re just in the middle so it’s not completely clear what can be done / it’s not a common problem to have. Maybe if we have some RIR staff here, they can chime in :)
The new portal is probably already in the works. I'd like that it allowed IRR entries for advanced users or a simple view with just description, AS, prefix. Our whois server should be registered at ARIN to allow clients to be referred to it. Our portal records can become IRR at the source..
The entire e-mail is my personal opinion, I am speaking on my personal capacity, and I have to admit that I don’t know anything about the new portal. However, I totally agree with you that it should be the source of truth for everything, and should be built with this in mind: route objects, ROAs, whois, squatting monitoring tools, hijacking monitor tools, … all depend on it for the single source of truth, and all use this, or frequent data dumps of it, to work.
Of course, things aren’t always that easy, and I understand that some times it can’t be possible to do this, but in my personal view we should at least try to go towards that direction.
Thanks, Antonis
I can’t see that happening anytime soon I’m afraid, if ever, unless
they drastically change their terms. We won’t do anything that risks losing our legacy status.
Have the ARDC approached each RIR and discussed this?
I will just throw this in here and say that the RIPE NCC does allow for "non-member service contract" which doesn't convert your legacy resources but does allow you to use RPKI.
https://www.ripe.net/manage-ips-and-asns/legacy-resources/ripe-ncc-services-...
I believe you might have to pay the fee though but unlike ARIN it doesn't scale with size, and it is currently 1400 EUR/year which seems totally reasonable for the ARDC.
An example of this is RGnet's /16, it is legacy status while being able to use RIPE NCC's RPKI services. https://apps.db.ripe.net/db-web-ui/lookup?source=ripe&key=147.28.0.0%20-...
-Cynthia
On Sun, Jan 31, 2021 at 4:04 PM Nat Morris via 44Net 44net@mailman.ampr.org wrote:
On Sun, Jan 31, 2021 at 2:55 PM G1FEF chris@g1fef.co.uk wrote:
On 31 Jan 2021, at 14:09, Nat Morris nat@nuqe.net wrote:
Which blocks did you report?
I don’t really want to go into specific details on an open mailing list.
Suffice to say that keeping an eye on these and responding to problems keeps me busy enough!
Why not? what is to hide? hijack discussions happen on other mailing lists in the public.
So no more comment from yourself as the BGP co-ordinator on the prefixes in the report?
https://docs.google.com/spreadsheets/d/1nb4cTYVG1tm4HpxgPp7TAcgZ_qOlcej1whdv...
If you really do have the details on all these prefixes, there should be no reason you can't provide a statement on each, if it is an expected announcement, misconfiguration or hijackk
Without you being slightly more forthcoming in public, in my eyes it puts the whole integrity of co-ordinating AMPRnet BGP announcements in doubt.
Any explanation for these prefixes announced in the UK by AS61337, along side your portal prefixes, they are not documented at all in the portal:
Not all allocations appear in the public listing on the portal, for
various reasons. Try the Whois server if you want by check specific prefixes.
Where is this publicly documented?
RADB is ok, but not sufficient for the future. A better investment would be for the ARDC to negotiation with one of the 5 RIRs for prefixes to be registered there, so we could all benefit from use of their RPKI trust anchors.
I can’t see that happening anytime soon I’m afraid, if ever, unless they
drastically change their terms. We won’t do anything that risks losing our legacy status.
Have the ARDC approached each RIR and discussed this?
Having prefixes in RADB will not provide trust anchor functionality.
Agreed, and RPKI is something we understand is desirable, there are
several ways it could be achieved and will be the focus for the TAC at some point in the future.
Which repo is this development taking place in?
The development is taking place currently and will be open sourced when
it’s ready. In the meantime, if you want to have input on any features you would like to see, feel free to contact Rosy and/or myself.
I'd like to see planning for this taking place in the open, not closed.
I noticed the github.com AMPRnet Portal repo has been removed.
There was no point in it being there, we tried that route a couple of
years ago and didn’t get anywhere.
Nat,
-- Nat
https://nat.ms +44 7531 750292
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Oh and I forgot to mention this too, Randy Bush (RGnet) also moved to the RIPE NCC from ARIN for the same reason, and there are slides from a talk here: https://iepg.org/2016-04-03-ietf95/160403.iepg-transfer.pdf
-Cynthia
On Sun, Jan 31, 2021 at 10:46 PM Cynthia Revström me@cynthia.re wrote:
I can’t see that happening anytime soon I’m afraid, if ever, unless
they drastically change their terms. We won’t do anything that risks losing our legacy status.
Have the ARDC approached each RIR and discussed this?
I will just throw this in here and say that the RIPE NCC does allow for "non-member service contract" which doesn't convert your legacy resources but does allow you to use RPKI.
https://www.ripe.net/manage-ips-and-asns/legacy-resources/ripe-ncc-services-...
I believe you might have to pay the fee though but unlike ARIN it doesn't scale with size, and it is currently 1400 EUR/year which seems totally reasonable for the ARDC.
An example of this is RGnet's /16, it is legacy status while being able to use RIPE NCC's RPKI services.
https://apps.db.ripe.net/db-web-ui/lookup?source=ripe&key=147.28.0.0%20-...
-Cynthia
On Sun, Jan 31, 2021 at 4:04 PM Nat Morris via 44Net < 44net@mailman.ampr.org> wrote:
On Sun, Jan 31, 2021 at 2:55 PM G1FEF chris@g1fef.co.uk wrote:
On 31 Jan 2021, at 14:09, Nat Morris nat@nuqe.net wrote:
Which blocks did you report?
I don’t really want to go into specific details on an open mailing
list. Suffice to say that keeping an eye on these and responding to problems keeps me busy enough!
Why not? what is to hide? hijack discussions happen on other mailing lists in the public.
So no more comment from yourself as the BGP co-ordinator on the prefixes in the report?
https://docs.google.com/spreadsheets/d/1nb4cTYVG1tm4HpxgPp7TAcgZ_qOlcej1whdv...
If you really do have the details on all these prefixes, there should be no reason you can't provide a statement on each, if it is an expected announcement, misconfiguration or hijackk
Without you being slightly more forthcoming in public, in my eyes it puts the whole integrity of co-ordinating AMPRnet BGP announcements in doubt.
Any explanation for these prefixes announced in the UK by AS61337, along side your portal prefixes, they are not documented at all in the portal:
Not all allocations appear in the public listing on the portal, for
various reasons. Try the Whois server if you want by check specific prefixes.
Where is this publicly documented?
RADB is ok, but not sufficient for the future. A better investment would be for the ARDC to negotiation with one of the 5 RIRs for prefixes to be registered there, so we could all benefit from use of their RPKI trust anchors.
I can’t see that happening anytime soon I’m afraid, if ever, unless
they drastically change their terms. We won’t do anything that risks losing our legacy status.
Have the ARDC approached each RIR and discussed this?
Having prefixes in RADB will not provide trust anchor functionality.
Agreed, and RPKI is something we understand is desirable, there are
several ways it could be achieved and will be the focus for the TAC at some point in the future.
Which repo is this development taking place in?
The development is taking place currently and will be open sourced when
it’s ready. In the meantime, if you want to have input on any features you would like to see, feel free to contact Rosy and/or myself.
I'd like to see planning for this taking place in the open, not closed.
I noticed the github.com AMPRnet Portal repo has been removed.
There was no point in it being there, we tried that route a couple of
years ago and didn’t get anywhere.
Nat,
-- Nat
https://nat.ms +44 7531 750292
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net