From vesely at tana.it Tue May 3 07:24:40 2011 From: vesely at tana.it (Alessandro Vesely) Date: Tue, 03 May 2011 07:24:40 +0200 Subject: [acm-tf] Determining a sanction is the primary issue Message-ID: <4DBF9198.1070505@tana.it> Hi all, after sleeping on it, it seems to me that determining a sanction is the most important item on our to-do list. When we'll have determined it, we will be able to state policies formed like If found guilty (for some sense of "guilty" that we will also determine) then sanction will be applied. An example of sanction is to encourage carriers to block packets originating from the guilty address range and destined to port 25; more in general, to a port associated with a "push" protocol (not port 587). Tobias pointed out that blocking a port may incur violation of connection supplies, as defined e.g. by German law. Thus this example of sanction is not possible unless we find out that most carriers would cooperate. An example of guiltiness is not having a responsive IRT (or whatever) and having outstanding abuse reports for some addresses in the relevant range. jm2c From kranjbar at ripe.net Tue May 3 09:33:36 2011 From: kranjbar at ripe.net (Kaveh Ranjbar) Date: Tue, 03 May 2011 09:33:36 +0200 Subject: [acm-tf] Draft Minutes for ACM-TF Meeting, Monday May 2nd 2011 Message-ID: <4DBFAFD0.4090604@ripe.net> Hello, Please find the draft of yesterday's meeting minutes below. Special Thanks to Denis and Athina who have prepared this document. Kind Regards, Kaveh. ----------------------------------------------------------- Acm-tf Amsterdam, 2 May 2011 1) Participants: Brian Nisbet (Chair) Wilfried Woeber Peter Koch Tobias Knecht Piotr Strzyzewski Kauto Huopio Alessandro Vesely For the RIPE NCC: Jochem Ruig Kaveh Ranjbar Denis Walker Athina Fragkouli 2) Task Force Charter - Discuss updated charter proposal 3) ACM policy principles (what are the conditions the policy has to meet?) - Discuss principles for the policy proposal 4) ACM policy requirements (what do we want to achieve with the policy proposal?) 5) ACM policy content 6) ACM policy implementation Discussion on agenda points 2-6 ? The problem is the confusion that people do not know where to put their abuse contact and the accuracy of this information ? The main principle is for a single consistent way to handle abuse contacts ? Abuse contact must lead to a responsible party ? The email address must receive emails without restriction ? Users with large number of objects must be able to manage the system with minimum effort ? Email address but url or other ways may be more appropriate for accuracy purposes -> Action on Kauto: to share with the task force relevant Finish regulations ? 2 functions of the database: registration of public resources and repository of contact details. Both aspects have to be taken into account ? ISPs are not the only network operators, there are others with different requirements whose resources may not be publicly available in the Internet and therefore may not need to have an abuse contact. The url idea also implies you are reachable on the public Internet ? Accuracy applies to all contacts, not only abuse ? The IRT object was design to allow outsourcing of abuse management ? All requirements have to be explicit; putting objects will not solve the problem by itself ? The abuse complaints procedures should not be part of this first initiative ? Someone should handle the abuse, it doesn?t have to be the ISP, it could be the upstream, some hierarchical model or outsourced to a third party ? There was talk about the RIPE NCC auto-generating date stamps as any object in the database is changed. But it was made clear that it would not be the RIPE NCC that assigns any credible meaning to these date stamps. The organizations have to build their own trust on the information they are receiving. Abuse contact, and trust information should be considered as separate issues ? The policy that will come out of this is very important and can have 3 possible degrees of influence: 1. You must have a place to put the abuse contact. 2. 1+you must verify the validity of the email address. 3. 2+you must verify the effectiveness of processing abuse reports. Number 3 is unrealistic and any such policy will be unlikely to achieve community consensus. Number 1 is the most practical as a first step ? There were a number of concerns regarding hierarchical models. o Upstream providers are not recorded in the RIPE DB. o They cannot be held reliable by default, even those that make assignments cannot be held liable by default. o Although the DB does not record the upstream information, the providers know who the upstream is. If the parties agree on handling abuse information the IRT object can accommodate this hierarchical arrangement. Following from the above discussion the basic requirements were summarised as: ? to have a single point of contact that o may be hierarchical, o can be simply queried to return a single piece of information o is easily configured and referenced by others ? to separate storage in the DB from querying the DB and presentation of the information Open issues: ? From an implementation point of view the question was raised whether a new object is required or if the existing IRT would satisfy all the requirements? ? What should be mandatory? An abuse reference on every single resource record or abuse references for resources grouped within hierarchies? -> Action on Brian: to give feedback on Thursday in both AA-WG and DB-WG -> Action on the RIPE NCC: To draft minutes and slides for WG presentations -> Action on the RIPE NCC: to update the acm-tf webpage Next meeting: end of May, beginning of June and meeting after that on September (check clashes with other meetings, eg. ICANN) -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis at ripe.net Tue May 3 10:27:07 2011 From: denis at ripe.net (Denis Walker) Date: Tue, 03 May 2011 10:27:07 +0200 Subject: [acm-tf] consensus in AfriNIC Message-ID: <4DBFBC5B.3040805@ripe.net> Hi all I just noticed this message on AfriNICs mailing list that may be of interest. regards denis Date: Mon, 02 May 2011 07:53:18 -0700 From: sm+afrinic at elandsys.com Subject: [AfriNIC-rpd] Consensus on AFPUB-2010-GEN-006-draft-02 - Abuse Contact Information in the AfriNIC service region Proposal To: rpd at afrinic.net, ALAIN AINA Cc: Alan Barrett Message-ID: <6.2.5.6.2.20110502073705.032449f0 at elandnews.com> Content-Type: text/plain; charset="us-ascii"; format=flowed The Abuse Contact Information in the AfriNIC service region Proposal (AFPUB-2010-GEN-006) specifies a dedicated object which shall be used as the preferred place to publish abuse public contact information within the AfriNIC service region. The mentioned object can be referenced in the inetnum, inet6num and aut-num objects in the AfriNIC Whois Database. It provides a more accurate and efficient way for abuse reports to reach the correct network contact. The proposal was discussed during the AfriNIC-13 meeting. There was a comment about what problem the proposal attempts to solve. It was pointed out that automated reports that are sent out regularly trips the constraints put in place to protect the Whois database from abuse. There was some discussion about whether a new object should be created or whether a new attribute should be added. The proposal leaves that implementation detail up to AfriNIC's technical department. It was also mentioned that the facility in the proposal is optional and not mandatory. AfriNIC will have to put the information in the RIPE abuse finder which is mentioned in the proposal. There was a Last Call for the proposal on 18 March, 2011. There wasn't any comments on the Resource Policy Discussion mailing list. The Interim co-chairs determined that AFPUB-2010-GEN-006-draft-02 has the consensus of the Policy Development Working Group. In line with Section 5.4 of the Policy Development Process, we recommend that AFPUB-2010-GEN-006-draft-02 be approved by the AfriNIC Board of Directors as a policy. Alan Barrett and S. Moonesamy Interim co-chairs, AfriNIC Policy Development Working Group From brian.nisbet at heanet.ie Tue May 3 10:31:30 2011 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Tue, 03 May 2011 09:31:30 +0100 Subject: [acm-tf] Determining a sanction is the primary issue In-Reply-To: <4DBF9198.1070505@tana.it> References: <4DBF9198.1070505@tana.it> Message-ID: <4DBFBD62.1070704@heanet.ie> Alessandro, I didn't think determining sanctions was on our to-do list at all? Brian. On 03/05/2011 06:24, Alessandro Vesely wrote: > Hi all, > after sleeping on it, it seems to me that determining a sanction is the most > important item on our to-do list. When we'll have determined it, we will be > able to state policies formed like > > If found guilty (for some sense of "guilty" that we will also > determine) then sanction will be applied. > > An example of sanction is to encourage carriers to block packets originating > from the guilty address range and destined to port 25; more in general, to a > port associated with a "push" protocol (not port 587). Tobias pointed out > that blocking a port may incur violation of connection supplies, as defined > e.g. by German law. Thus this example of sanction is not possible unless we > find out that most carriers would cooperate. > > An example of guiltiness is not having a responsive IRT (or whatever) and > having outstanding abuse reports for some addresses in the relevant range. > > jm2c > > From denis at ripe.net Tue May 3 15:43:33 2011 From: denis at ripe.net (Denis Walker) Date: Tue, 03 May 2011 15:43:33 +0200 Subject: [acm-tf] suggestion Message-ID: <4DC00685.10708@ripe.net> HI Something for you to think about and feel free to grab me any time this week if you want any more information. I was talking to Tobias this morning about some design ideas I have had over the last year for handling abuse POC information. While talking another idea came to mind. It would be quite easy for us to rename the "mnt-irt:" attribute to "abuse-c:". This would virtually implement the whole requirement for an abuse POC, without affecting its use for Incident Response Teams. It would still require authentication to add a reference to the IRT. It will be obvious to any user that this "new" attribute references a contact as it ends with '-c'. An IRT object IS a contact object, similar to PERSON and ROLE. It does not really matter that "abuse-c:" does not reference a NIC Handle. As long as we have good documentation. At the moment "mnt-irt:" does not reference a maintainer object which can be confusing to users. The IRT already includes "abuse-mailbox:" and "e-mail:". (We can change the optional/mandatory status of these attributes.) We can reference it from INET(6)num and AUT-NUM. Of course any name change may mean users have to change some of their software. This could be done in a phased manner. First rename the attribute and make it optional in the appropriate objects. Leave the existing "abuse-mailbox:" for a while to allow users to move them to the more appropriate place. Then deprecate "abuse-mailbox:" from the other objects. This implements the basic requirement of (moving towards) a single place to store abuse POC in a way that is more intuitive. While that is being rolled out and users start to adjust their data, the Task Force could move on to consider the implications of yesterdays discussion about hierarchies and what needs to be mandatory by syntax or required by business rules and formalising a policy to wrap around the whole issue. Hope the suggestion is helpful. regards Denis Business Analyst RIPE NCC Database Group From ops.lists at gmail.com Tue May 3 16:24:11 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 3 May 2011 19:54:11 +0530 Subject: [acm-tf] suggestion In-Reply-To: <4DC00685.10708@ripe.net> References: <4DC00685.10708@ripe.net> Message-ID: On Tue, May 3, 2011 at 7:13 PM, Denis Walker wrote: > It would be quite easy for us to rename the > "mnt-irt:" attribute to "abuse-c:" Does the IRT role usually perform the role of an abuse desk? And do organizations currently find some utility in populating mnt-irt with an IP / network ops contact person? -- Suresh Ramasubramanian (ops.lists at gmail.com) From denis at ripe.net Tue May 3 16:52:39 2011 From: denis at ripe.net (Denis Walker) Date: Tue, 03 May 2011 16:52:39 +0200 Subject: [acm-tf] suggestion In-Reply-To: References: <4DC00685.10708@ripe.net> Message-ID: <4DC016B7.5060102@ripe.net> Suresh Ramasubramanian wrote: > On Tue, May 3, 2011 at 7:13 PM, Denis Walker wrote: > >> It would be quite easy for us to rename the >> "mnt-irt:" attribute to "abuse-c:" >> > > Does the IRT role usually perform the role of an abuse desk? > The IRT object is currently being used both for Incident Response Teams and as an abuse desk for public complaints. The "abuse-mailbox:" was added to the IRT object to allow it to be used as an abuse desk. > And do organizations currently find some utility in populating mnt-irt > with an IP / network ops contact person? > > There are currently only about 200 IRT objects in the RIPE Database and about 9000 references. So it is probably unlikely much scripting is in place to handle IRT objects. regards denis From tk at abusix.com Tue May 3 16:55:22 2011 From: tk at abusix.com (Tobias Knecht) Date: Tue, 03 May 2011 16:55:22 +0200 Subject: [acm-tf] suggestion In-Reply-To: <4DC00685.10708@ripe.net> References: <4DC00685.10708@ripe.net> Message-ID: <4DC0175A.7040301@abusix.com> Hello, thanks Denis for writing down the ideas of our talk this morning. I absolutely like this idea. It lets us start soon. Almost now! It already offers a lot functionality that is needed. We still have time to adjust small things until RIPE 63. We can "refurbish" the good design of the IRT for a greater audience. And the probably biggest thing is, that we can ask community to start creating the object and give us feedback what will be needed. Something that came into my mind while talking to Denis was, that we should avoid the mistake of creating and developing an extremely nice object and forget about documentation as it has happend with the IRT Object. Thanks, Tobias Am 03.05.11 15:43, schrieb Denis Walker: > HI > > Something for you to think about and feel free to grab me any time this > week if you want any more information. > > I was talking to Tobias this morning about some design ideas I have had > over the last year for handling abuse POC information. While talking > another idea came to mind. It would be quite easy for us to rename the > "mnt-irt:" attribute to "abuse-c:". This would virtually implement the > whole requirement for an abuse POC, without affecting its use for > Incident Response Teams. It would still require authentication to add a > reference to the IRT. > > It will be obvious to any user that this "new" attribute references a > contact as it ends with '-c'. An IRT object IS a contact object, similar > to PERSON and ROLE. It does not really matter that "abuse-c:" does not > reference a NIC Handle. As long as we have good documentation. At the > moment "mnt-irt:" does not reference a maintainer object which can be > confusing to users. The IRT already includes "abuse-mailbox:" and > "e-mail:". (We can change the optional/mandatory status of these > attributes.) We can reference it from INET(6)num and AUT-NUM. Of course > any name change may mean users have to change some of their software. > > This could be done in a phased manner. First rename the attribute and > make it optional in the appropriate objects. Leave the existing > "abuse-mailbox:" for a while to allow users to move them to the more > appropriate place. > > Then deprecate "abuse-mailbox:" from the other objects. > > This implements the basic requirement of (moving towards) a single place > to store abuse POC in a way that is more intuitive. While that is being > rolled out and users start to adjust their data, the Task Force could > move on to consider the implications of yesterdays discussion about > hierarchies and what needs to be mandatory by syntax or required by > business rules and formalising a policy to wrap around the whole issue. > > Hope the suggestion is helpful. > > regards > Denis > Business Analyst > RIPE NCC Database Group > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 267 bytes Desc: OpenPGP digital signature URL: From ops.lists at gmail.com Tue May 3 16:56:31 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 3 May 2011 20:26:31 +0530 Subject: [acm-tf] suggestion In-Reply-To: <4DC016B7.5060102@ripe.net> References: <4DC00685.10708@ripe.net> <4DC016B7.5060102@ripe.net> Message-ID: Fair enough then. thanks On Tue, May 3, 2011 at 8:22 PM, Denis Walker wrote: > > There are currently only about 200 IRT objects in the RIPE Database and > about 9000 references. So it is probably unlikely much scripting is in > place to handle IRT objects. -- Suresh Ramasubramanian (ops.lists at gmail.com) From brian.nisbet at heanet.ie Tue May 3 17:23:47 2011 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Tue, 03 May 2011 16:23:47 +0100 Subject: [acm-tf] suggestion In-Reply-To: <4DC00685.10708@ripe.net> References: <4DC00685.10708@ripe.net> Message-ID: <4DC01E03.2080607@heanet.ie> Denis, On 03/05/2011 14:43, Denis Walker wrote: > HI > > Something for you to think about and feel free to grab me any time this > week if you want any more information. > > I was talking to Tobias this morning about some design ideas I have had > over the last year for handling abuse POC information. While talking > another idea came to mind. It would be quite easy for us to rename the > "mnt-irt:" attribute to "abuse-c:". This would virtually implement the > whole requirement for an abuse POC, without affecting its use for > Incident Response Teams. It would still require authentication to add a > reference to the IRT. I think this could well be a good idea, although I would, of course, welcome more feedback on it, especially from Wilfried. If the TF is happy with the principle of this idea, we can float it to the community on Thursday in DB & AA (but again, state that further updates will be in AA) and see what kind of reaction we get. I've just been speaking to Tobias and I'm wondering how much admin would be around this, ie would it require a policy or not? But this is something we can figure out fairly easily. Thanks, Brian. From denis at ripe.net Tue May 3 17:42:05 2011 From: denis at ripe.net (Denis Walker) Date: Tue, 03 May 2011 17:42:05 +0200 Subject: [acm-tf] suggestion In-Reply-To: <4DC01E03.2080607@heanet.ie> References: <4DC00685.10708@ripe.net> <4DC01E03.2080607@heanet.ie> Message-ID: <4DC0224D.9050209@ripe.net> Brian Nisbet wrote: > Denis, > > On 03/05/2011 14:43, Denis Walker wrote: >> HI >> >> Something for you to think about and feel free to grab me any time this >> week if you want any more information. >> >> I was talking to Tobias this morning about some design ideas I have had >> over the last year for handling abuse POC information. While talking >> another idea came to mind. It would be quite easy for us to rename the >> "mnt-irt:" attribute to "abuse-c:". This would virtually implement the >> whole requirement for an abuse POC, without affecting its use for >> Incident Response Teams. It would still require authentication to add a >> reference to the IRT. > > I think this could well be a good idea, although I would, of course, > welcome more feedback on it, especially from Wilfried. If the TF is > happy with the principle of this idea, we can float it to the > community on Thursday in DB & AA (but again, state that further > updates will be in AA) and see what kind of reaction we get. I've just > been speaking to Tobias and I'm wondering how much admin would be > around this, ie would it require a policy or not? But this is > something we can figure out fairly easily. Renaming the attribute is a semantic change and does not in any way change any existing behaviour. But the impact of a simple name change could be huge. Now it is a weird maintainer attribute name that does not even point to a maintainer object. Add to that the out of date documentation about the IRT object and nothing gives anyone confidence that this is the place to document an abuse contact. This name change, coupled with up to date documentation, makes it intuitive: Where do I document my abuse contact information? I see there is an "abuse-c:" attribute. It points to an object with an "abuse-mailbox:" attribute. That must be the place. It leads you to the right place. But this change does not address some of the other concerns raised by the Task Force yesterday about use of hierarchies and mandatory/required issues. That is something the Task Force still needs to discuss and may need a policy to implement any outcomes of those discussions. regards denis > > Thanks, > > Brian. > > From pk at DENIC.DE Tue May 3 19:44:09 2011 From: pk at DENIC.DE (Peter Koch) Date: Tue, 3 May 2011 19:44:09 +0200 Subject: [acm-tf] suggestion In-Reply-To: <4DC01E03.2080607@heanet.ie> References: <4DC00685.10708@ripe.net> <4DC01E03.2080607@heanet.ie> Message-ID: <20110503174409.GC18541@x27.adm.denic.de> On Tue, May 03, 2011 at 04:23:47PM +0100, Brian Nisbet wrote: > I think this could well be a good idea, although I would, of course, > welcome more feedback on it, especially from Wilfried. If the TF is > happy with the principle of this idea, we can float it to the community i believe we said that we would look at the desired properties of an "abuse contact" and then examine whether the IRT object is a close enough approximation to start from there and make modifications where necessary. I would agree that the/an abuse contact object would be closer to IRT than to person or role, but what exactly is missing or carrying less than desired semantics is still to be found out. Therefore I believe that a "simple rename" would be premature as would circulating this idea to the wider community. Please let's do the requirements first to get a reality check on those rather than on a proposed solution that we'd need to re-engineer for the problem. We also need to address the alleged or real difference between incident response and abuse and whether that can or should be preserved once we're facing the public. -Peter From tk at abusix.com Tue May 3 19:44:54 2011 From: tk at abusix.com (Tobias Knecht) Date: Tue, 03 May 2011 19:44:54 +0200 Subject: [acm-tf] suggestion In-Reply-To: <4DC0224D.9050209@ripe.net> References: <4DC00685.10708@ripe.net> <4DC01E03.2080607@heanet.ie> <4DC0224D.9050209@ripe.net> Message-ID: <4DC03F16.3080408@abusix.com> Hi, > Renaming the attribute is a semantic change and does not in any way > change any existing behaviour. But the impact of a simple name change > could be huge. Now it is a weird maintainer attribute name that does not > even point to a maintainer object. Add to that the out of date > documentation about the IRT object and nothing gives anyone confidence > that this is the place to document an abuse contact. This name change, > coupled with up to date documentation, makes it intuitive: > > Where do I document my abuse contact information? > I see there is an "abuse-c:" attribute. > It points to an object with an "abuse-mailbox:" attribute. > That must be the place. > > It leads you to the right place. > > But this change does not address some of the other concerns raised by > the Task Force yesterday about use of hierarchies and mandatory/required > issues. That is something the Task Force still needs to discuss and may > need a policy to implement any outcomes of those discussions. I could not more agree to this. Again, I think this is a great idea. Thanks, Tobias -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 267 bytes Desc: OpenPGP digital signature URL: From Woeber at CC.UniVie.ac.at Wed May 4 00:39:27 2011 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 03 May 2011 22:39:27 +0000 Subject: [acm-tf] Determining a sanction is the primary issue In-Reply-To: <4DBF9198.1070505@tana.it> References: <4DBF9198.1070505@tana.it> Message-ID: <4DC0841F.2070604@CC.UniVie.ac.at> Alessandro Vesely wrote: [...] > If found guilty (for some sense of "guilty" that we will also > determine) then sanction will be applied. I am pretty worried by both the choice of words and terms, as well as by the general mindset behind. The RIPE NCC has no mandate to determine "guilt" in a general sense. We do have more than enough self-appointed policemen and vigilantes on the 'net. As laudable as their individual or organisational goals may be, just as dangerous for the well-being and the stability of the network they sometimes are. Determining "guilt" in a formal sense, or serious infraction of laws and regulations is the job of a court. It cannot be a fuzzy notion of "having outstanding abuse reports". With regard to the NCC, it can enforce compliance with policy, based on actions or facts that are well-definced and agreed in a commercial contract, and that equally apply throughout its service region. E.g. supplying a bogus identity or claiming to reside in a non-existent location or making up a bugus network and addressing plan, and the like. Expecting the legitimate user(s) of IP resources to block packets within their network, or to interfere with operational aspects, like requiring a particular handling of ports or protocols, is definitely out of scope. I may add here, that some of those self-appointed vigilantes have themselves tried already to use mechanisms to "force" other entities by applying pressure mechanisms that would render them "guilty" in general terms. There is a good reason whay at least one of those organisations has already been taken to court for that, and has been publicly shamed for their activities and "reasoning". The last thing I would like to see is the RIPE NCC becoming one of "those" organisations, too. As bad as some stuff on the Internet is (I am well aware of that fact[1]) the stability and impartiality of the RIPE NCC is by far more important, imho. Regarding the aspect of trying to motivate operators to "do the right thing", as well as users, there are mechanisms and organsisations around, already, which can be (and already are!) involved and deployed. Amongst others, in the framework of RIPE, there's the mechanism of BCPs. However, the "enforcement" of such BCPs usually relies on peer pressure, halls of shame, or the like. But not on arbitrarily shouting "guilty" and imposing "sanctions". Sorry for the rant and the use of strong words, but I think this TF has to stay on the ground and SHOULD, or rather MUST, respect its mandate and the basis of existence of the RIPE NCC. Regards, Wilfried. [1] I was instrumental in setting up the 1st CERT Team in Austria (ACOnet-CERT), which became the 1st Austrian team to acquire FIRST Membership status and TI Accreditation, I am for the 2nd time on the Review Board of the Trusted Introducer Service in Europe, and I "happen" to be on the Advisory Board for the Austrian National CERT/Government CERT. Incidentally, I also served on the initial executive board of the RIPE NCC and on ICANN's Address Council since its inception. From ops.lists at gmail.com Wed May 4 03:15:02 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 4 May 2011 06:45:02 +0530 Subject: [acm-tf] Determining a sanction is the primary issue In-Reply-To: <4DC0841F.2070604@CC.UniVie.ac.at> References: <4DBF9198.1070505@tana.it> <4DC0841F.2070604@CC.UniVie.ac.at> Message-ID: It depends - at least some activists (and blocklists) have tried to use RIPE processes properly. And on the other hand there are some entitites that follow the RIPE processes in letter though definitely not in spirit, to get themselves lots of /15s. Can we please not go down this blame game path? On Wed, May 4, 2011 at 4:09 AM, Wilfried Woeber, UniVie/ACOnet wrote: > > I may add here, that some of those self-appointed vigilantes have themselves > tried already to use mechanisms to "force" other entities by applying pressure > mechanisms that would render them "guilty" in general terms. There is a good > reason whay at least one of those organisations has already been taken to court > for that, and has been publicly shamed for their activities and "reasoning". > > The last thing I would like to see is the RIPE NCC becoming one of "those" > organisations, too. As bad as some stuff on the Internet is (I am well aware > of that fact[1]) the stability and impartiality of the RIPE NCC is by far more > important, imho. -- Suresh Ramasubramanian (ops.lists at gmail.com) From brian.nisbet at heanet.ie Wed May 4 08:57:20 2011 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Wed, 04 May 2011 07:57:20 +0100 Subject: [acm-tf] Determining a sanction is the primary issue In-Reply-To: References: <4DBF9198.1070505@tana.it> <4DC0841F.2070604@CC.UniVie.ac.at> Message-ID: <4DC0F8D0.20107@heanet.ie> Morning (at least in this time zone), Let me be more clear than I was yesterday, I do not see this discussion as anywhere even close to the scope of the TF, regardless of its merits or otherwise, so I think it's best that we let it lie at this point. Thanks, Brian. On 04/05/2011 02:15, Suresh Ramasubramanian wrote: > It depends - at least some activists (and blocklists) have tried to > use RIPE processes properly. > > And on the other hand there are some entitites that follow the RIPE > processes in letter though definitely not in spirit, to get themselves > lots of /15s. > > Can we please not go down this blame game path? > > On Wed, May 4, 2011 at 4:09 AM, Wilfried Woeber, UniVie/ACOnet > wrote: >> >> I may add here, that some of those self-appointed vigilantes have themselves >> tried already to use mechanisms to "force" other entities by applying pressure >> mechanisms that would render them "guilty" in general terms. There is a good >> reason whay at least one of those organisations has already been taken to court >> for that, and has been publicly shamed for their activities and "reasoning". >> >> The last thing I would like to see is the RIPE NCC becoming one of "those" >> organisations, too. As bad as some stuff on the Internet is (I am well aware >> of that fact[1]) the stability and impartiality of the RIPE NCC is by far more >> important, imho. > > > From brian.nisbet at heanet.ie Wed May 4 09:06:26 2011 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Wed, 04 May 2011 08:06:26 +0100 Subject: [acm-tf] suggestion In-Reply-To: <20110503174409.GC18541@x27.adm.denic.de> References: <4DC00685.10708@ripe.net> <4DC01E03.2080607@heanet.ie> <20110503174409.GC18541@x27.adm.denic.de> Message-ID: <4DC0FAF2.9050605@heanet.ie> Peter, On 03/05/2011 18:44, Peter Koch wrote: > On Tue, May 03, 2011 at 04:23:47PM +0100, Brian Nisbet wrote: > >> I think this could well be a good idea, although I would, of course, >> welcome more feedback on it, especially from Wilfried. If the TF is >> happy with the principle of this idea, we can float it to the community > > i believe we said that we would look at the desired properties of > an "abuse contact" and then examine whether the IRT object is a close > enough approximation to start from there and make modifications > where necessary. I would agree that the/an abuse contact object would > be closer to IRT than to person or role, but what exactly is missing > or carrying less than desired semantics is still to be found out. > > Therefore I believe that a "simple rename" would be premature as would > circulating this idea to the wider community. Please let's do the > requirements first to get a reality check on those rather than on > a proposed solution that we'd need to re-engineer for the problem. > > We also need to address the alleged or real difference between incident > response and abuse and whether that can or should be preserved once > we're facing the public. All very good points, thank you. We did agree that, so let's do what we said we would do. Brian. From tk at abusix.com Wed May 4 10:09:31 2011 From: tk at abusix.com (Tobias Knecht) Date: Wed, 04 May 2011 10:09:31 +0200 Subject: [acm-tf] suggestion In-Reply-To: <20110503174409.GC18541@x27.adm.denic.de> References: <4DC00685.10708@ripe.net> <4DC01E03.2080607@heanet.ie> <20110503174409.GC18541@x27.adm.denic.de> Message-ID: <4DC109BB.10708@abusix.com> Hi, > i believe we said that we would look at the desired properties of > an "abuse contact" and then examine whether the IRT object is a close > enough approximation to start from there and make modifications > where necessary. I would agree that the/an abuse contact object would > be closer to IRT than to person or role, but what exactly is missing > or carrying less than desired semantics is still to be found out. Never the less I would present this idea to the community on Thursday. Depending on the feedback and the feedback on the mailinglist afterwards we can see if touching the IRT object in any way is a opportunity or a no-go. I want to avoid to come up with a policy proposal at RIPE 63 that is technically "perfect" but can't find consensus due other reasons. As far as I can remember the problem with 2010-08 was the mandatoryness of the IRT object. There were only a few other imho minor objections. > Therefore I believe that a "simple rename" would be premature as would > circulating this idea to the wider community. Please let's do the > requirements first to get a reality check on those rather than on > a proposed solution that we'd need to re-engineer for the problem. I would not rename it at the moment. I would look for the feedback on Thursday and the feedback until end of May on the ML. If there are no major objections, we know that if we want to go the way of using the IRT Object in whatever way we can do so. We can than start preparing for a rename until RIPE 63, and come up with the complete proposal. > We also need to address the alleged or real difference between incident > response and abuse and whether that can or should be preserved once > we're facing the public. After bringing this idea, just as an idea to the community we know if there are concerns about touching the IRT and more important which concerns. I would not like to start a discussion about the difference between Incident Response Teams and Abuse Teams, because in some cases there might not even be a difference. Probably even some of the IRTs do not see any difference anymore. And if there are concerns coming from the community we could stop thinking about the "simple rename" and write a proposal that creates a copy of the IRT, naming it abuse-c and develop the needed object that way. Thanks, Tobias -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 267 bytes Desc: OpenPGP digital signature URL: From vesely at tana.it Wed May 4 10:42:17 2011 From: vesely at tana.it (Alessandro Vesely) Date: Wed, 04 May 2011 10:42:17 +0200 Subject: [acm-tf] Determining a sanction is the primary issue In-Reply-To: <4DC0841F.2070604@CC.UniVie.ac.at> References: <4DBF9198.1070505@tana.it> <4DC0841F.2070604@CC.UniVie.ac.at> Message-ID: <4DC11169.5080108@tana.it> On 04.05.2011 00:39, Wilfried Woeber, UniVie/ACOnet wrote: > Alessandro Vesely wrote: > [...] >> If found guilty (for some sense of "guilty" that we will also >> determine) then sanction will be applied. > > I am pretty worried by both the choice of words and terms, as well as > by the general mindset behind. That's what we were talking about Monday at about 12:15. We didn't call it "sanction", but used phrases with terms like "three-month advice", "contract termination", or similar. I think "sanction" conveys the idea. As for the mindset, my concern is simply to avoid going "bananas"[1]. I don't want millions of users to be at the mercy of a few unscrupulous profiteers, and I know that writing "please be scrupulous" in a BCP is not enough to stop them. [1] http://en.wikipedia.org/wiki/Bananas_%28film%29 > Expecting the legitimate user(s) of IP resources to block packets within their > network, or to interfere with operational aspects, like requiring a particular > handling of ports or protocols, is definitely out of scope. That's what I wanted to know. > Sorry for the rant and the use of strong words I don't think you should be sorry for speaking clearly. Actually, that improves communication effectiveness :-) From vesely at tana.it Wed May 4 11:12:58 2011 From: vesely at tana.it (Alessandro Vesely) Date: Wed, 04 May 2011 11:12:58 +0200 Subject: [acm-tf] suggestion In-Reply-To: <4DC0175A.7040301@abusix.com> References: <4DC00685.10708@ripe.net> <4DC0175A.7040301@abusix.com> Message-ID: <4DC1189A.1080109@tana.it> On 03.05.2011 16:55, Tobias Knecht wrote: > I absolutely like this idea. > > It lets us start soon. Almost now! > It already offers a lot functionality that is needed. Yes, the idea looks good, and its ease of deployment is tempting. However, I don't think that terminating our task quickly is a priority. We should check whether it provides, or can be complemented so as to provide, /all/ the functionality that is needed. From tk at abusix.com Wed May 4 15:06:19 2011 From: tk at abusix.com (Tobias Knecht) Date: Wed, 04 May 2011 15:06:19 +0200 Subject: [acm-tf] Functionality Message-ID: <4DC14F4B.4060905@abusix.com> Hello, as logical next step of Denis' suggestion and the feedback, that it would make sense to start a list of functionality and not only saying it must have any functionality. To make it easier I suggest to divide functionality into 2 parts. Object functionality and content functionality. Object functionality describes how the object should behave in the hole environment of the database (hierarchy, place, ...) Content functionality describes the content that should be offered by the object within the object (2 mail addresses, url attribute, ...) Please do _not_ comment at this point on each of these things, we should just collect all ideas of functionality and discuss them later. Please ;-) I think we all agree on the following Object Functionalities: - a good name that is easy to understand (e.g. abuse-c) - reference it only once from INET(6)num and AUT-NUM. - hierarchical design. - be compatible with actual and future db design. - flexible - can not be linked by anyone to anywhere - mandatory or not mandatory object - On a Content side we have: - contains e-mail and abuse-mailbox attribute - query restriction on all attributes without abuse-mailbox attribute - contain url attribute for optional website of abuse team. - So please add all your ideas and recommendations to this lists. And discuss it later via ML or in person on another conference call. As soon as we agreed on which functionality should be implemented I suggest asking Denis and other from the database group what would be the best technical way to get things into production. Just an idea. Thanks, Tobias -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 267 bytes Desc: OpenPGP digital signature URL: From Piotr.Strzyzewski at polsl.pl Thu May 5 14:16:47 2011 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Thu, 5 May 2011 14:16:47 +0200 Subject: [acm-tf] whois data accuracy Message-ID: <20110505121647.GD3239@hydra.ck.polsl.pl> Hi We talk a lot about whois data acuracy and about how this could be improved. I just have found something in the RIPE NCC's playground after being assigned IP address during this meeting: inetnum: 193.0.24.0 - 193.0.31.255 netname: RIPE-MEETINGS descr: used exclusively by INROMA for RIPE 61 Rome remarks: RIPE61 15-19 November 2010 descr: RIPE Network Coordination Centre descr: Amsterdam, Netherlands remarks: Used for RIPE meetings. country: NL admin-c: JDR-RIPE admin-c: BRD-RIPE tech-c: OPS4-RIPE status: ASSIGNED PI mnt-by: RIPE-NCC-HM-MNT mnt-by: RIPE-NCC-MNT mnt-lower: RIPE-NCC-MNT source: RIPE changed: bit-bucket at ripe.net 20080409 changed: hostmaster at ripe.net 20101004 role: RIPE NCC Operations address: Singel 258 address: 1016 AB Amsterdam address: The Netherlands [...] and so on. Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From vesely at tana.it Thu May 5 19:57:14 2011 From: vesely at tana.it (Alessandro Vesely) Date: Thu, 05 May 2011 19:57:14 +0200 Subject: [acm-tf] Functionality In-Reply-To: <4DC14F4B.4060905@abusix.com> References: <4DC14F4B.4060905@abusix.com> Message-ID: <4DC2E4FA.3090504@tana.it> Hi Tobias, On 04.05.2011 15:06, Tobias Knecht wrote: > Please do _not_ comment at this point on each of these things, we should > just collect all ideas of functionality and discuss them later. Please ;-) What is "later", next meeting? Why not start new threads with the subjects copied from the lists you sent? From jochem at ripe.net Fri May 6 08:50:02 2011 From: jochem at ripe.net (Jochem de Ruig) Date: Fri, 06 May 2011 08:50:02 +0200 Subject: [acm-tf] whois data accuracy In-Reply-To: <20110505121647.GD3239@hydra.ck.polsl.pl> References: <20110505121647.GD3239@hydra.ck.polsl.pl> Message-ID: <4DC39A1A.8010102@ripe.net> Hi Pjotr and all, Good point, we have corrected this, the record should be more generic but due to the data protection legislation in Italy we were required to add these comments for the Rome meeting. Regards, Jochem On 5/5/11 2:16 PM, Piotr Strzyzewski wrote: > Hi > > We talk a lot about whois data acuracy and about how this could be > improved. I just have found something in the RIPE NCC's playground after > being assigned IP address during this meeting: > > inetnum: 193.0.24.0 - 193.0.31.255 > netname: RIPE-MEETINGS > descr: used exclusively by INROMA for RIPE 61 Rome > remarks: RIPE61 15-19 November 2010 > descr: RIPE Network Coordination Centre > descr: Amsterdam, Netherlands > remarks: Used for RIPE meetings. > country: NL > admin-c: JDR-RIPE > admin-c: BRD-RIPE > tech-c: OPS4-RIPE > status: ASSIGNED PI > mnt-by: RIPE-NCC-HM-MNT > mnt-by: RIPE-NCC-MNT > mnt-lower: RIPE-NCC-MNT > source: RIPE > changed: bit-bucket at ripe.net 20080409 > changed: hostmaster at ripe.net 20101004 > > role: RIPE NCC Operations > address: Singel 258 > address: 1016 AB Amsterdam > address: The Netherlands > > [...] and so on. > > Piotr > From brian.nisbet at heanet.ie Fri May 6 08:50:23 2011 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Fri, 06 May 2011 07:50:23 +0100 Subject: [acm-tf] Functionality In-Reply-To: <4DC2E4FA.3090504@tana.it> References: <4DC14F4B.4060905@abusix.com> <4DC2E4FA.3090504@tana.it> Message-ID: <4DC39A2F.1060506@heanet.ie> On 05/05/2011 18:57, Alessandro Vesely wrote: > Hi Tobias, > > On 04.05.2011 15:06, Tobias Knecht wrote: >> Please do _not_ comment at this point on each of these things, we should >> just collect all ideas of functionality and discuss them later. Please ;-) > > What is "later", next meeting? Why not start new threads with the subjects > copied from the lists you sent? Well, I think we can easy have some discussion on these items before the next meeting, but I think we should set a timeline of a week to gather further functionality ideas, before starting on the preliminary discussion. So, let's gather requirements until the 13th and go from there. Thanks, Brian. From tk at abusix.com Fri May 6 08:59:01 2011 From: tk at abusix.com (Tobias Knecht) Date: Fri, 06 May 2011 08:59:01 +0200 Subject: [acm-tf] Functionality In-Reply-To: <4DC39A2F.1060506@heanet.ie> References: <4DC14F4B.4060905@abusix.com> <4DC2E4FA.3090504@tana.it> <4DC39A2F.1060506@heanet.ie> Message-ID: <4DC39C35.9000404@abusix.com> Am 06.05.11 08:50, schrieb Brian Nisbet: > On 05/05/2011 18:57, Alessandro Vesely wrote: >> Hi Tobias, >> >> On 04.05.2011 15:06, Tobias Knecht wrote: >>> Please do _not_ comment at this point on each of these things, we should >>> just collect all ideas of functionality and discuss them later. >>> Please ;-) >> >> What is "later", next meeting? Why not start new threads with the >> subjects >> copied from the lists you sent? > > Well, I think we can easy have some discussion on these items before the > next meeting, but I think we should set a timeline of a week to gather > further functionality ideas, before starting on the preliminary discussion. > > So, let's gather requirements until the 13th and go from there. Perfect. Sorry I forgot to set a date. My bad. Have a nice last meeting day. Tobias -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 267 bytes Desc: OpenPGP digital signature URL: From pk at DENIC.DE Sat May 7 22:33:09 2011 From: pk at DENIC.DE (Peter Koch) Date: Sat, 7 May 2011 22:33:09 +0200 Subject: [acm-tf] Functionality In-Reply-To: <4DC14F4B.4060905@abusix.com> References: <4DC14F4B.4060905@abusix.com> Message-ID: <20110507203309.GC5823@x27.adm.denic.de> Tonias, all, On Wed, May 04, 2011 at 03:06:19PM +0200, Tobias Knecht wrote: > I think we all agree on the following Object Functionalities: > > - a good name that is easy to understand (e.g. abuse-c) we need to distinguish between the name of the object and the name of the attribute referencing the object. Primary target audience here would be the data publisher, so "abuse-c" in the referring object looks well consistent with "admin-c" and "tech-c". The object name itself may be "irt" or something different. For the reader/consumer, I believe the name of the object and attribute are of less importance. Either people are trained enough to use port 43 whois, then they are supposed to read documentation, or they ought to use the web whois or even a dedicated abuse contact finder tool that should take care of the necessary abstractions not to expose db level syntactic sugar to the end user. > - reference it only once from INET(6)num and AUT-NUM. Not sure it makes sense for aut-num. If that's the case, then what about teh route and route6 object types? Also, the current abuse finding tool apparently looks for remarks and URLs in other objects, too. It might be helpful to understand what objects these appear in and how to translate that into requirements. Whether or not it's a singleton attribute is an interesting question. > - hierarchical design. Needs clarification: does it mean the querying mechanism should be able to locate the closest covering reference for inetnum and inet6num objects? > - be compatible with actual and future db design. > - flexible that's too fuzzy for me. > - can not be linked by anyone to anywhere Needs clarification: who should be asked for confirmation for a reference this "the" object? > - mandatory or not mandatory object Assuming you mean the referencing attribute here, making it mandatory might be in conlict with the hierarchical approach and would also not too well work with an expected deployment curve. > On a Content side we have: > > - contains e-mail and abuse-mailbox attribute What would the difference be? > - query restriction on all attributes without abuse-mailbox attribute Could you clarify this? > - contain url attribute for optional website of abuse team. I'd almots assume we want a URL for some policy description or report/ report format requirements. We've had discussions about abuse vs incidents, but i'm split. If we start going down that path we might end up with an enumeration of potential abuse scenarios (spam, phish, portscan, ssh scan, dos, ...) that will never be distinguished enough for some but will soon be large enough to confuse the potential user. -Peter From tk at abusix.com Sun May 8 15:50:34 2011 From: tk at abusix.com (Tobias Knecht) Date: Sun, 08 May 2011 15:50:34 +0200 Subject: [acm-tf] Functionality In-Reply-To: <20110507203309.GC5823@x27.adm.denic.de> References: <4DC14F4B.4060905@abusix.com> <20110507203309.GC5823@x27.adm.denic.de> Message-ID: <4DC69FAA.6080101@abusix.com> Hi everybody, >> - a good name that is easy to understand (e.g. abuse-c) > > we need to distinguish between the name of the object and the name > of the attribute referencing the object. Primary target audience > here would be the data publisher, so "abuse-c" in the referring object > looks well consistent with "admin-c" and "tech-c". The object name > itself may be "irt" or something different. For the reader/consumer, > I believe the name of the object and attribute are of less importance. > Either people are trained enough to use port 43 whois, then they are > supposed to read documentation, or they ought to use the web whois > or even a dedicated abuse contact finder tool that should take care > of the necessary abstractions not to expose db level syntactic sugar > to the end user. I feel very comfotable about the name abuse-c, because everybody understands that "c" means contact as it does in admin-c and tech-c already. Publishers and Users. I think it is more the function of the database people to decide on a name for the final object. As Denis explained to me, we could use a special type of object like an IRT Object or database people could decide to use a role object with special rules around. >> - reference it only once from INET(6)num and AUT-NUM. > > Not sure it makes sense for aut-num. If that's the case, then what > about teh route and route6 object types? Good point. Need to be discussed. > Also, the current abuse finding tool apparently looks for remarks and URLs > in other objects, too. It might be helpful to understand what objects > these appear in and how to translate that into requirements. I would avoid doing this. As we have seen and RIPE NCC got the same feedback by users and publishers, sometimes they went a little bit to far. The links from one object to another to another maintainer could lead into complete wrong directions. > Whether or not it's a singleton attribute is an interesting question. > >> - hierarchical design. > > Needs clarification: does it mean the querying mechanism should be > able to locate the closest covering reference for inetnum and > inet6num objects? That has to be discussed as well. >> - can not be linked by anyone to anywhere > > Needs clarification: who should be asked for confirmation for a > reference this "the" object? If somebody references your Abuse Object, you need to acknowledge or at least be informed about. It should be avoided that everybody can link his abuse-c attribute to any object. >> - mandatory or not mandatory object > > Assuming you mean the referencing attribute here, making it mandatory > might be in conlict with the hierarchical approach and would also not > too well work with an expected deployment curve. Right. We could for example decide that all direct allocations need to have it and everything beyond will be linked to the highest level. That way the direct allocation can force his customers as well to create it or handle it by him self. I think this questions can not be answered with yes or no, there is a lot of grey between. >> On a Content side we have: >> >> - contains e-mail and abuse-mailbox attribute > > What would the difference be? e-mail attribute: personal correspondence between abuse departments. abuse-mailbox attribute: only automatic complaint handling. >> - query restriction on all attributes without abuse-mailbox attribute > > Could you clarify this? We could use query restrictions for all attributes, without the abuse-mailbox attribute as we have it already today. That way we could query unrestricted for example with the -b option. That way we could meet the requirements of the community not to publish email addresses for personal communication to widely. >> - contain url attribute for optional website of abuse team. > > I'd almots assume we want a URL for some policy description or report/ > report format requirements. Right. That would be the place. And it would really be easy to check if this URL is still valid after a while a request the maintainer to update his data if it i not. But this is not a part of this discussion, just an idea. > We've had discussions about abuse vs incidents, but i'm split. > If we start going down that path we might end up with an enumeration > of potential abuse scenarios (spam, phish, portscan, ssh scan, dos, ...) > that will never be distinguished enough for some but will soon be large > enough to confuse the potential user. I would not go down this road. Every organization is different. In some organizations there are only abuse departments handling all this things. In other they have just Incident Response Teams. So they should handle everything as well. The only problem we are facing is a organization that has both in place. And my experience with such organizations is that they do not exactly know who is responsible for what, so how should we be able to decide this. Let's stay with abuse team, because this easy to understand and $world does know what an abuse team is, but not necessary know what an incident response team is. Just my feeling. Thanks for the feedback. Are there any other functionalities that we should think of? Tobias -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 267 bytes Desc: OpenPGP digital signature URL: From ops.lists at gmail.com Sun May 8 15:57:10 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sun, 8 May 2011 19:27:10 +0530 Subject: [acm-tf] Functionality In-Reply-To: <4DC69FAA.6080101@abusix.com> References: <4DC14F4B.4060905@abusix.com> <20110507203309.GC5823@x27.adm.denic.de> <4DC69FAA.6080101@abusix.com> Message-ID: +1 to tobias. Can we now knock together a proposal for this and submit it for rough consensus? On Sun, May 8, 2011 at 7:20 PM, Tobias Knecht wrote: > > I feel very comfotable about the name abuse-c, because everybody > understands that "c" means contact as it does in admin-c and tech-c > already. Publishers and Users. > > I think it is more the function of the database people to decide on a > name for the final object. As Denis explained to me, we could use a > special type of object like an IRT Object or database people could > decide to use a role object with special rules around. -- Suresh Ramasubramanian (ops.lists at gmail.com) From pk at DENIC.DE Sun May 8 17:50:52 2011 From: pk at DENIC.DE (Peter Koch) Date: Sun, 8 May 2011 17:50:52 +0200 Subject: [acm-tf] Functionality In-Reply-To: <4DC69FAA.6080101@abusix.com> References: <4DC14F4B.4060905@abusix.com> <20110507203309.GC5823@x27.adm.denic.de> <4DC69FAA.6080101@abusix.com> Message-ID: <20110508155052.GC22691@x27.adm.denic.de> dear tf, On Sun, May 08, 2011 at 03:50:34PM +0200, Tobias Knecht wrote: > I feel very comfotable about the name abuse-c, because everybody > understands that "c" means contact as it does in admin-c and tech-c > already. Publishers and Users. maybe, but we need to keep in mind that there are different types of users. And there's also the subtle difference between "abuse" and "anti-abuse", really. > I think it is more the function of the database people to decide on a > name for the final object. The point i was trying to make is that the object and the attribute referencing it don't need to (an maybe shouldd not) bear the same name. > > >> - reference it only once from INET(6)num and AUT-NUM. > > > > Not sure it makes sense for aut-num. If that's the case, then what > > about teh route and route6 object types? > > Good point. Need to be discussed. If aut-num was going to allow a link to $object, the expectations for both publishers and users need to be clearly documented. Currently my imagination doesn't help me to link an "abuse" case to an AS rather than address space (or really, the route). Of course, announcing a wrong prefix might fall into this category, but then that would be an operational matter (read: "tech-c") to start with. > > Also, the current abuse finding tool apparently looks for remarks and URLs > > in other objects, too. It might be helpful to understand what objects > > these appear in and how to translate that into requirements. > > I would avoid doing this. As we have seen and RIPE NCC got the same > feedback by users and publishers, sometimes they went a little bit to > far. The links from one object to another to another maintainer could > lead into complete wrong directions. I dod not suggest to copy the current strategy. However, the claim I heardd in A'dam and before was that publishers (mntners, ISPs) would have difficulties to find the best, optimal, clear way to specify their abuse contact information. So, for us to back our requirements with some real world observation, looking into the publishers' practices to reverse engineer their desires isn't as good as direct input, but lacking that still more valuable than guessing. > >> - hierarchical design. > > > > Needs clarification: does it mean the querying mechanism should be > > able to locate the closest covering reference for inetnum and > > inet6num objects? > > That has to be discussed as well. So, could we start the discussion? > >> - can not be linked by anyone to anywhere > > > > Needs clarification: who should be asked for confirmation for a > > reference this "the" object? > > If somebody references your Abuse Object, you need to acknowledge or at > least be informed about. It should be avoided that everybody can link > his abuse-c attribute to any object. This smells a lot like IRT and would raise the same concerns that people are believed to have with irt today. I'd agree that some notification would be helpful, but then again, "copy+link" isn't much more effort than just "link". > >> - mandatory or not mandatory object > > > > Assuming you mean the referencing attribute here, making it mandatory > > might be in conlict with the hierarchical approach and would also not > > too well work with an expected deployment curve. > > Right. We could for example decide that all direct allocations need to > have it and everything beyond will be linked to the highest level. That > way the direct allocation can force his customers as well to create it > or handle it by him self. I think this questions can not be answered > with yes or no, there is a lot of grey between. Why should someone without intent to connect to the Internet be "forced" to publish an abuse contact? > >> - contains e-mail and abuse-mailbox attribute > > > > What would the difference be? > > e-mail attribute: personal correspondence between abuse departments. > abuse-mailbox attribute: only automatic complaint handling. How would one qualify as an "abuse department", allowing for inter-abuse communication? Also, "automatic complaint handling" might set the limits for what to expect, but woul be need to defined in detail, including formats and the like. I think we agreed further down this email that splitting the contacts is the best avenue into confusion, so i'm not convinced here. > >> - query restriction on all attributes without abuse-mailbox attribute > > > > Could you clarify this? > > We could use query restrictions for all attributes, without the > abuse-mailbox attribute as we have it already today. That way we could > query unrestricted for example with the -b option. OK, that would be more of a "limited visibility" rather than ACL based or volume based restrictions on queries. The experience with "-B" was split, I guess, since although it was expected to be used by "professionals" only, it kind of leaked. It appears to me that the real requirement is to not confuse the target audience which in turn leads us to the tricky question of who the target audiences are: 1) professional users with access to and understanding of teh DB documentation 2) semi- or pseudo professionals who are easily confused and tend to act as multipliers (e.g. by publishing tools) 3) web centric end users The case (2) is hopeless. (3) is better addressed by a well designed, web based user interface than by commandlinbe whois and (1) wouldn't need this kind of restrictions to visibility. > That way we could meet the requirements of the community not to publish > email addresses for personal communication to widely. That'd be security by obscurity and, again, experience shows that this kind of "secret" or "expert mode" switch will be well known rather soon. > >> - contain url attribute for optional website of abuse team. > > > > I'd almots assume we want a URL for some policy description or report/ > > report format requirements. > > Right. That would be the place. And it would really be easy to check if > this URL is still valid after a while a request the maintainer to update > his data if it i not. But this is not a part of this discussion, just an > idea. Agree. This information will not be subject to checking or vetting for registration. > everything as well. The only problem we are facing is a organization > that has both in place. And my experience with such organizations is > that they do not exactly know who is responsible for what, so how should > we be able to decide this. We wouldn't. By offering two (or maybe more) options, we'd just enable them to communicate the various contact points. But we _would_ have to set the expectations an i have so far not seen a crisp definition that would istinguish the two from the perspective of an end user. -Peter From ops.lists at gmail.com Sun May 8 17:53:37 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sun, 8 May 2011 21:23:37 +0530 Subject: [acm-tf] Functionality In-Reply-To: <20110508155052.GC22691@x27.adm.denic.de> References: <4DC14F4B.4060905@abusix.com> <20110507203309.GC5823@x27.adm.denic.de> <4DC69FAA.6080101@abusix.com> <20110508155052.GC22691@x27.adm.denic.de> Message-ID: I can see both use cases as possibles - where you'd specify an abuse@ for a whole ASN, and for individual CIDRs. In practice abuse issues that are routed to the abuse contact for the ASN owner are likely to land two or three levels (at least) upstream of the actual entity whose abuse team is the right POC. On Sun, May 8, 2011 at 9:20 PM, Peter Koch wrote: > > If aut-num was going to allow a link to $object, the expectations for > both publishers and users need to be clearly documented. ?Currently > my imagination doesn't help me to link an "abuse" case to an AS rather than > address space (or really, the route). ?Of course, announcing a > wrong prefix might fall into this category, but then that would be > an operational matter (read: "tech-c") to start with. -- Suresh Ramasubramanian (ops.lists at gmail.com) From tk at abusix.com Mon May 9 12:19:56 2011 From: tk at abusix.com (Tobias Knecht) Date: Mon, 09 May 2011 12:19:56 +0200 Subject: [acm-tf] Functionality In-Reply-To: <20110508155052.GC22691@x27.adm.denic.de> References: <4DC14F4B.4060905@abusix.com> <20110507203309.GC5823@x27.adm.denic.de> <4DC69FAA.6080101@abusix.com> <20110508155052.GC22691@x27.adm.denic.de> Message-ID: <4DC7BFCC.1040503@abusix.com> Hi, >>> Also, the current abuse finding tool apparently looks for remarks and URLs >>> in other objects, too. It might be helpful to understand what objects >>> these appear in and how to translate that into requirements. >> >> I would avoid doing this. As we have seen and RIPE NCC got the same >> feedback by users and publishers, sometimes they went a little bit to >> far. The links from one object to another to another maintainer could >> lead into complete wrong directions. > > I dod not suggest to copy the current strategy. However, the claim I > heardd in A'dam and before was that publishers (mntners, ISPs) would > have difficulties to find the best, optimal, clear way to specify their > abuse contact information. So, for us to back our requirements with > some real world observation, looking into the publishers' practices > to reverse engineer their desires isn't as good as direct input, but > lacking that still more valuable than guessing. That is probably true, but never the less I do not see to figure out the true desire of what people need by looking at remark fields, abuse-mailbox attributes and IRT Objects. The information that can be published over these ways is exactly what we would like to improve and not "copy" them. Or did I get something wrong? >>>> - hierarchical design. >>> >>> Needs clarification: does it mean the querying mechanism should be >>> able to locate the closest covering reference for inetnum and >>> inet6num objects? >> >> That has to be discussed as well. > > So, could we start the discussion? Sure. ;-) >>>> - can not be linked by anyone to anywhere >>> >>> Needs clarification: who should be asked for confirmation for a >>> reference this "the" object? >> >> If somebody references your Abuse Object, you need to acknowledge or at >> least be informed about. It should be avoided that everybody can link >> his abuse-c attribute to any object. > > This smells a lot like IRT and would raise the same concerns that people > are believed to have with irt today. I'd agree that some notification > would be helpful, but then again, "copy+link" isn't much more effort than > just "link". Yes this smell really a lot like IRT, even if my feeling tells me at the moment there is another better ways of doing it. The other questions with this would be. Is this not something we would like to see with all existing objects and not only with the $abuse_object? If we do, we should keep exactly this out of this discussion and bring up another proposal for all $objects in the database. >>>> - mandatory or not mandatory object >>> >>> Assuming you mean the referencing attribute here, making it mandatory >>> might be in conlict with the hierarchical approach and would also not >>> too well work with an expected deployment curve. >> >> Right. We could for example decide that all direct allocations need to >> have it and everything beyond will be linked to the highest level. That >> way the direct allocation can force his customers as well to create it >> or handle it by him self. I think this questions can not be answered >> with yes or no, there is a lot of grey between. > > Why should someone without intent to connect to the Internet be "forced" > to publish an abuse contact? Is this the majority? Or are there any numbers on how many organizations do not have the intent to connect to the Internet? If this is the Majority this might be not the right idea. We could as well decide that the hole ip space has to be covered with abuse contact information. If the the direct allocations do not want to offer it they have to force their sub allocations to publish it. Whatever idea we will come up with, there will always be space for discussions. So please lets keep it pragmatic and not to being to scientific. >>>> - contains e-mail and abuse-mailbox attribute >>> >>> What would the difference be? >> >> e-mail attribute: personal correspondence between abuse departments. >> abuse-mailbox attribute: only automatic complaint handling. > > How would one qualify as an "abuse department", allowing for inter-abuse > communication? Also, "automatic complaint handling" might set the limits > for what to expect, but woul be need to defined in detail, including > formats and the like. I think we agreed further down this email that > splitting the contacts is the best avenue into confusion, so i'm not > convinced here. Okay lets rephrase it: e-mail attribute: human correspondence between members of abuse dep. abuse-mailbox: complaint mailbox We are not splitting the contacts here. We offer the opportunity to route communication into different channels. You do not want to receive all the complaints and personal and/or transactional mail in one mailbox. That does not work. That was one reason to create the abuse-mailbox attribute a few years ago. >>>> - query restriction on all attributes without abuse-mailbox attribute >>> >>> Could you clarify this? >> >> We could use query restrictions for all attributes, without the >> abuse-mailbox attribute as we have it already today. That way we could >> query unrestricted for example with the -b option. > > OK, that would be more of a "limited visibility" rather than ACL based or > volume based restrictions on queries. The experience with "-B" was > split, I guess, since although it was expected to be used by "professionals" > only, it kind of leaked. It appears to me that the real requirement is > to not confuse the target audience which in turn leads us to the tricky > question of who the target audiences are: > > 1) professional users with access to and understanding of teh DB documentation > 2) semi- or pseudo professionals who are easily confused and tend to act > as multipliers (e.g. by publishing tools) > 3) web centric end users > > The case (2) is hopeless. (3) is better addressed by a well designed, > web based user interface than by commandlinbe whois and (1) wouldn't need > this kind of restrictions to visibility. Absolutely right. Offering the -B option was just an example for people in group 1. "-B" is there it works and it could be reused to avoid to much code changes in the world of abuse reporting tools. Having a fancy webform as we already have with the abuse finder will hopefully help groups 2 and 3. Offering a REST API as already implemented will help people to change with the next release from "whois -B" to REST. At the end we will face the same problem as we do with all person or role objects. We do not want to allow bulk queries that just look out for email addresses that are used for human correspondence. If we restrict the the queries for the e-mail address attributes as we do for the hole object without the abuse-mailbox attribute. This came up on a discussion on this topic about abuse contact information on the mailinglist. I can not find where at the moment. Sorry. >> That way we could meet the requirements of the community not to publish >> email addresses for personal communication to widely. > > That'd be security by obscurity and, again, experience shows that this > kind of "secret" or "expert mode" switch will be well known rather soon. The expert mode switch is not existing here. There will be no switch. Everybody can access abuse-mailbox attributes without any restrictions. Everybody can access all other attributes with restrictions. No switch, no security by obscurity. Easy to understand for publishers and users. And we should not get into any trouble with EU legal things since we could define the abuse-mailbox attribute as a non personal role-account. >> everything as well. The only problem we are facing is a organization >> that has both in place. And my experience with such organizations is >> that they do not exactly know who is responsible for what, so how should >> we be able to decide this. > > We wouldn't. By offering two (or maybe more) options, we'd just enable > them to communicate the various contact points. But we _would_ have to > set the expectations an i have so far not seen a crisp definition that > would istinguish the two from the perspective of an end user. Right, because imho there is none. Abuse Department, Abuse Desk, Incident Response Team are all names for imho one and the same thing. But to be honest I think we could keep the IRT Object plus the new $object for a while and see how the IRT Object is doing. IMHO I think we will not see a drastic increase of users there. I think it would help to have Wilfrieds opinion on that, since he is very involved into IRT using organizations as far as I understood. I think abuse-c is from a historical view easier to understand because of admin-c, tech-c. Every domain owner has at least once heard these things. The other reason for the name abuse-c is just easy to not use th already "burned" name of IRT. When people hear about IRT, they have already feelings about it. Most of these feelings are at the end not really positive otherwise we would have much more than 211 IRT Objects. Thanks for the feedback. Tobias -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 267 bytes Desc: OpenPGP digital signature URL: From vesely at tana.it Mon May 9 20:06:17 2011 From: vesely at tana.it (Alessandro Vesely) Date: Mon, 09 May 2011 20:06:17 +0200 Subject: [acm-tf] Functionality In-Reply-To: <20110508155052.GC22691@x27.adm.denic.de> References: <4DC14F4B.4060905@abusix.com> <20110507203309.GC5823@x27.adm.denic.de> <4DC69FAA.6080101@abusix.com> <20110508155052.GC22691@x27.adm.denic.de> Message-ID: <4DC82D19.30803@tana.it> Hi all, On 08/May/11 17:50, Peter Koch wrote: > On Sun, May 08, 2011 at 03:50:34PM +0200, Tobias Knecht wrote: > >> I feel very comfotable about the name abuse-c, because everybody >> understands that "c" means contact as it does in admin-c and tech-c >> already. Publishers and Users. > > maybe, but we need to keep in mind that there are different types of > users. And there's also the subtle difference between "abuse" > and "anti-abuse", really. hm... "anti-abuse-c", "abuse-reports", "send-spam-complaints-here"? Somewhere we should say that end users are supposed to report abuse to their mailbox providers who, in turn, will lookup this addresses after any local processing. Please help me with terminology. Here I call "end users" the customers of a mailbox provider, and "users" the customers of a network provider, who may be mailbox providers in turn. Does that sound correct? >>>> - hierarchical design. >>> >>> Needs clarification: does it mean the querying mechanism should be >>> able to locate the closest covering reference for inetnum and >>> inet6num objects? >> >> That has to be discussed as well. > > So, could we start the discussion? There is a point here, whether it is the intention of the user to run an SMTP server, or other "push" protocol, using these IP addresses. RIPE is not interested in this information, but network providers should be. If users run SMTP * they should have an abuse-c, * the real name of the "owner" should be given in admin-c, and * they should be at a higher priority for getting IPv4 ranges. The IPv4 priority derives from the fact that DNSBLs don't work for IPv6. Some operators might decide to reject mail from IPv6 addresses until a safe filtering system is devised. We currently have SPF and DKIM to authenticate an IP address, but domain reputation is just dawning. Thus new operators without IPv4 addresses might be forced to outsource their mail service. If users do _not_ run SMTP * they should filter outbound port 25 connections, or * they should ask their network provider to filter that for them. Connections can be shut down by courts in response to abuse. In this respect, having an abuse-c offers an occasion to mitigate abuse and continue operations. A network provider may want to monitor the stream of abuse reports, possibly by replacing the abuse-report address with a monitor-and-forward mailbox. IMHO, a mailbox provider should come to know if one of its end users spams. Some mailbox providers can personally reach their end users. They should educate their end users. A complainant should turn to the upstream network provider --or to an authority-- only after collecting evidence that the appointed abuse-c doesn't sort any effect (e.g. persistent spam from the same stream, abuse notifications notwithstanding.) The idea of a hierarchy comes from considering that if neither the network provider can solve the issue, it can be considered to be a party to the spammer. Then a complainant may want to turn to an even upper provider, and so forth. >>>> - mandatory or not mandatory object If a user is not willing to cooperate, its network provider should be ordered to shut down the contract, in case of abuse. Not having an abuse-report address is going to qualify a user as an ignorant spammer, and this may lead to kick them off the net more quickly than if they had a syntactically correct but non-working abuse-c. >>>> - contains e-mail and abuse-mailbox attribute >>> >>> What would the difference be? >> >> e-mail attribute: personal correspondence between abuse departments. >> abuse-mailbox attribute: only automatic complaint handling. > > How would one qualify as an "abuse department", allowing for inter-abuse > communication? Also, "automatic complaint handling" might set the limits > for what to expect, but would be need to defined in detail, including > formats and the like. I think we agreed further down this email that > splitting the contacts is the best avenue into confusion, so i'm not > convinced here. Neither am I. IRT and tech-c already exist, and the team's web page may provide further contacts. I propose three more attributes for abuse-c, in addition to the email address and the abuse team's URL: 1. *Domain name* That would be the principal domain name. Semantically, there should be a list of domain names, in order to provide for virtual hosts, but I'm not sure whether it's possible, and doubt it'd be very useful. The purpose of the domain name is to provide a link to the reputation. While negative reputation is traditionally linked to IP addresses, positive reputation is better managed by looking at domain names. Providing a domain name here is more reliable than looking at the domain part of an email address in *-c entries, especially if the corresponding role is outsourced. For accuracy, the name listed here must have a primary MX in the DNS, that resolves to an IP address within this same inetnum. 2. *Country code* For legal concerns. I'm not sure whether it would always be the same as the inetnum's "country". 3. *Format* Unless we stick to RFC 5965, which AFAIK is the only IETF standard defined for this purpose, it is handy for a software tool to know how to format messages destined to a given abuse-c. jm2c From vesely at tana.it Tue May 17 14:31:54 2011 From: vesely at tana.it (Alessandro Vesely) Date: Tue, 17 May 2011 14:31:54 +0200 Subject: [acm-tf] Rationale for reporting abuse Message-ID: <4DD26ABA.9020100@tana.it> Hi all, the rationale of a policy proposal, according to the RIPE Policy Proposal Template, consists of two lists of arguments, pros and cons. For example, Tobias' 2010-08 lists some arguments, apparently assuming that everybody else knows what abuse is going to be reported to whom and why. Is such assumption correct? AFAIK, Thunderbird and Outlook don't have a "Report-as-Spam" button, yet. The abuse-report flow that our policy aims to support is not yet clearly established. So, I propose that we put together some text that describes the abuse-reporting perspective in general. It will be much more straightforward to analyze the requirements of abuse contact management on that basis. The text itself can later be incorporated into the draft document. Shall we do it? I'd love to see some +/-1s about this... From kranjbar at ripe.net Wed May 25 12:23:43 2011 From: kranjbar at ripe.net (Kaveh Ranjbar) Date: Wed, 25 May 2011 12:23:43 +0200 Subject: [acm-tf] Planning next meeting Message-ID: <4DDCD8AF.3080902@ripe.net> Hi, As it was decided in the last ACM-TF Meeting, the next task force meeting should be scheduled for the end of may or early june. http://doodle.com/78y7aqvcck9d9quw is the link for a doodle schedule poll, please select all the time slots that you will be available for joining the meeting, before the end of the week. Kind Regards, Kaveh. -- Kaveh Ranjbar Database Group Manager, RIPE NCC From tk at abusix.com Wed May 25 12:38:28 2011 From: tk at abusix.com (Tobias Knecht) Date: Wed, 25 May 2011 12:38:28 +0200 Subject: [acm-tf] Planning next meeting In-Reply-To: <4DDCD8AF.3080902@ripe.net> References: <4DDCD8AF.3080902@ripe.net> Message-ID: <4DDCDC24.9030308@abusix.com> Hello, > As it was decided in the last ACM-TF Meeting, the next task force > meeting should be scheduled for the end of may or early june. > > > http://doodle.com/78y7aqvcck9d9quw is the link for a doodle schedule > poll, please select all the time slots that you will be available for > joining the meeting, before the end of the week. I'll be at maawg in San Francisco between 3rd and 11th of June. If possible I would like to get Wednesday the 1st or the other days at 4 o'clock which is 7 o'clock am in the US. This is just for explanation. ;-) Thanks, Tobias -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 267 bytes Desc: OpenPGP digital signature URL: From pk at DENIC.DE Fri May 27 10:13:16 2011 From: pk at DENIC.DE (Peter Koch) Date: Fri, 27 May 2011 10:13:16 +0200 Subject: [acm-tf] Planning next meeting In-Reply-To: <4DDCD8AF.3080902@ripe.net> References: <4DDCD8AF.3080902@ripe.net> Message-ID: <20110527081316.GA4040@x27.adm.denic.de> On Wed, May 25, 2011 at 12:23:43PM +0200, Kaveh Ranjbar wrote: > http://doodle.com/78y7aqvcck9d9quw is the link for a doodle schedule > poll, please select all the time slots that you will be available for > joining the meeting, before the end of the week. I'll be available after WorldIPv6Day only, sorry. -Peter From kranjbar at ripe.net Mon May 30 10:37:57 2011 From: kranjbar at ripe.net (Kaveh Ranjbar) Date: Mon, 30 May 2011 10:37:57 +0200 Subject: [acm-tf] Planning next meeting Message-ID: <4DE35765.5030909@ripe.net> Hi, Thanks for participating in the planning effort, I had a short chat with Brian and we decided to include 6 more days to the poll in order to find a time-slot with more attendees available. So, please kindly edit your schedule -or participate if you haven't done so the first time- at http://doodle.com/78y7aqvcck9d9quw We will close the poll by the end of Wed. 1st of June. Kind Regards, Kaveh. -- Kaveh Ranjbar Database Group Manager, RIPE NCC