bug? accepting larger than 32 bit BGP Communities in RPSL
Dear RIPE DB group, A small snippet from the current AS15562 object as stored in the RIPE DB. remarks: Larger than 32bit BGP Community test remarks: 64 bit export: to AS199036 action community .= { 0000199036:0000199036 }; announce AS-SNIJDERS The value "0000199036:0000199036" is a 64 bit integer: (199036<<32)+199036 = 854853110925692 854853110925692 Is far larger than what RFC 2622 [1] allows in section 7.1: typedef: # a community value in RPSL is either # - a 4 byte integer (ok to use 3561:70 notation) # - internet, no_export, no_advertise (see RFC-1997 ) community_elm union integer[1, 4294967295], enum[internet, no_export, no_advertise], So my main question is, why is the RIPE DB allowing such values to be stored? This is not conforming to any specification that I am aware of. Currently there is no consensus on what the future of BGP communities will look like within the IETF. Kind regards, Job [1] http://tools.ietf.org/html/rfc2622
Intersting observation, thanks for bringing it up! Q to the DB Team: is the software doing any checks against numeric values as numbers or is the data treated/stored exclusively as text? As a sort of more general sideline, there may be other limits or boundary conditions, and I am wondering where the proper place is to "enforce" those. I know about the 'be rigorous about what you transmit and liberal (and careful) in what you accept'. But I wonder whether that would not apply to tools just equally? Wilfried Job Snijders wrote:
Dear RIPE DB group,
A small snippet from the current AS15562 object as stored in the RIPE DB.
remarks: Larger than 32bit BGP Community test remarks: 64 bit export: to AS199036 action community .= { 0000199036:0000199036 }; announce AS-SNIJDERS
The value "0000199036:0000199036" is a 64 bit integer:
(199036<<32)+199036 = 854853110925692
854853110925692 Is far larger than what RFC 2622 [1] allows in section 7.1:
typedef: # a community value in RPSL is either # - a 4 byte integer (ok to use 3561:70 notation) # - internet, no_export, no_advertise (see RFC-1997 ) community_elm union integer[1, 4294967295], enum[internet, no_export, no_advertise],
So my main question is, why is the RIPE DB allowing such values to be stored?
This is not conforming to any specification that I am aware of. Currently there is no consensus on what the future of BGP communities will look like within the IETF.
Kind regards,
Job
Hello all and happy new year! To answer Wilfried's first question, in almost all cases we check for the values to be within defined (or logical) ranges. In the new RIPE Database update software we have centralised definitions for these kind of values and other syntax check and business rules. Now it is very easy to either add/remove or adjust new checks. In general, missing syntax checks are considered software bugs and will be fixed as soon as they are discovered by us or reported by our users. Your second question is aimed at the community and we are also interested to know what community thinks the rules should be. At the moment for the RIPE Database business rule checks we have a mix of both scenarios: - The Routing Registry part of RIPE Database is more liberal and is mainly bound to syntax checks (e.g. ROUTE(6) objects, set objects and AUT-NUM's routing attributes). - The Resource Registry part -- mainly to enforce policies -- has many business rules and checks embedded into it. Two examples are name server provisioning checks for domain objects which is far beyond checking the "nserver:" attribute syntax and INET(6)NUM "status:" attribute checks. Kind regards, Kaveh --- Kaveh Ranjbar, RIPE NCC Database Group Manager On Jan 2, 2013, at 2:24 PM, Wilfried Woeber <Woeber@CC.UniVie.ac.at> wrote:
Q to the DB Team: is the software doing any checks against numeric values as numbers or is the data treated/stored exclusively as text?
As a sort of more general sideline, there may be other limits or boundary conditions, and I am wondering where the proper place is to "enforce" those. I know about the 'be rigorous about what you transmit and liberal (and careful) in what you accept'. But I wonder whether that would not apply to tools just equally?
On Wed, Jan 02, 2013 at 03:27:33PM +0100, Kaveh Ranjbar wrote: Hi
Your second question is aimed at the community and we are also interested to know what community thinks the rules should be. At the moment for the RIPE Database business rule checks we have a mix of both scenarios:
It seems that checking all various kind of rules during the insert or update process is not a problem of heavy load to the DB. Taking this into account, I'm absolutely for checking the quality of the data wherever it is possible, which means also on the DB. Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
Hi, Accepting 64 bit values where only 32bit values can exist is absolute garbage and should not be accepted by the RIPE DB. Kind regards, Job On Jan 2, 2013, at 3:27 PM, Kaveh Ranjbar <kranjbar@ripe.net> wrote:
Hello all and happy new year!
To answer Wilfried's first question, in almost all cases we check for the values to be within defined (or logical) ranges. In the new RIPE Database update software we have centralised definitions for these kind of values and other syntax check and business rules. Now it is very easy to either add/remove or adjust new checks.
In general, missing syntax checks are considered software bugs and will be fixed as soon as they are discovered by us or reported by our users.
Your second question is aimed at the community and we are also interested to know what community thinks the rules should be. At the moment for the RIPE Database business rule checks we have a mix of both scenarios:
- The Routing Registry part of RIPE Database is more liberal and is mainly bound to syntax checks (e.g. ROUTE(6) objects, set objects and AUT-NUM's routing attributes).
- The Resource Registry part -- mainly to enforce policies -- has many business rules and checks embedded into it. Two examples are name server provisioning checks for domain objects which is far beyond checking the "nserver:" attribute syntax and INET(6)NUM "status:" attribute checks.
Kind regards, Kaveh
--- Kaveh Ranjbar, RIPE NCC Database Group Manager
On Jan 2, 2013, at 2:24 PM, Wilfried Woeber <Woeber@CC.UniVie.ac.at> wrote:
Q to the DB Team: is the software doing any checks against numeric values as numbers or is the data treated/stored exclusively as text?
As a sort of more general sideline, there may be other limits or boundary conditions, and I am wondering where the proper place is to "enforce" those. I know about the 'be rigorous about what you transmit and liberal (and careful) in what you accept'. But I wonder whether that would not apply to tools just equally?
On 02/01/2013 14:59, Job Snijders wrote:
Accepting 64 bit values where only 32bit values can exist is absolute garbage and should not be accepted by the RIPE DB.
Good grief, Job, it's only zeros and ones. Do chill out - bugs happen! Nick
Kind regards,
Job
On Jan 2, 2013, at 3:27 PM, Kaveh Ranjbar <kranjbar@ripe.net> wrote:
Hello all and happy new year!
To answer Wilfried's first question, in almost all cases we check for the values to be within defined (or logical) ranges. In the new RIPE Database update software we have centralised definitions for these kind of values and other syntax check and business rules. Now it is very easy to either add/remove or adjust new checks.
In general, missing syntax checks are considered software bugs and will be fixed as soon as they are discovered by us or reported by our users.
Your second question is aimed at the community and we are also interested to know what community thinks the rules should be. At the moment for the RIPE Database business rule checks we have a mix of both scenarios:
- The Routing Registry part of RIPE Database is more liberal and is mainly bound to syntax checks (e.g. ROUTE(6) objects, set objects and AUT-NUM's routing attributes).
- The Resource Registry part -- mainly to enforce policies -- has many business rules and checks embedded into it. Two examples are name server provisioning checks for domain objects which is far beyond checking the "nserver:" attribute syntax and INET(6)NUM "status:" attribute checks.
Kind regards, Kaveh
--- Kaveh Ranjbar, RIPE NCC Database Group Manager
On Jan 2, 2013, at 2:24 PM, Wilfried Woeber <Woeber@CC.UniVie.ac.at> wrote:
Q to the DB Team: is the software doing any checks against numeric values as numbers or is the data treated/stored exclusively as text?
As a sort of more general sideline, there may be other limits or boundary conditions, and I am wondering where the proper place is to "enforce" those. I know about the 'be rigorous about what you transmit and liberal (and careful) in what you accept'. But I wonder whether that would not apply to tools just equally?
-- Network Ability Ltd. | Chief Technical Officer | Tel: +353 1 6169698 3 Westland Square | INEX - Internet Neutral | Fax: +353 1 6041981 Dublin 2, Ireland | Exchange Association | Email: nick@inex.ie
On 03/01/2013 20:23, Nick Hilliard wrote:
On 02/01/2013 14:59, Job Snijders wrote:
Accepting 64 bit values where only 32bit values can exist is absolute garbage and should not be accepted by the RIPE DB. Good grief, Job, it's only zeros and ones. Do chill out - bugs happen!
Looks like this is just a bug. Can we just get it fixed please? Shouldn't be too difficult I'm sure. Nigel
Hello, The bug is fixed and the fix will be included in our next release. We will send an announcement when the release is deployed to the production. There are currently 8 objects in the RIPE Database containing invalid data regarding this new syntax check. We will contact their maintainers to fix those issues after the deployment. Kind Regards, Kaveh. --- Kaveh Ranjbar, RIPE NCC Database Group Manager On Jan 5, 2013, at 6:45 PM, Nigel Titley <nigel@titley.com> wrote:
On 03/01/2013 20:23, Nick Hilliard wrote:
On 02/01/2013 14:59, Job Snijders wrote:
Accepting 64 bit values where only 32bit values can exist is absolute garbage and should not be accepted by the RIPE DB. Good grief, Job, it's only zeros and ones. Do chill out - bugs happen!
Looks like this is just a bug. Can we just get it fixed please? Shouldn't be too difficult I'm sure.
Nigel
On 07/01/2013 18:05, Kaveh Ranjbar wrote:
Hello,
The bug is fixed and the fix will be included in our next release. We will send an announcement when the release is deployed to the production. There are currently 8 objects in the RIPE Database containing invalid data regarding this new syntax check. We will contact their maintainers to fix those issues after the deployment.
Keveh Many thanks for the quick action All the best Nigel
participants (6)
-
Job Snijders -
Kaveh Ranjbar -
Nick Hilliard -
Nigel Titley -
Piotr Strzyzewski -
Wilfried Woeber