From jtk@cymru.com Wed Feb 3 20:40:29 2010 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFBDF28C0FD for ; Wed, 3 Feb 2010 20:40:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8g3IIcXvd4F9 for ; Wed, 3 Feb 2010 20:40:28 -0800 (PST) Received: from obelisk11.ord01.cymru.com (obelisk11.ord01.cymru.com [38.229.66.8]) by core3.amsl.com (Postfix) with ESMTP id 7F1333A67AD for ; Wed, 3 Feb 2010 20:40:28 -0800 (PST) Received: from t61p (vpn-21-32.svcs.iad01.cymru.com [192.168.21.32]) by obelisk11.ord01.cymru.com (Postfix) with ESMTP id CAA7CB00DE for ; Thu, 4 Feb 2010 04:41:12 +0000 (GMT) Date: Wed, 3 Feb 2010 22:41:13 -0600 From: John Kristoff To: opsec@ietf.org Message-ID: <20100203224113.2a79333f@t61p> In-Reply-To: <4B42CE9B.8070505@bogus.com> References: <4B42CE9B.8070505@bogus.com> X-Mailer: Claws Mail Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [OPSEC] noted: draft-dugal-opsec-protect-control-plane-00 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 04:40:29 -0000 On Mon, 04 Jan 2010 21:31:07 -0800 Joel Jaeggli wrote: > I notes with interest today the initial publication of: > > http://tools.ietf.org/html/draft-dugal-opsec-protect-control-plane-00 > > for which I am certain review and feedback would be greatly > appreciated. I realize there is a -01 version of this draft. Nonetheless, this comment still applies. One of the major stumbling blocks in managing control plane filtering in my experience has been when a platform lacks sufficient diagnostic capability such as control plane filter logging. Perhaps some mention of this in the Design Trade-offs section might include some text highlighting this concern. Rate limiting can be particularly troublesome when "bad" traffic starves the "good". John From christopher.morrow@gmail.com Thu Feb 4 19:23:44 2010 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 989923A6A97 for ; Thu, 4 Feb 2010 19:23:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4omKuJPzcAY for ; Thu, 4 Feb 2010 19:23:43 -0800 (PST) Received: from mail-iw0-f184.google.com (mail-iw0-f184.google.com [209.85.223.184]) by core3.amsl.com (Postfix) with ESMTP id ADA8B3A6A7F for ; Thu, 4 Feb 2010 19:23:43 -0800 (PST) Received: by iwn14 with SMTP id 14so3643138iwn.17 for ; Thu, 04 Feb 2010 19:24:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=g3INlsJU2XWbMf6PWtx87P2/6cCnnG8Jct3l/gO0CNw=; b=SP21yj5aemc72jzw/Jb7fLsPdekMhm6i5thaq0lXAOb9JXrSJsrwmxWZBtqNjgQZu5 GM/FmYJk4GNUBH+zEHsIQVzUe0k8EGlWdEY62jY422dllA+iTv/xJj6V/sgJJAhnsTt1 VJEgaeHJKzFkmaH5JyEokTAcizA3Cz/zikxdQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=ac1rwZsJPwjR+02+QnvDYeXkrK+SrpVaCeCTJj9DI31n/ecjE2DGXyLoNJYoYmJ9uL BxMK7SDQLR34aHQUpHWwppmCjQ1/KCM8/QE5sliINAD64Vtfkb1wESCcglYbza+lcchT CMNTNEyb3NqV4X3PkegxRmZoyGOm4kcn5I5hk= MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.231.162.9 with SMTP id t9mr615387ibx.5.1265340264560; Thu, 04 Feb 2010 19:24:24 -0800 (PST) In-Reply-To: <20100203224113.2a79333f@t61p> References: <4B42CE9B.8070505@bogus.com> <20100203224113.2a79333f@t61p> Date: Thu, 4 Feb 2010 22:24:24 -0500 X-Google-Sender-Auth: 652897d35cfe57e8 Message-ID: <75cb24521002041924g5cab7594xff7a12e995768831@mail.gmail.com> From: Christopher Morrow To: John Kristoff Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: opsec@ietf.org Subject: Re: [OPSEC] noted: draft-dugal-opsec-protect-control-plane-00 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 03:23:44 -0000 On Wed, Feb 3, 2010 at 11:41 PM, John Kristoff wrote: > On Mon, 04 Jan 2010 21:31:07 -0800 > Joel Jaeggli wrote: > >> I notes with interest today the initial publication of: >> >> http://tools.ietf.org/html/draft-dugal-opsec-protect-control-plane-00 >> >> for which I am certain review and feedback would be greatly >> appreciated. > > I realize there is a -01 version of this draft. =A0Nonetheless, this > comment still applies. > > One of the major stumbling blocks in managing control plane filtering > in my experience has been when a platform lacks sufficient diagnostic yes, if you can block/limit it, you MUST be able to log that fact, and count that fact. Otherwise it because exceptionally difficult to get a tcpdump on that sonet link to your neighbor... > capability such as control plane filter logging. =A0Perhaps some mention > of this in the Design Trade-offs section might include some text > highlighting this concern. =A0Rate limiting can be particularly > troublesome when "bad" traffic starves the "good". it might be nice to have special macros for 'bgp neighbors' or 'local interfaces' or 'connected networks'. to make configuration management easier... of course those could be called 'implementation details' but :) now I'll go read the doc, and hopefully provide some comments. -Chris > > John > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > From rodunn@cisco.com Fri Feb 5 17:30:30 2010 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 496FA3A69B0 for ; Fri, 5 Feb 2010 17:30:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22Z2H2w6WrzF for ; Fri, 5 Feb 2010 17:30:29 -0800 (PST) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id 4B40D3A696F for ; Fri, 5 Feb 2010 17:30:29 -0800 (PST) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o161VIcR023358; Fri, 5 Feb 2010 20:31:18 -0500 (EST) Received: from rtp-rodunn-8713.cisco.com (rtp-rodunn-8713.cisco.com [10.116.190.132]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o161VHCe014675; Fri, 5 Feb 2010 20:31:17 -0500 (EST) Message-ID: <4B6CC665.7070909@cisco.com> Date: Fri, 05 Feb 2010 20:31:17 -0500 From: Rodney Dunn Organization: Cisco Systems Inc. User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Christopher Morrow References: <4B42CE9B.8070505@bogus.com> <20100203224113.2a79333f@t61p> <75cb24521002041924g5cab7594xff7a12e995768831@mail.gmail.com> In-Reply-To: <75cb24521002041924g5cab7594xff7a12e995768831@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: opsec@ietf.org Subject: Re: [OPSEC] noted: draft-dugal-opsec-protect-control-plane-00 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: rodunn@cisco.com List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Feb 2010 01:30:30 -0000 Thanks a lot for the feedback. We'll go back and see if/where/how we can work something around that in. It is a valid point for sure. On a side note...what if there were netflow on the control plane per class with drop codes in the export data? ;) On 2/4/10 10:24 PM, Christopher Morrow wrote: > On Wed, Feb 3, 2010 at 11:41 PM, John Kristoff wrote: >> On Mon, 04 Jan 2010 21:31:07 -0800 >> Joel Jaeggli wrote: >> >>> I notes with interest today the initial publication of: >>> >>> http://tools.ietf.org/html/draft-dugal-opsec-protect-control-plane-00 >>> >>> for which I am certain review and feedback would be greatly >>> appreciated. >> >> I realize there is a -01 version of this draft. Nonetheless, this >> comment still applies. >> >> One of the major stumbling blocks in managing control plane filtering >> in my experience has been when a platform lacks sufficient diagnostic > > yes, if you can block/limit it, you MUST be able to log that fact, and > count that fact. Otherwise it because exceptionally difficult to get a > tcpdump on that sonet link to your neighbor... > >> capability such as control plane filter logging. Perhaps some mention >> of this in the Design Trade-offs section might include some text >> highlighting this concern. Rate limiting can be particularly >> troublesome when "bad" traffic starves the "good". > > it might be nice to have special macros for 'bgp neighbors' or 'local > interfaces' or 'connected networks'. to make configuration management > easier... of course those could be called 'implementation details' but > :) > > now I'll go read the doc, and hopefully provide some comments. > > -Chris > >> >> John >> >> _______________________________________________ >> OPSEC mailing list >> OPSEC@ietf.org >> https://www.ietf.org/mailman/listinfo/opsec >> > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec From christopher.morrow@gmail.com Fri Feb 5 17:41:26 2010 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 957293A6FCC for ; Fri, 5 Feb 2010 17:41:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2uf35aA0z0F for ; Fri, 5 Feb 2010 17:41:25 -0800 (PST) Received: from mail-iw0-f180.google.com (mail-iw0-f180.google.com [209.85.223.180]) by core3.amsl.com (Postfix) with ESMTP id 98EC43A6FCB for ; Fri, 5 Feb 2010 17:41:25 -0800 (PST) Received: by iwn10 with SMTP id 10so4816294iwn.22 for ; Fri, 05 Feb 2010 17:42:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=PDCuvJkb7hrAk7PG4nH4z+mxkpPIP5FDiE1B7J0oWPQ=; b=oD2IfMldZrmh4QC2xwxUvsL7aI0IEC86MQkZ8Bem143ojd3Fn0U8xZlvWBQYzIMwyu nHqShSdBOdcAYCurjoEb723y9ECSsYhN/aNG3OSARUlVQubX0mahaEwts0RRzq6M4PRx P3KoYOSu59cDSFxDBa3AJ47JUd4ODrbpDg3Qo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=NV2lziqWQqizsRd0vb57kDMEAsrFPAiJT8lOpssHExPPGXFsrsLtyf9aWvkdPZIm92 WqvSREysuVhWxB47qP3RRDzXD9pGj/GW0sVJj7NEsLvTuEhneNhQUe6DfpVywWByr12I F5ocmJ0tWe4f+b2FaFe4oe8fIua06WdPzEwe4= MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.231.160.149 with SMTP id n21mr614103ibx.93.1265420535217; Fri, 05 Feb 2010 17:42:15 -0800 (PST) In-Reply-To: <4B6CC665.7070909@cisco.com> References: <4B42CE9B.8070505@bogus.com> <20100203224113.2a79333f@t61p> <75cb24521002041924g5cab7594xff7a12e995768831@mail.gmail.com> <4B6CC665.7070909@cisco.com> Date: Fri, 5 Feb 2010 20:42:15 -0500 X-Google-Sender-Auth: 3432336ebb7946a2 Message-ID: <75cb24521002051742n75442ebas365882f7d7bd9bbc@mail.gmail.com> From: Christopher Morrow To: rodunn@cisco.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: opsec@ietf.org Subject: Re: [OPSEC] noted: draft-dugal-opsec-protect-control-plane-00 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Feb 2010 01:41:26 -0000 On Fri, Feb 5, 2010 at 8:31 PM, Rodney Dunn wrote: > Thanks a lot for the feedback. We'll go back and see if/where/how we can > work something around that in. > > It is a valid point for sure. > > On a side note...what if there were netflow on the control plane per clas= s > with drop codes in the export data? ;) > sure, seems like netflow would be more heavyweight than the just logging... and I think I'd rather have logs (less sampling I'd hope?) -chris > > On 2/4/10 10:24 PM, Christopher Morrow wrote: >> >> On Wed, Feb 3, 2010 at 11:41 PM, John Kristoff =A0wrote: >>> >>> On Mon, 04 Jan 2010 21:31:07 -0800 >>> Joel Jaeggli =A0wrote: >>> >>>> I notes with interest today the initial publication of: >>>> >>>> http://tools.ietf.org/html/draft-dugal-opsec-protect-control-plane-00 >>>> >>>> for which I am certain review and feedback would be greatly >>>> appreciated. >>> >>> I realize there is a -01 version of this draft. =A0Nonetheless, this >>> comment still applies. >>> >>> One of the major stumbling blocks in managing control plane filtering >>> in my experience has been when a platform lacks sufficient diagnostic >> >> yes, if you can block/limit it, you MUST be able to log that fact, and >> count that fact. Otherwise it because exceptionally difficult to get a >> tcpdump on that sonet link to your neighbor... >> >>> capability such as control plane filter logging. =A0Perhaps some mentio= n >>> of this in the Design Trade-offs section might include some text >>> highlighting this concern. =A0Rate limiting can be particularly >>> troublesome when "bad" traffic starves the "good". >> >> it might be nice to have special macros for 'bgp neighbors' or =A0'local >> interfaces' or 'connected networks'. to make configuration management >> easier... of course those could be called 'implementation details' but >> :) >> >> now I'll go read the doc, and hopefully provide some comments. >> >> -Chris >> >>> >>> John >>> >>> _______________________________________________ >>> OPSEC mailing list >>> OPSEC@ietf.org >>> https://www.ietf.org/mailman/listinfo/opsec >>> >> _______________________________________________ >> OPSEC mailing list >> OPSEC@ietf.org >> https://www.ietf.org/mailman/listinfo/opsec > From jtk@cymru.com Fri Feb 5 20:21:54 2010 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06D863A6831 for ; Fri, 5 Feb 2010 20:21:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7ZTp7tGW99Z for ; Fri, 5 Feb 2010 20:21:53 -0800 (PST) Received: from obelisk11.ord01.cymru.com (obelisk11.ord01.cymru.com [38.229.66.8]) by core3.amsl.com (Postfix) with ESMTP id DEEA93A6767 for ; Fri, 5 Feb 2010 20:21:52 -0800 (PST) Received: from t61p (vpn-21-37.svcs.iad01.cymru.com [192.168.21.37]) by obelisk11.ord01.cymru.com (Postfix) with ESMTP id 33229B00BA; Sat, 6 Feb 2010 04:22:44 +0000 (GMT) Date: Fri, 5 Feb 2010 22:22:47 -0600 From: John Kristoff To: rodunn@cisco.com Message-ID: <20100205222247.633c41a8@t61p> In-Reply-To: <4B6CC665.7070909@cisco.com> References: <4B42CE9B.8070505@bogus.com> <20100203224113.2a79333f@t61p> <75cb24521002041924g5cab7594xff7a12e995768831@mail.gmail.com> <4B6CC665.7070909@cisco.com> X-Mailer: Claws Mail Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: opsec@ietf.org Subject: Re: [OPSEC] noted: draft-dugal-opsec-protect-control-plane-00 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Feb 2010 04:21:54 -0000 On Fri, 05 Feb 2010 20:31:17 -0500 Rodney Dunn wrote: > On a side note...what if there were netflow on the control plane per > class with drop codes in the export data? ;) That would be useful not only for the control plane of course. However, I concur with Chris. Logging would be preferable in my experience when you're in a diagnostic situation. John From joelja@bogus.com Sat Feb 6 11:49:48 2010 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 830583A693E for ; Sat, 6 Feb 2010 11:49:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IrV89QzBi5b for ; Sat, 6 Feb 2010 11:49:47 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [147.28.0.81]) by core3.amsl.com (Postfix) with ESMTP id AF5D73A68E8 for ; Sat, 6 Feb 2010 11:49:47 -0800 (PST) Received: from [192.168.2.101] (m040e36d0.tmodns.net [208.54.14.4]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id o16JnwYk001224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 6 Feb 2010 19:50:42 GMT (envelope-from joelja@bogus.com) Message-ID: <4B6DC3E1.4060806@bogus.com> Date: Sat, 06 Feb 2010 11:32:49 -0800 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "'opsec@ietf.org'" X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Sat, 06 Feb 2010 19:50:43 +0000 (UTC) Subject: [OPSEC] IETF 77 timeline, X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Feb 2010 19:49:48 -0000 FYI, I have requested a meeting slot for Anaheim, even if your are not planning on attending please let me know if you have agenda items for consideration in the opsec meeting, also if have interest in presenting or participating remotely please let me know so that I can request the use of one of the Webex enabled rooms (in addition to the streaming) to facilitate this activity. Remaining Milestone Date for the meeting are below: 2010-02-08 (Monday): Cutoff date for requests to schedule Working Group meetings at 17:00 PST (01:00 Tuesday, February 9 UTC). To request a Working Group session, use the IETF Meeting Session Request Tool. 2010-02-17 (Wednesday): Preliminary agenda published for comment. 2010-02-22 (Monday): Cutoff date for requests to reschedule Working Group and BOF meetings 17:00 PST (01:00 Tuesday, February 23 UTC). 2010-02-22 (Monday): Working Group Chair approval for initial document (Version -00) submissions appreciated by 17:00 PST (01:00 Tuesday, February 23 UTC). 2010-02-26 (Friday): Final agenda to be published. 2010-03-01 (Monday): Internet Draft Cut-off for initial document (-00) submission by 17:00 PST (01:00 Tuesday, March 2 UTC), upload using IETF ID Submission Tool. 2010-03-08 (Monday): Internet Draft final submission cut-off by 17:00 PST (01:00 Tuesday, March 9 UTC), upload using IETF ID Submission Tool. 2010-03-10 (Wednesday): Draft Working Group agendas due by 17:00 PST (01:00 Thursday, March 11 UTC), upload using IETF Meeting Materials Management Tool. 2010-03-12 (Friday): Early Bird registration and payment cut-off at 17:00 PST (01:00 Saturday, March 13 UTC). 2010-03-15 (Monday): Revised Working Group agendas due by 17:00 PDT (24:00 UTC), upload using IETF Meeting Materials Management Tool. 2010-03-15 (Monday): Registration cancellation cut-off at 17:00 PDT (24:00 UTC). 2010-03-19 (Friday): Final Pre-Registration and Pre-Payment cut-off at 17:00 PDT (24:00 UTC). 2010-03-21 - 2010-03-26: 77th IETF Meeting in Anaheim, California, USA. From Donald.Smith@qwest.com Mon Feb 8 08:32:45 2010 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8961E28C149 for ; Mon, 8 Feb 2010 08:32:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRDajGlGVnb2 for ; Mon, 8 Feb 2010 08:32:44 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by core3.amsl.com (Postfix) with ESMTP id 5D84428C147 for ; Mon, 8 Feb 2010 08:32:42 -0800 (PST) Received: from sudnp796.qintra.com (sudnp796.qintra.com [151.116.2.212]) by suomp64i.qwest.com (8.14.0/8.14.0) with ESMTP id o18GXgns008855; Mon, 8 Feb 2010 10:33:43 -0600 (CST) Received: from qtdenexhtm21.AD.QINTRA.COM (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.0/8.14.0) with ESMTP id o18GXRCE003353; Mon, 8 Feb 2010 09:33:37 -0700 (MST) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm21.AD.QINTRA.COM ([151.119.91.230]) with mapi; Mon, 8 Feb 2010 09:33:32 -0700 From: "Smith, Donald" To: Christopher Morrow , "rodunn@cisco.com" Content-Class: urn:content-classes:message Date: Mon, 8 Feb 2010 09:33:26 -0700 Thread-Topic: [OPSEC] noted: draft-dugal-opsec-protect-control-plane-00 Thread-Index: AcqmzaCQZaBizM+ZRgSFHe6dGlNU9gCDSbrWAABqNPE= Message-ID: <619972AE-EB58-4A0B-85B6-3F712F2AEEE5@mimectl> References: <4B42CE9B.8070505@bogus.com> <20100203224113.2a79333f@t61p> <75cb24521002041924g5cab7594xff7a12e995768831@mail.gmail.com> <4B6CC665.7070909@cisco.com>, <75cb24521002051742n75442ebas365882f7d7bd9bbc@mail.gmail.com> In-Reply-To: <75cb24521002051742n75442ebas365882f7d7bd9bbc@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-mimectl: Produced By Microsoft Exchange V8.1.348.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "opsec@ietf.org" Subject: Re: [OPSEC] noted: draft-dugal-opsec-protect-control-plane-00 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 16:32:45 -0000 I think a counter per rule is the minimum. An snmp trap with the FIRST hit in X minutes with X being defined via confi= guration would be helpful in that we could notify the NOC of the issue, get= them looking at it and could set levels. If an not snmp trap, some way to get the counters exported (netflow, syslog= , something) would be helpful. Then if a counter is getting hit it would be nice to be able to "request" a= dditional information something like netflow v5 fields is probably good eno= ugh. Log vs count with options for different reporting methods. (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com ________________________________ From: opsec-bounces@ietf.org [opsec-bounces@ietf.org] On Behalf Of Christop= her Morrow [morrowc.lists@gmail.com] Sent: Friday, February 05, 2010 6:42 PM To: rodunn@cisco.com Cc: opsec@ietf.org Subject: Re: [OPSEC] noted: draft-dugal-opsec-protect-control-plane-00 On Fri, Feb 5, 2010 at 8:31 PM, Rodney Dunn wrote: > Thanks a lot for the feedback. We'll go back and see if/where/how we can > work something around that in. > > It is a valid point for sure. > > On a side note...what if there were netflow on the control plane per clas= s > with drop codes in the export data? ;) > sure, seems like netflow would be more heavyweight than the just logging... and I think I'd rather have logs (less sampling I'd hope?) -chris > > On 2/4/10 10:24 PM, Christopher Morrow wrote: >> >> On Wed, Feb 3, 2010 at 11:41 PM, John Kristoff wrote: >>> >>> On Mon, 04 Jan 2010 21:31:07 -0800 >>> Joel Jaeggli wrote: >>> >>>> I notes with interest today the initial publication of: >>>> >>>> http://tools.ietf.org/html/draft-dugal-opsec-protect-control-plane-00 >>>> >>>> for which I am certain review and feedback would be greatly >>>> appreciated. >>> >>> I realize there is a -01 version of this draft. Nonetheless, this >>> comment still applies. >>> >>> One of the major stumbling blocks in managing control plane filtering >>> in my experience has been when a platform lacks sufficient diagnostic >> >> yes, if you can block/limit it, you MUST be able to log that fact, and >> count that fact. Otherwise it because exceptionally difficult to get a >> tcpdump on that sonet link to your neighbor... >> >>> capability such as control plane filter logging. Perhaps some mention >>> of this in the Design Trade-offs section might include some text >>> highlighting this concern. Rate limiting can be particularly >>> troublesome when "bad" traffic starves the "good". >> >> it might be nice to have special macros for 'bgp neighbors' or 'local >> interfaces' or 'connected networks'. to make configuration management >> easier... of course those could be called 'implementation details' but >> :) >> >> now I'll go read the doc, and hopefully provide some comments. >> >> -Chris >> >>> >>> John >>> >>> _______________________________________________ >>> OPSEC mailing list >>> OPSEC@ietf.org >>> https://www.ietf.org/mailman/listinfo/opsec >>> >> _______________________________________________ >> OPSEC mailing list >> OPSEC@ietf.org >> https://www.ietf.org/mailman/listinfo/opsec > _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec ________________________________ This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From danny@tcb.net Thu Feb 11 15:05:27 2010 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BA0B3A75BC for ; Thu, 11 Feb 2010 15:05:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWx4-773eC2g for ; Thu, 11 Feb 2010 15:05:26 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 6BDAF3A749C for ; Thu, 11 Feb 2010 15:05:26 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id 87B3C3680A7; Thu, 11 Feb 2010 16:06:42 -0700 (MST) Received: from [192.168.1.64] (97-118-239-19.hlrn.qwest.net [97.118.239.19]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for opsec@ietf.org; Thu, 11 Feb 2010 16:06:42 -0700 (MST) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=97.118.239.19; client-port=56337; syn-fingerprint=65535:56:1:64:M1408,N,W1,N,N,T,S; data-bytes=0 From: Danny McPherson Content-Type: multipart/alternative; boundary=Apple-Mail-335--140406913 Date: Thu, 11 Feb 2010 16:06:41 -0700 References: To: opsec wg mailing list Message-Id: Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [OPSEC] Fwd: Last Call for Comments: draft-oreirdan-mody-bot-remediation-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 23:05:27 -0000 --Apple-Mail-335--140406913 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 If you've not seen it.. -danny Begin forwarded message: > From: Jason Livingood > Date: February 11, 2010 12:50:20 PM MST > To: "ietf@ietf.org" > Subject: Last Call for Comments: = draft-oreirdan-mody-bot-remediation-06 >=20 > A few months ago, I asked for comments on an individual draft = regarding the remediation of malicious bots on ISP networks. I and my = co-authors have incorporated all feedback received into the latest = revision of this draft at = http://tools.ietf.org/html/draft-oreirdan-mody-bot-remediation-06. I=92d = like to call one last time for any comments people may have regarding = this draft, before we close the book on it. >=20 > If you have any comments, please send them to me privately for = consideration. >=20 > Thank you, > Jason >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf --Apple-Mail-335--140406913 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
From: Jason Livingood <jason_livingood@cable.co= mcast.com>
Date: February 11, 2010 12:50:20 PM = MST
Subject: Last Call for = Comments: = draft-oreirdan-mody-bot-remediation-06

A few months ago, I asked for comments on an = individual draft regarding the remediation of malicious bots on ISP = networks.  I and my co-authors have incorporated all feedback = received into the latest revision of this draft at http://tools.ietf.org/html/draft-oreirdan-mody-bot-remediation-06. =  I=92d like to call one last time for any comments people may have = regarding this draft, before we close the book on it.

If you have any comments, please send them to me privately for = consideration.

Thank you,
Jason
_______________________________________________
Ietf mailing = list
Ietf@ietf.org
https://www.ietf.org/ma= ilman/listinfo/ietf

= --Apple-Mail-335--140406913-- From joelja@bogus.com Sun Feb 14 14:44:59 2010 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7723F28C12B for ; Sun, 14 Feb 2010 14:44:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HH5x+bnF3hY for ; Sun, 14 Feb 2010 14:44:58 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [147.28.0.81]) by core3.amsl.com (Postfix) with ESMTP id 7703728C122 for ; Sun, 14 Feb 2010 14:44:58 -0800 (PST) Received: from [192.168.1.151] (c-98-234-104-156.hsd1.ca.comcast.net [98.234.104.156]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id o1EMkJHY049324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 14 Feb 2010 22:46:21 GMT (envelope-from joelja@bogus.com) Message-ID: <4B787D3A.70905@bogus.com> Date: Sun, 14 Feb 2010 14:46:18 -0800 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Danny McPherson References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Sun, 14 Feb 2010 22:46:24 +0000 (UTC) Cc: nirmal_mody@Cable.Comcast.com, opsec wg mailing list , jason_livingood@Cable.Comcast.com, Mike O'Reirdan Subject: Re: [OPSEC] Fwd: Last Call for Comments: draft-oreirdan-mody-bot-remediation-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2010 22:44:59 -0000 just some comments that came to mind. Section 2.3 I find the term computer somewhat ambiguous in this context, though I understand the meaning that the author intended. The ietf has a long history with the term's host and router and I think we should generally prefer those terms even when they apply to the same device. section 5 bullet a The other problem with ports scan is simply that in the case of nated devices or stateful firewalls, either host or network based impose a barrier to the utility of vulnerability/nac methods based on open ports To the extent systems are running unauthorized listening services as a product of bot infection, that's a detection of the hosts currently infected state rather than it's vulnerability to attack. fingerprint of applications is necessarily more complex that simply port scanning and in particular home gateways with upnp service may result multiple systems being jumbled together in a port scan. section 6 "This record should only be maintained for a period of time which is necessary, in order to maintain the protection of the privacy of an individual subscriber." as noted in some other sections there my be statutory requirements that apply to the consideration of how long such data is retained or not as the case may be. section 8 bullet 2 these urls while provided for the purpose of examples are unlikely to be stable on any kind of long timescale. fundamently updating os software addresses vulnerability not remediation (windows malcious software removal tool notwithstanding) bullets 4-7 It's unclear how these steps are even feasible to undertake for organizations nominally characterized as ISPs. there's a several thousand fold cost differential between automated help and remediation by sending a train proessional to lay hands on one computer. Danny McPherson wrote: > > If you've not seen it.. > > -danny > > Begin forwarded message: > >> *From: *Jason Livingood > > *Date: *February 11, >> 2010 12:50:20 PM MST *To: *"ietf@ietf.org " >> > *Subject: **Last Call for >> Comments: draft-oreirdan-mody-bot-remediation-06* >> >> A few months ago, I asked for comments on an individual draft >> regarding the remediation of malicious bots on ISP networks. I and >> my co-authors have incorporated all feedback received into the >> latest revision of this draft at >> http://tools.ietf.org/html/draft-oreirdan-mody-bot-remediation-06. >> I’d like to call one last time for any comments people may have >> regarding this draft, before we close the book on it. >> >> If you have any comments, please send them to me privately for >> consideration. >> >> Thank you, Jason >> >> _______________________________________________ Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf > > > ------------------------------------------------------------------------ > > > _______________________________________________ OPSEC mailing list > OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From glen.kent@gmail.com Sun Feb 14 19:44:10 2010 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8808128C0F7 for ; Sun, 14 Feb 2010 19:44:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cw-VDMnLzyFa for ; Sun, 14 Feb 2010 19:44:09 -0800 (PST) Received: from mail-yw0-f173.google.com (mail-yw0-f173.google.com [209.85.211.173]) by core3.amsl.com (Postfix) with ESMTP id AD12828C0DE for ; Sun, 14 Feb 2010 19:44:09 -0800 (PST) Received: by ywh3 with SMTP id 3so4008479ywh.22 for ; Sun, 14 Feb 2010 19:45:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=KTZWYd4qsPbQvUL9PavB2aV6NfwLqeR2q+RKBi9Fw0s=; b=KkOQGgSf+IF8h2tDGUhEh6oXnxHi/T3MOsazXX7neTd7RVywkTe6sN5rlFd8afQAim X4OlfhIF6HnTYTLEC7zNyXLz00rmCKXluGef9RAnQg1L92vQRcH/wYkV7ykVrfIDVSfx 82nobjnl9F7kEmMCXy/P15ZrmzYLmB5iQLlno= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=YBPIxRag07RrOvzEjf0VfU25uM/NwBg68djDFcOC0Pc4VwtV8zvgjDLe9rnRTPzCQo BS2HEuVjQgL2qYVl9r5hLbwTIqUp7EQbacMzmHIh13uFv21SYgxX0cdokxAUbOZEfyhO AzS7cWzIaClz6AJ9ZjcxOryMBya0D4jDqe6k0= MIME-Version: 1.0 Received: by 10.150.175.17 with SMTP id x17mr5834057ybe.239.1266205535606; Sun, 14 Feb 2010 19:45:35 -0800 (PST) In-Reply-To: <4B4BF40E.4050606@bogus.com> References: <4B29DEE9.1090202@bogus.com> <4B42CFCC.3030501@bogus.com> <4B4BF40E.4050606@bogus.com> Date: Mon, 15 Feb 2010 09:15:35 +0530 Message-ID: <92c950311002141945q47aa1c5ch91391e13138619b3@mail.gmail.com> From: Glen Kent To: joel jaeggli Content-Type: text/plain; charset=ISO-8859-1 Cc: "opsec@ietf.org" Subject: Re: [OPSEC] (deadline for last call is 1/7/10) Working Group last call for draft-ietf-opsec-routing-protocols-crypto-issues-02 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 03:44:10 -0000 Any update on this draft, has it been submitted to the IESG? I see that the -03 version was posted long time back which takes care of my comments. Glen On Tue, Jan 12, 2010 at 9:31 AM, joel jaeggli wrote: > The comment period on this draft has closed... > > glens comments have been noted and will be incorporated prior to > submission to the iesg. > > a notice will be posted when the updated draft is ready. > > joel > > Joel Jaeggli wrote: >> Just as a reminder there remain three days to submitt comments before >> the last call window closes. >> >> Thanks >> joel >> >> Joel Jaeggli wrote: >>> This is the working group Last call for >>> draft-ietf-opsec-routing-protocols-crypto-issues-02 >>> >>> Please review the current draft: >>> >>> http://tools.ietf.org/html/draft-ietf-opsec-routing-protocols-crypto-issues-02 >>> >>> Deadline for Comments is 0000 UTC, Thurs Jan 7th 2010. the extended >>> period is to account for the compound set of holidays occuring in a >>> number of locations within the immediate two week period. >>> >>> As per the minutes the thinking is that this draft will be aimed at >>> informational status. >>> >>> thanks >>> joel >>> _______________________________________________ >>> OPSEC mailing list >>> OPSEC@ietf.org >>> https://www.ietf.org/mailman/listinfo/opsec >>> >> _______________________________________________ >> OPSEC mailing list >> OPSEC@ietf.org >> https://www.ietf.org/mailman/listinfo/opsec >> > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > From Donald.Smith@qwest.com Mon Feb 15 10:15:45 2010 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72B0128C25C for ; Mon, 15 Feb 2010 10:15:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.002 X-Spam-Level: X-Spam-Status: No, score=-1.002 tagged_above=-999 required=5 tests=[AWL=-1.597, BAYES_20=-0.74, HTTP_ESCAPED_HOST=0.134, J_CHICKENPOX_22=0.6, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSSSSUa1Mx2J for ; Mon, 15 Feb 2010 10:15:39 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by core3.amsl.com (Postfix) with ESMTP id 4667328C21D for ; Mon, 15 Feb 2010 10:15:39 -0800 (PST) Received: from suomp61i.qintra.com (suomp61i.qintra.com [151.117.69.28]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id o1FIH4s5015501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 15 Feb 2010 12:17:05 -0600 (CST) Received: from qtdenexhtm22.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id o1FIGwVG024433; Mon, 15 Feb 2010 12:16:59 -0600 (CST) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm22.AD.QINTRA.COM ([151.119.91.231]) with mapi; Mon, 15 Feb 2010 11:16:58 -0700 From: "Smith, Donald" To: Joel Jaeggli , Danny McPherson Date: Mon, 15 Feb 2010 11:16:57 -0700 Thread-Topic: [OPSEC] Fwd: Last Call for Comments: draft-oreirdan-mody-bot-remediation-06 Thread-Index: Acqtx42/UyVFz2xtQbKi5RBxrqoIrwAomV5o Message-ID: References: , <4B787D3A.70905@bogus.com> In-Reply-To: <4B787D3A.70905@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "jason_livingood@Cable.Comcast.com" , mailing list , Mike O'Reirdan , "nirmal_mody@Cable.Comcast.com" , opsec Subject: Re: [OPSEC] Fwd: Last Call for Comments: draft-oreirdan-mody-bot-remediation-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 18:15:45 -0000 First I agree with most of Joel's comments. 2nd original text of this draft are marked with > My comments are not. I have numerous comments and corrections below. Some attempt to fix grammar or make some of the statements more concise or = stronger. Others are comments or questions about the text itself. Fixes I put directly under the line they are intended to address. Comments have at least one line from a fix or last section I am attempting = to address. I believe most of your aware that qwest has been doing several types of aut= omated infected customer notifications for a long time now so I have a bit = of experience in this area. > > > Internet Engineering Task Force J. Livingood > Internet-Draft N. Mody > Intended status: Informational M. O'Reirdan > Expires: August 16, 2010 Comcast > February 12, 2010 > > > Recommendations for the Remediation of Bots in ISP Networks > draft-oreirdan-mody-bot-remediation-07 > > Abstract > > This document contains recommendations on how Internet Service > Providers can manage the effects of computers used by their * subscribers, which have been infected with malicious bots, via A bot is a tool. It can't really be malicious nor benign any more that a gu= n, or screwdriver is malicious however I understand as this is widely used,= incorrectly, within the industry. But malicious implies intent to do harm. As long as that is addressed in the malicious bot/bot definition it's proba= bly acceptable to use it in this way. > various remediation techniques. Internet users with infected > computers are exposed to risks such as loss of personal data, as well > as increased susceptibility to online fraud and/or phishing. Such > computers can also become an inadvertent participant in or component > of an online crime network, spam network, and/or phishing network, as > well as be used as a part of a distributed denial of service attack. The risks to users of infected systems and others are included/defined in m= any places within this document. It should probably be defined clearly in one place and referenced in all ot= her places. > Mitigating the effects of and remediating the installations of > malicious bots will make it more difficult for botnets to operate and > could reduce the level of online crime on the Internet in general > and/or on a particular Internet Service Provider's network. > > Status of this Memo > > This Internet-Draft is submitted to IETF in full conformance with the > provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on August 16, 2010. > > > > Livingood, et al. Expires August 16, 2010 [Page 1] > > Internet-Draft Remediation of Bots in ISP Networks February 2010 > > > Copyright Notice > > Copyright (c) 2010 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the BSD License. > > This document may contain material from IETF Documents or IETF > Contributions published or made publicly available before November > 10, 2008. The person(s) controlling the copyright in some of this > material may not have granted the IETF Trust the right to allow > modifications of such material outside the IETF Standards Process. > Without obtaining an adequate license from the person(s) controlling > the copyright in such materials, this document may not be modified > outside the IETF Standards Process, and derivative works of it may > not be created outside the IETF Standards Process, except to format > it for publication as an RFC or to translate it into languages other > than English. > > > > > > > > > > > > > > > > > > > > > > > > > > Livingood, et al. Expires August 16, 2010 [Page 2] > > Internet-Draft Remediation of Bots in ISP Networks February 2010 > > > Table of Contents > > 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 > 2. Key Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 > 3. Introduction and Problem Statement . . . . . . . . . . . . . . 6 > 4. Important Notice of Limitations and Scope . . . . . . . . . . 7 > 5. Detection of Bots . . . . . . . . . . . . . . . . . . . . . . 8 > 6. Notification to Internet Users . . . . . . . . . . . . . . . . 12 > 7. Remediation of Computers Infected with a Bot . . . . . . . . . 17 > 8. Guided Remediation Process . . . . . . . . . . . . . . . . . . 18 > 9. Professionally-Assisted Remediation Process . . . . . . . . . 20 > 10. Sharing of Data from the User to the ISP . . . . . . . . . . . 20 > 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 > 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 > 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 > 14. Informative references . . . . . . . . . . . . . . . . . . . . 22 > Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 24 > Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 25 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Livingood, et al. Expires August 16, 2010 [Page 3] > > Internet-Draft Remediation of Bots in ISP Networks February 2010 > > > 1. Requirements Language > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. > > > 2. Key Terminology > > This section defines the key terms used in this document. > > 2.1. Malicious Bots, or Bots > > A malicious "bot" (derived from the word "robot", hereafter simply Malicious bot implies intent to do harm, while these are really bots that c= an be used to perform potentially harmful tasks for the bot master. Perhaps= potentially harmful bot? > referred to as a "bot") refers to a program that is surreptitiously Some times they are installed on purpose but the user doesn't understand th= e full functionality of the software installed or the amount of remote cont= rol the application provides to the remote controller (bot master) > installed on a system in order to enable that system to automatically > (or semi-automatically) perform a task or set of tasks typically Isn't always automatically? I am not sure you need the semi-automatically p= art. > under the command and control of a remote administrator, or "bot > master." Bots are also known as "zombies". > > It is important to note that there are 'good', or benign bots. Such > benign bots are often found in such environments such as gaming and > Internet Relay Chat (IRC) [RFC1459], where a continual, interactive > presence can be a requirement for participating in the games, > interacting with a computing resource, or other purposes. Since such > benign bots are performing useful, lawful, and non-disruptive > functions, there is no reason for a provider to monitor for their > presence and/or alert users to their presence. Again Benign implies intent. Perhaps harmless instead? > > Thus, while there may be benign bots, for the purposes of this > document all mention of bots shall assume that the bots involved are > malicious in nature. Such malicious bots shall generally be assumed > to have been deployed without the permission or conscious > understanding of a particular Internet user. Thus, without a user's > knowledge, bots may transform the user's computing device into a > platform from which malicious activities can be conducted. In > general, installation of a malicious bot without user knowledge and > consent is considered in most regions to be unlawful, and the > activities of malicious bots typically involve unlawful or other > maliciously disruptive activities. > > 2.2. Bot Networks, or Botnets > > These are defined as concerted networks of bots capable of acting on > instructions generated remotely. The malicious activities are either > focused on the information on the local machine or acting to provide > services for remote machines. Bots are highly customizable so they > can be programmed to do many things. Binary based bots aren't usually highly customizable. The source code for b= ot programs is frequently publicly available therefore customizing or addin= g a new feature isn't difficult for someone with programming abilities. >The major malicious activities > > > > Livingood, et al. Expires August 16, 2010 [Page 4] > > Internet-Draft Remediation of Bots in ISP Networks February 2010 > > > include: identity theft, spam, distributed denial of service (DDoS) > attacks, key-logging, fraudulent DNS (pharming), proxy services, fast * flux hosting and click fraud. This is a pretty good risk identification. You might want to add spim, spit= , email address harvesting, hosting of highly questionable or illegal conte= nt (BulletProof hosting), various MITM attacks (banking ssl ala Zeus) and w= eb site scraping. > > Infection vectors include un-patched operating systems, software > vulnerabilities, weak/non-existent passwords, malicious websites, un- > patched browsers, malware, vulnerable helper applications and social > engineering techniques to gain access to the user's computer. The use of vulnerable and un-patched seems slightly redundant. An un-patched piece of software is likely to be vulnerable. I think your trying to cover the concept of un-patched vs zero day (no patc= h publicly available) exploitation. > The detection and destruction of bots is an ongoing issue and also= a > constant battle between the internet security community, network > security engineers and bot developers. > > Initially, bots used IRC to communicate but were easy to shutdown= if Initally SOME bots used IRC, Q, TFN, Trinoo, etc... all had non-IRC based c= ontrol. > the command and control server was identified and deactivated. Newer > command and control methods have evolved, such that those currently > employed by bot masters make them much more resistant to > deactivation. With the introduction of P2P, HTTP and other resilient > communication protocols along with the widespread adoption of > encryption, bots are considerably more difficult to identify and > isolate from typical network usage. As a result increased reliance > is being placed on anomaly detection and behavioral analysis, both > locally and remotely, to identify bots. > > 2.3. Computer > > A computer, as used in the context of this document, is intended to > refer to a computing device that connects to the Internet. This > encompasses devices used by Internet users such as personal > computers, including laptops, desktops, and netbooks, as well as > mobile phones, smart phones, home gateway devices, and other end user > computing devices which are connected or can connect to the public > Internet and/or private IP networks. > > Increasingly, other household systems and devices contain embedded > computers which are connected to or can connect to the public > Internet and/or private IP networks. However, these devices may not > be under interactive control of the Internet user, such as may be the > case with various smart home and smart grid devices. So do you intend for your computer definition to include smart ip enabled = devices or not. It's hard to tell from this definitation. I would limit the definition to computers that humans use as general purpos= e computers. > > 2.4. Malware > > This is short for malicious software. In this case, malicious bots > are considered a subset of malware. Other forms of malware could > include viruses and other similar types of software. Internet users > can sometimes cause their computer to be infected with malware, which > may include a bot or cause a bot to install itself, via inadvertently > accessing a specific website, downloading a specific file, or other a website, downloading a file ... > activities. > > > > Livingood, et al. Expires August 16, 2010 [Page 5] > > Internet-Draft Remediation of Bots in ISP Networks February 2010 > > > Alternatively, Internet-connected computers may become infected with Not really alternatively, since you mention vulnerabilities above but I thi= nk your trying to say without user interaction (scan and spolit) right? > malware through externally initiated malicious activities such as the > exploitation of vulnerabilities or the brute force guessing of access > credentials. Again risk defined. This one is pretty good and maybe the right place to define the risk but it= should probably only be defined in detail in one spot. > > 2.5. Fast Flux > > DNS Fast Fluxing occurs when a domain is bound in DNS using A records > to multiple IP addresses, each of which has a very short Time To Live > (TTL) value associated with it. This means that the domain resolves > to varying IP addresses over a short period of time. > > DNS Fast Flux is typically used in conjunction with proxies which > then route the web requests to the real host which serves the data > being sought. The proxies are normally hosted on compromised user > computers. The effect of this is to make the detection of the real > host for a piece of content much more difficult and to ensure that > the site remains up for as long as possible. The backend/hidden site > > > 3. Introduction and Problem Statement > > Computers used by Internet users, which in this case are customers of > an Internet Service Provider (ISP), can be infected with malware > which may contain and/or install one or more bots on a computer. > This can present a major problem for an ISP for a number of reasons > (not to mention of course the problems created for users). First, mentioning users here seems out of place plus you mention them so I would e= ither remove or rephrase. The can present a major problem for an ISP and their users ... > these bots can be used to send spam, in some cases very large volumes > of spam [Spamalytics: An Empirical Analysis of Spam Marketing > Conversion]. This spam can result in extra cost for the ISPs in > terms of wasted network, server, and/or personnel resources, among > many other potential costs and side effects. Such spam can also > negatively affect the reputation of the ISP, their customers, and the > email reputation of the IP address space used by the ISP (often > referred to simply as 'IP reputation'). Again risk defined but given that these are risks to the ISP that may be ap= propriate as long as its defined one time and referenced in other places. > > In addition, these bots can act as platforms for directing, > participating in, or otherwise conducting attacks on critical > Internet infrastructure [Emerging Cyber Threats Report for 2009: > Data, Mobility and Questions of Responsibility will Drive Cyber > Threats in 2009 and Beyond]. Bots are frequently used as part of > concerted Distributed Denial of Service (DDoS) attacks for criminal, coordinated > political or other motivations [The Gh0st in the Shell: Network > Security in the Himalayas] [The snooping dragon: social-malware > surveillance of the Tibetan movement]. For example, bots have been > used to attack Internet resources and infrastructure ranging from web > sites, to email servers and DNS servers, as well as the critical > Internet infrastructure of entire countries [Battling Botnets and > > > > Livingood, et al. Expires August 16, 2010 [Page 6] > > Internet-Draft Remediation of Bots in ISP Networks February 2010 > > > Online Mobs: Estonia's Defense Efforts during the Internet War] > [Cyberspace as a Combat Zone: The Phenomenon of Electronic Jihad]. > Motivations for such coordinated DDoS attacks can range from criminal > extortion attempts through to online protesting and nationalistic > fervor [Case Study: How a Bookmaker and a Whiz Kid Took On a > DDOS-based Online Extortion Attack]. > > While any computing device can be infected with bots, the majority of > bot infections affect the personal computers used by Internet end > users. As a result of the role of ISPs in providing IP connectivity, > among many other services, to Internet users, these ISPs are in a > unique position to be able to attempt to detect and observe bot nets > operating in their networks. Furthermore, ISPs may also be in a > unique position to be able to communicate to Internet users which are unique position to be able to notify their customers of potential infection= by bots or other infections. > their customers, when customers' computers may have been determined > to have been or possibly have been infected with one or more bots. > > From an end user perspective, knowing that their computer has been >From an end user perspective, being notified that they may have an infected= computer on their network is important information. > infected with one or more bots is very important information. Once > they know this, they can take steps to remove the bot, protect > themselves in the future, and resolve any problems which may stem > from the bot infection. Given that bots can drain local computing Given that bots can consume vast amounts of local computing and network res= ources ... > and network resources, enable theft of personal information > (including personal financial information), enable the computer to be > used from criminal activities (that may result in the Internet user > being legally culpable), destroy or leave the PC in an unrecoverable > state via 'kill switch' bot technologies, it is important to notify > the user that they may be infected with a bot. I haven't really seen a case where the "kill switch" was triggered by attem= pts to remediate an infection. Additionally your redefining the risk here again. > > As a result, the intent of this document is to provide a guide to The intent of this document is to provide guidence to ISPs... > ISPs and other organizations for the remediation of these computers > infected with bots, so as to reduce the size of bot nets and minimize remediation of bot infected computers ... > the potential harm that bots can inflict upon Internet infrastructure > generally, as well as on individual Internet users. Efforts by ISPs > and other organizations could therefore, over time, reduce the pool and other organizations can over time reduce the pool of ... > of computers infected with bots on the Internet, which in turn could > result in smaller bot nets with less capability for disruption. > > The potential mitigation of bots is accomplished through a process of > detection, notification to Internet users, and remediation of that > bot with a variety of tools, as described later in this document. bot infections with a variety ... > > > 4. Important Notice of Limitations and Scope > > The techniques described in this document in no way guarantee the > remediation of all bots. Bot removal is potentially a task requiring > specialized knowledge, skills and tools, and may be beyond the > > > > Livingood, et al. Expires August 16, 2010 [Page 7] > > Internet-Draft Remediation of Bots in ISP Networks February 2010 > > > ability of average users. Attempts at bot removal may frequently be > unsuccessful, or only partially successful, and may leave a user's unsuccessful or only partially successful leaving the system ... > system in an unstable and unsatisfactory state or even in a state > where it is still infected. Attempts at bot removal can also result > in side effects ranging from a loss of data or other files, all the > way through partial or complete loss of system usability. Attempts at bot removal can result in side effects from a loss of data to p= artial or complete loss of system usablility. > > In general, the only way a user can be sure they have removed some of > today's increasingly sophisticated malware is by 'nuking-and-paving' > the system: reformatting the drive, reinstalling the operating system > and applications (including all patches) from scratch, and then > restoring user files from a clean backup. However the introduction restoring user files from a known clean backup... > of BIOS-based malware may mean that, in some cases, this will not be of persistent memory based malware may meant that, in some cases, this may = not be ... > enough and may prove to be more than any end user can be reasonably > expected to resolve [Persistent BIOS Infection]. Experienced users Persistent memory infections. > would have to re-flash BIOS in their machines in order to remove > BIOS-based malware. However, in some cases, not even 'nuking-and- would have to re-flash or re-image persistent memory sections on their mach= ines in order ... > paving' the system will solve the problem, which calls for hard drive > and/or complete computer replacement. > > Devices with embedded operating systems, such as video gaming > consoles and smart home appliances, will most likely be beyond a > user's capability to remediate by themselves, and will typically > require the aid of vendor-specific advice, updates and tools. Care > must be taken when imparting remediation advice to Internet users > given the increasingly wide array of computing devices that can be, > or could be, infected by bots in the future. Many such devices have a "reset to factory defaults" switch which will be t= he main method to clear such devices if infected. > > > 5. Detection of Bots > > An ISP must first identify that an Internet user, in this case a user > that is assumed to be their customer or otherwise connected to the > ISP's network, is determined to be infected, or likely to have been > infected with a bot. The ISP must attempt to detect the presence of > bots using methods, processes, and tools which maintain the privacy > of the personally identifiable information (PII) of their customers. > The ISP also must not block legitimate traffic in the course of bot > detection, and must instead employ detection methods, tools, and > processes which seek to be non-disruptive, as well as being > transparent to Internet users and end-user applications. You can't be totally transparent nor completely non-disruptive. Nothing can be observed without affecting what your observing. Perhaps rewrite with the concept of MINUMIZING such effects? > > Detection methods, tools, and processes may include things such as may include analysis of specific ... > analysis of specific network and/or application traffic flows (such > as traffic to an email server), analysis of aggregate network and/or > application traffic data, data feeds received from other ISPs and > organizations (such as lists of the ISP's IP addresses which have > been reported to have sent spam), feedback from the ISP's customers > > > > Livingood, et al. Expires August 16, 2010 [Page 8] > > Internet-Draft Remediation of Bots in ISP Networks February 2010 > > > or other Internet users, as well as a wide variety of other > possibilities. It is likely that a combination of multiple bot In order to validate any bot net detection source a combination of multiple= bot detection sources has proven to be an effective approach ... > detection data points will prove to be an effective approach in order > to corroborate information of varying dependability or consistency, > as well as to avoid or minimize the possibility of false positive > identification of computers. Detection should also, where possible > and feasible, attempt to classify a bot in order to confirm that it to classify the specific bot infection type in order to ... > is malicious in nature, estimate the variety and severity of threats > it may pose (such as spam bot, key-logging bot, file distribution > bot, etc.), and to determine potential methods for eventual > remediation. However, given the dynamic nature of botnet management > and the criminal incentives to seek quick financial rewards, botnets > frequently update or change their core malicious capabilities. As a > consequence, botnets that are initially detected and classified by > the ISP as one particular type of bot need to be continuously > monitored and tracked in order to correctly identify the threat they > pose at any particular point in time. Not really, while it is helpful to provide as much information as possible = to the victim, generic bot (or infection) notification has proven to be suc= cessfully. > > Detection is also time-sensitive. If complex analysis is required It seems like you just said that above. > and multiple confirmations are needed to confirm a bot is indeed > present, then it is possible that the bot may cause some damage (to > either the infected computer or a remotely targeted system) before it > can be stopped. This may mean that an ISP may need to balance the > desire or need to definitively classify and/or confirm a bot, which > may take an extended period of time, with the ability to predict the > strong likelihood of a bot in a very short period of time. This > 'definitive-vs-likely' challenge is difficult and, when in doubt, > ISPs should probably err on the side of caution by communicating when I agree erring on the side of caution BUT that should be don't communicate = with your customers unless your fairly certain they are infected (False pos= itive rate of 5% or less)! Notifying customers just on "likely" (ie greater= then 50%) will cause customers loose faith in such notification. > a likely bot infection has taken place. This also means that > Internet users may benefit from the deployment of client-based > software protections or other software tools, which can enable rapid > performance of heuristically-based detection bot activity, such as There is a risk here in that this teaches users to install software on thei= r computer that may not be effective given todays botnet + root kit hiding = abilities. Thus a false sense of security plus you've trained them to insta= ll software outside of normal OS maintenance. Would this even be included i= f it weren't the approach you choose? > the detection of a bot as it starts to communicate a bot net and communicate to a bot net ... > execute some type of command. Any bot detection systems should also execute commands. > be capable of learning and adapting, either via manual intervention > or automatically, in order to cope with a rapidly evolving threat. If done learning is done automatically you have just solved the turing test= . Computers don't learn. > > As noted above, detection methods, tools, and processes should ensure > that privacy of customers' PII is maintained. While bot detection > methods, tools, and processes are similar to spam and virus defenses > deployed by the ISP for the benefit of their customers (and may be > directly related to those defenses), attempts to detect bots should > take into account the need of an ISP to take care to ensure any PII > collected or incidentally detected is properly protected. The > definition of PII varies from one jurisdiction to the next so proper > care must be taken to ensure that any actions taken comply with > legislation and good practice in the jurisdiction in which the PII is > gathered. Finally, depending upon the geographic region within which While this is true in many cases the customers PII is already at risk from = criminal elements that want to exploit it. So being overly concerned about = the privacy of PII (such as hiding PII from internal analysis teams) should= be recommended against. > > > > Livingood, et al. Expires August 16, 2010 [Page 9] > > Internet-Draft Remediation of Bots in ISP Networks February 2010 > > > an ISP operates, certain methods relating to bot detection may need > to be included in relevant terms of service documents or other > documents which are available to the customers of a particular ISP. > > There are several bot detection methods, tools, and processes that an > ISP may choose to utilize, as noted in the list below. It is > important to note that the technical solutions available are > relatively immature, and are likely to change over time, evolving > rapidly in the coming years. While these items are described in > relation to ISPs, they may also be applicable to organizations > operating other networks, such as campus networks and enterprise > networks. > > a. Where legally permissible or otherwise an industry accepted > practice in a particular market region, an ISP may in some manner > "scan" their IP space in order to detect un-patched or otherwise > vulnerable hosts. This may provide the ISP with the opportunity > to easily identify Internet users who appear to already be or are > at great risk of being infected with a bot. ISP's should note > that some types of port scanning may leave network services in a > hung state or render them unusable due to common frailties, and > that many modern firewall and host-based intrusion detection > implementations may alert the Internet user to the scan. As a > result the scan may be interpreted as a malicious attack against > the computer. Vulnerability scanning has a higher probability of > leaving accessible network services and applications in a damaged > state and will often result in a higher probability of detection > by the Internet user and subsequent interpretation as a targeted > attack. Depending upon the vulnerability being scanned, some > automated methods of vulnerability checking may result in data > being altered or created afresh on the Internet users computer > which be a problem in many legal environments. I would strongly recommend against this as a common practice. You provided = most of the risks that make this a dangerous course. > > b. An ISP may also communicate and share selected data, via feedback > loops or other mechanisms, with various third parties. Feedback > loops are consistently formatted feeds of real-time (or nearly > real-time) abuse reports offered by threat data clearinghouses, > security alert organizations, other ISPs, and other > organizations. The data may include, but is not limited to, I think your "feed back loop" is really "trusted third party notification".= While those may include feed back, as your well aware, there isn't that mu= ch feed back in most cases due to PII concerns. So most the time the truste= d 3rd party gets a "THANKS we will take care of it" as opposed to yes we se= e some of those ip being reported as infected. > lists of the IP addresses computers which have or are likely to > have a bot running, domain names or fully qualified domain names > (FQDNs) known to host malware and/or be involved in the command > and control of botnets, IP addresses know to host malware and/or > be involved in the command and control of botnets, recently > tested or discovered techniques or detecting or remediating bot > infections, new threat vectors, and other relevant information. > Good examples of this include SNDS from Microsoft, XBL and PBL > from Spamhaus and the DSHIELD AS tool from the SANS Institute. > > > > Livingood, et al. Expires August 16, 2010 [Page 10] > > Internet-Draft Remediation of Bots in ISP Networks February 2010 > > > c. An ISP may use Netflow [RFC3954] or other similar passive network > monitoring to identify network anomalies that may be indicative > of botnet attacks or bot communications. For example, an ISP may > be able to identify compromised hosts by identifying traffic > destined to IP addresses associated with the command and control destined to an IP address and control port associated with the ... Most of the time the host associated with c and c has other legit traffic s= o having the control port helps a LOT when running potentially infected bot= net reports. > of botnets. In addition, bots can be identified when a remote > host is under a DDoS attack because computers participating in > the attack will likely be infected by a bot, frequently as I would caution against FPs due to spoofing of source IP addresses. With netflow you can check which router and interface the attack traffic is= coming in from as method to reduce FPs. > observed at network borders. > > d. An ISP may use DNS-based techniques to perform detection. For > example, a given classified bot may be known to query a specific > list of domain names at specific times or on specific dates (in > the example of the so-called "Conficker" bot), often by matching > DNS queries to a well known list of domains associated with > malware. In many cases such lists are distributed by or shared > using third parties, such as threat data clearinghouses. > > e. User complaints: Because hosts infected by bots are frequently > used to send spam or participate in DDoS attacks, the ISP > servicing those hosts will normally receive complaints about the > malicious network traffic. Those complaints may be sent to > RFC2142-specified [RFC2142] role accounts, such as abuse@ or > postmaster@ or to abuse or security addresses specified by the postmaster is for email delivery issues and we shouldn't be encouraging peo= ple to use it for abuse unless no other contact info is available. NOC or security should be encouraged instead if abuse@ doesn't work. > site as part of its WHOIS (or other) contact data. > > f. ISPs may also discover likely bot infected hosts located at other > sites; when legally permissible or otherwise an industry accepted located on other ISPs networks; when legally ... You mention industry accepted practice here as an or legally permissible bu= t I think you mean and not or. It has to be legal or you shouldn't do it pe= riod. If it is an industry accepted practice shouldn't really come in to it= . The first of us that started share such reports to other ISPs we were the= first to do so. It wasn't the industry accepted practice at that time. > practice in a particular market region, it may be worthwhile for in a particular geo-political area based on local laws. It is valuable for ISPs to share evidence related to those likely bot infected hosts with the = ... > ISPs to share evidence relating to those compromised hosts with > the relevant remote ISP, with security researchers, and with > blocklist operators. > > g. ISPs may operate or subscribe to services that provide > 'sinkholing' or 'honeynet' capabilities. This may enable the ISP > to obtain near-real-time lists of bot infected computers as they > attempt to join a larger botnet or propagate to other hosts on a > network. > > h. ISP industry associations should examine the possibility of > collating statistics from ISP members in order to provide good > statistics about bot infections based on real ISP data. > > i. An Intrusion Detection System(IDS) can be a useful tool to > actually identify to help identify the malware. An IDS tool such > as SNORT (open source IDS platform) can be placed in a Walled > Garden and used to analyze end user traffic to confirm malware > type. This will help with remediation of the infected device. Some mention of within local laws and/or aup may be helpful here. In fact maybe a strong statement at the beginning that say that for all of = these detection methods ensure its legal and/or within AUP/ELUA. > > > > Livingood, et al. Expires August 16, 2010 [Page 11] > > Internet-Draft Remediation of Bots in ISP Networks February 2010 > > > 6. Notification to Internet Users > > Once an ISP has detected a bot, or the strong likelihood of a bot, > steps should be undertaken to inform the Internet user that they may > have a bot-related problem. Depending upon a range of factors, from > the technical capabilities of the ISP, to the technical attributes of > their network, financial considerations, available server resources, > available organizational resources, the number of likely infected > computers detected at any given time, and the severity of any > possible threats, among many other things, an ISP should decide the > most appropriate method or methods for providing notification to one Ideally the customer should be notified via as many methods as possible at = nearly the same time if possible. While most ISPs could do more then one no= tification method most of the "bad guys" won't be able to spoof many differ= ent notification types within a small amount of time. I don't know anyone that has implemented this but it seems like a really go= od recommendation. > or more of their customers or Internet users. Such notification > methods may include one or more of the following, as well as other > possible methods not described below > > It is important to note that none of these methods are guaranteed to > be successful, and that each has its own set of limitations. In 100% successful, > addition, in some cases, an ISP may determine that a combination of > two or more methods is most appropriate. Finally, notification is > also considered time sensitive; if the user does not receive or view > the notification or a timely basis, then a particular bot could > launch an attack, exploit the user, or cause other harm. If > possible, an ISP should establish a preferred means of communication > when the subscriber first signs up for service. As a part of the > notification process, ISPs should maintain a record of the allocation > of IP addresses to subscribers for such a period as allows any bot commonly used bot detection > detection technology to be accurately able to link an infected IP to be able to accurately link an infected ... > address to a subscriber. This record should only be maintained for a > period of time which is necessary, in order to maintain the > protection of the privacy of an individual subscriber. > > One important factor to bear in mind is that notification to end > users needs to be defended against spoofing by third parties. This > must be done to protect against the possibility of notifications > being spoofed and used by bots to deliver additional malware. must be done to protect as well as reasonably possible against the possibil= ity of legitimate notifications being spoofed and used by persons with mali= cious intent to perform additional malicious acts against the victims. They may not be bots and they may not use this to "infect" with a bot in ma= ny cases "they" will be an AD that sells fake AV/scareware. > > 6.1. Email Notification > > This is probably the most common form of notification used by ISPs. Is it? Do we have any surveys or stats on this? I think your correct but it= would be good to have some kind of backup. > One drawback of using email is that it is not guaranteed to be viewed > within a reasonable time frame, if at all. The user may be using a > different primary email address than that which they have provided to > the ISP. In addition, some ISPs do not provide an email account at > all, as part of a bundle of Internet services, and/or do not have a > need for or method in which to request or retain the primary email > addresses of Internet users of their networks. Another possibility > is that the user, their email client, and/or their email servers > could determine or classify such a notification as spam, which could > > > > Livingood, et al. Expires August 16, 2010 [Page 12] > > Internet-Draft Remediation of Bots in ISP Networks February 2010 > > > delete the message or otherwise file it in an email folder that the > user may not check on a regular and/or timely basis. Bot masters > have also been known to impersonate the ISP or trusted sender and > send fradulent emails to the users. This technique of social fraudulent > engineering, generally referred to as 'phishing', often leads to new Phishing is generally defined as attempting to gain user credentials or oth= er sensitive information by spoofing a trusted source. What your describing is a method used by some viruses such as beagle to spr= ead by convincing customers to install it thinking it was a fix to some mal= ware or other issue. This is commonly refered to as social engineering as y= ou state but not phishing. > bot infestations. Finally if the user's email credentials are > compromised, then a hacker and/or a bot could simply login to the > user's email account and delete the email before it is read by the > user. > > 6.2. Telephone Call Notification > > A telephone call may be an effective means of communication in > particularly high-risk situations. However, telephone calls may not > be feasible due to the cost of making a large number of calls, as > measured in either time, money, organizational resources, server > resources, or some other means. In addition, there is no guarantee > that the user will answer their phone. To the extent that the > telephone number called by the ISP can be answered by the infected > computing device, the bot on that computer may be able to disconnect, > divert, or otherwise interfere with an incoming call. Users may also > interpret such a telephone notification as a telemarketing call and > as such not welcome it, or not accept the call at all. Finally, even > if a representative of the ISP is able to connect with and speak to a > user, that user is very likely to lack the necessary technical > expertise to understand or be able to effectively deal with the > threat. Isn't this last statement true for ALL notifications methods. I agree it is true, but it probably needs to be a caveat for all notificati= on methods. You mention it else where but perhaps a special paragraph at th= e beginning that states this is true for all notification types. > > 6.3. Postal Mail Notification > > This form of notification is probably the least popular and effective > means of communication, due to both preparation time, delivery time, > the cost of printing and paper, and the cost of postage. For ISPs that are already billing their customers there wouldn't need to be= additional cost of postage, printing or paper it could be incorporated int= o the bill its self. The biggest risk here is delivery time and the fact th= at some customers don't review their bills (similar to the email issue iden= tified above). > > 6.4. Walled Garden Notification > > Placing a user in a walled garden is another approach that ISPs may > take to notify users. A walled garden refers to an environment that > controls the information and services that a subscriber is allowed to > utilize and what network access permissions are granted. This is an That is really the definition of a quarantine walled garden. Walled garden's don't have to quarantine the user (much) to notify the cust= omer. They can be fairly leaky and still notify the customer of their infection. > effective technique because it could be able to block all > communication between the bot and the command and control channel, > which may impair the ability of a bot to disrupt or block attempts to > notify the user. > > While in many cases the user is almost guaranteed to view the > notification message and take any appropriate remediation actions, Exactly. > this approach poses can pose other challenges. For example, it is > > > > Livingood, et al. Expires August 16, 2010 [Page 13] > > Internet-Draft Remediation of Bots in ISP Networks February 2010 > > > not always the case that a user is actively using a computer that > uses a web browser or which has a web browser actively running on it. not always the case that a user is using a application that used the ports = being redirected to the walled garden. This is more of an application issue then the "computer". > In one example, a user could be playing a game online, via the use of > a dedicated, Internet-connected game console. In another example, > the user may not be using a computer with a web browser when they are > placed in the walled garden and may instead be in the course of a > telephone conversation, or may be expecting to receive a call, using > a Voice Over IP (VoIP) device of some type. As a result, the ISP may > feel the need to maintain a potentially lengthy white list of domains > which are not subject to the typical restrictions of a walled garden, > which could well prove to be an onerous task, from an operational > perspective. Or design a leaky walled garden that allows most traffic without interferen= ce only redirecting the traffic needed to mitigate or notify. > > The ISP has several options to determine when to let the user out of > the walled garden. One approach may be to let the user determine > when to exit. This is really the only viable approach. Any other approach encroaches on u= ser rights, drive up help desk calls ($) and generally be unacceptable to your = users. > This option is suggested when the purpose of the primary purpose of the > walled garden is to notify users and provide information on > remediation only, particularly since notification is not a guarantee > of successful remediation. It could also be the case that, for No you can still let the user determine when to leave since you have notifi= ed them you have reduced your liability for any malicious traffic that may = be allowed out when they request exiting the walled garden. > whatever reason, the user makes the judgment that they cannot then > take the time to remediate their computer and that other online > activities which they would like to resume are more important. Exit > from the walled garden may also involve a process to verify that it > is indeed the user who is requesting exit from the walled garden and > not the bot. If you mean requesting some kind of credentials before they exit I would ad= vise against that as it is an avenue for phishing. > > Once the user acknowledges the notification, then the user decides to the notification, decides to remediate and exit the walled garden or exit t= he walled garden without remediating the issue. > either remediate and then exit the walled garden, or exit the walled > garden without addressing the issue. Another approach may be to > enforce a stricter policy and require the user to clean the computer > prior to permitting the user to exit the walled garden, though this > may not be technically feasible depending upon the type of bot, > obfuscation techniques employed by a bot, and/or a range of other > factors. Thus, the ISP may also need to support tools to scan the > infected computer and determine whether it is still infected or rely > on user judgment that the bot has been disabled or removed. One Scanning is risky and should be identified as such. Port scanning or vulnerability scanning is dangerous as you identified else= where. Anti-virus scanning is also risky if the ISP initiates it as that means you= have taken some level of control (and responsibility) for that infected ma= chine. A better method would be to use SNORT or similar tool to passively watch fo= r packets indicating an continued infection. Another good approach is just to keep track of whom was put into the walled= garden for which infection and if they keep showing up as infected via the= trusted third party reports then you can assume they are unable/unwilling = to remediate and take what ever additional actions you deem appropriate. > challenge with this approach is that if the user has multiple > computers sharing a single IP address, such as via a common home > gateway device which performs Network Address Translation (NAT). In > such a case, the ISP may need to determine from user feedback, or > other means, that all affected computers have been remediated, which > may or may not be technically feasible. > > Finally, when a walled garden is used, a list of well-known addresses > for both operating system vendors and security vendors should be > created and maintained in a white list which permits access to these > sites. This can be important for allowing access from the walled While this is possible in the cases where the ISP can provide links to tool= s that are known to effectively remove the infection you only have to white= list that URL/site while the user is in the walled garden then let them out= once they determine that they think they are clean and they can get OS/AV = updates without the WG needing a large whitelist. > garden by end users in search of operating system and application > > > > Livingood, et al. Expires August 16, 2010 [Page 14] > > Internet-Draft Remediation of Bots in ISP Networks February 2010 > > > patches. > > 6.5. Instant Message Notification > > Instant messaging provides the ISP with a simple means to communicate > with the user. There are several advantages to using IM which makes > it an attractive option. If the ISP provides IM service and the user > subscribes to it, then the user can be notified easily. IM-based > notification can be a cost effective means to communicate with users > automatically from an IM alert system or via a manual process, by the > ISP's support staff. Ideally, the ISP should allow the user to > register their IM identity in an ISP account management system and > grant permission to be contacted via this means. If the IM service > provider supports off-line messaging, then the user can be notified > regardless of whether they are currently logged into the IM system. > > There are several drawbacks with this communications method. There > is a high probability that subscriber may interpret the communication > to be spam, and as such ignore it. Also, not every user uses IM > and/or the user may not provide their IM identity to the ISP so some > alternative means have to be used. Even in those cases where a user > does have an IM address, they may not be signed onto that IM system > when the notification is attempted. There maybe also be a privacy > concern on the part of users, when such an IM notification must be > transmitted over a third-party network and/or IM service. As such, > should this method be used, the notification should be discreet and > not include any PII in the notification itself. Isn't this true for email, sms and possibly other methods. Again if so it could become part of the opening statement rather then tied = to just one notification type. > > 6.6. Short Message Service (SMS) Notification > > SMS allows the ISP send a brief description of the problem to notify > the user of the issue, typically to a mobile device such as a mobile > phone or smart phone. Ideally, the ISP should allow the user to > register their mobile number and/or SMS address in an ISP account > management system and grant permission to be contacted via this > means. The primary advantage of SMS is that users are familiar with > receiving text messages and are likely to read them. However, users > may not act on the notification immediately if they are not in front > of their computer system at the time of the SMS notification. > > One disadvantage is that ISPs may have to follow up with an alternate > means of notification if not all of the necessary information maybe > conveyed in one message, given constraints on the number of > characters in an individual message (typically 140 characters). > Another disadvantage with SMS is the cost associated with it. The > ISP has to either build its own SMS gateway to interface with the > various wireless network service providers or use a third-party SMS > clearinghouse (relay) to notify users. In both cases, an ISP will > > > > Livingood, et al. Expires August 16, 2010 [Page 15] > > Internet-Draft Remediation of Bots in ISP Networks February 2010 > > > typically pay on a per-message basis to send SMS notifications. An No in most cases the ISP would use the customers SMS providers SMTP to SMS = gateway and wouldn't encore additional costs for an sms msg. > additional downside is that SMS messages sent to a user may result in > a charge to the user by their wireless provider, depending upon the > plat to which they subscribe. Another minor disadvantage is that it did you mean platform or feature set here? > is possible to notify the wrong user if the intended user changes > their mobile number but forgets to update it with the ISP. Again this applies to more then just sms, certainly to email accounts and p= robably other notification methods. > > There are several other drawbacks with this communications method. > There is a high probability that subscriber may interpret the > communication to be spam, and as such ignore it. Also, not every > user uses SMS and/or the user may not provide their SMS address or > mobile number to the ISP. Even in those cases where a user does have > an SMS address or mobile number, their device may not be powered on > or otherwise available on a wireless network when the notification is > attempted. There maybe also be a privacy concern on the part of > users, when such an SMS notification must be transmitted over a > third-party network and/or SMS clearinghouse. As such, should this > method be used, the notification should be discreet and not include > any PII in the notification itself. > > 6.7. Web Browser Notification > > Near real-time notification to the user's web browser is another > technique that may be utilized for notifying the user, though how > such a system might operate is outside the scope of this document. > Such a notification could have a comparative advantage over a walled > garden notification, in that it does not restrict traffic to a > specified list of destinations in the same way that a walled garden > by definition would. However, as with a walled garden notification, As I pointed out elsewhere a walled garden doesn't have to restrict traffic= to a specified list. Just redirect the web traffic long enough to notify. > there is no guarantee that a user is at any given time making use of > a web browser, though such a system could certainly provide a > notification when such a browser is eventually used. Compared to a > walled garden, a web browser notification is probably preferred from > the perspective of Internet users, as it does not have the risk of > disrupting non-web sessions, such as online games, VoIP calls, etc. > (as noted in Section 6.4). Again a leaky walled garden doesn't have this issue. > > 6.8. Considerations for Notification to Public Network Locations > > Delivering a notification to a location that provides a shared public > network, such as a train station, public square, coffee shop, or > similar location may be of low value since the users connecting to > such networks are typically highly transient and generally not know > to site or network administrators. For example, a system may detect > that a computer on such a network has a bot, but by the time a > notification is generated that user has departed from the network and > moved elsewhere. > > > > > Livingood, et al. Expires August 16, 2010 [Page 16] > > Internet-Draft Remediation of Bots in ISP Networks February 2010 > > > 6.9. Considerations for Notification to Network Locations Using a > Shared IP Address > > Delivering a notification to a location that Internet access routed > through one or more shared public IP addresses may be of low value > since it may be quite difficult to differentiate between users when > providing a notification. For example, on a business network of 500 > users, all sharing one public IP address, it may be sub-optimal to > provide a notification to all 500 users if you only need one specific > user to be notified and take action. As a result, such networks may In cases like this to assist the business network you describe providing a = date/timestamp, source port of the infected system, and malicious sites it = was visiting often helps them find the infected system. > find value in establishing a localized bot detection and notification > system, just as they are likely to also establish other localized > systems for security, file sharing, email, and so on. One thing I don't see mentioned anywhere in the notification section is wha= t I call the respect factor. Give your customer respect. Do not talk down t= o them or make them feel as if they have done anything wrong remember these= are victims and you would like to build trust with them! > > > 7. Remediation of Computers Infected with a Bot > > This section covers the different options available to remediate a > computer, which means to remove, disable, or otherwise render a bot > harmless. Prior to this step, an ISP has detected the bot, notified > the user that one of their computers is infected with a bot, and now > may provide some recommended means to clean the computer. The > generally recommended approach is to provide the necessary tools and > education to the user so that they may perform bot remediation > themselves, particularly given the risks and difficulties inherent in > attempting to remove a bot. > > For example, this may include the creation of a special web site with > security-oriented content that is dedicated for this purpose. This > should be a well-publicized security web site to which a user with a > bot infection can be directed to for remediation. This security web > site should clearly explain why the user was notified and may include > an explanation of what bots are, and the threats that they pose. > There should be a clear explanation of the steps that the user should > take in order to attempt to clean their computer and provide > information on how users can keep the computer free of future > infections. The security web site should also have a guided process > that takes non-technical users through the remediation process, on an > easily understood, step-by-step basis. > > In terms of the text used to explain what bots are and the threats > that they pose, something simple such as this may suffice: > > "What is a bot? A bot is a piece of software, generally > installed on your machine without your knowledge, which either > sends spam or tries to steal your personal information. They > can be very difficult to spot, though you may have noticed that > your computer is running much more slowly than usual or you > > > > Livingood, et al. Expires August 16, 2010 [Page 17] > > Internet-Draft Remediation of Bots in ISP Networks February 2010 > > > notice regular disk activity even when you are not doing > anything. Ignoring this problem is not really an option since Ignoring this problem is risky to you and your personal information .. > your personal information is currently at risk. Thus, bots > need to be removed to protect your data and your personal > information." > > It is also important to note that it may not be immediately apparent > to the Internet user precisely which devices have been infected with > a particular bot. This may be due to the user's home network > configuration, which may encompass several computers, where a home > gateway which performs Network Address Translation (NAT) to share a > single public IP address has been used. Therefore, any of these > devices can be infected with a bot. The consequence of this for an > ISP is that remediation advice may not ultimately be immediately > actionable by the Internet user, as that user may need to perform > additional investigation within their own home network. You mentioned this in the notification section not sure it is needed here t= oo. > > An added complication is that the user may have a bot infection on a > device such as a video console, multimedia system, appliance, or > other end-user computing device which does not have a typical Windows > or Macintosh user interface. As a result, diligence needs to be which does not have a user feed back interface such as a web browser or ema= il client. > taken by the ISP where possible such that they can identify and > communicate the specific nature of the device that has been infected > with a bot, and further providing appropriate remediation advice. Mentioned in the notification process probably not needed here. > > There are a number of forums that exist online to provide security > related support to end users. These forums are staffed by volunteers > and often are focussed around the use of a common tool set to help > end users to remediate computers infected with malware. It may be > advantageous to ISPs to foster a relationship with one or more > forums, perhaps by offering free hosting or other forms of > sponsorship. > > > 8. Guided Remediation Process > > Minimally the Guided Remediation Process should include options > and/or recommendations on how a user should: > > 1. Backup personal Documents, for example: "Before you start, make > sure to back up all of your important data. (You should do this > on a regular basis anyway.) You can back up your files manually > or using a system back-up software utility, which may be part of > your Operating System (OS). You can back your files up to a USB > Thumb Drive (aka USB Key), a writeable CD/DVD-ROM, an external > hard drive, or a network file server." > I would argue that the FIRST step in Guided remediation process is getting = the customer cleaned but understand the desire to backup before preforming = the cleaning. However it has to be the 2nd step if you put backup first. Mo= st bot software is going to prevent the OS and antivirus steps until the cu= stomer is uninfected. > > > > Livingood, et al. Expires August 16, 2010 [Page 18] > > Internet-Draft Remediation of Bots in ISP Networks February 2010 > > > 2. Download OS patches and Anti-Virus (A/V) software updates. For > example, links could be provided to Microsoft Windows updates at > http://update.microsoft.com/microsoftupdate/v6/ > default.aspx?ln=3Den-us as well as to Apple MacOS updates at > http://support.apple.com/kb/HT1338?viewlocale=3Den_US. > > 3. Explain how to configure the computer to automatically install > updates for the OS, A/V and other common Web Browsers such as > Microsoft Internet Explorer, Mozilla Firefox, Apple Safari, > Opera, and Google Chrome. > > 4. The flow should also have the option for users to get > professional assistance if they are unable to remove the bots > themselves. If purchasing third party assistance, then the user > should be encouraged to pre-determine how much they are willing > to pay for that help. If the computer that is being remediated > is old and can easily be replaced with a new, faster, larger and > more reliable system for three or four hundred dollars, the it > makes no sense to spend five or six hundred dollars to fix the > old computer, for example. On the other hand, if the customer > has a brand new computer that cost several thousand dollars, it > might make perfect sense to spend the money in attempting to > remediate it. > > 5. To continue, regardless of whether the user or a knowledgeable > technical assistant is working on remediating the computer, their > first task should be to determine which of multiple potentially- > infected machines may be the one that needs attention (in the > common case of multiple computers in a home network). Sometimes, > as in cases where there is only a single directly-attached > computer, or the user has been noticing problems with one of > their computers, this can be easy. Other times, it may be more > difficult. If the user is behind a home gateway/router, then the > first task may be to ascertain which of the machines is infected. > In some cases the user may have to check all machines to identify > the infected one. > > 6. User surveys to solicit feedback on whether the notification and > remediation process is effective and what recommended changes > could be made in order to improve the ease, understandability, > and effectiveness the remediation process. > > 7. If the user is interested in reporting his or her computer's bot > infection to an applicable law enforcement authority, then the > computer effectively becomes a cyber "crime scene" and should not > be mitigated unless or until law enforcement has collected the > necessary evidence. For individuals in this situation, the ISP > should refer them to local, state, federal, or other relevant > > > > Livingood, et al. Expires August 16, 2010 [Page 19] > > Internet-Draft Remediation of Bots in ISP Networks February 2010 > > > computer crime offices. (Note: Some "minor" incidents, even if > highly traumatic to the user, may not be sufficiently serious for > law enforcement to commit some of their limited resources to an > investigation.) In addition, individual regions may have other, > specialized computer crime organizations to which these incidents > can be reported. For example, in the United States, that > organization is the Internet Crime Complaint Center, at > http://www.ic3.gov. > > 8. Users may also be interested in links to security expert forums, > where other users can assist them. > > > 9. Professionally-Assisted Remediation Process > > It should be acknowledged that, based on the current state of > remediation tools and the technical abilities of end users, that many > users may be unable to remediate on their own. As a result, it is > recommended that users have the option to avail themselves of > professional assistance. This may entail online or telephone > assistance for remediation, as well as working face to face with a > professional who has training and expertise in the removal of > malware. This can be recommended but shouldn't be part of an "upsell" as that could = be seen as potential revenue. > > > 10. Sharing of Data from the User to the ISP > > As an additional consideration, it may be useful to create a process > by which users could choose, at their option and with their express > consent, to share data regarding their bot infection with their ISP > and/or another authorized third party. Such third parties may > include governmental entities that aggregate threat data, such as the > Internet Crime Complaint Center referred to earlier in this document, > to academic institutions, and/or security researchers. While in many > cases the information shared with the user's ISP or designated third > parties will only be used for aggregated statistical analysis, it is > also possible that certain research needs may be best met with more > detailed data. Thus, any such data sharing from a user to the ISP or > authorized third party may contain some type of personally > identifiable information, either by design or inadvertently. As a > result, any such data sharing must be enabled on an opt-in based, > where users review and approve of the data being shared and the > parties with which it is to be shared. Unless the ISP is already required to provide said information due local la= ws or judicial requirements (subpoena)... > > > 11. Security Considerations > > This document describes in detail the numerous security risks and > > > > Livingood, et al. Expires August 16, 2010 [Page 20] > > Internet-Draft Remediation of Bots in ISP Networks February 2010 > > > concerns relating to bot nets. As such, it has been appropriate to > include specific information about security in each section above. > This document describes the security risks related to malicious bot > infections themselves, such as enabling identity theft, theft of > authentication credentials, and the use of a computer to unwittingly > participate in a DDoS attack, among many other risks. This document > also describes at a high level the activities that ISPs should be > sensitive to, where the collection or communication of PII may be > possible. Finally, the document also describes security risks which > may relate to the particular methods of communicating a notification > to Internet users. Bot networks and bot infections pose extremely > serious security risks and any reader should review this document > carefully. > > In addition, regarding notifications, as described in the Section 6, > care should be taken to assure users that notifications have been > provided by a trustworthy site and/or party, so that the notification > is more difficult for phishers to mimic, or that the user has some I think you are talking social engineers not phishers. > level of trust that the notification is valid, and/or that the user > has some way to verify via some other mechanism or step that the > notification is valid. > > Lastly, as noted in Section 10, any sharing of data from the User to > the ISP and/or authorized third parties must be done on an opt-in > basis and with a clear by the user of the data to be shared and with > whom it is to be shared. > > > 12. IANA Considerations > > There are no IANA considerations in this document. > > > 13. Acknowledgements > > The authors wish to acknowledge the following individuals for > performing a detailed review of this document and/or providing > comments and feedback with had helped to improve and evolve this > document: > > Mark Baugher > > Richard Bennett > > James Butler > > Vint Cerf > > > > > Livingood, et al. Expires August 16, 2010 [Page 21] > > Internet-Draft Remediation of Bots in ISP Networks February 2010 > > > Alissa Cooper > > Jonathan Curtis > > Jeff Chan > > Roland Dobbins > > Dave Farber > > Eliot Gillum > > Joel Halpern > > Scott Keoseyan > > The Messaging Anti-Abuse Working Group (MAAWG) > > Jose Nazario > > Gunter Ollmann > > David Reed > > Joe Stewart > > Forrest Swick > > Robb Topolski > > Eric Ziegast > > > 14. Informative references > > [Battling Botnets and Online Mobs: Estonia's Defense Efforts during > the Internet War] > Evron, G., "Battling Botnets and Online Mobs: Estonia's > Defense Efforts during the Internet War", May 2005, //docs.google.com/ > gview?a=3Dv& > q=3Dcache%3AbyUMj6Djlb8J%3Awww.ciaonet.org%2Fjournals% > 2Fgjia%2Fv9i1%2F0000699.pdf>. > > [Case Study: How a Bookmaker and a Whiz Kid Took On a DDOS-based > Online Extortion Attack] > Berinato, S., "Case Study: How a Bookmaker and a Whiz Kid > Took On a DDOS-based Online Extortion Attack", May 2005, < > > > > Livingood, et al. Expires August 16, 2010 [Page 22] > > Internet-Draft Remediation of Bots in ISP Networks February 2010 > > > http://www.csoonline.com/article/220336/ > How_a_Bookmaker_and_a_Whiz_Kid_Took_On_a_DDOS_based_Online > _Extortion_Attack>. > > [Cyberspace as a Combat Zone: The Phenomenon of Electronic Jihad] > Alshech, E., "Cyberspace as a Combat Zone: The Phenomenon > of Electronic Jihad", February 2007, www.memrijttm.org/content/en/report.htm?report=3D1822>. > > [Emerging Cyber Threats Report for 2009: Data, Mobility and Questions > of Responsibility will Drive Cyber Threats in 2009 and Beyond] > Ahamad, M., Amster, D., Barret, M., Cross, T., Heron, G., > Jackson, D., King, J., Lee, W., Naraine, R., Ollman, G., > Ramsey, J., Schmidt, H., and P. Traynor, "Emerging Cyber > Threats Report for 2009: Data, Mobility and Questions of > Responsibility will Drive Cyber Threats in 2009 and > Beyond", October 2008, bitstream/1853/26301/1/CyberThreatsReport2009.pdf>. > > [Persistent BIOS Infection] > Sacco, A. and A. Ortega, "Persistent BIOS Infection", > March 2009, attachments/Persistent_BIOS_Infection_CanSecWest09.pdf>. > > [RFC1459] Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol", > RFC 1459, May 1993. > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. > > [RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND > FUNCTIONS", RFC 2142, May 1997. > > [RFC3954] Claise, B., "Cisco Systems NetFlow Services Export Version > 9", RFC 3954, October 2004. > > [Spamalytics: An Empirical Analysis of Spam Marketing Conversion] > Kanich, C., Kreibich, C., Levchenko, K., Enright, B., > Voelker, G., Paxson, V., and S. Savage, "Spamalytics: An > Empirical Analysis of Spam Marketing Conversion", > October 2008, 2008-ccs-spamalytics.pdf>. > > [The Gh0st in the Shell: Network Security in the Himalayas] > Vallentin, M., Whiteaker, J., and Y. Ben-David, "The Gh0st > in the Shell: Network Security in the Himalayas", > February 2010, uploads/2010/02/cs294-28-paper.pdf>. > > > > Livingood, et al. Expires August 16, 2010 [Page 23] > > Internet-Draft Remediation of Bots in ISP Networks February 2010 > > > [The snooping dragon: social-malware surveillance of the Tibetan > movement] > Nagaraja, S. and R. Anderson, "The snooping dragon: > social-malware surveillance of the Tibetan movement", > March 2009, > . > > > Appendix A. Document Change Log > > [RFC Editor: This section is to be removed before publication] > > -07 version: > > o Corrected various spelling and grammatical errors, pointed out by > additional reviewers. Also added a section on information flowing > from the user. Lastly, updated the reviewer list to include all > those who either were kind enough to review for us or who provided > interesting, insightful, and/or helpful feedback. > > -06 version: > > o Corrected an error in the version change log, and added some extra > information on user remediation. Also added an informational > reference to BIOS infection. > > -05 version: > > o Minor tweaks made by Jason - ready for wider review and next > steps. Also cleared open issues. Lastly, added 2nd paragraph to > security section and added sections on limitations relating to > public and other shared network sites. Added a new section on > professional remediation. > > -04 version: > > o Updated reference to BIOS based malware, added wording on PII and > local jurisdictions, added suggestion that industry body produce > bot stats, added suggestion that ISPs use volunteer forums > > -03 version: > > o all updates from Jason - now ready for wider external review > > -02 version: > > o all updates from Jason - still some open issues but we're now at a > place where we can solicit more external feedback > > > > Livingood, et al. Expires August 16, 2010 [Page 24] > > Internet-Draft Remediation of Bots in ISP Networks February 2010 > > > -01 version: > > o -01 version published > > > Appendix B. Open Issues > > [RFC Editor: This section is to be removed before publication] > > A question has been raised about whether this should change from > Informational to BCP. > > > Authors' Addresses > > Jason Livingood > Comcast Cable Communications > One Comcast Center > 1701 John F. Kennedy Boulevard > Philadelphia, PA 19103 > US > > Email: jason_livingood@cable.comcast.com > URI: http://www.comcast.com > > > Nirmal Mody > Comcast Cable Communications > One Comcast Center > 1701 John F. Kennedy Boulevard > Philadelphia, PA 19103 > US > > Email: nirmal_mody@cable.comcast.com > URI: http://www.comcast.com > > > Mike O'Reirdan > Comcast Cable Communications > One Comcast Center > 1701 John F. Kennedy Boulevard > Philadelphia, PA 19103 > US > > Email: michael_oreirdan@cable.comcast.com > URI: http://www.comcast.com > > > > > > Livingood, et al. Expires August 16, 2010 [Page 25] Donald.Smith@qwest.com (coffee !=3D sleep) & (!coffee =3D=3D sleep) This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From jason_livingood@cable.comcast.com Mon Feb 15 13:45:53 2010 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E4333A7A49 for ; Mon, 15 Feb 2010 13:45:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.098 X-Spam-Level: X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[AWL=1.297, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CD9Eni1quAWL for ; Mon, 15 Feb 2010 13:45:52 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id B4DE03A78F3 for ; Mon, 15 Feb 2010 13:45:51 -0800 (PST) Received: from ([10.52.116.31]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.72467123; Mon, 15 Feb 2010 16:47:19 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Feb 2010 16:47:20 -0500 Received: from 147.191.227.88 ([147.191.227.88]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.153]) with Microsoft Exchange Server HTTP-DAV ; Mon, 15 Feb 2010 21:47:19 +0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Mon, 15 Feb 2010 16:47:13 -0500 From: Jason Livingood To: Joel Jaeggli , Danny McPherson Message-ID: Thread-Topic: [OPSEC] Fwd: Last Call for Comments: draft-oreirdan-mody-bot-remediation-06 Thread-Index: AcquiG66JjjDcV4erkiv8c9LHiHOxA== In-Reply-To: <4B787D3A.70905@bogus.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 15 Feb 2010 21:47:20.0252 (UTC) FILETIME=[730D57C0:01CAAE88] X-Mailman-Approved-At: Mon, 15 Feb 2010 20:41:43 -0800 Cc: Nirmal Mody , opsec wg mailing list , Mike O'Reirdan Subject: Re: [OPSEC] Fwd: Last Call for Comments: draft-oreirdan-mody-bot-remediation-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 21:45:53 -0000 Inline below=20 Thanks for the detailed review!! Jason On 2/14/10 5:46 PM, "Joel Jaeggli" wrote: > just some comments that came to mind. >=20 > Section 2.3 > I find the term computer somewhat ambiguous in this context, though I > understand the meaning that the author intended. The ietf has a long > history with the term's host and router and I think we should =20 > generally prefer those terms even when they apply to the same device. Thanks for raising that. I have noted it as an open item on the draft and intend to discuss it with my co-authors. =20 > section 5 bullet a > The other problem with ports scan is simply that in the case of nated > devices or stateful firewalls, either host or network based impose a > barrier to the utility of vulnerability/nac methods based on open ports Good point, and I plan to add to that section the following (feel free to suggest changes): "It should also be noted that due to the prevalence of Network Address Translation devices, Port Address Translation devices, and/or firewall devices in user networks, network-based vulnerability scanning may be of limited value." > To the extent systems are running unauthorized listening services as a > product of bot infection, that's a detection of the hosts currently > infected state rather than it's vulnerability to attack. fingerprint of > applications is necessarily more complex that simply port scanning and > in particular home gateways with upnp service may result multiple > systems being jumbled together in a port scan. Fair enough, so I modified the first sentence as follows: "... an ISP may in some manner "scan" their IP space in order to detect un-patched or otherwise vulnerable hosts, or to detect the signs of infection. This may provide the ISP with the opportunity to easily identify Internet users who appear to already be infected or are at great risk of being infected with a bot. " >=20 > section 6 > "This record should only be maintained for a period of time which is > necessary, in order to maintain the protection of the privacy of an > individual subscriber." >=20 > as noted in some other sections there my be statutory requirements that > apply to the consideration of how long such data is retained or not as > the case may be. I've added an additional point in the security section as follows: "Lastly, as noted in some other sections, there my be legal requirements in particular legal jurisdictions concerning how long any subscriber-related o= r other data is retained, of which an ISP operating in such a jurisdiction must be aware and with which an ISP must comply." >=20 > section 8 bullet 2 >=20 > these urls while provided for the purpose of examples are unlikely to > be stable on any kind of long timescale. fundamently updating os > software addresses vulnerability not remediation (windows malcious > software removal tool notwithstanding) I've tagged this on our open issues list as well, and we'll determine how t= o address that in the next revision. > bullets 4-7 >=20 > It's unclear how these steps are even feasible to undertake for > organizations nominally characterized as ISPs. there's a several > thousand fold cost differential between automated help and remediation > by sending a train proessional to lay hands on one computer. As above, tagged on our open issues list. >=20 > Danny McPherson wrote: >>=20 >> If you've not seen it.. >>=20 >> -danny >>=20 >> Begin forwarded message: >>=20 >>> *From: *Jason Livingood >> > *Date: *February 11, >>> 2010 12:50:20 PM MST *To: *"ietf@ietf.org " >>> > *Subject: **Last Call for >>> Comments: draft-oreirdan-mody-bot-remediation-06* >>>=20 >>> A few months ago, I asked for comments on an individual draft >>> regarding the remediation of malicious bots on ISP networks. I and >>> my co-authors have incorporated all feedback received into the >>> latest revision of this draft at >>> http://tools.ietf.org/html/draft-oreirdan-mody-bot-remediation-06. >>> I=B9d like to call one last time for any comments people may have >>> regarding this draft, before we close the book on it. >>>=20 >>> If you have any comments, please send them to me privately for >>> consideration. >>>=20 >>> Thank you, Jason >>>=20 >>> _______________________________________________ Ietf mailing list >>> Ietf@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf >>=20 >>=20 >> ------------------------------------------------------------------------ >>=20 >>=20 >> _______________________________________________ OPSEC mailing list >> OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From jabley@hopcount.ca Wed Feb 17 21:39:44 2010 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 408263A7BFC for ; Wed, 17 Feb 2010 21:39:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aJIy-FNiLJC for ; Wed, 17 Feb 2010 21:39:43 -0800 (PST) Received: from monster.hopcount.ca (monster.hopcount.ca [216.235.14.38]) by core3.amsl.com (Postfix) with ESMTP id 8E7283A73B2 for ; Wed, 17 Feb 2010 21:39:43 -0800 (PST) Received: from [72.254.59.11] (helo=[10.77.215.178]) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NhzAg-000Dsk-IB; Thu, 18 Feb 2010 05:43:31 +0000 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Joe Abley In-Reply-To: <92c950311002141945q47aa1c5ch91391e13138619b3@mail.gmail.com> Date: Wed, 17 Feb 2010 21:41:19 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <84415894-1ED0-41C7-B463-2527750E77E4@hopcount.ca> References: <4B29DEE9.1090202@bogus.com> <4B42CFCC.3030501@bogus.com> <4B4BF40E.4050606@bogus.com> <92c950311002141945q47aa1c5ch91391e13138619b3@mail.gmail.com> To: Glen Kent X-Mailer: Apple Mail (2.1077) X-SA-Exim-Connect-IP: 72.254.59.11 X-SA-Exim-Mail-From: jabley@hopcount.ca X-SA-Exim-Scanned: No (on monster.hopcount.ca); SAEximRunCond expanded to false Cc: "opsec@ietf.org" Subject: Re: [OPSEC] (deadline for last call is 1/7/10) Working Group last call for draft-ietf-opsec-routing-protocols-crypto-issues-02 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 05:39:44 -0000 On 2010-02-14, at 19:45, Glen Kent wrote: > Any update on this draft, has it been submitted to the IESG? I see > that the -03 version was posted long time back which takes care of my > comments. This is me being slow due to non-IETF distractions. Many apologies; I = will endeavour to get the write-up completed and submitted before the = weekend. Joe From fernando@gont.com.ar Sat Feb 20 02:14:32 2010 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDC8E3A7F0C for ; Sat, 20 Feb 2010 02:14:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.145 X-Spam-Level: X-Spam-Status: No, score=-3.145 tagged_above=-999 required=5 tests=[AWL=0.454, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CeswMh9lpYX7 for ; Sat, 20 Feb 2010 02:14:31 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id C46A63A7EFD for ; Sat, 20 Feb 2010 02:14:29 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 94FAD6B680A; Sat, 20 Feb 2010 07:16:18 -0300 (ART) Received: from [192.168.0.100] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o1KAGFIu030627; Sat, 20 Feb 2010 07:16:15 -0300 Message-ID: <4B7FB66C.3020404@gont.com.ar> Date: Sat, 20 Feb 2010 07:16:12 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "'opsec@ietf.org'" X-Enigmail-Version: 0.96.0 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Sat, 20 Feb 2010 07:16:17 -0300 (ART) Subject: [OPSEC] Revision of the ip-security I-D X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2010 10:14:32 -0000 Folks, FYI, I have just posted a rev of the ip-security I-D, as the draft was going to expire tomorrow, and I had already applied quite a few changes that deserved a rev. I'm still working on some changes proposed by Alfred as part of the WGLC, and should be able to submit another rev (that addresses all of Alfred comments) next week. Thanks! Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From root@core3.amsl.com Sat Feb 20 02:15:02 2010 Return-Path: X-Original-To: opsec@ietf.org Delivered-To: opsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id EAE833A80FA; Sat, 20 Feb 2010 02:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100220101501.EAE833A80FA@core3.amsl.com> Date: Sat, 20 Feb 2010 02:15:01 -0800 (PST) Cc: opsec@ietf.org Subject: [OPSEC] I-D Action:draft-ietf-opsec-ip-security-02.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2010 10:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operational Security Capabilities for IP Network Infrastructure Working Group of the IETF. Title : Security Assessment of the Internet Protocol version 4 Author(s) : F. Gont Filename : draft-ietf-opsec-ip-security-02.txt Pages : 74 Date : 2010-02-20 This document contains a security assessment of the IETF specifications of the Internet Protocol version 4, and of a number of mechanisms and policies in use by popular IPv4 implementations. It is based on the results of a project carried out by the UK's Centre for the Protection of National Infrastructure (CPNI). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opsec-ip-security-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-opsec-ip-security-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-02-20021211.I-D@ietf.org> --NextPart-- From rodunn@cisco.com Tue Feb 23 12:57:40 2010 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5DDF3A84F0 for ; Tue, 23 Feb 2010 12:57:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PV6XW2tswH0e for ; Tue, 23 Feb 2010 12:57:40 -0800 (PST) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id 025A03A72CE for ; Tue, 23 Feb 2010 12:57:39 -0800 (PST) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o1NKxgO5016813; Tue, 23 Feb 2010 15:59:42 -0500 (EST) Received: from dhcp-64-102-221-233.cisco.com (dhcp-64-102-221-233.cisco.com [64.102.221.233]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o1NKxgNv001203; Tue, 23 Feb 2010 15:59:42 -0500 (EST) Message-ID: <4B8441BE.1010803@cisco.com> Date: Tue, 23 Feb 2010 15:59:42 -0500 From: Rodney Dunn Organization: Cisco Systems Inc. User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: opsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-dugal-opsec-protect-control-plane@tools.ietf.org Subject: [OPSEC] New Version Notification for draft-dugal-opsec-protect-control-plane-02 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: rodunn@cisco.com List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 20:57:40 -0000 Thanks for all the feedback that has been provided on the document so far. We have published a revision -02 that incorporates the feedback both on and off the list. Rodney http://tools.ietf.org/html/draft-dugal-opsec-protect-control-plane-02 A new version of I-D, draft-dugal-opsec-protect-control-plane-02.txt has been successfuly submitted by Rodney Dunn and posted to the IETF repository. Filename: draft-dugal-opsec-protect-control-plane Revision: 02 Title: Protecting The Router Control Plane Creation_date: 2010-02-23 WG ID: Independent Submission Number_of_pages: 13 Abstract: This memo provides a method for protecting a router's control plane from undesired or malicious traffic. In this approach, all legitimate control plane traffic is identifed. Once legitimate traffic has been identified, a filter is deployed on the router's forwarding plane. That filter prevents traffic not specifically identified as legitimate from reaching the router's control plane.