MERIT Darknet Experiment and RPKI alerts
A number of you have reported that your are getting alert emails from the Resource Certification (RPKI) service. The alerting system can warn you if some of your certified address space has the RPKI validity "Unknown" or "Invalid". The warning people are receiving will look something like this:
There are alerts about BGP announcements with your certified address space in the Resource Certification (RPKI) service.
These are BGP announcements with your certified address space that have the status Unknown. You should create a ROA for each authorised announcement to make them Valid:
AS Number Prefix AS237 2a00::/12
You are able to fix and ignore reported issues, change your alert settings, or unsubscribe by visiting http://certification.ripe.net/.
In this case, the alert is triggered for LIRs who hold an IPv6 address block, but do not announce (all of) it. The *unannounced* address space is being "hijacked" by MERIT as part of its darknet experiment: http://www.ripe.net/internet-coordination/news/merit-to-temporarily-use-2a00... If you have received the alert, your certified, unannounced IPv6 prefix is hijacked by AS237 because 2a00::/12 is the most specific announcement that overlaps with it. There are two things you can do: 1. Announce *all* of the IPv6 address space you hold. This way AS237 cannot hijack your prefix with a less specific announcement. 2. Suppress the alert for the announcement from AS237 in the Resource Certification (RPKI) system in the LIR Portal. Please note that the RPKI Alerting system uses the RIPE NCC Route Collectors to trigger the errors, so there may be slight differences between what they see and what you actually do. If you have any questions, please do not hesitate to contact me. Kind regards, Alex Band
On 11/9/12 10:33 AM, Alex Band wrote:
If you have received the alert, your certified, unannounced IPv6 prefix is hijacked by AS237 because 2a00::/12 is the most specific announcement that overlaps with it. There are two things you can do:
Hi Alex, thank you for your advice. Anyway, this behavior was easily foretold in a previous message posted on the list ipv6-wg about 20 days ago. Thanks -- antonio
Overall, I think this is very dangerous approach, and the wrong way to start with. There might be very good reasons, why a full block of (IPv6) addresses, or a subset of, ist not (yet) globally visible. Announcing/Hijacking those addresses may seriously interfere with local tests or pilot deployment. IMHO this should be strictly opt-in, instead of opt-out! Wilfried. Alex Band wrote:
A number of you have reported that your are getting alert emails from the Resource Certification (RPKI) service. The alerting system can warn you if some of your certified address space has the RPKI validity "Unknown" or "Invalid".
The warning people are receiving will look something like this:
There are alerts about BGP announcements with your certified address space in the Resource Certification (RPKI) service.
These are BGP announcements with your certified address space that have the status Unknown. You should create a ROA for each authorised announcement to make them Valid:
AS Number Prefix AS237 2a00::/12
You are able to fix and ignore reported issues, change your alert settings, or unsubscribe by visiting http://certification.ripe.net/.
In this case, the alert is triggered for LIRs who hold an IPv6 address block, but do not announce (all of) it. The *unannounced* address space is being "hijacked" by MERIT as part of its darknet experiment:
http://www.ripe.net/internet-coordination/news/merit-to-temporarily-use-2a00...
If you have received the alert, your certified, unannounced IPv6 prefix is hijacked by AS237 because 2a00::/12 is the most specific announcement that overlaps with it. There are two things you can do:
1. Announce *all* of the IPv6 address space you hold. This way AS237 cannot hijack your prefix with a less specific announcement. 2. Suppress the alert for the announcement from AS237 in the Resource Certification (RPKI) system in the LIR Portal.
Please note that the RPKI Alerting system uses the RIPE NCC Route Collectors to trigger the errors, so there may be slight differences between what they see and what you actually do.
If you have any questions, please do not hesitate to contact me.
Kind regards,
Alex Band
On 09.11.2012, at 12:05 , Wilfried Woeber wrote:
Overall, I think this is very dangerous approach, and the wrong way to start with.
There might be very good reasons, why a full block of (IPv6) addresses, or a subset of, ist not (yet) globally visible. Announcing/Hijacking those addresses may seriously interfere with local tests or pilot deployment.
IMHO this should be strictly opt-in, instead of opt-out!
Wilfried.
Wilfried, you are right. The agreement I thought we made with Merit was to use unallocated address space. Apparently a misunderstanding occurred somewhere along the way. We will talk to Merit and correct this. Daniel
Daniel, On Tuesday, 2012-11-13 09:36:39 +0100, Daniel Karrenberg <daniel.karrenberg@ripe.net> wrote:
On 09.11.2012, at 12:05 , Wilfried Woeber wrote:
Overall, I think this is very dangerous approach, and the wrong way to start with.
There might be very good reasons, why a full block of (IPv6) addresses, or a subset of, ist not (yet) globally visible. Announcing/Hijacking those addresses may seriously interfere with local tests or pilot deployment.
IMHO this should be strictly opt-in, instead of opt-out!
Wilfried.
Wilfried, you are right. The agreement I thought we made with Merit was to use unallocated address space. Apparently a misunderstanding occurred somewhere along the way. We will talk to Merit and correct this.
Possibly such experiments should be announced in advance in the future, so that everyone can know what is going on. Ideally a pointer to a web page with full details about the experiment, but at least just a quick mail to the routing working group (and the IPv6 working group in cases where appropriate) seems reasonable. If this is something that requires a policy change I'd be happy to push it forward. Cheers, -- Shane
On 13.11.2012, at 11:59 , Shane Kerr wrote:
Daniel,
On Tuesday, 2012-11-13 09:36:39 +0100, Daniel Karrenberg <daniel.karrenberg@ripe.net> wrote:
On 09.11.2012, at 12:05 , Wilfried Woeber wrote:
Overall, I think this is very dangerous approach, and the wrong way to start with.
There might be very good reasons, why a full block of (IPv6) addresses, or a subset of, ist not (yet) globally visible. Announcing/Hijacking those addresses may seriously interfere with local tests or pilot deployment.
IMHO this should be strictly opt-in, instead of opt-out!
Wilfried.
Wilfried, you are right. The agreement I thought we made with Merit was to use unallocated address space. Apparently a misunderstanding occurred somewhere along the way. We will talk to Merit and correct this.
Possibly such experiments should be announced in advance in the future, so that everyone can know what is going on. Ideally a pointer to a web page with full details about the experiment, but at least just a quick mail to the routing working group (and the IPv6 working group in cases where appropriate) seems reasonable.
If this is something that requires a policy change I'd be happy to push it forward.
Cheers,
https://labs.ripe.net/Members/mirjam/ipv6-darknet-experiment
Daniel, On Friday, 2012-11-23 00:36:46 +0100, Daniel Karrenberg <daniel.karrenberg@ripe.net> wrote:
On 13.11.2012, at 11:59 , Shane Kerr wrote:
Daniel,
On Tuesday, 2012-11-13 09:36:39 +0100, Daniel Karrenberg <daniel.karrenberg@ripe.net> wrote:
On 09.11.2012, at 12:05 , Wilfried Woeber wrote:
Overall, I think this is very dangerous approach, and the wrong way to start with.
There might be very good reasons, why a full block of (IPv6) addresses, or a subset of, ist not (yet) globally visible. Announcing/Hijacking those addresses may seriously interfere with local tests or pilot deployment.
IMHO this should be strictly opt-in, instead of opt-out!
Wilfried.
Wilfried, you are right. The agreement I thought we made with Merit was to use unallocated address space. Apparently a misunderstanding occurred somewhere along the way. We will talk to Merit and correct this.
Possibly such experiments should be announced in advance in the future, so that everyone can know what is going on. Ideally a pointer to a web page with full details about the experiment, but at least just a quick mail to the routing working group (and the IPv6 working group in cases where appropriate) seems reasonable.
If this is something that requires a policy change I'd be happy to push it forward.
Cheers,
https://labs.ripe.net/Members/mirjam/ipv6-darknet-experiment
Thanks for this link, however in this case this is not a complete answer. I was obviously unclear, so let me try again. 1. This link was not posted *in advance*. The reason I proposed in advance is partially so that we could get review and feedback such as Wilfried's, and prevent future issues. 2. It was not sent to any of the RIPE mailing lists until after problems were reported. RIPE Labs is cool, but AFAIK the RIPE community still lives & breathes in the RIPE working group mailing lists. 3. There is apparently neither a procedure nor a policy concerning notification of experiments. Cheers, -- Shane
* Shane Kerr:
3. There is apparently neither a procedure nor a policy concerning notification of experiments.
I'm concerned that this is not the first time something went wrong.
On 23.11.2012, at 9:28 , Shane Kerr wrote:
1. This link was not posted *in advance*. The reason I proposed in advance is partially so that we could get review and feedback such as Wilfried's, and prevent future issues.
That is true and an oversight on my part for which I take responsibility. There are many reasons why this particular experiment got started too quickly and why it included address space that was not "dark". We can discuss them over a beverage or at the next working group meeting if anyone wishes to make a point of this particular oversight. I will not waste mailing list bandwidth unless there is a strong call to discus these reasons here.
2. It was not sent to any of the RIPE mailing lists until after problems were reported. RIPE Labs is cool, but AFAIK the RIPE community still lives & breathes in the RIPE working group mailing lists.
That was also an oversight and not intentional. Usually we indeed announce these articles on the relevant working group mailing lists. It has not happened this time, but it is certainly an exception.
3. There is apparently neither a procedure nor a policy concerning notification of experiments.
Does there need to be a *policy* on everything? Look: we made a mistake with this one. It did not have any real consequences. Yet we corrected it very very quickly and without hesitation once the mistake was apparent. Don't you trust the RIPE NCC anymore to do the right thing without a policy? Do we need to invoke the policy cannon for everything until our community does nothing else but make policies and the RIPE NCC does nothing else but make sure to make no mistakes running afoul of all these policies? I think we should be very conscious about when we invoke the policy process. In areas like address space distribution and registration formal policies are vital. However, invoking the policy process whenever anyone has an issue with what the NCC does or did is not the right thing to do. Daniel
On Wed, Dec 5, 2012 at 11:27 AM, Daniel Karrenberg <daniel.karrenberg@ripe.net> wrote:
I think we should be very conscious about when we invoke the policy process. In areas like address space distribution and registration formal policies are vital. However, invoking the policy process whenever anyone has an issue with what the NCC does or did is not the right thing to do.
Policies are bureaucracy and should be created *only* if there is no other way. Although this particular experiment might have not helped pushing signed routes and also caused a lot of confusing for some operators, I generally like the idea of the NCC support experiments. Only in an environment where NCC staff does not need to go through hundreds of policies and regulations right before every single step, worthy experiments bringing up worthy results can take place. To sum it all up: Please do *not* make a policy just because NCC staff acts open minded. Regards Dan (who dislikes bureaucracy in general) -- Dan Luedtke http://www.danrl.de
Hi, On Sat, Dec 08, 2012 at 11:43:19PM +0100, Dan Luedtke wrote:
To sum it all up: Please do *not* make a policy just because NCC staff acts open minded.
Nobody was suggesting to do a policy because of an *open* mind set - the problem was more with "not enough brains involved" here. (I don't have a specific problem with this experiment, partly because it's not using my address space - but I second the notion that this should have been clearly communicated to the community beforehand, and maybe someone should have told Merit that they are supposed to announce unallocated address space, not "all of it", if that was the underlying agreement... but I don't think this needs to be discussed any further, as Daniel has already agreed to improve in-advance communication for next time) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
participants (8)
-
Alex Band -
Antonio Prado -
Dan Luedtke -
Daniel Karrenberg -
Florian Weimer -
Gert Doering -
Shane Kerr -
Wilfried Woeber