Hello everyone,
The mailing list has been buzzing this month! This mail is intended to
serve as a summary of what happened on the mailing list and behind the
scenes.
#######################################################################################################################
By far, one of the most active threads concerned the correct *use of the
"route" and "route6" objects in a DDOS mitigation scenario. *[1]
*Context:*
Kaupo Ehtnurm runs a multihomed AS, and one of his upstream providers
offers DDOS mitigation service. To ensure all traffic passes through the
DDOS mitigation service, they announce a more specific prefix. Kaupo
explains that to achieve this, they need to create ROAs and Route objects.
ROAs have a max-length field, which allows Kaupo to use just one ROA for
a /32 IPv6 with the max-length set to /48. As route objects do not have
a max-length field, they explain that they would have to create 65536
/48 route6 objects for their /32, which is difficult to manage.
They ask why route objects don't have a comparable "max-length" field.*
**Related discussion:*
Most of the discussion does not concern the possible reasons why a
"max-length" field for route-objects does not exist, but rather
discusses operational practice and the actual behavior of DDOS
mitigation announcements. Job Snijders explains some of the possible
reasons this field does not exist [2]. Job [2] and Nick Hilliard [3]
have recommended reading BCP 185 / RFC 9319 for additional information
regarding best practices.
*Majority consensus:*
From what I was able to determine, the following statements are the
majority consensus:
* Most networks will accept the more specific prefixes, even without a
more-specific route object. [4] [5] [6] [7]
o Networks have their own reasons for why or why not they might
filter more-specifics. [7] [8] [9]
o Some traffic might still take the aggregate route instead of the
more-specific, this shouldn't be a problem in practice. [10]
o Testing the behavior of routes using tools like RIPE Atlas might
yield different results, but is said to be unlikely. [7]
* Creating a route object for every /48 in a /32 is not recommended.
[11] [12]
o Announcing and creating route objects for slightly longer
prefixes like a few /33 or /34 instead of many /48 might be an
acceptable compromise. [13]
#######################################################################################################################
Another very active thread was started by Denis Walker, Co-chair of this
working group, and concerned*the participation of working group chairs
in discussions. *[14]
*Context:*
Starting the discussion, Denis Walker has explained that he – following
feedback from community members – has decided to reduce his community
engagement temporarily to evaluate the effect on the working group. He
explains that he has not seen current NWIs progress during this time,
and that, in his opinion, the lack of engagement by co chairs does not
work in some working groups. He states that he will return to his
original level of engagement.
*Majority consensus:
*From what I was able to determine, the following statements are the
majority consensus:
* Overall, people support active working group chairs that drive
discussion, but do not support working group chairs taking a side as
a working group chair. [15] [16] [17]
* Working group chairs can express their personal opinion when they
remove themself from the working group position. [18] [19]
*Related discussion:*
Most of the discussion has been about co-chair neutrality in discussions.
Denis referenced RIPE documents outlaying the responsibilities of a
co-chair, where one co chair expressing their opinion to drive
discussion is not prohibited. [20]
This was followed up by Nick Hilliard, referencing information regarding
non-RIPE chair responsibilities. [21]
In the end, a policy proposal to clarify the rules was mentioned. [22] [23]
#######################################################################################################################
*News from the NCC*
* The "rev-srv:" attribute, which was deprecated in 2009, was removed
on July 27th. The maintainers of about 34,711 affected objects were
informed. [24]
* The "NONE" authentication scheme, which was deprecated in 2004, was
removed on July 27th. The maintainers of about 613 affected objects
were informed. [25]
* Client certificate authentication is planned for the database. The
NCC has a working implementation internally and is working on
getting it ready for production.
* The NCC is working on impact analysis concerning a "tuple" solution
for NWI-4, where the prefix and status are considered part of the
primary key. This will be published soon.
* Preparing for the open-source release, the web application for the
RIPE Database service is being audited by an external company. This
audit is planned to finish by the end of August.
#######################################################################################################################*
Personal note
*
Please do not hesitate to tell me if you think I should have included
something, or I misrepresented something. I didn't want to go into too
much detail, and contemplated a lot about the things to include.
You are welcome to contact me if you'd like changes to the format, or
you would just like to mention that you thought it was good. I
appreciate all feedback.
*
*
#######################################################################################################################
*All the links*
Route objects for DDOS mitigation:
[1] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007843.html
[2] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007859.html
[3] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007855.html
[4] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007855.html
[5] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007867.html
[6] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007856.html
[7] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007862.html
[8] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007866.html
[9] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007868.html
[10] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007861.html
[11] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007865.html
[12] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007865.html
[13] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007861.html
The participation of working group chairs in discussions:
[14] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007869.html
[15]https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007873.html
[16] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007880.html
[17] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007891.html
[18] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007872.html
[19] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007875.html
[20] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007883.html
[21] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007886.html
[22] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007889.html
[23] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007890.html
NCC news:
[24] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007877.html
[25] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007878.html
--
To unsubscribe from this mailing list, get a password reminder, or change your
subscription options, please visit:
https://lists.ripe.net/mailman/listinfo/db-wg
