[db-wg] abuse-c

Hi Menno,


> Well, except that the word 'abuse' may be a bit easier to understand
> than 'irt' for many non-RIPE-database-gurus, I do not see much
> difference between a reference to an IRT object or a reference to a
> person/role object. The big difference is that an IRT is usually better
> protected (see below) and provides more information.
>
> The protection that the IRT gives over a person/role object includes:
> - It MUST be maintained, while a person or role object does not have to
> be; it can be completely unprotected.
> - Authorization from the IRT is required, before the IRT can be linked
> to the inet[6]num object. This is important so not all mail for a
> malicious company can go to another (or non-existent) address.
>
> Moreover, if the IRT object is maintained by TRUSTED-INTRODUCER-MNT (or
> possibly other organisations of Incident Response Teams), it means the
> object's information has been verified and is verified on a regular basis.

We can agree that it would be preferable to have a special abuse-object with
a mandatory maintainer attribute instead of just refering a role/person
object, still the most important is that the whois database is an effectiv
tool to locate an abuse address.

Regarding authorization of the object, it could be done kind of the same way
as a route object meaning maintainer has to be the same or can authorize the
other.

The LIR maintaing an address block is responsible for taking care of the
related abuse cases. I see no problem in some LIRs outsourcing this to a
third party (which I guess is what you mean by "other organisations of
Incident Response Teams"), but I don't see it to be more trustworthy if a
third party is involved than if the LIR takes care of it. But I do see it as
a problem if such third party needs to be verified and such procedure makes
this matter so complicated that almost no LIRs bother using it (as the case
is today).


> > So we can start advertising the irt mechanism to both the LIR's and the
> > people who migth come searching for an address to send a complaint to. I
> > don't think it is very likely to hit a large public in a
> reasonable time.
>
> Neither would another extra attribute, because people will still be
> sending their mail to ALL adresses found...

The current problem is that the majority of LIRs have chosen not to use irt,
probably both because it haven't been announced enough and because it is too
complicated. As soon as an attribute is implemented in most inetnum objects,
meaning people have a reason to trust that an abuse address actually works,
then people will stop using any other address, simply because the abuse
address will work and the others will not.

>
> > Introducing an extra (mandatory) field in inetnum objects to hold the
> > abuse address for that specific netblock and nothing more makes it much
> > more easier for all those people who write automated process to get the
> > information requested and not have to fallback to listing addresses in
> > changed: fields as a possible way to complain.
>
> If they can find the information in a person/role object, so can they in
> an IRT object. If the tool finds an mnt-irt attribute, just let it look
> for the contact information (address, phone, fax-no and e-mail) in the
> IRT object and display that to the user.

Yes, but thats not the point. Either the current irt object or a new and
simpler abuse object implemented in most inetnum objects will be easy to
retrieve abuse addresses from. The point is simply that it is much more
realistic to implement a simple object than a complex one in most inetnum
objects.


> > As such can this subject be put an the wg-agenda for ripe-47 ?
> >
> > To formalize it a little bit I wan't to put forward the
> proposal to add an
> > 'abuse' field to inetnum and inet6num objects.

Sounds like a good idea.


> Personally, I would suggest promoting the current advanced mechanism
> instead of inventing something new.

The question simply is if ALL LIRs are ready/willing to implement the
current irt object, its much more likely that the majority will implement a
simpler version. The irt features can then be introduced at a later time
once all inetnum objects have been updated.

I would suggest a project be initiated like when encryption was made
mandatory in maintainer objects. Abuse addresses in inetnum objects will not
have much effect until they are implemented in all inet[6]num objects.

Once the correct attribute has been decided it must be implemented ASAP.



Med venlig hilsen/Best regards

Christian Rasmussen
Hosting manager, jay.net a/s

Smedeland 32, 2600 Glostrup, Denmark

Email: noc at jay.net
Personal email: chr at corp.jay.net
Tlf./Phone: +45 3336 6300, Fax: +45 3336 6301

Produkter / Products:
http://hosting.jay.net