- db-wg - mailman.ripe.net

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

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

13 Jan '04

MarcoH <mailto:marcoh@marcoh.net> wrote: > On Tue, Jan 13, 2004 at 04:14:13PM +0100, Christian Rasmussen wrote: >> Hi Marco, >> >> >> Okay, I think I now understand better what you mean. There are >> different levels of check of entered abuse address: >> >> 1. Nothing >> 2. Syntax check >> 3. Address validity check (as previously described) >> 4. Response time check > > level 4 would be to run random audits on the information present in > the database. > Last time I misfilled an inetnum abuse with a mnt-lower ( yes I did :( ). as my email was present in changed: they complained a lot to everybody even in the "upper block" including me that abuse email was wrong. My idea is if internet user follow the RFC and their common erratic sense (i.e. complaining to the "upper authority" if no response from the implied inetnum) and we all read our emails, everything should be fine. I think internet users are really are our best low cost efficient auditing system, and we might listen to them. If you want to pay for something that is free though ... well it is no matter to me. -- Julien Tayon LDCOM networks BU DATA- +33 1 70 18 14 45 1 square Chaptal , 92309 Levallois Cedex

1 0

Database Modifications for X.509 Support
by Shane Kerr 13 Jan '04

13 Jan '04

All, Attached please find a description of the database modifications necessary to implement X.509 authentication in the RIPE Database. This is the outcome of previous discussions on the mailing list, presentations and discussions at RIPE meetings, and a review of the implementation details. The only new feature added is making "fingerpr:" an inverse key, which helps dbupdate lookup the appropriate X.509 key. -- Shane Kerr Software Engineering Group Manager RIPE NCC Database Modifications for X.509 Support 1. Proposal ------------- To add X.509 authentication to the RIPE Database. 2. Changes to the key-cert class -------------------------------- The key-cert class will be altered to allow both PGP and X.509 certificates to be represented. PGP certificates will remain the same. X.509 certificates will have the following attributes: - "key-cert:" will be of the form X509-nnn, where nnn is a unique number assigned by the database. (See "Primary key for X.509 KEY-CERT objects" below.) - "method:" will be X509. - "owner:" will be the Distinguished Name (DN) of the certificate. Sometimes this is called the certificate subject. - "fingerpr:" will be the MD5 fingerprint of the certificate. - "certif:" will contain the ASCII representation of the X.509 certificate. The "fingerpr:" attribute will become an inverse key. The format and meaning of all other attributes remain unchanged. Example of an X.509 KEY-CERT object: key-cert: X509-42 method: X509 owner: /C=NL/O=RIPE NCC/OU=Members/CN=eu.ripe-ncc.shane/Email=shane(a)ripe.net fingerpr: D5:92:29:08:F8:AB:75:5F:42:F5:A8:5F:A3:8D:08:2E certif: -----BEGIN CERTIFICATE----- certif: MIID/DCCA2WgAwIBAgICAIQwDQYJKoZIhvcNAQEEBQAwcTELMAkGA1UEBhMCRVUx certif: EDAOBgNVBAgTB0hvbGxhbmQxEDAOBgNVBAoTB25jY0RFTU8xHTAbBgNVBAMTFFNv . . . certif: hZNmF5c/d0gauqvL+egb+3V+Zg+sJTzHMVKQLF1ybWgJjU75Pi+mO7BG0zsQ13pT certif: YxuZCR2W15nwt7zLiHtmfw== certif: -----END CERTIFICATE----- remarks: Sample Key Certificate notify: ripe-dbm(a)ripe.net mnt-by: RIPE-DBM-MNT changed: ripe-dbm(a)ripe.net 20040101 source: RIPE 3. Primary key for X.509 KEY-CERT objects ----------------------------------------- The "key-cert:" attribute is the primary key of KEY-CERT objects. This will be given a generated value that is the object ID. X.509 object IDs are auto-generated similar to the way person/role "nic-hdl:" attributes are auto-generated. For new KEY-CERT objects, the user must use AUTO-<digit> during creation of the object, it will then it will be assigned an appropriate ID. The key-cert ID cannot be reused. If a key-cert ID was used in the past by a KEY-CERT object and then deleted, this ID cannot be used in new KEY-CERT objects. Using a unique identifier is different from the PGP object IDs. In PGP, the key ID is used as part of the object ID (specified in RFC 2726). This is a 32-bit value, expressed in hexadecimal. There are several problems with this. Collisions occur (*), and keys can be spoofed (**). This is less of a problem with X.509 because it uses much longer fingerprints; however, in any system where the source of the fingerprint is passed to other users the possibility exists of a third party adding the certificate to the database. 4. Change to the "auth:" attribute ---------------------------------- The "auth:" attribute is present in MNTNER and IRT objects, and specifies the authentication scheme of the maintainer. The following additional value will be added: X509-<id> Strong scheme of authentication. This string is the same one that is used in the corresponding KEY-CERT object's "key-cert:" attribute. 5. Change to authentication --------------------------- When a maintainer specifies an X.509 KEY-CERT object the signature, using the private key associated with the certificate contained in the KEY-CERT object, will authenticate that maintainer. 6. Changes to e-mail processing ---------------------------- S/MIME messages will be accepted. S/MIME messages must not be encrypted; an encrypted message will be rejected as invalid input. Either the whole message may be an S/MIME signed message or one MIME part may contain an S/MIME signed message. S/MIME may be used fully, partially, or not at all with other authentication mechanisms. Therefore, it is acceptable to receive a message that is an S/MIME signed message which has been further signed by PGP, or an S/MIME message may be forwarded with the addition of a password at the outer level. 7. Changes to synchronous updates --------------------------------- The server will accept SSL connections with any client side certificate, this certificate will be used to authenticate any updates. (*) http://www.imc.org/ietf-openpgp/mail-archive/msg00484.html (**) http://archives.neohapsis.com/archives/vuln-dev/2001-q4/0147.html

2 1

abuse-c
by Rev Adrian Kennard 13 Jan '04

13 Jan '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am new to this mailing list, so forgive me if this has been covered before. It seems there is a pretty clear need for an extra field in inetnum and inet6num records, specifically something like an abuse-c field referencing a person record. A lot of inetnum records I have seen have a remarks field identifying the abuse ocntact, but this is in an inconsistent format making it difficult to automate in any way. It also seems that a lot of network administrators (admin-c) do not feel they should administer their network to remove viruses, etc, and get quite annoyed when contacted regarding abuse. What would be the procedure for proposing such a new field? - -- Rev Adrian Kennard uk.aa -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE//o/MHBb4e52L0Y0RAoPzAJ9Vp94eC6DMAPvAK7Lx5HiiVBPQSgCfTfFZ HfzTEAB6TwmsFBbivTe4KaU= =mlgj -----END PGP SIGNATURE-----

14 29

Re: abuse-c
by Thor Kottelin 13 Jan '04

13 Jan '04

So, we already have the irt object and the trouble attribute. Additionally, abuse is often reported based on admin-c, tech-c, changed, remarks and $DEITY knows what. Please let's not add to the confusion by creating even more attribute or object types. As for the irt object requiring a maintainer, that requirement exists for security, the need for which should be obvious in the context of abuse reports as well. The obvious hardliner approach would be to require future inetnum updates to carry valid mnt-irt attributes. Thor -- http://thorweb.anta.net/

3 3

Re: db-wg digest, Vol 1 #152 - 13 msgs
by Rev Adrian Kennard 12 Jan '04

12 Jan '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 | From: Thor Kottelin <thor(a)anta.net> | So, we already have the irt object and the trouble attribute. | Additionally, | abuse is often reported based on admin-c, tech-c, changed, remarks and | $DEITY knows what. Please let's not add to the confusion by creating | even more attribute or object types. There is a clear problem with what we have now, whether techncially or simply awareness, as it is clear that lots and lots of inet[6]num objects have remarks identifying abuse contacts in a variety of formats. There is a need for people to identify abuse contacts associated with an IP[6]. "trouble" does not help as it is also free format and so not much better than remarks. "irt" may be the answer, and I am creating one for our use at present (still not had a reply - why is it a manual process?). It may be over complex. It is not well publicised to those that need to know. Even those that know of it (and I had seen it) do not realise it is the way to put an abuse contact on an inetnum (hence my original question). FYI, our abuse report scripts now look for a mnt-irt field and if not found go for the admin-c field. They used to just go for the admin field. However, I do think something has to be done as it is a nonsense the way it is now. - -- Rev Adrian Kennard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAAufMHBb4e52L0Y0RAoHlAJ0ZLrp5QiftL7iWEqpcUxVUxZjLSgCcC8Vo j86xkD4uQ0dcTkzcWOOjtaU= =ykiB -----END PGP SIGNATURE-----

1 0

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

12 Jan '04

Hi John! >Menno Pieters (Stelvio) wrote: >> TI is an organisation that verifies the information, so that it can be >> *trusted*. For ordinary users it may be to hard to understand this and >> how to make sure it all correct. For IRT among eachother it may be >> important. > >But all that going via the TI route gives you is a "mnt-by: TI" entry in >your object. Yes - what is wrong with that? > There are other non-RIPE ways for teams to infer how much >trust they should give to another team, Correct. >and overloading mnt-by seems undesirable. Maybe, but I don't see what the downside is in using a mechanism which is there, instead of inventing something new. Actually it was - maybe - blue-eyed to invent a new object type. Inventing a new attribute _without a proper syntax and semantic to go with it_ is probably not too much better... >Some useful changes would be renaming the IRT object to something more >general, like Abuse (?) object If we can reach consensus that this should be the name I expect the NCC to make the necessary modifications to the implementation. The problem (which was discussed in various environments more than once!) is that different entities have a different interpretation of the word "abuse". >and for it to be returned by default when querying an IP (or AS). I keep hearing that again and again (and from the incident/abuse point of view I agree!), so I'll put it onto the DB-WG. Maybe others can try to put it onto other WGs' agendas, as this is a pretty big change to the behaviour of the whois server. >The seperation into an easily maintainable object which includes stuff >in addition to email address (like postal address, pgp and phone) are >useful enhancements to "trouble:". > >Cheers >John Wilfried.

2 1

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

12 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? Or - what is the query to get this from ARIN? Thanks, Wilfried.

2 1

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

12 Jan '04

Christian, >I have a lot of inetnum objects which I need the same abuse address for so I >would REALLY appriciate not having to change each and everyone of them!.. :) supporting that was one of the goals in the design of the IRT object. All the (resources described by a set of) objects which are handled by the same incident team or function just get linked to the same IRT object. If you want to make any changes, then you update the info in _one_ place - much like the maintainer approach. And, the IRT structure supports hierarchy (for those resources which do have a hierarchy :-) It allows quite a few other things to be nicely described and maintained, eg. - giving key info if you want to use encryption for your complaint, or verify the identity of the security contact you get an answer from - decoupling of IP-Address management from operations ("rouitng") and incident handling - registering credibility info with this contact info, like the Trusted Introducer, which was the first structure to use this machinery. We are definitely still missing some things to make it fly high... Things that come to my mind without doing a full inventory: - make additional documentation available (TF-CSIRT is actively working on this) - try to get it deployed and _used_ (I'd look into the direction of the Anti-Spam folks to help with this) - maybe modify the default answer from the server for a whois query (what would the impact be on the "other" users of the registry data?) - try to define complaint handling roles in a concise way to allow selecting the "correct" contact from an object. (this doesn't chance whether you put it into an inetnum or an IRT object ;-) (I guess there will be another attempt in Madrid next week to deal with that amongst the incident handlers, and we may come back with a proposal or at least an idea) Wilfried.

1 0

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

12 Jan '04

John Green <mailto:j.green@ukerna.ac.uk> wrote: > I have never understood what this gives you. If "Evil Company" wants > to misdirect abuse reports (why?) they can circumvent this by making > a fake IRT object with IRT XYZ as the contact email address. > If people circumvent this they are either evil or incompetent which is alreday a strong hint to be suspicious. Julien Tayon LDCOM networks BU DATA- +33 1 70 18 14 45 1 square Chaptal , 92309 Levallois Cedex

4 4

Defined roles
by Rev Adrian Kennard 12 Jan '04

12 Jan '04

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? Only update the RIPE > Database? Coordinate with the RIPE NCC? Is it the CEO of a company? > The manager of the IT department? Or an independent contractor who handles > all the details of connectivity? 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? 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. 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). I suspect to go this far would request some legal framework in countries affected, 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. 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. 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

1 0

E-mail Client Testing for S/MIME Compliance
by Denis Walker 09 Jan '04

09 Jan '04

[apologies for duplicate messages] Dear Colleagues, At the RIPE 45 Meeting a proposal was presented to implement an additional form of strong authentication for protecting objects in the RIPE Database and to allow for secure communication by e-mail with the RIPE NCC. This implementation uses the X.509 certificates. A question was raised by some members about how widespread is the compliance of S/MIME within mail clients. The RIPE NCC Software Engineering Department has undertaken a study to evaluate the use of S/MIME by mail clients. The results of this study can be found on our web site at: http://www.ripe.net/ripencc/pub-services/db/mail_client_tests.html Regards, -- Denis Walker Software Engineering Department RIPE NCC

4 5

Domail Clean-up
by RIPE Database Manager 06 Jan '04

06 Jan '04

Dear Colleagues, As of 6 January, 2004, messages concerning inconsistencies between "nserver:" attributes in DOMAIN objects and delegation NS RRs in our zone files will be sent out. The messages will be mailed to various contact addresses for the relevant DOMAIN objects. In addition to the description of the inconsistencies, an indication of the 'default actions' will also be provided. We kindly request data be updated so that the inconsistencies are corrected before 1 March, 2004. About two weeks before 1 March, 2004 we will send a second set of warnings for the remaining inconsistencies. By 1 March, 2004 all remaining inconsistencies will be cleaned by the RIPE NCC, using the 'default actions'. If you receive a warning about inconsistencies we recommend that you fix the data yourself. It may be that you receive multiple mails for multiple domains with multiple inconsistencies. If you want to configure a dedicated mail filter the messages will contain the subject header "Subject: Reverse DNS inconsistencies in the RIPE Database" and originate "From: <ripe-dbm(a)ripe.net>". If you have further questions please contact <ripe-dbm(a)ripe.net>. Background The cleanup is part of the effort to streamline reverse DNS operations [1] and make it easier for network range users to manipulate related DOMAIN objects. The goal of the cleanup [2] is to streamline the contents of DOMAIN objects and zone configuration files so that we can create zone files from the Whois Database. An explanation of the various possible inconsistencies can be found at: http://www.ripe.net/reverse/rdns-project/Cleanup.html. ----- [1]: Original proposal http://www.ripe.net/reverse/proposal.html. Discussion on this proposal has taken place on the RIPE NCC Services WG mailing list and was summarized in: http://www.ripe.net/ripe/mail-archives/ncc-services-wg/2003/msg00361.html [2]: Original cleanup proposal http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00738.html. ----- Can Bican Software Engineering Department Olaf Kolkman New Projects Group RIPE NCC

1 0

creating a mntner
by Randy Bush 29 Dec '03

29 Dec '03

so, i have a clean database, 3.2.0 server running, blah blah blah now i have the old problem of creating a first mntner: i run bin/dbupdate -c conf/rip.config -t -d mntner: MAINT-RGNET descr: RGnet admin-c: RB366 upd-to: rw(a)rg.net auth: NONE override: <cleartext override password> mnt-by: MAINT-RGNET referral-by: MAINT-RGNET changed: randy(a)psg.com 20031217 source: RGNET ^D and it pukes saying Create FAILED: [mntner] MAINT-RGNET ***Info: Syntax check passed mntner: MAINT-RGNET descr: RGnet admin-c: RB366 upd-to: rw(a)rg.net auth: NONE mnt-by: MAINT-RGNET referral-by: MAINT-RGNET changed: randy(a)psg.com 20031217 source: RGNET ***Error: Unknown object referenced and the interesting part of the debug output up_source_commit: entered with operation [UP_CREATE] up_send_object_db: entered, operation [UP_CREATE] up_send_object_db: object to be sent [ mntner: MAINT-RGNET descr: RGnet admin-c: RB366 upd-to: rw(a)rg.net auth: NONE mnt-by: MAINT-RGNET referral-by: MAINT-RGNET changed: randy(a)psg.com 20031217 source: RGNET ] up_get_transaction_id: entered spent 0.00 sec; got 1 rows from [dbrgnet: INSERT INTO tid VALUES(NULL)] up_get_transaction_id: exiting with new id [18] up_send_object_db: transaction ID [18] SK_write = { sockfd=[7], buf=[ADD], count=[3] SK_write = { sockfd=[7], buf=[ ], count=[1] SK_write = { sockfd=[7], buf=[18], count=[2] SK_write = { sockfd=[7], buf=[ ], count=[2] SK_write = { sockfd=[7], buf=[mntner: MAINT-RGNET descr: RGnet admin-c: RB366 upd-to: rw(a)rg.net auth: NONE mnt-by: MAINT-RGNET referral-by: MAINT-RGNET changed: randy(a)psg.com 20031217 source: RGNET ], count=[218] SK_write = { sockfd=[7], buf=[ ], count=[2] SK_write = { sockfd=[7], buf=[ACK ], count=[4] SK_write = { sockfd=[7], buf=[18], count=[2] SK_write = { sockfd=[7], buf=[ ], count=[2] up_send_object_db: send complete up_send_object_db: received from socket [ %ERROR 4 ] up_send_object_db: received from socket [ E[4][1:RB366]:ref integrity: reference cannot be resolved ] up_send_object_db: received from socket [ ] up_send_object_db: received blank line from socket, stop reading Closing socket... 7 up_send_object_db: exiting with value UP_OK up_interpret_ripudb_result: entered, ripupd_result [%ERROR 4 E[4][1:RB366]:ref integrity: reference cannot be resolved clue by four, please randy

4 11

Re: [db-wg] 3.2.0 make_db getvar cores
by Randy Bush 19 Dec '03

19 Dec '03

> Everything seems OK in your config files you've sent. I could not > replicate your problem. My best bet is that, in rip.config > SOURCEFILE /usr/home/whois/conf/sources.config > points to a file which is _not_ the one you've sent. sigh. with that gdb output? puhleeze! (gdb) back #0 0x805087d in ca_parseSrcLine (lineStr=0xbfbff74c "database:\tdbrgnet", srcStructPtr=0x80c8400) at ca_sourceLoader.c:792 #1 0x8050147 in ca_readSources ( sourcesDefFile=0x80c2840 "/usr/home/whois/conf/sources.config", confVars=0x80b1840) at ca_sourceLoader.c:464 #2 0x804faa2 in ca_init (configFile=0xbfbff9b1 "../conf/rip.config") at ca_initFn.c:87 #3 0x804bc2f in main (argc=7, argv=0xbfbff858) at getvar.c:84 let me try to debug by turning on debugging in ca_sourceLoader.c # /usr/home/whois/utils/getvar -s SAMPLE -c /usr/home/whois/conf/rip.config -p dbhost Inside ca_readSources() function. Sources file is: /usr/home/whois/conf/sources.config We are reading a comment or an empty line ..... line:DATABASE SAMPLEDB:End of line Length of line: 17 LINE >>>DATABASE SAMPLEDBEND_OF_LINE Beginning of a database defintion ..... Database name is: SAMPLEDB line:host: localhost:End of line Length of line: 16 LINE >>>host: localhostEND_OF_LINE tokens[0] = host tokens[1] = localhost VarName: host; dbComp: localhost line:port: 3306:End of line Length of line: 11 LINE >>>port: 3306END_OF_LINE tokens[0] = port tokens[1] = 3306 VarName: port; dbComp: 3306 line:trx_support: n:End of line Length of line: 14 LINE >>>trx_support: nEND_OF_LINE tokens[0] = trx_support tokens[1] = n VarName: trx_support; dbComp: n line:user: rip:End of line Length of line: 10 LINE >>>user: ripEND_OF_LINE tokens[0] = user tokens[1] = rip VarName: user; dbComp: rip line:password: secret:End of line Length of line: 19 LINE >>>password: secretEND_OF_LINE tokens[0] = password tokens[1] = secret VarName: password; dbComp: secret line:/DATABASE:End of line Length of line: 9 LINE >>>/DATABASEEND_OF_LINE We have reached the end of a DATABASE definition Testing the population of the db structure: localhost::3306::n::rip::secret:: ^ wowie zowie! no database name ^ the very problem we sought guess what happens when the password is nine characters! .../ripe-dbase-3.2.0# grep -c strcpy ./modules/ca/ca_sourceLoader.c 16 oh wonderful and thanks a million for the debugging help randy

1 0

3.2.0 make_db getvar cores
by Randy Bush 17 Dec '03

17 Dec '03

o freebsd 4.9-stable, quite recent o all ports just rebuilt o wanted to do a clean fresh install of whois 3.2.0, as i could not successfully convert o successful build o successful install conf/rip.config same as used for 3.1.1 excpt did emacs diff merge to get the syntax changes conf/sources.rip same as used for 3.1.1 except added trx_support: n in mysql, i deleted both databases, RIPADMIN and dbrgnet /scripts# ./make_db -c ../conf/rip.config -s RGNET -0 Error: Non-existent database "dbrgnet" referenced !!! died: +792 ca_sourceLoader.c Segmentation fault (core dumped) ************** ERROR *************** *** 05:19:01 unknown source RGNET ************************************ # gdb /usr/local/src/net/ripe-dbase-3.2.0/utils/getvar/getvar getvar.core GNU gdb 4.18 (FreeBSD) Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"...Deprecated bfd_read called at /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/dbxread.c line 2627 in elfstab_build_psymtabs Deprecated bfd_read called at /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/dbxread.c line 933 in fill_symbuf Core was generated by `getvar'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/lib/libgthread12.so.3...done. Reading symbols from /usr/local/lib/libglib12.so.3...done. Reading symbols from /usr/local/lib/mysql/libmysqlclient_r.so.10...done. Reading symbols from /usr/lib/libm.so.2...done. Reading symbols from /usr/lib/libcrypt.so.2...done. Reading symbols from /usr/lib/libpam.so.1...done. Reading symbols from /usr/lib/libcipher.so.2...done. Reading symbols from /usr/local/lib/libxml2.so.5...done. Reading symbols from /usr/local/lib/libiconv.so.3...done. Reading symbols from /usr/local/lib/libxslt.so.2...done. Reading symbols from /usr/lib/libc_r.so.4...done. Reading symbols from /usr/lib/libz.so.2...done. Reading symbols from /usr/libexec/ld-elf.so.1...done. #0 0x805087d in ca_parseSrcLine (lineStr=0xbfbff74c "database:\tdbrgnet", srcStructPtr=0x80c8400) at ca_sourceLoader.c:792 792 die; (gdb) back #0 0x805087d in ca_parseSrcLine (lineStr=0xbfbff74c "database:\tdbrgnet", srcStructPtr=0x80c8400) at ca_sourceLoader.c:792 #1 0x8050147 in ca_readSources ( sourcesDefFile=0x80c2840 "/usr/home/whois/conf/sources.config", confVars=0x80b1840) at ca_sourceLoader.c:464 #2 0x804faa2 in ca_init (configFile=0xbfbff9b1 "../conf/rip.config") at ca_initFn.c:87 #3 0x804bc2f in main (argc=7, argv=0xbfbff858) at getvar.c:84 randy

2 2

Re: [sed] problem updating database to 3.2.0
by Randy Bush 17 Dec '03

17 Dec '03

engin pointed out my stupid, using the admin db as opposed to the whois db. but now i fail on the last set # mysql -ufoo -pbar -Ddbrgnet -e'ALTER TABLE acl ADD COLUMN threshold tinyint(3) unsigned Default '4' NOT NULL after trustpass' $SOURCE ERROR 1146 at line 1: Table 'dbrgnet.acl' doesn't exist # mysql -ufoo -pbar -Ddbrgnet -e'ALTER TABLE acl ADD COLUMN maxconn tinyint(3) unsigned Default '6' NOT NULL after threshold' $SOURCE ERROR 1146 at line 1: Table 'dbrgnet.acl' doesn't exist another clue by four please randy

2 1