[db-wg] July 2023 Database Working Group update

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ripe.net/ripe/mail/archives/db-wg/attachments/20230803/a9cb0b34/attachment.html>