Hello, To put together a Proposal for how a Referece solution could be done . This abuse-c inherits all the features of irt as well, resulting in just one object for this area [Like in tech-c which is also not fine-grained like having something for routing, something for hardware, for peering, for .....] What can be done to have the 'abuse-mailbox' like in Randy/niall's proposal would be the Role/Person object: This would also make it easier to reference existing data, i.e. the one Person NOC where the local guru is admin and tech and abuse. For example: inetnum: 131.130.7.32 - 131.130.7.47 netname: UK-V4 descr: LAN Ulrich Kiermayr country: AT admin-c: UK3 tech-c: UK3 abuse-c: UK3 mnt-by: UK-MNT status: ASSIGNED PA changed: ulrich.kiermayr@univie.ac.at 20040506 source: RIPE person: Ulrich Kiermayr address: Lacknergasse 71/23 address: A-1180 Wien address: AT phone: +43 663 8174818 e-mail: Ulrich.Kiermayr@UniVie.ac.at abuse-mailbox:abuse@uk.atat.at # up to disc. nic-hdl: UK3 mnt-by: UK-MNT notify: Ulrich.Kiermayr@UniVie.ac.at changed: Ulrich.Kiermayr@UniVie.ac.at 20020723 source: RIPE --------------------------- Proposed Templates: [Changes are denoted by the <--] Add abuse-c to the objects where we need it (note that i have removed mnt-irt there) inetnum: [mandatory] [single] [primary/look-up key] netname: [mandatory] [single] [lookup key] descr: [mandatory] [multiple] [ ] country: [mandatory] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] abuse-c: [optional] [multiple] [inverse key] <-- rev-srv: [optional] [multiple] [inverse key] status: [mandatory] [single] [ ] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] mnt-lower: [optional] [multiple] [inverse key] mnt-routes: [optional] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] inet6num: [mandatory] [single] [primary/look-up key] netname: [mandatory] [single] [lookup key] descr: [mandatory] [multiple] [ ] country: [mandatory] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] abuse-c: [optional] [multiple] [inverse key] <-- rev-srv: [optional] [multiple] [inverse key] status: [mandatory] [single] [ ] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] mnt-lower: [optional] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] aut-num: [mandatory] [single] [primary/look-up key] as-name: [mandatory] [single] [ ] descr: [mandatory] [multiple] [ ] member-of: [optional] [multiple] [ ] import: [optional] [multiple] [ ] export: [optional] [multiple] [ ] default: [optional] [multiple] [ ] remarks: [optional] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] abuse-c: [optional] [multiple] [inverse key] <-- notify: [optional] [multiple] [inverse key] mnt-lower: [optional] [multiple] [inverse key] mnt-routes: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] 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] [ ] role: [mandatory] [single] [lookup key] address: [mandatory] [multiple] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [lookup key] signature: [optional] [multiple] [ ] <-- encryption: [optional] [multiple] [ ] <-- trouble: [optional] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] 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] [ ] For the consistency of the system one shoud add reference protection to the mntner too in that implementation. mntner: [mandatory] [single] [primary/look-up key] descr: [mandatory] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] tech-c: [optional] [multiple] [inverse key] upd-to: [mandatory] [multiple] [inverse key] mnt-nfy: [optional] [multiple] [inverse key] auth: [mandatory] [multiple] [ ] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] referral-by: [mandatory] [single] [inverse key] ref-nfy: [optional] [multiple] [inverse key] <-- mnt-ref: [optional] [multiple] [ ] <-- changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] 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). Query behaviour: -) 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). -) Change the -c flag to use abuse-c instead of mnt-irt. I hope that makes some sense. 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
Hello, On 6 May 2004, at 09:25, Ulrich Kiermayr wrote:
Hello,
To put together a Proposal for how a Referece solution could be done .
See comments below.
This abuse-c inherits all the features of irt as well, resulting in just one object for this area [Like in tech-c which is also not fine-grained like having something for routing, something for hardware, for peering, for .....]
Yes and no. Not where I think we should focus our thinking just now.
What can be done to have the 'abuse-mailbox' like in Randy/niall's proposal would be the Role/Person object:
This would also make it easier to reference existing data, i.e. the one Person NOC where the local guru is admin and tech and abuse.
Yes; exploit, leverage, take advantage of [...] what we already have. IMHO, a new "reference solution" involves excessive effort for both development and deployment. We already have reference attributes: admin-c => person/role/org tech-c => person/role/org mnt-irt => irt Adding a new reference attribute requires modification of primary objects (inet*num, AS-whatever-the -object-is called). If a parallel reference is already in place, I don't see that this gives us a useful return on effort. Since all primary objects of interest must already have a tech-c reference, we should better say "Because" than "If". I thought we had all agreed we should avoid modifying primary objects except _in extremis_. An optional distinguished attribute allows the choice (of what to modify) be made by whoever is responsible for doing the work. I'm very much in favour of co-locating decision-making with the effort to which the decision gives rise. Making the _same_ distinguished attribute available in both primary (inet*num, AS) and secondary (reference-targets: person, role, org, irt) objects gives the widest scope for maintainers to do what is _convenient for them_ whilst retaining overall consistency. NCC can (and, if I've understood correctly what was said this morning, will) advise on the development effort needed for whatever we finally agree on. Complementary to that, we (for some value of "we") have to devise a least-effort, greatest-effect strategy for reaching "there" from "here". I keep feeling we're still looking at tactics. More in follow-up. ATB, Niall
Hi,
This abuse-c inherits all the features of irt as well, resulting in just one object for this area [Like in tech-c which is also not fine-grained like having something for routing, something for hardware, for peering, for .....]
Yes and no. Not where I think we should focus our thinking just now.
I am Coming from the 'using a consistent Mindset designing the features' Point of view. If the Design itself is not based on a consistent way of doing things, we cant expect the 'not into the Database' users to be anything else but confused.
What can be done to have the 'abuse-mailbox' like in Randy/niall's proposal would be the Role/Person object:
This would also make it easier to reference existing data, i.e. the one Person NOC where the local guru is admin and tech and abuse.
Yes; exploit, leverage, take advantage of [...] what we already have.
IMHO, a new "reference solution" involves excessive effort for both development and deployment.
Because?
We already have reference attributes: admin-c => person/role/org tech-c => person/role/org mnt-irt => irt
Adding a new reference attribute requires modification of primary objects (inet*num, AS-whatever-the -object-is called). If a parallel reference is already in place, I don't see that this gives us a useful return on effort. Since all primary objects of interest must already have a tech-c reference, we should better say "Because" than "If".
Ahem. In what respect this situation is different from adding abuse-mailbox to those primary objects?
I thought we had all agreed we should avoid modifying primary objects except _in extremis_. An optional distinguished attribute allows the choice (of what to modify) be made by whoever is responsible for doing the work. I'm very much in favour of co-locating decision-making with the effort to which the decision gives rise. Making the _same_ distinguished attribute available in both primary (inet*num, AS) and secondary (reference-targets: person, role, org, irt) objects gives the widest scope for maintainers to do what is _convenient for them_ whilst retaining overall consistency.
Hmmm, maybe I am in a minority group, but for me consistency _is_ convinient.
NCC can (and, if I've understood correctly what was said this morning, will) advise on the development effort needed for whatever we finally agree on.
Better even on all the ideas we have, because it might be input to the desicion-making process.
Complementary to that, we (for some value of "we") have to devise a least-effort, greatest-effect strategy for reaching "there" from "here". I keep feeling we're stilllooking at tactics.
at least I want to make sure that the plan is useful for a certain time (whatever certain means) and reducing the risk of realising halfway through that we have to turn around and start all over again. 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 6 May 2004, at 12:28, Ulrich Kiermayr wrote:
Yes; exploit, leverage, take advantage of [...] what we already have. IMHO, a new "reference solution" involves excessive effort for both development and deployment.
Because?
That's what I go on to explain in the earlier mail. I'll answer each of your points separately, to avoid an explosion of interleaved comments. 8-) ATB, Niall
Hi,
Because?
That's what I go on to explain in the earlier mail. I'll answer each of your points separately, to avoid an explosion of interleaved comments. 8-)
And I did not really get it here either .... (which is my problem ;-) ) Seriously, i do not see it, because this problem is on the "what to return" side, not on the "how to store the Data" side. Work mostly lies in the first part (independent of the second), and I tried to address the second one in a consistent way. 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 6 May 2004, at 12:57, Ulrich Kiermayr wrote:
Work mostly lies in the first part (independent of the second), and I tried to address the second one in a consistent way.
I appreciate that. Me too! ATB, Niall
On 6 May 2004, at 12:28, Ulrich Kiermayr wrote:
Adding a new reference attribute requires modification of primary objects (inet*num, AS-whatever-the -object-is called). If a parallel reference is already in place, I don't see that this gives us a useful return on effort. Since all primary objects of interest must already have a tech-c reference, we should better say "Because" than "If".
Ahem. In what respect this situation is different from adding abuse-mailbox to those primary objects?
I'm supposing that primary objects come in clusters, each managed by a single NOC team, and that the NOC team is already represented in the database by the target of identical tech-c attributes in each primary. Adding a new reference to each primary requires updating each primary. For me in UCD, this means several operations, as we have a handful of inetnum objects, and just one inet6num. I expect it's not all that different at UniVie. Placing a new attribute in the common, existing tech-c object requires updating just one object. What the saving is, depends on the level of aggregation in any given case. The point is, to take systematic advantage of any existing aggregation-point, be this a PRO (person/role/org) or an IRT. ATB, Niall
Hi,
Adding a new reference to each primary requires updating each primary. For me in UCD, this means several operations, as we have a handful of inetnum objects, and just one inet6num. I expect it's not all that different at UniVie.
That is where the -c kicks in. and for a good solution, id prefer a shell -liner (similar to the one i presented in january) to update all these (at once). I think this is bearable for the NOCs that care. <cynical> and i fear, that those who don't would not do anything we'd like them to do </cynical> nevertheless as I stated in my proposal - adding the abuse-mailbox to person/role is not prohibited anyway - which then is used in admin-c/tech-c as well. 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 6 May 2004, at 13:14, Ulrich Kiermayr wrote:
That is where the -c kicks in. and for a good solution, id prefer a shell -liner (similar to the one i presented in january) to update all these (at once). I think this is bearable for the NOCs that care.
Fine. That makes it less onerous, but why would I want to add abuse-c: NO8 to every object where I already have tech-c: NO8 ? I don't see the gain. Now, I'm on a break with my family until Monday. Have a good weekend, everyone! Niall
Niall O'Reilly wrote:
On 6 May 2004, at 13:14, Ulrich Kiermayr wrote:
That is where the -c kicks in. and for a good solution, id prefer a shell -liner (similar to the one i presented in january) to update all these (at once). I think this is bearable for the NOCs that care.
Fine. That makes it less onerous, but why would I want to add
abuse-c: NO8
to every object where I already have
tech-c: NO8
?
I don't see the gain.
But what if I want. abuse-c: UVABU1-RIPE everywhere where I have tech-c: UVNA1-RIPE because Abuse is handled by someone else that technical Issues on the Network. And I see gain here. where es you do not loose something if you like to achieve the first. Hmm (I think there are a lot of Inetnums out there where admin-c == tech-c at the moment; where is the gain in that?) 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 Thu, 2004-05-06 at 15:32, Ulrich Kiermayr wrote: <SNIP>
because Abuse is handled by someone else that technical Issues on the Network.
And I see gain here. where es you do not loose something if you like to achieve the first.
Hmm (I think there are a lot of Inetnums out there where admin-c == tech-c at the moment; where is the gain in that?)
Thus you want to stick a different person/role in *every* allocation? I sure hope you will never have to change that or that you use role accounts. Why do you not just use IRT? The prime reason, with which I agree, is that there is this 'mandatory' encryption field. Two things: - either RIPE can make it an optional field. - people don't mail using it because they ignore it ;) I don't see automated tools encrypting anyways... Another thing which might be considered is adding a 'abuse-mailbox' and 'spam-mailbox' to the IRT object, making everybody happy. Any other 'issues' with IRT? (which doesn't require one to update *all* their objects. Of course replacing it is 'easy' with a shell one liner, request all the refered objects from whois and update them. Checking your stats also shows that only 3x the amount of IPv4 inetnum's have a abuse@ line in comparison to the amount of objects with irt's. I think that reason awareness for adding IRT's is something which is something which is much higher on the priority list then and not inventing yet another object... Greets, Jeroen
Hi,
Thus you want to stick a different person/role in *every* allocation? I sure hope you will never have to change that or that you use role accounts.
There is still the -c Feature, therefor the 'handful' I had in mind only applies to the allocations we have which is 1 from Ripe and a few Lebacy B/C s.
Why do you not just use IRT?
Yes, but irt has one shortcoming (which maybe is a result of the approach, when irt was designed [1]): If I ( == LIR ) have some small customers, where I want to denote the abuse handling seperate from the LIR one. Now there are all the relevant persons in the DB. Th denote abuse-features with IRT, i have to create/maintain a seperate Object, to do int with a person/role I don't.
The prime reason, with which I agree, is that there is this 'mandatory' encryption field. Two things: - either RIPE can make it an optional field.
fine with that as well.
- people don't mail using it because they ignore it ;) I don't see automated tools encrypting anyways...
Another thing which might be considered is adding a 'abuse-mailbox' and 'spam-mailbox' to the IRT object, making everybody happy.
and a DoS-Mailbox, and a piracy-mailbox, and .... sorry I was carried away ;-) I just think, that adding an arbitrary number of attributes to denote special-features does not scale in this environment.
Any other 'issues' with IRT? (which doesn't require one to update *all* their objects. Of course replacing it is 'easy' with a shell one liner, request all the refered objects from whois and update them.
-c can/should still be there.
Checking your stats also shows that only 3x the amount of IPv4 inetnum's have a abuse@ line in comparison to the amount of objects with irt's. I think that reason awareness for adding IRT's is something which is something which is much higher on the priority list then and not inventing yet another object...
I fully agree on that as well. [1] irt/abuse in my opinion is something someone (=person/group) does, and not something that protects (=maintains) objects in the database. So I _personally_ think the maintainer approach is not appropriate for denoting any security-capability. 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 6 May 2004, at 12:28, Ulrich Kiermayr wrote:
Hmmm, maybe I am in a minority group, but for me consistency _is_ convinient.
If it's a minority, it's one I count myself in also! ATB, Niall
On 6 May 2004, at 12:28, Ulrich Kiermayr wrote:
NCC can (and, if I've understood correctly what was said this morning, will) advise on the development effort needed for whatever we finally agree on.
Better even on all the ideas we have, because it might be input to the desicion-making process.
Yes, indeed!
Complementary to that, we (for some value of "we") have to devise a least-effort, greatest-effect strategy for reaching "there" from "here". I keep feeling we're stilllooking at tactics.
at least I want to make sure that the plan is useful for a certain time (whatever certain means) and reducing the risk of realising halfway through that we have to turn around and start all over again.
Yes, again! ATB, Niall
Hello *, Since no one commented on that yet, i'd like to ask your opinion on something i 'sneaked' into my proposal, which is not directly related to the abuse-c problem, but more of Security in the Database itself: It is the reference protection in person/role/mnt.
person: [mandatory] [single] [lookup key] [...] ref-nfy: [optional] [multiple] [inverse key] <-- mnt-ref: [optional] [multiple] [ ] <--
Is it useful for someone else than me, to protect this objects from unsolicited reference in an other object? This behavior currently only exists for mnt-irt and org (with slightly different implementations though). I'd like to at leas know, or moreover have to acknoledge, when someone wants to put me in as admin-c/tech-c/.... somewhere (esp. when I denote something of security relevance in there). Currently this is only possible by regularly searhing the database (afaik). any opinions on that? 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
participants (3)
-
Jeroen Massar -
Niall O'Reilly -
Ulrich Kiermayr