- db-wg - mailman.ripe.net

Proposed change 2004.1: extended route creation rules
by Engin Gunduz 16 Feb '04

16 Feb '04

Dear colleagues, [apologies for duplicate mails] Some time ago, Frank brought an issue regarding route object aggregation to our attention in the DB-WG mailing list. Please see the short thread at: http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00474.html http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00475.html We have prepared a proposal to extend the route object creation rules to resolve this issue. However, the resulting proposal turns out to be quite complex as it builds on the current route object creation rules, which are already complex enough. Considering that the need for route object aggregation is encountered very rarely, it might not be worth implementing it. After the deployment of version 3 of our whois software, we have seen only a couple of such cases. In those cases, we have resolved the issue by applying the rules that we specify below manually. I would like to ask the working groups if they think this proposal is too complex. Implementing it would not be a problem technically, but I'm more concerned about explaining the complex rules properly to the users of the whois database. Best regards, and thanks for your time, -- Engin Gunduz RIPE NCC Software Engineering Department ============================================================= A PROPOSAL FOR EXTENDED ROUTE OBJECT CREATION RULES This document is about being able to create route objects that aggregate inetnums/route objects. This is needed where a user cannot merge two or more inetnum objects into one larger inetnum object, but still needs to create a route object that aggregates these inetnum objects. This is seen especially with assigned PI inetnum objects. A hypothetical example: Suppose there exist the following two inetnums in the whois database: inetnum: 12.0.0.0 - 12.0.0.255 netname: EXAMPLE-PI descr: Example Banking PLC admin-c: AA1-RIPE status: ASSIGNED PI inetnum: 12.0.1.0 - 12.0.1.255 netname: ANOTHER-EXAMPLE-PI descr: Anotherexample Printing Industries NV admin-c: ZZ1-RIPE status: ASSIGNED PI These are assigned to different end-users. Further suppose that they coincidentally take service from the same Internet Service Provider. The Internet Service Provider will want to aggregate these two assignments into a single 12.0.0.0/23 route to be announced, rather than announcing two separate prefixes, in order to keep the number of prefixes in routing tables to the minimum. However, the Internet Provider will not be able to create a single route object in the RIPE Routing Registry which implements RPSSec RFC (RFC2725). This is because the inetnum object that contains the 12.0.0.0/23 prefix will be inetnum: 12.0.0.0 - 12.9.255.255 netname: EU-ZZ-000000 descr: block for PI assignments descr: maintained by RIPE NCC country: EU remarks: These addresses are assigned to network operators. The RIPE NCC does not operate any networks using address space from this block. An explanation of how to find the correct contacts is available at <http://www.ripe.net/nicdb.html> admin-c: CREW-RIPE tech-c: CREW-RIPE tech-c: OPS4-RIPE status: ALLOCATED PI mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT changed: hostmaster(a)ripe.net 20030731 source: RIPE Note the "mnt-lower:" attribute that has RIPE-NCC-HM-MNT. See http://www.ripe.net/ripencc/faq/database/qa4.html#5 for a graphical representation of the current route object creation rules. Proposal: To address this problem, we need to extend the route object creation rules so that it would be possible to create a route object that takes its authorisation from a collection of route and/or inetnum objects that are more specific than the route object to be created. As the situation is quite rare, the 'extended' behaviour can be activated by using the keyword 'EXTENDED-ROUTE-CREATION' in the subject line of the update message or with the syncupdates. The extended behaviour is not the default behaviour. The Algorithm: The proposed algorithm to authorise the route object creation is: Check if the keyword was used. If not, proceed with normal route creation rules as described in RFC2725 (http://www.ripe.net/ripencc/faq/database/qa4.html#5) Check if there is an exact match route object or an exact match inetnum object If there is one, then proceed with normal route creation rules even if the keyword was specified. Find the inetnums/routes that can be used for route creation: Get a list of all inetnums and route objects that are one level more specific than the route object to be created. (-r -Troute,inetnum -m <prefix>) From this list, eliminate the inetnums that have exact match or less specific route objects. (Note: During route object creation, the existing route objects take precedence over existing inetnum objects). Check if the resulting set of inetnums/routes cover the whole space of the route to be created. If not, authorisation fails, hence creation attempt fails. Collect the mntners to be used during the authorisation check. Follow these rules: For each object in the set, check if there are "mnt-routes:" attributes in the object. If there are, they will be used. If there are not, the mntners that are mentioned in "mnt-by:" attributes will be used. Check the authorisation: During the authorisation, the mntners in the same object will be ORed, while the mntners in separate objects will be ANDed. Example 1: Suppose we have these inetnums in the database: inetnum: 0.0.0.0 - 255.255.255.255 status: ALLOCATED UNSPECIFIED mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT mnt-routes: RIPE-NCC-NONE-MNT inetnum: 12.0.0.0 - 12.255.255.255 status: ALLOCATED PI mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT inetnum: 12.0.0.0 - 12.0.0.255 netname: EXAMPLE-PI descr: Example Banking PLC admin-c: AA1-RIPE status: ASSIGNED PI mnt-by: MNT-EXAMPLE-PI inetnum: 12.0.1.0 - 12.0.1.255 netname: ANOTHER-EXAMPLE-PI descr: Anotherexample Printing Industries NV admin-c: ZZ1-RIPE status: ASSIGNED PI mnt-by: MNT-ANOTHEREXAMPLE-MNT-BY mnt-routes: MNT-ANOTHEREXAMPLE-MNT-ROUTES mnt-routes: MNT-ANOTHEREXAMPLE-MNT-ROUTES-2 There is also this aut-num object: aut-num: AS65534 mnt-by: MNT-AUT-NUM-MNT-BY mnt-routes: MNT-AUT-NUM-MNT-ROUTES There are no route objects that are in 12.0.0.0/23 space, or less specific of 12.0.0.0/23. The user wants to create the following route object: route: 12.0.0.0/23 origin: AS65534 mnt-by: MNT-ROUTE When the creation is attempted without the keyword 'EXTENDED-ROUTE-CREATION,' the whois software will try to get the IP space authentication from inetnums, as no related route object exists. The one level less specific inetnum is 12.0.0.0 - 12.255.255.255, which has the attribute "mnt-lower: RIPE-NCC-HM-MNT". As the user does not have access to the authorisation for RIPE-NCC-HM-MNT mntner, the creation attempt will fail. When the creation is attempted with the keyword 'EXTENDED-ROUTE-CREATION': - There are no exact match route or inetnum objects, so proceed with extended route creation rules. - to get the authorisation from IP space, the whois software will perform '-r -Troute,inetnum -m 12.0.0.0/23' query, which will return inetnum: 12.0.0.0 - 12.0.0.255 inetnum: 12.0.1.0 - 12.0.1.255 - there are no inetnums to be eliminated from the list. - the resulting set of inetnums/routes (it actually has two inetnums and no routes) covers the whole space of 12.0.0.0/23. - collect the mntners to be used in the authorisation process. from the aut-num: MNT-AUT-NUM-MNT-ROUTES from the route object itself that will be created: MNT-ROUTE from the IP space: (MNT-EXAMPLE-PI AND (MNT-ANOTHEREXAMPLE-MNT-ROUTES OR MNT-ANOTHEREXAMPLE-MNT-ROUTES-2)) 12.0.0.0 - 12.0.0.255 does not have "mnt-routes:", so "mnt-by:" must be used. 12.0.1.0 - 12.0.1.255 has two "mnt-routes:", so they both must be used, but they must be ORed. - the resulting mntner list: ( MNT-AUT-NUM-MNT-ROUTES AND MNT-ROUTE AND ( MNT-EXAMPLE-PI AND ( MNT-ANOTHEREXAMPLE-MNT-ROUTES OR MNT-ANOTHEREXAMPLE-MNT-ROUTES-2 ) ) ) Example 2: Suppose there are these inetnums in the database: inetnum: 0.0.0.0 - 255.255.255.255 mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT mnt-routes: RIPE-NCC-NONE-MNT inetnum: 12.0.0.0 - 12.255.255.255 mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT inetnum: 12.0.0.0 - 12.0.0.255 mnt-routes: MNT-INETNUM-1 inetnum: 12.0.1.0 - 12.0.1.255 mnt-routes: MNT-INETNUM-2 and the following route objects: route: 12.0.1.0/24 origin: AS65534 mnt-routes: MNT-ROUTE-1 route: 12.0.2.0/23 origin: AS6 mnt-routes: MNT-ROUTE-2 route: 12.0.2.0/23 origin: AS65534 mnt-routes: MNT-ROUTE-3 mnt-routes: MNT-ROUTE-4 and this aut-num: aut-num: AS65534 mnt-by: MNT-AUT-NUM-MNT-BY mnt-routes: MNT-AUT-NUM-MNT-ROUTES The user wants to create the following route object: route: 12.0.0.0/22 origin: AS65534 mnt-by: MNT-ROUTE When the creation is attempted without the keyword 'EXTENDED-ROUTE-CREATION,' the whois software will try to get the IP space authentication from inetnums, as no related route object exists. The one level less specific inetnum is 12.0.0.0 - 12.255.255.255, which has "mnt-lower: RIPE-NCC-HM-MNT" attribute. As the user does not have access to the authorisation for RIPE-NCC-HM-MNT mntner, the creation attempt will fail. When the creation is attempted with the keyword 'EXTENDED-ROUTE-CREATION': - There are no exact match route or inetnum objects, so proceed with extended route creation rules. - to get the authorisation from IP space, the whois software will perform '-r -Troute,inetnum -m 12.0.0.0/22' query, which will return inetnum: 12.0.0.0 - 12.0.0.255 inetnum: 12.0.1.0 - 12.0.1.255 route: 12.0.1.0/24 route: 12.0.2.0/23 (origin AS6) route: 12.0.2.0/23 (origin AS65534) - eliminate the inetnums with less specific or exact match route objects in the list. The resulting list will be: inetnum: 12.0.0.0 - 12.0.0.255 route: 12.0.1.0/24 route: 12.0.2.0/23 (origin AS6) route: 12.0.2.0/23 (origin AS65534) - the resulting list covers the whole 12.0.0.0/22 space. Continue. - Collect the mntners to be used during the authorisation check. from the aut-num: MNT-AUT-NUM-MNT-ROUTES from the route object itself that will be created: MNT-ROUTE from the IP space: (MNT-INETNUM-1 AND MNT-ROUTE-1 AND (MNT-ROUTE-2 AND (MNT-ROUTE-3 OR MNT-ROUTE-4))) - the resulting mntner list: ( MNT-AUT-NUM-MNT-ROUTES AND MNT-ROUTE AND ( ( MNT-INETNUM-1 AND MNT-ROUTE-1 AND ( MNT-ROUTE-2 AND ( MNT-ROUTE-3 OR MNT-ROUTE-4 ) ) ) ) )

3 5

Re: abuse-c: proposal
by Niall O'Reilly 10 Feb '04

10 Feb '04

Comments in context below ... On 6 Feb 2004, at 14:31, Randy Bush wrote: >> Attribute name >> Name should be distinctive, eg: 'abuse-mailbox'; not 'e-mail' > > since it should be a handle, which allows me to even get to > a <gasp!> phone number, calling it mail-anything seems a > mis-direction. since all the rest are of the form <foo>-c:, > do we have to invent something new? Yes, we do. A number of ppl (MarcoH, dfk), in different ways, and for divers reasons, have made it clear that we need a new attribute to carry as its value (yes, I do mean RHS) the e-mail address where abuse notifications should be sent. Marco explained this particularly well; The following example is an attempt to illustrate his point. Running whois -h whois.ripe.net 137.43.0.0 | \ perl -ne 'next unless /@/; ($addr) = grep /@/, split; print "$addr\n"' gives a bunch of addresses, which will probably ALL be used by your generic cheap-n-cheerful, save-the-world-from-SPAM robot. [ Hmm.. look at those victims! Must try to spread the load even wider! 8-) ] We aim to make it easy for everyone; the following should be nearly enough. whois -h whois.ripe.net 137.43.0.0 | \ awk '/^abuse-mailbox:/ {print $2}' > >> Handle >> Handle is upwardly scalable >> Handle could refer to person, role, or maintainer > > yep > >> Value >> Value is necessary; if not in primary object, then indirectly >> Value in primary object is attractive at low end of scale >> Value is vulnerable to RHS-hijacking, even if not in primary object! > > do not understand. do you mean the value (right hand side) > of the abuse-c: attribute? or are we sending cash? :-) [ I'll happily receive cash. 8-) ] I mean the RHS of the abuse-mailbox: attribute. This attribute MAY be specified in the primary (inet*num or such) object, but for scalability belongs in the object whose handle is on the RHS of a *-c: or mnt-by: attribute. [ Hmm.. *-c, *-by, *-fly 8-) ] As dfk has pointed out, we can get by without abuse-c: if we focus on taking advantage of _existing_ person/role/mntner objects linked by *-c: or mnt-by: and just use abuse-mailbox:. <p loaded-with="irony" remark="In case it's not obvious"> This is the speedy-deployment option, so I'm sure we won't want to use it! </p> IHTH TGIF /NO8

8 27

(no subject)
by Wilfried Woeber, UniVie/ACOnet 10 Feb '04

10 Feb '04

>> Creating irt objects is not any harder than creating a new maintainer, >> maybe the documentation should focus more on this and less on marketing >> the TI concept (which apparently only NRENs care about). > >First problem with IRT is that in order for it to have any value every LIR >has to actively modify ALL their inetnum objects......... Now that must mean >that the intention has never been to make sure all LIRs implement it. Sorry, but this just wrong. It is exactly one of the advantages (of course you might want to have a different point of view :-) that modifying 1 (or a very small number of) object(s) would be sufficient - as long as we are talking hierarchical (i.e. LIR) address space. Tagging the _allocation_ object of an LIR would cover _all_ the _assignment_ objects in that block. With the added benefit that you can still have a "more specific" or 1st-line pointer in an assignment object. >Next problem is the idea behind IRT, apparently it is to be used by >companies who outsource handling of abuse - we don't. Out-sourcing would be supported, but it is a secondary issue. The primary issue is that it allows maintaining the data by the group being responsible for a certain function. There are real life situations where the role/group/team keeping track of address assignments is _different_ from the role/group/team being responsible for abuse or incident handling. If I should use this >object it should have a normal mnt-by attribute and the following fields >either removed or made optional: address, signature, encryption, auth. > >I can appriciate the need for the features of the IRT object, but WHY can't >the rest of us get a working solution to our problem? "You" (actually we ;-) can certainly get a solution, as soon as there is rough consensus in the WG that the approach proposed is _probably_ going to work and has a reasonable "price tag" (i.e. the implementation effort). > It doesn't necessarily >mean that we can't preserve the features of the IRT. > > > >Med venlig hilsen/Best regards > >Christian Rasmussen >Hosting manager, jay.net a/s > >Smedeland 32, 2600 Glostrup, Denmark > >Email: noc(a)jay.net >Personal email: chr(a)corp.jay.net >Tlf./Phone: +45 3336 6300, Fax: +45 3336 6301 > >Produkter / Products: >http://hosting.jay.net -------------------------------------------------------------------------------- Wilfried.

3 2

RE: [db-wg] Re: abuse-c: proposal
by TAYON, Julien 09 Feb '04

09 Feb '04

MarcoH <mailto:marcoh@marcoh.net> wrote: > On Mon, Feb 09, 2004 at 03:25:12PM +0100, Marco d'Itri wrote: [...] > > To provide such a behaviour, we need to store the information somewhere in > the database and free-form remarks or a more generic e-mail attribute is > IMHO not the way. I have been caught in a story of alledged spam with an end-user customer and my experience is that ISP abuse team is at the crossroad between - lawyer (commercial and penal one), - wannabe hacker (coders with good programming skills and poor comprehension of the universe ;) - end-user customer that want bad guy punished and their mails delivered (especially the unsollicited one they send), - anti and pro spam lobby wich abhores one another What I understood is abuse / IP problems are mostly resolved if you teach / inform / communicate correctly. As the situation is already quite confusing and complicated I definitively want a Keep It Simple Stupid solution. IMHO abuse-c: field wich is a valid email is Simple & Stutid (aka what I need) : as a proof of concept I can successfully "sell" it today in my company to the marketing department :) Regards, Julien Tayon 9T

1 0

c-client lib?
by Randy Bush 09 Feb '04

09 Feb '04

building on a new machine. freebsd 5.2-current. have never built on 5.x before. # ./build.sh --prefix=/usr/home/whois checking build system type... i386-unknown-freebsd5.2 checking host system type... i386-unknown-freebsd5.2 checking for /usr/local/bin/glib-config... yes checking for /usr/local/include/mysql/mysql.h... yes checking for /usr/local/lib/mysql/libmysqlclient_r.so... yes checking for /usr/local/bin/mysql... yes checking for /usr/local/bin/xslt-config... yes checking for /usr/local/bin/xml2-config... yes checking for /usr/local/src/mail/imap-2001.RELEASE-CANDIDATE.1/c-client/mail.h... yes checking for /usr/local/src/mail/imap-2001.RELEASE-CANDIDATE.1/c-client/c-client.a... yes checking for /usr/local/bin/gpg... yes checking for gcc... gcc checking for C compiler default output... configure: error: C compiler cannot create executables Configure failed. Exiting\n any hints? # gcc -v Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.3.3 [FreeBSD] 20031106 # cc -v Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.3.3 [FreeBSD] 20031106 randy

2 1

Re: [db-wg] Re: abuse-c: proposal
by Niall O'Reilly 07 Feb '04

07 Feb '04

On 7 Feb 2004, at 04:43, Randy Bush wrote (privately): > how little can we do > and get the result I think a truly minimalist approach would be to add the abuse-mailbox: attribute, with an e-mail address on RHS and an optional hint string on far-RHS beyond the '#', to the existing person, role, and mntner objects only. This would provide a means for operators/sysadmins to advertise 'effectively'. They are not doing this at present because IRT is (perceived as) too complex, and 'remarks:' is easier. MarcoH's statistics (as I recall) show on the order of 900k objects, 100k with remarks pointing to abuse contacts, and about 1k with IRT's set up. Adding one optional attribute to the three objects mentioned has the following advantages: the new attribute name signals its specific semantics; no new object is required; no new cross-checking between objects is required; no new RHS systax-checking is required (syntax is as for 'e-mail:'); deployment is optional; deployment scales per-contact, not per-network; the motivation (whatever it is) for overloading the 'remarks:' attribute is undermined; and use of the new attribute is simple, both for operators and for tool writers. The chief disadvantage is that the motivation for using IRT is undermined. Since IRT uptake is about 0.1%, and going nowhere fast, this is something I can live with. Niall O'Reilly

2 1

Re: [db-wg] Re: abuse-c: proposal
by Niall O'Reilly 06 Feb '04

06 Feb '04

On 6 Feb 2004, at 17:18, Randy Bush wrote: > not when you are using it as a reason to affect decisions in > this discussion, i.e. allowing email addresses in abuse-c: Not me! Something must have gotten lost in translation. My picture is that the RHS of abuse-c: is a handle, while the RHS of abuse-mailbox: is an RFC822 addr-spec. Niall

1 0

Re: [db-wg] Re: abuse-c: proposal
by Wilfried Woeber, UniVie/ACOnet 06 Feb '04

06 Feb '04

Niall, I'd like to add one line... >We're trying for something with the following characteristics: > > something new and specifically focused, to avoid existing baggage; > simplicity for sysadmins; > simplicity for robot-builders; > a simple message for marketing/evangelism. [ and doesn't break concepts or tools which are there already ] >Niall Could you agree to that? Wilfried.

3 2

Re: abuse-c: proposal
by Wilfried Woeber, UniVie/ACOnet 06 Feb '04

06 Feb '04

>not when you are using it as a reason to affect decisions in >this discussion, i.e. allowing email addresses in abuse-c: > >randy Assuming that we build the abuse[xyz], I'd suggest to use abuse-c: if we want to use a pointer, i.e. a handle. This preserves DB conventions. From my point of view there is a pro and a con in allowing an email address directly in a dedicated attribute (whatever its name): - pro: . it saves a couple of lines in a robot script, and it gets displayed irrespective of the querying tool or path . but at the same time it would not support hierarchy or tree-walk towards the encompassing address block objects - con: . it runs against a concept we tried to adhere to in designing the schemas for objects: "don't try to put attributes into the same object, for which the values will be maintained by different entities". Putting an email address directly into the "primary" objects would be such a case. The inet*num objects are the responsibility of the LIRs, maintaining (at least most specific) abuse contact information would be the responsibility of the end site (or direct up-stream connectivity provider). In many cases those are different entities. Wilfried.

1 0

Draft Minutes for DB-WG Ripe 47
by Titley, Nigel 06 Feb '04

06 Feb '04

Gentlefolk, Please find attached Draft minutes for the recent DB Working group meeting at RIPE 47. Comments please. Best regards Nigel ********************************************************************** This e-mail message is confidential and is intended only for the use of the individual or entity named above and contains information which is or may be confidential, non-public or legally privileged. Any dissemination or distribution of this message other than to its intended recipient is strictly prohibited. If you have received this message in error, please notify us by email to postmaster(a)flagtelecom.com immediately and delete the original message and all copies from all locations in your computer systems. This e-mail has been swept by Mailsweeper TM for viruses. However, FLAG Telecom cannot accept liability for any damage which you may sustain as a result of software viruses. ********************************************************************** This message has been scanned for viruses by MailControl - www.mailcontrol.com

1 0

Re: abuse-c: proposal
by Wilfried Woeber, UniVie/ACOnet 06 Feb '04

06 Feb '04

>Perhaps, but that's another discussion. >Let's put that on the WIBNI list and stay focused. > >Niall > >On 6 Feb 2004, at 16:06, Randy Bush wrote: > >> perhaps instead of adding another address they can call, we >> should allow changed: and notify: to be nic-handles:. notify:, upd-to: and maybe one or too more are defined as email addresses. I don't see a good reason to get those changed. Both are used to manage successful or unsuccessful database updates. Different purpose. The changed is a sort of "weird" attribute anyway. It has been under discussion a few times, but no definite result as yet. AFAIK the NCC's hostmasters use it (the date part) for some sort of internal sanity checking of assignment transaction. I agree here: out of scope for this discussion. Wilfried.

1 0

abuse-c: proposal
by Niall O'Reilly 06 Feb '04

06 Feb '04

It's been very quiet on the list since the frantic activity at the end of last week. I expect day-to-day reality has imposed itself. I've done some further thinking, and have reviewed the contributions last week on the db-wg list. I've tried to recognize the issues and alternatives in this message and to make proposals as straw-men for consensus. I've used a bullet-point approach, as I think no-one is likely to have time to read anything more discursive. I'll happily explain anything that people find too terse. Here goes ... Attribute name Name should be distinctive, eg: 'abuse-mailbox'; not 'e-mail' Handle Handle is upwardly scalable Handle could refer to person, role, or maintainer Value Value is necessary; if not in primary object, then indirectly Value in primary object is attractive at low end of scale Value is vulnerable to RHS-hijacking, even if not in primary object! Hint string Trailing #-comment is easiest RFC822 parens-comment as part of value is possible Qualifier to attribute name would be neat, but may be difficult to implement (eg: abuse-mailbox-{spam,security}) Proposal (1) Advertisement (sysadmin) side Use two attributes: one to hold value, the other to hold handle Use attribute 'abuse-mailbox' to hold value Use attribute name 'abuse-c' to hold indirect object handle Allow use of 'abuse-mailbox' attribute in primary object Encourage use of attribute in indirect object as best practice Support all relevant indirect objects (person, role, maintainer) in order to make it easy for sysadmins We REALLY WANT sysadmins to ADOPT this (NAFS: no apol for shout) Inheritance Implemented in query tool: design and coding resource impact Must be 'intuitive' for advertising sysadmin Two axes: by reference to handle; by containing block Priority: by reference first, but ... Proposal (2) Query side algorithm Specifies behaviour of focused query tool Sysadmins must take account when advertising in order to align query result with their intent Needs discussion: Concept Implementation: cost to implement, performance, possible pruning of search tree Given object (from inet*num, asnum, ...) and circumstances To identify appropriate abuse contact Find contact set for given object Include tech-c.email value for given object if set is empty Discard members of set unless circumstances match hint Return survivor(s) To find contact set Start with empty set Add all abuse-mailbox values found in current object While set still empty visit abuse-c, mnt-c, tech-c ... (?) Find contact set for visited object Stop visiting as soon as set is no longer empty While set still empty visit containing block Find contact set for containing block (if any) (Note: person, role, mntner have no containing block) Stop visiting as soon as set is no longer empty Return set -- Ends --

4 7

Re: [db-wg] abuse-c: proposal
by Wilfried Woeber, UniVie/ACOnet 06 Feb '04

06 Feb '04

>> we might consider to also extend irt with the abuse-mailbox and >> allow abuse-c to refer to an irt object ? > >why not remove irt entirely? it is not needed given this proposal. Sorry, I have to disagree. The abuse / abuse-c /abuse-mailbox proposal(s) as being discussed will (maybe - maybe not) solve a different problem... >"less is more." -- mies van der rohe and nothing is best? >randy Wilfried.

1 0

abuse-c: proposal
by Niall O'Reilly 30 Jan '04

30 Jan '04

Co-authors: Randy Bush, Niall O'Reilly Proposal for Adding Abuse Contact to inet*num: Objects in RIPE Database Requirement: Net users who perceive abuse from some net source wish to contact some service which has officially agreed to deal with the abuse. Currently, they seem to scan the inet*num: objects and send mail to any or all contacts in that object, including strange things such as the email address in the changed: attribute. This need seems to be clearly applicable to the inetnum: and inet6num: objects, so those objects are addressed by this proposal. Should there be similar needs in other object types, it is anticipated that the abuse-c: attribute would be added to those objects as appropriate. Two things are needed: o The inetnum: and inet6num: objects are enhanced with an optional attribute "abuse-c:". The value of the attribute is a nic-handle: which must refer to an extant person: or role: object. There may be zero or more abuse-c: attributes in an inet*num: object. The value of the abuse-c: attribute MAY be extended by appending a hint string. This is expected to be useful to organizations who wish to advertise more than one abuse contact, and to give guidance as to which of these is the appropriate notification target in particular circumstances. In case a hint string is specified, it MUST be discarded when forming inverse keys. Therefore, the syntax of the inetnum: object would become inetnum: [mandatory] [single] [primary/lookup key] netname: [mandatory] [single] [lookup key] descr: [mandatory] [multiple] [ ] country: [mandatory] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] abuse-c: [optional] [multiple] [inverse key] rev-srv: [optional] [multiple] [inverse key] status: [mandatory] [single] [ ] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] mnt-lower: [optional] [multiple] [inverse key] mnt-routes: [optional] [multiple] [inverse key] mnt-irt: [optional] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] o Document and Publish that the abuse-c: contact is the one and only contact that should be used to report spam and other forms of abuse. This documentation should be made prominently available so that manual seekers and creators of automated reporting tools will all clearly know that the abuse-c: is the one and only place at which abuse should be reported, and that other contacts in the objects should not be abused. The documentation should make it clear that automated reporting tools MAY always ignore the hint string, but SHOULD search the advertised abuse-c: attributes to find a hint string that matches the circumstances of the abuse to be reported. The hint string specified SHOULD be taken from a limited vocabulary. This vocabulary SHOULD be reviewed from time to time. It contains initially the following terms, treated as case-insensitive, and with the indicated semantics: '' Always notify this contact 'Spam' Notify this contact for spam abuse ONLY 'Security' Notify this contact for DDoS and intrusion abuse ONLY -- End --

12 32

Re: [db-wg] abuse-c: proposal
by Niall O'Reilly 29 Jan '04

29 Jan '04

Ulli, On 29 Jan 2004, at 14:03, Ulrich Kiermayr wrote (privately): > What is the difference between the following to answers from the > database (One with the existing Machine [ changing the default answer > behaviour] and one following the proposal): I want to share my response with the list. No difference between the answers. The difference is in the cost to (effort for) a netadmin in setting up the IRT stuff. Marco's statistics, as I understood them, seem to bear this out: there is a ratio of 2 orders of magnitude between the instances respectively of IRT references and free-text remarks about abuse notifications. I'm close to convinced that the IRT approach is correct, elegant, and the rest. I just find it too much trouble to use: I need it to be much easier than that to advertise my abuse contacts. As the saying goes, "Le mieux est l'ennemi du bien." Make it barely good enough, but simple; then we'll see it adopted. Niall PS. "Daddy, what does 'feature creep' mean?"

1 0

[announce] releasing a tool to help LIR visualizing IPv4 LIR-as signments vs RIPE-allocations
by TAYON, Julien 28 Jan '04

28 Jan '04

Hello, LDCOM Networks/N9uf telecom release its tool ripe_wrap. Its purpose is to enable a LIR to make a cross view between Assigned inetnums (such as seen when making a whois request) and the "netnames" allocated by the RIPE (such as seen through the lirportal). It gives usefull information such as biggest available holes per ip-range, % of assigned space over the space that was declared for a netname. Since LDCOM is not a software editor, it has been decided to release our tool under Afferro GPL licence. Temporarily, its location is http://www.julbox.net/ripe_wrap-1.0.tgz I use it every day and I think it is quite fine, but I made no intensive test. Please report to the author(s) (see AUTHORS) any bug(s) and suggestion. Our main gool is to build a toolbox for a LIR to work on its RIPE informations without hosting any Database by crossing various informations such as the configuration it have on its network equipments. Beware, first access is slow since it makes requests to the web and then sort out the data. We will think of a way to improve this ... later. Friendly, -- Julien Tayon - N9uf Telecom - BU DATA - +33 1 70 18 14 45

1 0

draft agenda (V1) for DB-WG meeting, RIPE 47, Amsterdam, NL
by Wilfried Woeber, UniVie/ACOnet 22 Jan '04

22 Jan '04

[ for whatever reason, this message of Jan.16th didn't leave the mail ] [ system to be distributed to all the intended recipients... :-( ] _______________________________________________________________________ Dear DB-WG community, below please find V.1 of the draft agenda for the DB-WG meeting at RIPE47 in Amsterdam, NL. Could every individual or group mentioned in the list of topics please check the lengh of the timeslot allocated and/or reply _to me privately, pls._ with information missing or change requests. If you want to see modifications made to the list of topics, then pls. send or cc: to the list. Pls. let me know asap if I missed any of the topic proposals or requests. If so, it was not done on purpose!! Just FYI, most probably I am not going to have access to my email between later today (Fr. 16.1.) and next Thursday, so I'll be slow in responding :-( Looking forward to see many of you in Amsterdam! Wilfried. ++++++++ A. Administrative Matters - scribe - list of participants - agenda - minutes B. DB Operational Update (N.N., RIPE NCC) [~20 min] C. ERX (Leo V., RIPE NCC) [~15 min] D. X.509 support implementation (N.N., RIPE NCC) [~10 min] E. CRISP/Joint-Whois status (Shane K.(?), RIPE NCC) [~15 min] F. Getting rid of auth NONE (N.N., RIPE NCC) [??? min] G. irt: / abuse: [60+ min] - populating inet[6]nums w/ irt links, DFN, SURFnet (Jan M./Marko T.) - abuse-c: discussion and proposal summary (MarcoH, mch2-ripe) - whois server: review of (default) behaviour & format (WW144) - how to get the other WGs involved? Spam? Routing? (WW144) H. RPSLng status and deployment (Simon L., SWITCH) [~20 min] G. S/MIME support (Denis W., RIPE NCC, t.b.c!) [~10 min] H. BCP on "use of the Registry Database"?? (WW144, t.b.c) [~15 min] Y. Input from other WGs Z. AOB --------------------------------------------------------------------------------

1 0

DNS Related Policy and Procedure Proposals
by Olaf Kolkman 22 Jan '04

22 Jan '04

Dear Colleagues, Apologies for duplicate mails. Shortly after this mail we will be sending two separate mails to the DNS Working Group mailing list. We will also be posting a draft policy document (see below). These mails also have relevance to the RIPE NCC Services and Database Working Groups. The two messages and revised policy document are part of a project started in October 2003 to streamline and simplify the process of requesting and managing reverse DNS delegation for the holders of the address space allocated or assigned by the RIPE NCC. The original proposal can be found at: http://www.ripe.net/reverse/proposal.html The content of the mails are: - A proposal for the introduction of a new "mnt-domains:" attribute in INETNUM objects to authorise the creation of DOMAIN objects. This proposal also suggests making "mnt-by:" a mandatory DOMAIN object attribute. This authorisation mechanism will enable address space users to delegate the responsibility for maintaining reverse address space to third parties in a flexible manner. - An assessment of the consequences of the introduction of the "mnt-domains:" attribute and of the "mnt-by:" attribute being made mandatory. The reverse delegation policy has been revised, relaxing the terms under which reverse delegation will be serviced and providing the framework to implement the authorisation mechanism described above. The draft "Policy for Reverse Address Delegation of IPv4 and IPv6 Address Space in the RIPE NCC Service Region" can be found at: http://www.ripe.net/ripe/draft-documents/reverse-draft-200401.html We would like to invite your comments on this. Please discuss these proposals on the DNS Working Group mailing list. More information can be found at: http://www.ripe.net/reverse/rdns-project/ -- Olaf Kolkman New Projects Group RIPE NCC

3 2

abuse-c
by Rev Adrian Kennard 14 Jan '04

14 Jan '04

Following up my own mail... > Also, the "trouble" field is a good thought - maybe we should add > "trouble" to inetnum, as there is already a field name defined for the > purpose essentially. Just an idea. "trouble" is not really the answer as it is freeform. It needs to be a syntax checked email address. abuse-c to a person/role object seems sensible. -- Rev Adrian Kennard Andrews & Arnold Ltd / AAISP www.aaisp.net.uk

8 25

RE: REMINDER - RIPE 47 Agendas
by Wilfried Woeber, UniVie/ACOnet 14 Jan '04

14 Jan '04

This is the very crude V0 for the draft agenda, DB-WG at RIPE47 in Amsterdam. Please expect a somewhat better polished version by tomorrow or Friday. But pls. let me know asap if I missed any of the topic proposals or requests. If so, it was not done on purpose!! ++++++++ Chair Agenda Format: A. Administrative Matters - scribe - list of participants - agenda - minutes B. DB Operational Update (N.N., RIPE NCC) C. ERX (Leo V., RIPE NCC) D. X.509 support implementation (N.N., RIPE NCC) E. CRISP/Joint-Whois status (Shane K.(?), RIPE NCC) F. Getting rid of auth NONE (N.N., RIPE NCC) G. irt: / abuse: discussion (MarcoH, mch2-ripe) H. RPSLng status and deployment (Simon L., SWITCH) G. S/MIME support (Denis W., RIPE NCC, t.b.c!) H. BCP on "use of the Registry Database" (WW144, t.b.c) Y. Input from other WGs Z. AOB A you can see we are goi8ng to have a pretty long program list :-) -------------------------------------------------------------------------------- Wilfried.

1 0

Erroneous Domain Cleanup Messages
by Olaf Kolkman 13 Jan '04

13 Jan '04

Dear Colleagues, Apologies for duplicate mails. == Introduction We recently informed the Working Groups about the start of a cleanup of inconsistencies between data in our reverse DNS and data in the Whois Database [1]. Since Wednesday 7 January, 2004 we have been sending out warning messages. Unfortunately a number of messages were sent out in error. == The Problem Due to a bug in the script, messages have been sent to contacts for /24 DOMAIN objects that have a more specific /16 object, stating that there are no matching NS RRs in the zone files and that the DOMAIN object will be deleted. This has been done in error and these DOMAIN objects will remain unaltered. The contacts for these /24 DOMAIN objects will be sent a message shortly confirming that their objects will remain unaltered and that no further action is required on their part. == Background The Whois Database holds informational data for domains in the reverse tree. The database holds information about reverse domains corresponding to /8, /16 and /24 address space. The '/8 domain' zone files at the RIPE NCC only contain NS RRs for the delegation corresponding to the most less specific address block. If there is a /16 DOMAIN object and a number of more specific /24 DOMAIN objects in the database only a delegation will be created corresponding to the /16 DOMAIN object. In other words, if the /16 domain has been delegated one cannot delegate its children any longer. Therefore, the absence of the NS resource records corresponding to the "nserver:" attributes in the /24 DOMAIN objects is not an error. Note: for End Users it is not obvious if an NS RR is in the zone files of the RIPE NCC since ns.ripe.net is a secondary DNS server for the /16 zones. Our apologies for any confusion and extra work this may have caused. For further clarification please do not hesitate to contact <ripe-dbm(a)ripe.net>. --Olaf Kolkman New Projects RIPE NCC [1]: http://www.ripe.net/ripe/mail-archives/dns-wg/2004/msg00000.html Further information about the cleanup project can be found at: http://www.ripe.net/reverse/rdns-project/cleanup.html

1 0

Re: [db-wg] Defined roles
by Wilfried Woeber, UniVie/ACOnet 13 Jan '04

13 Jan '04

>> I don't have any problem with the concept of an abuse-c:, in whatever >> colour, shape or texture. the real problem that I (still) have after so >> many years is that we still lack a definition of "abuse", and which part >> of an organisation is supposed to deal with the "abuse". >> >> Also note that usually there is an aspect of "incoming" and >> "originated" abuse. > >In that case, db-wg will only supply the tools and not make any decision >on the contents or the usage and we should get other working groups >involved in this (anti-spam ?). Indeed. >However in some sort of way, the information in the database is 'abused' >by users in the way that they don't use the correct attributes. This in >some form can be explained as the current tools lacking some functionality >or being to complex to use for the larger public. I agree. >So what we need to decide on is whether there is a problem and users will >gain something if we add some functionallity to the system. > >I think that the usability of the system is on-topic for this working >group definitely > and as far as my personal opinion goes, we need to do something >extra to stop people from 'abusing' certain information before the >majority decides that it's a lost game and start removing information >which is usefull for other parts of the work like troubleshooting 'the >internet'. Private opinion: I am one of those who think it is a lost case already. How long has the info in changed: been abused to spam the folks for the address distribution, who simply update a record in the DB, with spam and port scan and xyz complaints? >We don't have to go further then to specify you can include only 1 valid >email address and advice people to insert the address where they want to >recieve the complaints and if you query the database for this information >use this field as a default. > >MarcoH Wilfried.

1 0

Re: [db-wg] abuse-c
by Wilfried Woeber, UniVie/ACOnet 13 Jan '04

13 Jan '04

> >> Not if the relevant IRT object is automatically returned for every > >> inetnum query. This is what ARIN does, BTW. > > Could I see an example of ARIN doing that, please? >$ whois 4.0.0.1 > >OrgName: Genuity >[...] > >NetRange: 4.0.0.0 - 4.255.255.255 >[...] > >OrgAbuseHandle: ABUSE23-ARIN >OrgAbuseName: Abuse >OrgAbusePhone: +1-800-436-8489 >OrgAbuseEmail: abuse(a)genuity.com Thanks, Marco! 2 observations: - the XyzOrg-Type objects seem to be optional (as our university's address block info comes back without them) ? - where can I find documentation about the schema for those XyzOrg... entries? Wilfried.

2 1

RE: [db-wg] Defined roles
by Wilfried Woeber, UniVie/ACOnet 13 Jan '04

13 Jan '04

[up-front disclaimer: apologies or this loooong reply. Maybe it's of help ] >Following on from the comment bt Shane Kerr > > > Also, what various contact information means is not clear. What > > administration does the "admin-c:" do exactly? It is (was [1]) the point of contact in the organisation holding a resource, who or which is allowed/expected to represent the organisation "administratively" > Only update the RIPE Maybe, but not necessarily. > Database? Coordinate with the RIPE NCC? > Is it the CEO of a company? The manager of the IT department? Maybe, yes, but it can also be an employee which is put in charge of that responsibility. Depends on the internal organisation. Someone or something _inside_ the organisation. >Or an independent contractor who handles > all the details of connectivity? No, that is the entity which would be listed as the tech-c: There is a good chance that an organisation holds resources (e.g. address space, an AS Number) which always remains the same, while the operational aspects may be tendered on a regular basis, out-sourced to a third party, or taken care of collectively with an/other organisation/s. Hence the concept of a role: to eg. describe a NOC >I have to agree that "what is the responsibility" or perhaps just "the >role" of the admin-c and tech-c. From what I have read on RIPE documents >the role is not at all clear. I believe it said the admin contact has to >be at the same address as the network? So what of unattended sites? You have to take into account that many parties try to use the DB these days in ways and for purposes for which it was not designed from the beginning. At that point in time there were 2 (3?) goals or objectives: 1 Provide an _authoritative_ registry for internet resources (IP address blocks and AS numbers) which were allocated or assigned (distributed) within the framework of RIPE and the RIPE NCC. There is a formal relatinship in place between the RIPE NCC and the LIRs defining the requirements of collectively maintaining these records. This is the IP- and ASN-Registry inside the RIPE DataBase 2 Provide the means to register Routing Policy for Autonomous Systems. This set of data is - from the point of view of the NCC! - NOT authoritative. In the sense that the NCC is not responsible for completeness and/or correctness of entries. This is the Rouitng Registry inside the RIPE DataBase 3 In support of the IP-Address Registry, and as a convenience for the community in the "early days" of the Internet in Europe, there is a mechanism to register DNS Domain objects in the database. The only (important!) functionality that is left here is keeping track of the ReverseDNS Tree for those address blocks which belong to the IP-Address Registry. All the other domain objects were eventually removed, after going through a lengthy migration and clean-up phase, together with many TLD administrations. At that point in time there was no "Spam", (almost) no attacks or break-ins, a limited library of malware, and so on. >There are many questions, and perhaps there should be some attempt to >define more accurately what admin-c and tech-c are meant to be used for. No problem with that. But this probably has to be taken up in other working groups, like the Addess Policy WG, the Routing WG, etc. The DataBase Gang should only provide the tools to implement their semantics. >As internet usage is becoming more of an issue (spam, child porn, etc) I >can't help feeling that there should be some formal "responsibility" >associated with an inetnum (like we have a "keeper of a vehicle" in the >UK who has some responsibilities). Yes, I fully agree. The interesting part here is that we'll open _many_ BIG cans of worms if we try to progress that. Every attempt until now has got entangled between the colliding interests of the network operators (technical trouble-shooting), law- and intellectual property-rights-enforcement (child porn, copyright violations, etc.) and the _protection of privacy_ of the users. There is at least one region which has proposed to hide name, address and email data on whois queries, in the interest of privacy protection. I didn't have the time to follow up whether it was implemented. But I agree, we may be very close to the point in time where this has to happen, somewhere... > I suspect to go this far would >request some legal framework in countries affected, You bet. I can tell from some private discussions with people from the EU commission that not even between them they have resolved those conflicting points of views. >but RIPE could at >least indicate, say, "The admin contact is intended to take >responsibility for the IP addresses" or some such, which would be a good >basis. From my point of view, that is exactly the role of the admin-c _at large_ or at least as a fall-back. However the organisation can "delegate" responsibilty for some aspects to other groups, parties, or contacts. This is done in real life! E.g. - for operational aspects we can list a differenet tech-c. - for database maint. there is the maintainer (and notification) mechanism - for routing there is the set of objects in the routing registry - for hacking, intrusion, DoS, and law/(C) stuff there is the machinery to point/link to the Incident Response Team to be contacted for those cases. [Note, that even in that camp there is'nt full consensus yet on how to document the different contacts for different incident types ;-] >Of course, if there was an abuse-c, then this could be a document >explaining the detailed role of admin-c, tech-c, and abuse-c. I don't have any problem with the concept of an abuse-c:, in whatever colour, shape or texture. the real problem that I (still) have after so many years is that we still lack a definition of "abuse", and which part of an organisation is supposed to deal with the "abuse". Also note that usually there is an aspect of "incoming" and "originated" abuse. >Also, the "trouble" field is a good thought - maybe we should add >"trouble" to inetnum, as there is already a field name defined for the >purpose essentially. Just an idea. > >-- >Rev Adrian Kennard >Andrews & Arnold Ltd / AAISP www.aaisp.net.uk Regards, Wilfried (this time wearing my hat as DB-WG Chair :-) _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Never attribute to malice what can adequately be explained by incompetence.

2 1

RE: [db-wg] abuse-c
by TAYON, Julien 13 Jan '04

13 Jan '04

Christian Rasmussen <mailto:chr@jay.net> wrote: Hi Christian, >> >> I'd also like to see a mandatory/multiple abuse-c field containing a >> rfc-valid email address. > > Im not sure why it should be multiple? But I think most of us on this > list can agree with you that a valid abuse email address associated > with each inetnum in the database would be very welcome. >From what I have seen so far I would need: abuse: copyright.infringement@ourdomain // spam from some people abuse: system.attack@ourdomain // DoS, portscan .... abuse: spam@ourdomain abuse: legal@ourdomain // For cybersquatting, legal procedure But I am not sure the problem is only technic I see it partly as a matter of usage : if we where behaving the same even putting the abuse in remarks, desc or whatever the field is, people would get used to it, and they would stop writing to all address. Regards, -- Julien Tayon LDCOM networks BU DATA- +33 1 70 18 14 45 1 square Chaptal , 92309 Levallois Cedex

4 3