call for agenda items, DB-WG, RIPE48 @AMS
Dear DB WG! Our next meeting is scheduled for less than a month from today, so it is time to ask for agenda items for the draft agenda. Support items for the logistics will be provided by Nigel T. and myself, the meet on the bones should be suggested from "your" end:-) Looking forward to meet many of you in Amsterdam! Wilfried ( https://cert.aco.net/ ) _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber@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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ...there's no place like 127.0.0.1 (or is it ::1 ?)
On 5 Apr 2004, at 12:41, Wilfried Woeber, UniVie/ACOnet wrote:
Our next meeting is scheduled for less than a month from today, so it is time to ask for agenda items for the draft agenda.
Proposal for Adding Abuse Contact for inet*num: Objects in RIPE Database This proposal responds to action item AP-47.2 arising from the RIPE Database Working Group Meeting at RIPE 47. Niall O'Reilly Randy Bush 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. One variant or another of this approach appears also to be the basis on which a number of notification robots are built. The result is that alerts are too often misdirected, may never reach an appropriate contact person, and even if they do, are unnecessarily delayed. There is an apparent need to provide, document, and promote a means for clearer advertisement and retrieval of the appropriate abuse contacts. This need seems to be clearly applicable to the inetnum: and inet6num: objects. A new attribute for these objects is defined to address this apparent need. Each of these objects must already have person: or role: objects linked to the admin-c: and tech-c: attributes. Many of them also use the mnt-by: attribute to link to a mntner: object. We propose allowing the new attribute to be used in these objects as well. Since a single person:, role:, or mntner: object may be linked to a large number of inet*num: objects, this approach allows the abuse contacts to be advertised for a large number of inet*num: objects simply by specifying them in a much smaller number of linked objects. This is expected to reduce very significantly the effort involved in taking advantage of our proposal. Should there be similar needs in other object types, it is anticipated that the abuse-mailbox: attribute described below would be added to those objects as appropriate. Three things are needed: - The inetnum:, inet6num:, person:, role: and mntner: objects are extended with an optional attribute "abuse-mailbox:". The value of this attribute must be a valid and active RFC-2822 e-mail address. - The procedure for identifying the appropriate abuse contact for a given inet*num: object in the database must be defined and instantiated in a reference implementation. - This procedure must be documented and promoted as the one and only method that should be used to identify the contact address for reporting 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-mailbox: is the one and only place to which abuse should be reported, and that other contacts in the objects should not be abused. Extension to database objects: The objects addressed by this proposal (inetnum:, inet6num:, person:, role:, mntner:) would be extended by the addition to their templates of a new attribute definition, as follows. abuse-mailbox: [optional] [multiple] [inverse key] The value of the "abuse-mailbox:" attribute must be a valid and active RFC-2822 address. Optionally, the value of the "abuse-mailbox:" attribute may be extended by inserting a hint string before the RFC-2822 address, to indicate the kinds of abuse which are to be notified to the specified address. 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 an inverse key. The limited vocabulary to be used for the hint string may be reviewed from time to time. Initially, the following terms are allowed. They are to be treated as case-insensitive, and to have 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 The syntax for the "abuse-mailbox:" attribute is specified below, using the notation of RFC-2822. Whitespace between tokens is not specified, but is implicitly permitted. abuse-mailbox-attribute = "abuse-mailbox:" [ hint-string ] RFC-2822-addr-spec [ RFC-2622-comment ] hint-string = "(" "scope" "=" scope-list ")" scope-list = scope-keyword / "'" scope-keyword-list "'" scope-keyword-list = scope-keyword / scope-keyword-list "," scope-keyword scope-keyword = "" "Spam" / "Security" The "RFC-2822-addr-spec" rule is specified (as "addr-spec") in RFC-2822. The "RFC-2622-comment" rule is specified in RFC-2622. Procedure The procedure for advertising abuse contacts is complementary to that for discovering the contacts: the "abuse-mailbox:" attribute must be added to one or more database objects so that the result of the discovery procedure matches the intent of the advertiser. The procedure for discovering the appropriate abuse contact for a given network object (inetnum:, inet6num:, asnum:) in particular circumstances of abuse (spam, intrusion, ...) is defined below. The procedure provides for traversing the database to find the "best" (or "nearest") "abuse-mailbox:" attribute. It also provides a fallback mechanism in case the optional "abuse-mailbox:" attribute is not found. Given a database object (inet*num, asnum, ...) and a keyword (spam, security, ...) representing the circumstances of the abuse, the following four-stage procedure is used. - First find the best abuse-contact-set for the given object. - Then discard any members of the abuse-contact-set which do not match the circumstances of abuse. - Next, if the set is empty, apply the fallback procedure to add members to the abuse-contact-set. - Finally, consider all surviving distinct members of the abuse-contact-set as the list of mailboxes to be notified. These stages are to be implemented as follows. Finding the best abuse-contact-set: Initially, the abuse-contact-set and the fallback-contact-set are empty. The list of database objects to be visited contains only the given database object. Repeat the following steps until either the abuse-contact-set is no longer empty or the list of database objects to be visited is exhausted. Select the first object from the list of database objects to be visited, and discard this object from the list. Add the "abuse-mailbox:" value(s), if any, found in the selected object to the abuse-contact-set. If the abuse-contact-set is still empty, add the following objects, in the given order, to the list of database objects to be visited: - the object indicated by each "mnt-by:" attribute of the selected object; - the object indicated by each "tech-c:" attribute of the selected object; - the object indicated by each "admin-c:" attribute of the selected object; - the next containing database object. It is assumed that existing database procedures are sufficient to identify the next containing database object. Adding "abuse-mailbox:" values to the abuse-contact-set: Expand any "abuse-mailbox:" value which contains a "scope-keyword-list" to a list of values, each containing a single "scope-keyword". Then add each value in the list to the abuse-contact-set. The expansion operation is illustrated by the following example. The attribute specified as abuse-mailbox: (scope='tea,coffee') coffee-bar@ripe.net becomes, on expansion: abuse-mailbox: (scope=tea) coffee-bar@ripe.net abuse-mailbox: (scope=coffee) coffee-bar@ripe.net For completeness, we note that the syntax defined above allows redundant information to be specified in the "abuse-mailbox:" attribute, as illustrated in the following examples. 1. (scope='tea','tea') is equivalent to (scope='tea'). 2. (scope='') is equivalent to omitting the hint string. 3. (scope=',tea') is also equivalent to omitting the hint string. More elaborate examples are easily constructed. This is not recommended by the authors. Discarding members of the abuse-contact-set: For each member of the abuse-contact-set for which a non-empty hint-string is specified which differs from the given keyword representing the circumstances of the abuse, remove that member from the abuse-contact-set. Matching of hint-strings to the keyword is to be performed as follows. - The distinction between upper and lower case is not significant. - Leading or trailing white space is not significant. - Embedded white space is significant, provided that any run of adjacent white-space characters is to be considered as a single white-space character. This provision is not relevant to the initial vocabulary allowed for hint-strings. Fallback procedure: Select all database objects indicated by a "tech-c:" attribute of the originally given database object and add each "e-mail:" value found in this set of objects to the abuse-contact-set. References: [1] [Draft] Minutes, Database Working Group, RIPE 47 Nigel Titley, 2 March 2004 [2] RFC-2822: Internet Message Format P. Resnick, April 2001 [3] RFC-2622: Routing Policy Specification Language (RPSL) C. Alaettinoglu et al., June 1999 -- Ends --
Hi all, On 2004-04-06 17:23:53 +0100, Niall O'Reilly wrote: [...]
Three things are needed:
- The inetnum:, inet6num:, person:, role: and mntner: objects are
mntner objects are specifically for authorisation/authentication purposes in the whois database. I would not put "abuse-mailbox:" into mntner objects, as this is irrelevant to mntner object's purpose. Let's keep the functions of object types clean and distinct. For "inetnum:"s and "inet6num:"s, would it make sense to put "abuse-c:" which will reference to a person/role object by NIC handle, thus removing the need to bulk-update the inet(6)num objects when the abuse mailbox changes? Also, it might make sense to add "abuse-mailbox:" into the new organisation object, that will be put into production soon. [...]
abuse-mailbox-attribute = "abuse-mailbox:" [ hint-string ] RFC-2822-addr-spec [ RFC-2622-comment ]
We have RPSL-comments already (anything after a hash '#'). Would it make sense to use it rather than RFC-2622-comment? My 2 cents, -engin -- Engin Gunduz RIPE NCC Software Engineering Department
We have RPSL-comments already (anything after a hash '#'). Would it make sense to use it rather than RFC-2622-comment?
an old lesson from language design. do not put semantics into a comment. putting it in an rpsl comment says "this has absolutely no meaning" putting it in an 2822 comment means this is about the 2822-addr-spec randy
On 7 Apr 2004, at 17:43, Engin Gunduz wrote:
mntner objects are specifically for authorisation/authentication purposes in the whois database. I would not put "abuse-mailbox:" into mntner objects, as this is irrelevant to mntner object's purpose. Let's keep the functions of object types clean and distinct.
You're right, of course. This overloads the mntner. We deliberated carefully over this, and formed the view that potential for rapid deployment is a strong enough pragmatic reason for doing this.
For "inetnum:"s and "inet6num:"s, would it make sense to put "abuse-c:" which will reference to a person/role object by NIC handle, thus removing the need to bulk-update the inet(6)num objects when the abuse mailbox changes?
Perhaps. We reckoned that the burden of initially populating existing inet*num's with a new link attribute would be an obstacle to rapid deployment.
Also, it might make sense to add "abuse-mailbox:" into the new organisation object, that will be put into production soon.
Definitely (or, as we tend to say in this part of the world, with a connotation of extra enthusiasm, "defny!"). Niall
On Apr 07, Engin Gunduz <engin@ripe.net> wrote:
For "inetnum:"s and "inet6num:"s, would it make sense to put "abuse-c:" which will reference to a person/role object by NIC handle, thus removing the need to bulk-update the inet(6)num objects when the abuse mailbox changes? What is the point? IRT records already work this way.
-- ciao, | Marco | [5602 pr0Eh4bg9IRRQ]
On 7 Apr 2004, at 18:39, Marco d'Itri wrote:
What is the point? IRT records already work this way.
No. They are _designed_ to work this way. Whether they ever will on a significant scale depends on deployment. The statistics which Marco Hogeloon presented at Anti-Spam-47 suggest to me that IRT is not being enthusiastically deployed. It would be interesting to see how those statistics are evolving [hint -- MarcoH, are you there?]. The proposal from Randy and me is intended to offer a pragmatic, lightweight, and easily deployed means to advertise abuse contacts. Best regards, Niall O'Reilly
On Wed, 2004-04-07 at 23:33, Niall O'Reilly wrote:
On 7 Apr 2004, at 18:39, Marco d'Itri wrote:
What is the point? IRT records already work this way.
No. They are _designed_ to work this way. Whether they ever will on a significant scale depends on deployment.
The same will be for the abuse-* line, if it is not used, there is no deployment ;) Did you request an IRT object for your organisation and implement it? It only took me a couple of hours as I mentioned some time ago.
The statistics which Marco Hogeloon presented at Anti-Spam-47 suggest to me that IRT is not being enthusiastically deployed. It would be interesting to see how those statistics are evolving [hint -- MarcoH, are you there?].
And what reasons are there to assume that the new proposal will be deployed all of a sudden? It is mostly the same, but worse, as the IRT method thus it doesn't make much sense.
The proposal from Randy and me is intended to offer a pragmatic, lightweight, and easily deployed means to advertise abuse contacts.
IRT is also lightweight and easily deployed: Create PGPKEY, which you should already have in most cases, eg for authentication of the maintainer object, fill in the irt form pass it to the ripe-db group and get it assigned, add them to your _top layer_ allocations, thus not for smaller ones and done. The lightweight part is partially not so true because you need to request RIPE for the IRT object, but hey one needs to request them AS, inetnum's inet6nums etc also, so where is the problem there? Greets, Jeroen
Hi, On Thu, Apr 08, 2004 at 10:07:54AM +0200, Jeroen Massar wrote:
Did you request an IRT object for your organisation and implement it? It only took me a couple of hours as I mentioned some time ago.
If you have a PGP infrastructure in place (or you have only *one* person reading PGP-encrypted abuse e-mails) it's easy. We haven't setup an IRT object for us yet, because there is no key we can put into the "encryption:" field without breaking internal processes. Abuse handling does *sign* outgoing mails, but those are personal keys, not group keys. As abuse@space.net runs through a ticketing system that doesn't know PGP (yet, the next generation will), having a mandatory encryption: field here is a major obstacle - and putting personal mailboxes and keys into the irt: object is not overly useful. We'd be quite happy to implement a "lightweight abuse-contact reference" solution. 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
On Thu, 2004-04-08 at 10:52, Gert Doering wrote:
On Thu, Apr 08, 2004 at 10:07:54AM +0200, Jeroen Massar wrote:
Did you request an IRT object for your organisation and implement it? It only took me a couple of hours as I mentioned some time ago.
If you have a PGP infrastructure in place (or you have only *one* person reading PGP-encrypted abuse e-mails) it's easy.
We haven't setup an IRT object for us yet, because there is no key we can put into the "encryption:" field without breaking internal processes. Abuse handling does *sign* outgoing mails, but those are personal keys, not group keys.
Nothing requires communications to be PGP encrypted (afaik). Signing email is something that most people should do anyways even it is just to protect yourself from fakers/emails etc and making it a way to prove that you where the one writing the email and not someone/thing else. Most endusers, which seems to be the target here, won't have a pgp capable email system in place. Automated tools won't do pgp signing nor encryption either as then they would need to fetch + trust the key automatically and I think that is not an option in most cases.
As abuse@space.net runs through a ticketing system that doesn't know PGP (yet, the next generation will), having a mandatory encryption: field here is a major obstacle - and putting personal mailboxes and keys into the irt: object is not overly useful.
We'd be quite happy to implement a "lightweight abuse-contact reference" solution.
I assume that quite a lot of parties would indeed be happy when at least the encryption field would be optional. On Thu, 2004-04-08 at 11:28, MarcoH wrote:
Did you request an IRT object for your organisation and implement it?
It only took me a couple of hours as I mentioned some time ago.
That's not the problem. The problem is that the IRT-object will only carry the more generic e-mail attribute. From the operational experience I have, it looks like a lot of 'users' have trouble to distinguish all the e-mail atrributes and mail addresses in the whois output and find the correct one.
Thus adding 'more specific' email addresses into the irt object might be a solution to this problem? You can already do that, with the same way you, or was it someone else, proposed the abuse-mailbox format: ... email: spam@example.com # SPAM email: ddos@example.com # DDOS ... The IRT object also has remarks and comment fields so one can fill it with large ASCII drawings and other ways to make it clear to the user. The advantages for the ISP: - only one top-level object to add - only one object to manage/change - central in place - works now and already for quite some time.
The abuse-mailbox: attribute should be clear to everybody and makes automation much easier for the generic user, who never read the database specs, but only looks at the raw whois output.
If a 'user' automates, they are no endusers any more but toolwriters. When a toolwriter doesn't read the specs they should be hit by a cluestick :) There is nothing/not much you can do against ignorant (end)users. Greets, Jeroen
For some reason I have this vision of Bart at the blackboard, writing I must not use comments to convey semantic payload I must not use comments to convey semantic payload I must not use comments to convey semantic payload I must not use comments to convey semantic payload I must not use comments to convey semantic payload I must not use comments to convey semantic payload I must not use comments to convey sema On 8 Apr 2004, at 11:05, Jeroen Massar wrote:
email: spam@example.com # SPAM email: ddos@example.com # DDOS
Niall
On Thu, 2004-04-08 at 13:54, Niall O'Reilly wrote:
For some reason I have this vision of Bart at the blackboard, writing
I must not use comments to convey semantic payload I must not use comments to convey semantic payload I must not use comments to convey semantic payload I must not use comments to convey semantic payload I must not use comments to convey semantic payload I must not use comments to convey semantic payload I must not use comments to convey sema
On 8 Apr 2004, at 11:05, Jeroen Massar wrote:
email: spam@example.com # SPAM email: ddos@example.com # DDOS
Actually Bart would write it with multiple pens and he would add that the teacher himself told to do something similar, like I mentioned a couple of lines above my post, but you cut those out. Greets, Jeroen
For some reason I have this vision of Bart at the blackboard, writing
I must not use comments to convey semantic payload I must not use comments to convey semantic payload I must not use comments to convey semantic payload I must not use comments to convey semantic payload I must not use comments to convey semantic payload I must not use comments to convey semantic payload I must not use comments to convey sema
professor wirth was ever so much more succinct randy
On Thu, Apr 08, 2004 at 12:05:33PM +0200, Jeroen Massar wrote:
That's not the problem. The problem is that the IRT-object will only carry the more generic e-mail attribute. From the operational experience I have, it looks like a lot of 'users' have trouble to distinguish all the e-mail atrributes and mail addresses in the whois output and find the correct one.
Thus adding 'more specific' email addresses into the irt object might be a solution to this problem?
You can already do that, with the same way you, or was it someone else, proposed the abuse-mailbox format:
Yes, but don't call it e-mail. You want something you can easily filter on, because apparently, looking at the number of wrongly addressed complaints and the addresses they use, a lot of people tend to grep on the '@' sign. There are 2 problems in the real world, 10 % of the inet(6)num objects use the freeform 'remarks' attribute for pointers to the abuse department, which makes automation harder and the e-mail attribute is highly overloaded, you need to look at the context to find out if it's the correct one (returned in an IRT object). I'm not opposed to the IRT object, but is not very helpful for the millions of people out there who only want to send a simple spam complaint and trust on some piece of script they downloaded somewhere. So what's the chance people will actually introduce enough IRT objects to make it usefull to look for them and at the same time enough toolwriters with some decent knowledge about the database to find the correct e-mail attribute ? So the real question is, what will change if we introduce a specific attribute which people can actually find using 'grep' on the full output. Which we can use to replace all the remarks attributes. Oh and while we are advertising it, we might as well put in some pointers on irt. MarcoH
On Apr 12, MarcoH <marcoh@marcoh.net> wrote:
So what's the chance people will actually introduce enough IRT objects to make it usefull to look for them and at the same time enough toolwriters with some decent knowledge about the database to find the correct e-mail attribute ? I'd say it will be much higher than for abuse-mailbox given that it does not require to update each and every inetnum object.
-- ciao, | Marco | [5681 genR.Kq.r6lpg]
On Mon, Apr 12, 2004 at 11:57:50AM +0200, Marco d'Itri wrote:
On Apr 12, MarcoH <marcoh@marcoh.net> wrote:
So what's the chance people will actually introduce enough IRT objects to make it usefull to look for them and at the same time enough toolwriters with some decent knowledge about the database to find the correct e-mail attribute ? I'd say it will be much higher than for abuse-mailbox given that it does not require to update each and every inetnum object.
To quote the original proposal: == The objects addressed by this proposal (inetnum:, inet6num:, person:, role:, mntner:) would be extended by the addition to their templates of a new attribute definition, as follows. abuse-mailbox: [optional] [multiple] [inverse key] The value of the "abuse-mailbox:" attribute must be a valid and active RFC-2822 address. == Where does this gives the need to update each and every object in the database ? Next to that, 10% of the inetnum objects contain the less maintainable remarks workaround. MarcoH
On Apr 08, Jeroen Massar <jeroen@unfix.org> wrote:
And what reasons are there to assume that the new proposal will be deployed all of a sudden? I think it should be obvious that abuse-c and abuse-mailbox attributes are much harder to deploy, because they require modifying every bottom level inetnum/inetnum6 object (which may even be protected by the mntner object of the customer).
I still think that the requirements for handling of abuse contacts have not been discussed enough. -- ciao, | Marco | [5613 diD/o8PEXAukY]
Did you request an IRT object for your organisation and implement it? It only took me a couple of hours as I mentioned some time ago.
That's not the problem. The problem is that the IRT-object will only carry the more generic e-mail attribute. From the operational experience I have, it looks like a lot of 'users' have trouble to distinguish all the e-mail atrributes and mail addresses in the whois output and find the correct one. The abuse-mailbox: attribute should be clear to everybody and makes automation much easier for the generic user, who never read the database specs, but only looks at the raw whois output. MarcoH
On Apr 08, MarcoH <marcoh@marcoh.net> wrote:
Did you request an IRT object for your organisation and implement it? It only took me a couple of hours as I mentioned some time ago.
That's not the problem. The problem is that the IRT-object will only carry the more generic e-mail attribute. From the operational experience I have, it looks like a lot of 'users' have trouble to distinguish all the e-mail atrributes and mail addresses in the whois output and find the correct one.
The abuse-mailbox: attribute should be clear to everybody and makes automation much easier for the generic user, who never read the database specs, but only looks at the raw whois output. I do not believe this is true. Many operators in the last years pointed at the correct address with detailed explanations in natural language (usually in english, possibly translated as well) and even ASCII art. Yet some users still send mail to the wrong address. I think that the issue here is more complex than "users do not know the semantics of the contacts of inetnum objects". If a well marked abuse@domain address is ignored, I can't see why abuse-c or even abuse-mailbox: would be easier to understand.
Clueless users do not use port 43 whois, they usually paste an IP address in some web-based gateway. If the requirement is to provide end users an idiot-proof way to look up the abuse contact for a domain then RIPE could as well install a CGI prominently linked from www.ripe.net which would first look for an IRT object, fall back to tech-c if needed and then report back only the relevant email address. -- ciao, | Marco | [5615 es25qV8fvhotg]
On 8 Apr 2004, at 10:50, Marco d'Itri wrote:
Clueless users do not use port 43 whois
Not directly. They buy some shrink-wrapped software to run on their WinXX box, which has a clue-free default configuration which they never review. Niall O'Reilly
On Thu, 2004-04-08 at 13:58, Niall O'Reilly wrote:
On 8 Apr 2004, at 10:50, Marco d'Itri wrote:
Clueless users do not use port 43 whois
Not directly. They buy some shrink-wrapped software to run on their WinXX box, which has a clue-free default configuration which they never review.
Which makes every proposal useless as in that case you are assuming the current toolwrites don't know about IRT objects. Then for sure they are not going to accept implementing the suddenly new abuse-mailbox and a seperate spam-mailbox etc on every object too. Notez bien that adding spam/abuse/attack/questions-mailboxes can also be added to the irt object. Or if you really want to make it general, why not start thinking of a contact object, but wait, we have that already it is called person/role... If you don't expect toolwriters to implement irt objects, because many people, or at least the couple on this list, don't want to add that simple object to their inet[6]num's then you should not expect everybody to start adding abuse+spam-mailbox and all the others to _all_ the objects they own. Unfortunatly the people making up/defining the documents can't force ever tool writer in this world to do their job correctly and implementing it as expected, especially with such a loose "protocol" as whois that is different in the 4 current regions of this world. ARIN registry is imho a mess compared to the RIPE/APNIC registries and I think one can bet that ARIN region folks think the same about the RIPE/APNIC registries. But you might educate those toolwriters to do so, either way, if that would be to let them check irt objects or let them check abuse-mailboxes that is a difficult and long process. Taking into account that most RIPE members are ISP's and that they don't want to have a big burden updating these objects I still think that the irt object is the way to go, though as seen from the comments, for instance Gert's about the mandatory encryption field, there could be done some work there. Also adding a 'spam/abuse-email' field to the irt might be handy. But how many toolwriters will suddenly move to this new standard, that will probably only be active in the RIPE registry while most toolwriters are from the ARIN or APNIC regions... Greets, Jeroen
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At 08/04/2004 13:14 +0100, Jeroen Massar wrote:
Clueless users ...
... buy some shrink-wrapped software to run on their WinXX box, which has a clue-free default configuration which they never review.
Which makes every proposal useless as in that case you are assuming the current toolwriters don't know about IRT objects. Then for sure they are not going to accept implementing the suddenly new abuse-mailbox and a separate spam-mailbox etc on every object too.
The IRT route has an extra step. Instead of inet[6]num -> e-mail address[es] they have to do inet[6]num -> IRT(if present) -> e-mail address[es] and tool-writers have to add extra code. They will understand that. There's a deadly embrace. Toolwriters will write the extra code (for IRT or multiple reporting addresses) if it gets them a working address nearly every time; and not if it doesn't. LIRs and ISPs will bother to deploy IRTs if almost everybody uses the e-mail address they publish; and not otherwise. The challenge for the WG is to come up with something in which the benefits exceed the costs for all the players involved, in a fairly short time. Of the ideas so far, the following combinations come somewhere close: 1. Encourage widespread deployment of IRT objects, and change the default behaviour of the whois _servers_ (in consultation with toolwriters and other RIRs) to follow through and show the right e-mail address and no wrong ones for a single _client_ request; 2. Like 1, but invent a separate AbuseHandler object that works like IRT; and make similar changes to default server behaviour; 3. Encourage LIRs and ISPs to add an abuse-mail atribute to inet[6]nums, and again change the default server behaviour. 4. Do any of the above without changing default server behaviour, and run a project to help all important toolwriters update their products. (other really different ideas, anyone?) (4) does not help the truly clueless (back to Jeroen's original point), as it needs changes to the installed base of dedicated tools and of plain whois clients. It will take several years. (3) looks a bad choice for any LIR or ISP who needs to change the destination e-mail address in all their inet[6]nums. That need not happen often; but if it does, the timing is sure to be inconvenient. (1) and (2) are technically identical; the choice between them depends on whether you think e-mail abuse is sometimes, always or never a suitable task for an Incident Response team. I do not know a rational way to make that choice. Rodney Tillotson, JANET-CERT +44 1235 822 255. -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com> iQA/AwUBQHVhPMxy/J7PAuvpEQLEyQCdFTPgAkHYwHujQwn+oTKRqzr9aacAn3Vp sOjYu0HNwF1m3PeCSyTCBH4D =3BEE -----END PGP SIGNATURE-----
Rodney, Nice diagram! It says part of something I wanted to say, but misses a particular detail, and so masks a significant saving in the effort involved in deploying additional contact data in the current database. I'm not sure whether you were thinking of deployment, or rather of development work on tools and server. I'm thinking of deployment as the major task. Besides filling in this detail, I'm suggesting how we might quantify this effort. MarcoH, You may already have real numbers to use in place of my assumptions. On 8 Apr 2004, at 15:27, Rodney Tillotson wrote:
The IRT route has an extra step. Instead of
any one of the following:
inet[6]num -> e-mail address[es] inet[6]num -> person/role (which must already be present as admin-c or tech-c) -> e-mail inet[6]num -> mntner (which may already be present as mnt-by) -> e-mail
they have to do inet[6]num -> IRT(if present) -> e-mail address[es]
and must create the IRT if it's not already present (which involves updating the inet[6]num to link it to the relevant IRT),
and tool-writers have to add extra code. They will understand that.
It would be interesting to quantify the deployment effort necesssary to reach the point where every inet[6]num is associated, either directly or via linked objects, with a distinguished attribute (eg: abuse-mailbox). As a starting point, let's take (approximations to) MarcoH's RIPE-47 statistics. Number of inet[6]num objects: 10**6 Number of inet[6]num objects with IRT: 10**3 (not significant) I'll assume that the minimal set of person/role/mntner objects required to cover all 10**6 inet[6]num objects is of the order of 10**5, to allow for multiple inet[6]num objects under common management. This assumption can be validated (and corrected if unjustified: I haven't done the analysis) from the existing contents of the database. I'll further assume that 10**5 IRT objects will likewise be sufficient to cover all 10**6 inet[6]num objects. This assumption cannot be validated on the basis of current information, it seems reasonable to treat the eventual IRT population on the same basis as the actual P/R/M population. I'll also assume that any required tool and server development and/or modification effort is negligible compared to that required to deploy whatever new data is needed. Now I look at some possible methods for deploying the desired information in the database. Method A: Provide every inet[6]num _directly_ with a distinguished attribute indicating the appropriate abuse contact: 10**6 update transactions on the inet[6]num objects Method B: Provide every inet[6]num with an appropriately configured IRT object: 10**6 - 10**3 ( ~ 10**6 ) update transactions on inet[6]num objects 10**5 - 10**3 ( ~ 10**5 ) _new_ IRT's to be created Method C: Provide an _existing_ contact object (person/role/mntner/IRT (even!)) of every inet[6]num object with a distinguished attribute indicating the appropriate abuse contact: 10**5 update transactions on _existing_ contact objects I understand why nobody likes method A. I think I hear people declaring a preference for method B over method C. I'm missing something here; who can help? MarcoH has explained the advantage of a distinguished attribute (abuse-mailbox or, as he originally suggested, just plain abuse) over a common attribute (specifically: e-mail) which takes on extra semantics in the particular context of belonging to an IRT object. I don't think I need to his excellent explanation. Best regards, Niall O'Reilly
On Apr 13, Niall O'Reilly <niall.oreilly@ucd.ie> wrote:
Method B: Provide every inet[6]num with an appropriately configured IRT object: This is not a good assumption because not all inet[6]num objects need to be updated to be protected, only the parent object does. Look at IRT-SIXXS and at how many objects it protects for a simple example.
-- ciao, | Marco | [5719 prCHm.K4ZTyVo]
Marco, Of course my initial assumptions are crude ones. I believe we have to move the discussion from principled polemics to quantities on which we can base a decision. Can you quantify what will still be required after taking advantage of the kind of aggregation you suggest ? If not, are there any other volunteers out there? Best regards, Niall O'Reilly On 13 Apr 2004, at 16:59, Marco d'Itri wrote:
Method B: Provide every inet[6]num with an appropriately configured IRT object: This is not a good assumption because not all inet[6]num objects need to be updated to be protected, only the parent object does. Look at IRT-SIXXS and at how many objects it protects for a simple example.
On Apr 13, Niall O'Reilly <niall.oreilly@ucd.ie> wrote:
Can you quantify what will still be required after taking advantage of the kind of aggregation you suggest ? I think that a much better estimate is the number of ALLOCATED-BY-RIR (for inet6num), ALLOCATED PA and ASSIGNED PI (for inetnum) objects.
After the top level objects will have a contact, detailed data can be added by customers and the need for this will be regulated by the usual ISP-customer relationships. -- ciao, | Marco | [5722 unFXozsm8iBp6]
On 13 Apr 2004, at 18:00, Marco d'Itri wrote:
On Apr 13, Niall O'Reilly <niall.oreilly@ucd.ie> wrote:
Can you quantify what will still be required after taking advantage of the kind of aggregation you suggest ? I think that a much better estimate is the number of ALLOCATED-BY-RIR (for inet6num), ALLOCATED PA and ASSIGNED PI (for inetnum) objects.
After the top level objects will have a contact, detailed data can be added by customers and the need for this will be regulated by the usual ISP-customer relationships.
Fine. You suggest a method for arriving at a better estimate of the scope of the discussion. I don't see that this changes the nature of the argument. Do you have a rough idea of what the new estimate is, numerically? More specifically, the following questions arise. Is the population of inet[6]num objects which are included in your improved estimate closer to 10**6, 10**5, 10**4, or even 10**3? Let's call the number, (for the sake of originality) "N". Of this population, how many already are associated with a person/role/ mntner/IRT object (PRMIO), and what is the minimal set of PRMIO's which will cover the population? This will give a good estimate of how many existing objects need to be updated with a DAIAC in order to cover the whole population of interest. Let's call this number "M". I expect that M is significantly less than N; it clearly can't be greater. Now, we can cover all N inet[6]num objects within our scope by applying just M updates to the related PRMIO's. I believe that this is the lower bound on the effort involved. The data needed to drive the planning for this effort is already in the database. Another approach would be, to choose an IRT-only solution. In this case, we let "P" be the number of inet[6]num objects within our scope which require a new IRT object, and "Q" the least number of such IRT objects needed to meet these requirements. It's useful to consider a factor "R" which represents the inertial tendency against the creation of the new IRT objects. This doesn't directly represent extra effort, but rather delay in achieving results, expressed in terms of effort-equivalent. Ideally, R = 1; in practice, R > 1. To estimate the effort involved, we count: Q new IRT objects, and P updates to existing inet[6]num objects, in order to link the new IRT's, and then reckon the total effort-equivalent as P + (R * Q). The quantity, P is available from the existing database. The set of new IRT objects has to be chosen before the number Q is available. However, Q cannot be greater than P. I suggest that the comparison of M with P+(R*Q) is a reasonable basis for deciding which way to proceed, and that the following table shows how this comparison should determine the actual decision. Since neither Q or R is yet available, I tentatively estimate Q * R = 1.5 * P. I know this isn't "accurate"; I'm pretty sure it's not "outrageous" either. M < P: PRMIO solution M > 2.5 * P: IRT-only solution P < M < 2.5 * P: Further study Best regards, Niall O'Reilly
Sorry, I muddled two quite different named. Of course, I meant Marco Hogewoning. Sincere apologies, Niall On 7 Apr 2004, at 22:33, Niall O'Reilly wrote:
The statistics which Marco Hogeloon presented at Anti-Spam-47
On Apr 07, Niall O'Reilly <niall.oreilly@ucd.ie> wrote:
The proposal from Randy and me is intended to offer a pragmatic, lightweight, and easily deployed means to advertise abuse contacts. Even if I disagree I can see why some people think that abuse-mailbox is a good idea, but I still see no reason why abuse-c would be easier to deploy and to use than mnt-irt.
Some people voiced objections over the mandatory use of encryption, but if perceived to be a problem this could be easily changed. What about trying to fix irt objects instead of complicating the database with multiple features with overlapping scope (irt, abuse-mailbox, abuse-c)? -- ciao, | Marco | [5612 qudenW7V5vzds]
On Wed, Apr 07, 2004 at 10:33:51PM +0100, Niall O'Reilly wrote:
The statistics which Marco Hogeloon presented at Anti-Spam-47 suggest to me that IRT is not being enthusiastically deployed. It would be interesting to see how those statistics are evolving [hint -- MarcoH, are you there?].
Yep, I'll be there and will do the statistics run again. Marco Hogewoning
participants (9)
-
Engin Gunduz -
Gert Doering -
Jeroen Massar -
Marco d'Itri -
MarcoH -
Niall O'Reilly -
Randy Bush -
Rodney Tillotson -
Wilfried Woeber, UniVie/ACOnet