RE: [db-wg] Proposal: Abuse-C as a Reference
Ulrich Kiermayr wrote at 5/6/04 09:25:
This abuse-c inherits all the features of irt as well ...
Except that crypto is optional. Fair enough.
... resulting in just one object for this area
I suggest we keep IRT for the purpose for which it was built, and make no changes to it (so it will be different from the role or person used we make available for abuse). This might actually encourage the use of IRT objects, since it reduces the risk that CSIRTs will get abuse reports they mostly don't want. And IRTs may then be useful, so I don't support removing them.
Implementing abuse-c that way would give a 1:1 mapping between irt and role and therefore making irt obsolete (and the existing objects auto-convertable).
I think the 1-1 mapping is unnecessary; auto-copying is still possible. Can you confirm that the abuse-c: attribute can also refer to an IRT object for people who want to do it that way?
Add the missing features from irt: to the person and role objects:
person: [mandatory] [single] [lookup key] address: [mandatory] [multiple] [ ] phone: [mandatory] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [optional] [multiple] [lookup key] signature: [optional] [multiple] [ ] <-- encryption: [optional] [multiple] [ ] <-- nic-hdl: [mandatory] [single] [primary/look-up key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [optional] [multiple] [inverse key] ref-nfy: [optional] [multiple] [inverse key] <-- mnt-ref: [optional] [multiple] [ ] <-- changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ]
Do we need a dedicated attribute in role and person? abuse-mail: [optional] [multiple] [ ] (or the name could be 'abuse-mailbox' as in Ulrich's example) Does the attribute need to be a lookup key like e-mail? (again as in the example) Should we make the abuse-mail attribute mandatory for the object types concerned? But that might force us to use a new object type :-(
Query behaviour:
Return abuse-c by default as well
The thing to return is not the name of the abuse-c reference; it's the abuse-mail attribute of the object referred to. Perhaps that's what you meant anyway?
Return abuse-c by default as well (or include default -c i.e. return abuse-c from the least specific inetnum containing the ip in question).
Not quite, surely. We want to provide one user population with exactly one e-mail address and not too much else; so somehow we have to walk the database for them and not put the burden on them or their client software. I do not believe we can expect tool writers (eg SpamCop, geektools) to do that for us; I do not believe we can deploy a different whois client. We might get away with publishing a different server location (whois-for-the-masses.ripe.net? abuse.ripe.net?); or with putting this behaviour on whois.ripe.net and moving the present behaviour to a new address. But don't we want to present the mail address derived from the _most_ specific inetnum (rather than the least)?
Change the -c flag to use abuse-c instead of mnt-irt.
No need to change that behaviour if we take the above approach. Rodney Tillotson, JANET-CERT
Hi,
This abuse-c inherits all the features of irt as well ... Except that crypto is optional. Fair enough.
Intentionally here (since it modifies existing object tempates - using mandatory here is not a good itea(tm))
... resulting in just one object for this area
I suggest we keep IRT for the purpose for which it was built, and make no changes to it (so it will be different from the role or person used we make available for abuse).
This might actually encourage the use of IRT objects, since it reduces the risk that CSIRTs will get abuse reports they mostly don't want. And IRTs may then be useful, so I don't support removing them.
Fair enough as well. (though I'd like to think about that a little more)
I think the 1-1 mapping is unnecessary; auto-copying is still possible.
You basically get that basically for free: All the attributes I added to person/role i conscider useful independently of this topic.
Can you confirm that the abuse-c: attribute can also refer to an IRT object for people who want to do it that way?
This goes against how i understand the database's logic. so No. The issue here is what I tried to point out before lunch: the mindset of irt being a maintainer is flawed. anf for that reason I originally proposed this migration irt-> person/role (wether te attribute is called abuse-c, security-c, irt-c, or whatever is a matter of taste)
Do we need a dedicated attribute in role and person? abuse-mail: [optional] [multiple] [ ]
This is the part that I was not sure of.
(or the name could be 'abuse-mailbox' as in Ulrich's example) Does the attribute need to be a lookup key like e-mail? (again as in the example)
probably yes.
Should we make the abuse-mail attribute mandatory for the object types concerned?
No - for the same reasons as with encryption above and:
But that might force us to use a new object type :-(
Return abuse-c by default as well The thing to return is not the name of the abuse-c reference; it's the abuse-mail attribute of the object referred to. Perhaps that's what you meant anyway?
This depends. Id. Like this discussed in the broader-sense of what the Database returns how. Would for example a comment above the Returned objects be useful: % This is the RIPE Whois server. % The objects are in RPSL format. % % Rights restricted by copyright. % See http://www.ripe.net/ripencc/pub-services/db/copyright.html inetnum: 131.130.7.32 - 131.130.7.47 mnt-irt: IRT-UK org: ORG-UK1-RIPE netname: UK-V4 descr: LAN Ulrich Kiermayr country: AT admin-c: UK6107-RIPE tech-c: UK3 abuse-c: UK3 mnt-by: AS760-MNT mnt-by: UK-MNT status: ASSIGNED PA changed: ulrich.kiermayr@univie.ac.at 20020822 changed: uk@uk.atat.at 20040128 source: RIPE % % Administrative Contact: person: Ulrich Kiermayr address: Vienna University address: Computer Center address: Universitaetsstrasse 7 address: A-1010 Vienna address: Austria phone: +43 1 4277 14104 fax-no: +43 1 4277 9140 e-mail: Ulrich.Kiermayr@UniVie.ac.at nic-hdl: UK6107-RIPE remarks: GPG-Key: PGPKEY-A8D764D8 mnt-by: ACONET-LIR-MNT changed: panigl@cc.univie.ac.at 20010629 changed: kiermayr@cc.univie.ac.at 20020603 changed: ulrich.kiermayr@univie.ac.at 20020805 source: RIPE % % Technical and Abuse Contact: person: Ulrich Kiermayr address: Lacknergasse 71/23 address: A-1180 Wien address: AT phone: +43 1 5248266 phone: +43 664 8174818 e-mail: Ulrich.Kiermayr@UniVie.ac.at nic-hdl: UK3 remarks: GPG-Key: PGPKEY-A8D764D8 mnt-by: UK-MNT notify: Ulrich.Kiermayr@UniVie.ac.at changed: Ulrich.Kiermayr@UniVie.ac.at 20020723 source: RIPE In the classical whois inteface i se broblems modifing information presented. i.e. you should be able to put into the machinary exactly what the DB gave you in the query. (Otherwise tools migt break). But I see no problen in structuring this by means of comments (which are present on top anyway with the well denoted %-sign). or does RPSL prohibit this?
Return abuse-c by default as well (or include default -c i.e. return abuse-c from the least specific inetnum containing the ip in question).
wich in the above Idea means: % % Closest Match Abuse Contact: .....
Not quite, surely. We want to provide one user population with exactly one e-mail address and not too much else; so somehow we have to walk the database for them and not put the burden on them or their client software. I do not believe we can expect tool writers (eg SpamCop, geektools) to do that for us; I do not believe we can deploy a different whois client. We might get away with publishing a different server location (whois-for-the-masses.ripe.net? abuse.ripe.net?); or with putting this behaviour on whois.ripe.net and moving the present behaviour to a new address.
more of the first (because of what I stated above).
But don't we want to present the mail address derived from the _most_ specific inetnum (rather than the least)?
Sorry this was a typo. substitute least by most in my statement.
Change the -c flag to use abuse-c instead of mnt-irt.
Depends. -c is handy for both things i think. lG uk -- Ulrich Kiermayr Zentraler Informatikdienst der Universitaet Wien Network - Security - ACOnet-CERT Universitaetsstrasse 7, 1010 Wien, AT eMail: ulrich.kiermayr@univie.ac.at Tel: (+43 1) 4277 / 14104 PGP Key-ID: 0xA8D764D8 Fax: (+43 1) 4277 / 9140
Hi,
Not quite, surely. We want to provide one user population with exactly one e-mail address and not too much else;
In an ideal world (tm). The database would contain e-mail addresses in objects that describe a person or a group of persons (because only they can actually read eMails). everywhere else (i.e. Notifications/changed,....) should contain a reference to that someone. Because: What you do is to notify/inform/write something to _someone_ having an email address, and not notifying a Mailbox. This in conjunction whith the comment thing from my last mail should actually make the 'normal' output understandable to anyone who reads [1]. But I know that this would Imply a _major_ change in the way the Database works, and therefore I suppose it is not realistic. But at least the comments migt help in that case. lG uk [1] Howver I know that the ability to read scales whith the Clue-Density defined in the Secret-WG, so all of this might not solve any of these issues ;-) -- Ulrich Kiermayr Zentraler Informatikdienst der Universitaet Wien Network - Security - ACOnet-CERT Universitaetsstrasse 7, 1010 Wien, AT eMail: ulrich.kiermayr@univie.ac.at Tel: (+43 1) 4277 / 14104 PGP Key-ID: 0xA8D764D8 Fax: (+43 1) 4277 / 9140
Ulrich Kiermayr wrote:
Would for example a comment above the Returned objects be useful:
One idea that came up over conversation with Wilfried (IIRC) was to replace the e-mail addresses in all objects with references to contact objects. This would include notification addresses and the changed lines: notify: mnt-nfy: upd-to: irt-nfy: ref-nfy: changed: This might help by removing spurious e-mail addresses from the output. Modifying Ulrich's example, we would get: % This is the RIPE Whois server. % The objects are in RPSL format. % % Rights restricted by copyright. % See http://www.ripe.net/ripencc/pub-services/db/copyright.html inetnum: 131.130.7.32 - 131.130.7.47 mnt-irt: IRT-UK org: ORG-UK1-RIPE netname: UK-V4 descr: LAN Ulrich Kiermayr country: AT admin-c: UK6107-RIPE tech-c: UK3 abuse-c: UK3 mnt-by: AS760-MNT mnt-by: UK-MNT status: ASSIGNED PA changed: 20020822 UK3 changed: 20040128 source: RIPE % % Administrative Contact: person: Ulrich Kiermayr address: Vienna University address: Computer Center address: Universitaetsstrasse 7 address: A-1010 Vienna address: Austria phone: +43 1 4277 14104 fax-no: +43 1 4277 9140 e-mail: Ulrich.Kiermayr@UniVie.ac.at nic-hdl: UK6107-RIPE remarks: GPG-Key: PGPKEY-A8D764D8 mnt-by: ACONET-LIR-MNT changed: 20010629 CP8-RIPE changed: 20020603 changed: 20020805 UK3 source: RIPE % % Technical and Abuse Contact: person: Ulrich Kiermayr address: Lacknergasse 71/23 address: A-1180 Wien address: AT phone: +43 1 5248266 phone: +43 664 8174818 e-mail: Ulrich.Kiermayr@UniVie.ac.at nic-hdl: UK3 remarks: GPG-Key: PGPKEY-A8D764D8 mnt-by: UK-MNT notify: UK3 changed: 20020723 UK3 source: RIPE % % Incident Response Team: irt: IRT-UK address: Lacknergasse 71/23 address: A-1180 Wien address: AT phone: +43 1 5248266 phone: +43 664 8174818 e-mail: Ulrich.Kiermayr@UniVie.ac.at signature: PGPKEY-A8D764D8 encryption: PGPKEY-A8D764D8 admin-c: UK3 tech-c: UK3 irt-nfy: UK3 auth: PGPKEY-A8D764D8 notify: UK3 mnt-by: UK-MNT changed: 20020820 UK3 changed: 20030115 UK3 source: RIPE %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% In this case, we only get a single e-mail address. Now, this would still not solve the case of people just searching for '@' and sending e-mail, but it would help the problem. Notice that I've put the comments in separate blocks, to help people who parse one object at a time. I've also swapped the order on the "changed:" attribute, also to ease parsing, since we will always have a date but maybe not always other information. -- Shane Kerr RIPE NCC
Hi Shane, Hi *
One idea that came up over conversation with Wilfried (IIRC) was to replace the e-mail addresses in all objects with references to contact objects. This would include notification addresses and the changed lines:
notify: mnt-nfy: upd-to: irt-nfy: ref-nfy: changed:
As I stated In an other Mail, this not only helps in this issue, but to me would seem as mor logical, than what we have at the moment.
In this case, we only get a single e-mail address. Now, this would still not solve the case of people just searching for '@' and sending e-mail, but it would help the problem.
Yes because it at least would only go to persons rols that have a direct responsibility for the object, not the ones who maintain the Database.
Notice that I've put the comments in separate blocks, to help people who parse one object at a time.
Yes, I overlooked that.
I've also swapped the order on the "changed:" attribute, also to ease parsing, since we will always have a date but maybe not always other information.
as long as the autmatical adding of the changed-date is handeled as well, it sound reasonable. So we might get to the ideal world(tm) after all? lG uk -- Ulrich Kiermayr Zentraler Informatikdienst der Universitaet Wien Network - Security - ACOnet-CERT Universitaetsstrasse 7, 1010 Wien, AT eMail: ulrich.kiermayr@univie.ac.at Tel: (+43 1) 4277 / 14104 PGP Key-ID: 0xA8D764D8 Fax: (+43 1) 4277 / 9140
On Mon, May 10, 2004 at 02:57:44PM +0200, Shane Kerr wrote:
Ulrich Kiermayr wrote:
Would for example a comment above the Returned objects be useful:
One idea that came up over conversation with Wilfried (IIRC) was to replace the e-mail addresses in all objects with references to contact objects. This would include notification addresses and the changed lines:
notify: mnt-nfy: upd-to: irt-nfy: ref-nfy: changed:
This might help by removing spurious e-mail addresses from the output. Modifying Ulrich's example, we would get:
<snip>
% % Technical and Abuse Contact:
Didn't reply to Ulrich's mail yet, but I think this is not good[tm] as the whole problem is that people mail tech-c/admin-c with abuse complaints. I would rather see them separated, also in the comments.
In this case, we only get a single e-mail address. Now, this would still not solve the case of people just searching for '@' and sending e-mail, but it would help the problem.
Notice that I've put the comments in separate blocks, to help people who parse one object at a time. I've also swapped the order on the "changed:" attribute, also to ease parsing, since we will always have a date but maybe not always other information.
I think it's still usefull to have more then a date only, otherwise I say we just drop the requirement for an email address in the changed attribute. This certainly would make the cleanup easier, we can just drop all existing data from the changed: attributes present and allow for people to add nic-handles again (or allow people to change it and after date X, we drop all old data). But I my gut feeling is that it's not good to just delete data from the db. Grtx, MarcoH
Hi,
% % Technical and Abuse Contact:
Didn't reply to Ulrich's mail yet, but I think this is not good[tm] as the whole problem is that people mail tech-c/admin-c with abuse complaints. I would rather see them separated, also in the comments.
Maybe it was a bad example, but in this case, they were the same, so the comment merged them, but one could also repeat them twice. lG uk -- Ulrich Kiermayr Zentraler Informatikdienst der Universitaet Wien Network - Security - ACOnet-CERT Universitaetsstrasse 7, 1010 Wien, AT eMail: ulrich.kiermayr@univie.ac.at Tel: (+43 1) 4277 / 14104 PGP Key-ID: 0xA8D764D8 Fax: (+43 1) 4277 / 9140
On 10.05.2004 at 14:57, Shane Kerr wrote:
inetnum: 131.130.7.32 - 131.130.7.47 % Administrative Contact: person: Ulrich Kiermayr % Technical and Abuse Contact: person: Ulrich Kiermayr
Just one simple adjustment: the abuse contact should be the first diplayed, so that it is the first address found. Cheers Hendrik -- Hendrik T. Voelker HTV5-RIPE MCI EMEA Registrar Team UUNET Deutschland GmbH, Sebrathweg 20, 44149 Dortmund, GERMANY A MCI Company tel+49-231-972-1565 fax+49-231-972-1180 http://www.mci.com/de/
Hi, On Fri, May 07, 2004 at 03:05:12PM +0200, Ulrich Kiermayr wrote:
% % Administrative Contact: person: Ulrich Kiermayr address: Vienna University
I like that approach - because you can then have:
% % Closest Match Abuse Contact: .....
... which should be displayed in any case. Right now, the whole "-c" semantics is nice, but not *that* useful, because the irt: object itself isn't fetched - you will get back the "next lower level inetnum with an mnt-irt:", but then you have to issue yet another query to get the actual irt: contacts (or did I miss something here?). So the sequence is: - whois -c $ip - if nothing returned, get "whois $ip | grep e-mail:" - if something returned, parse result, query "whois $irt" from an infamous tool writer's perspective, this is quite some effort, and "whois $ip | grep @ | uniq | spam" will in most cases also reach "someone"... [..]
Change the -c flag to use abuse-c instead of mnt-irt. Depends. -c is handy for both things i think.
Is there a flag that will make "-c" fetch the irt: object in the same whois call? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Hi,
from an infamous tool writer's perspective, this is quite some effort, and
"whois $ip | grep @ | uniq | spam"
will in most cases also reach "someone"...
It was proposed to order the aubuse-c up, to be displayed first. Thet it can be: whois $ip | grep ^e-mail: | head -1 | spam which should direct the stuff to the 'right place' or at least 'into the right direction'.
Is there a flag that will make "-c" fetch the irt: object in the same whois call?
Not at the moment. lG uk -- Ulrich Kiermayr Zentraler Informatikdienst der Universitaet Wien Network - Security - ACOnet-CERT Universitaetsstrasse 7, 1010 Wien, AT eMail: ulrich.kiermayr@univie.ac.at Tel: (+43 1) 4277 / 14104 PGP Key-ID: 0xA8D764D8 Fax: (+43 1) 4277 / 9140
Hi, On Tue, May 11, 2004 at 10:06:25AM +0200, Ulrich Kiermayr wrote:
from an infamous tool writer's perspective, this is quite some effort, and
"whois $ip | grep @ | uniq | spam"
will in most cases also reach "someone"...
It was proposed to order the aubuse-c up, to be displayed first. Thet it can be:
whois $ip | grep ^e-mail: | head -1 | spam
which should direct the stuff to the 'right place' or at least 'into the right direction'.
Yes, this would be very convenient indeed. :-) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
participants (6)
-
Gert Doering -
Hendrik T Voelker -
MarcoH -
Rodney Tillotson -
Shane Kerr -
Ulrich Kiermayr