[db-wg] abuse-c

Hi Menno,



Thank you for your comments.


> > 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).
>
> In the current implementation the IRT and the LIR (maintainer) are
> supposes to be different groups of persons, whether they are part of the
> same organisation of not.

This is where I disagree with the idea behind the irt implementation, I do
not see the reason for making the distinction between LIR and IRT as it do
not apply to all LIRs. In many LIRs abuse is handled by the same group (and
sometimes even the same persons) as the ones handling general LIR functions.

> for its IP range, but the IRT has to authorise this, by counter-signing
> the request to add an mnt-irt attribute to the inet[6]num object.
> Otherwise any maintainer of an inet[6]num (which could be delegated)
> could simply make the inet[6]num object point to any IRT for abuse
> complaints. The current mechanism is to protect the IRT form being
> blamed for things they are not responsible for simply because "Evil
> Company" points a finger towards them.

I very much agree with you that a LIR shall not be able to "forward the
problem" by using another organsations irt object without permission.

But the question is how many LIRs choose to "outsource" abuse, even to a
group within the organization? I could have hoped this had been determined
before implementing the IRT object.

I understand that it is necessary for LIRs who prefer to use a seperate
group within the organization or a third party to use encryption for
authentication, but can we agree that for the rest of the LIRs it could just
as easily be done by maintainer authentication like when creating route
objects? If so what would the disadvantage be?

Im not opposed that some LIRs can effectively outsource abuse even if it
requires special objects/attributes in the Ripe database, but Im very much
opposed that these special objects/attributes are mandatory meaning it
becomes an obstacle for LIRs prefering to keep abuse within the
organization.


> > 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.
>
> That is exactly why there must be double authorization for the
> relationship between IRT and inet[6]num: to ensure correctness and
> mutual agreement.

Only in cases where LIRs choose to outsource abuse, if it is within the same
organzation, one LIR cannot (hopefully) hijack another LIRs maintainer,
meaning an abuse object created and used by one LIR cannot be used by
another.


> I agree that there must be a better mechanism than the comments in the
> inet[6]num and maintainer objects, but I'm still in favor of promoting
> the existing one and perhaps explaining it a little better.

The reason why a better explanation is needed for the current IRT object is
because it has extensive authentication, if
many LIRs have no use for these extra features, can you find any reason for
them to spent time finding out how to use/create this object?



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