Return-Path: Received: from murder ([unix socket]) by eikenes.alvestrand.no (Cyrus v2.2.8-Mandrake-RPM-2.2.8-4.2.101mdk) with LMTPA; Thu, 21 Jul 2005 16:49:11 +0200 X-Sieve: CMU Sieve 2.2 Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A88B661B89 for ; Thu, 21 Jul 2005 16:49:11 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04422-01 for ; Thu, 21 Jul 2005 16:49:08 +0200 (CEST) X-Greylist: domain auto-whitelisted by SQLgrey-1.4.8 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3499F61B43 for ; Thu, 21 Jul 2005 16:49:01 +0200 (CEST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvcKV-0003ie-H1; Thu, 21 Jul 2005 10:47:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvcKR-0003hm-OE for ietf@megatron.ietf.org; Thu, 21 Jul 2005 10:47:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06934 for ; Thu, 21 Jul 2005 10:47:13 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvcoU-0004mu-KX for ietf@ietf.org; Thu, 21 Jul 2005 11:18:18 -0400 Received: from i03m-212-195-148-209.d4.club-internet.fr ([212.195.148.209] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DvcKH-0006PD-Cx; Thu, 21 Jul 2005 07:47:05 -0700 Message-Id: <6.2.1.2.2.20050721163115.036df3d0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 21 Jul 2005 16:40:30 +0200 To: "Hallam-Baker, Phillip" , "Stephen Kent" From: "JFC (Jefsey) Morfin" In-Reply-To: <198A730C2044DE4A96749D13E167AD37250431@MOU1WNEXMB04.vcorp. ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD37250431@MOU1WNEXMB04.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: Keith Moore , John Kristoff , ietf@ietf.org Subject: Re: Accountability X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-bounces@ietf.org Errors-To: ietf-bounces@ietf.org X-Virus-Scanned: amavisd-new at alvestrand.no At 16:01 21/07/2005, Hallam-Baker, Phillip wrote: > > >So in the question of ingress filtering what I am looking at is > > >mechanisms to create accountability. > > > > Just beware that accountability in an interdependence system > > can only based > > on the threat of retaliation. What means that you must be a > > little be more > > equal than you peers for it to succeed. > >That is not true. Accountability must have consequences but >'retaliation' is a specific type of consequence that is generally >considered to be best applied as a last resort. Sure, but in relations what count is the "ultima ratio". Graduation is only politeness. > > Beware that whatever the accountability, when you are dead, > > you are dead. > > Your heirs can revenge you, but you failed your target. > >Accountability is used in the security field in a very specific fashion >and with specific applications. > >Clearly you want to apply traditional access control approach to running >a nuclear power station. But very few of the problems we are now >concerned with fall into that category. This is to be expected, the >problems for which access control is appropriate are essentially solved. > >The problems we have today are of the form where an individual violation >is not that much of a concern but the aggregate violations are very much >a concern. Spam is a prime example, one spam is a nuisance, a thousand a >day makes email unusable. > >The other characteristic of the problems we are now facing is that the >set of access criteria is not well defined. The question of what is spam >is clear to the reader but very hard to define in machine readable >terms. > >We thus have two basic tools; fuzzy logic type approaches to access >control and accountability type schemes. Both are useful but in the long >term the way to make the system stable is by establishing the right >accountability mechanisms. This is basic. I am not discussing that, but motivation and quality of the expected deliveries. By nature there is a threshold where you cannot accept the lacks of your partner. Whatever the threshold. Here is the problem. If you relate with only one partner (ally) your security depends on its priorities. If you relate with the intergovernance of your allies, his security will depend on your allies. So there will be possibilities for other solutions. So, what you name accountability mechanism is a part of what I name intergovernance, where retaliation threat is not even considered anymore, because it is impossible to leave security degrade. Difference between an alliance and a coalition. jfc _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf