From opsec-bounces@ietf.org Sat Aug 2 20:16:25 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E4843A69BD; Sat, 2 Aug 2008 20:16:25 -0700 (PDT) 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 785B43A6991 for ; Sat, 2 Aug 2008 20:16:24 -0700 (PDT) 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=[AWL=0.000, 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 c1GdFBaJnjfe for ; Sat, 2 Aug 2008 20:16:23 -0700 (PDT) Received: from monster.hopcount.ca (monster.hopcount.ca [199.212.90.4]) by core3.amsl.com (Postfix) with ESMTP id 4A1513A69E7 for ; Sat, 2 Aug 2008 20:16:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=monster; d=ca.afilias.info; h=Received:Cc:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer; b=jiL58RbTIBaLTmqsr6usbvEIDbKJywe4mEgRl5nAOiesNNjJNPydOkwP/LO5LF8+evCxclo0pecbJ5vuPPeYdgkMmE8Cmgv4hpLh1LR+yDx/0UlmE2BwFBOSe5famPvE; Received: from [130.129.23.132] (helo=shiny.meeting.ietf.org) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOXYM-0009zB-CD; Thu, 31 Jul 2008 12:46:55 +0000 Message-Id: From: Joe Abley To: Fernando Gont In-Reply-To: <200807301748.m6UHmBm1000969@venus.xmundo.net> Mime-Version: 1.0 (Apple Message framework v926) Date: Thu, 31 Jul 2008 13:46:43 +0100 References: <61BF1842-7DC2-49EA-9DE5-AE62AE2CED82@ca.afilias.info> <200807301748.m6UHmBm1000969@venus.xmundo.net> X-Mailer: Apple Mail (2.926) Cc: opsec@ietf.org Subject: Re: [OPSEC] draft minutes for opsec meeting today 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org On 30 Jul 2008, at 18:43, Fernando Gont wrote: > At 02:32 p.m. 30/07/2008, Joe Abley wrote: > >> Please see attached. Please send comments/corrections to the list, or >> to me directly. > > In a number of places the minutes say "Draft-gony-opsec-icmp- > filtering" instead of "Draft-gont-opsec-icmp-filtering" (that is, my > surname is "gont", and not "gony"). Fixed, thanks and sorry :-) Joe _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Sat Aug 2 20:16:26 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6621B3A69F6; Sat, 2 Aug 2008 20:16:26 -0700 (PDT) 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 ED7B53A69BD for ; Sat, 2 Aug 2008 20:16:24 -0700 (PDT) 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 4iQwsMPQSiNs for ; Sat, 2 Aug 2008 20:16:23 -0700 (PDT) Received: from monster.hopcount.ca (monster.hopcount.ca [199.212.90.4]) by core3.amsl.com (Postfix) with ESMTP id D18B53A69D6 for ; Sat, 2 Aug 2008 20:16:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=monster; d=ca.afilias.info; h=Received:Message-Id:From:To:In-Reply-To:Content-Type:Mime-Version:Subject:Date:References:X-Mailer; b=fmfVGQryZP5B+s9cisaCmBjM380qWgiBxdGhG6QLd6hYY9xhJ6Z2dILuedMwsuMpkOP8pB/cMO+Iz4GEpQ6RMZ2slXVTT+083fnN431BGDpjF00Tt726EwHU1oSQcYAQ; Received: from [130.129.23.132] (helo=shiny.meeting.ietf.org) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOXaM-0009zf-44 for opsec@ietf.org; Thu, 31 Jul 2008 12:48:51 +0000 Message-Id: <6FA17FAC-7174-4E24-A336-F7067986B579@ca.afilias.info> From: Joe Abley To: opsec@ietf.org In-Reply-To: <61BF1842-7DC2-49EA-9DE5-AE62AE2CED82@ca.afilias.info> Content-Type: multipart/mixed; boundary=Apple-Mail-2-830642647 Mime-Version: 1.0 (Apple Message framework v926) Date: Thu, 31 Jul 2008 13:48:47 +0100 References: <61BF1842-7DC2-49EA-9DE5-AE62AE2CED82@ca.afilias.info> X-Mailer: Apple Mail (2.926) Subject: Re: [OPSEC] draft minutes for opsec meeting today 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: , Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org --Apple-Mail-2-830642647 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 30 Jul 2008, at 18:32, Joe Abley wrote: > Please see attached. Please send comments/corrections to the list, > or to me directly. Second cut attached. Joe --Apple-Mail-2-830642647 Content-Disposition: attachment; filename=opsec-ietf72-1.txt Content-Type: text/plain; x-unix-mode=0644; name="opsec-ietf72-1.txt" Content-Transfer-Encoding: 7bit Minutes of the OPSEC meeting IETF 72, Dublin, Ireland 2008-07-30 1510 UTC+1 Note-taker: jabley Jabber proxy: jabley (no jabber scribe) The meeting opened at 1518 UTC+1. 1. Joel Jaeggli, OPSEC WG Joel Gaeggli presented on the working group rechartering and document status. There is fatigue on existing milestones, and abandonment with recharter is a more pragmatic way forward than closing the working group and chartering a new one. The new charter has passed working group last call and has been sent to the IESG. Milestones on the new charter are a bit thin. We want to keep the working group to bring problems from the network operations space into. ron bonica: charter has changed -- no longer to do with requirements for vendors, now to do with BCP for operators. Old documents should be allowed to wither on the vine. An alternative might be to fold this work into OPSAWG. dan romanescu: conscious decision to keep opsec separate from opsawg in order to separate and maintain focus on the security aspects There are two new potential work items from Warren Kumari on blackhole communities. danny mcpherson: comment on warren's blackhole draft; many isps use different communities for different kinds of blackholes, different places to drop packets, etc Draft-gont-opsec-icmp-filtering is a draft which has seen positive discussion on the mailing list. mohacsi janos: similar draft for v6 icmp fltering, around rfc 4890. I think the author should consider looking at this draft. There was a strong hum for adopting draft-gont-opsec-icmp-filtering as a working group document. There was no hum in dissent. The author was encouraged to resubmit the draft as an opsec working group document. 2. SAVI Overview, Christian Vogt Christian Vogt provided an overview of the problem space and approach for work starting in the SAVI working group. There was no discussion from the floor. 3. draft-savola-rtgwg-backbone-attacks-03, Pekka Savola Pekka Savola provided a brief history of this draft. merike kaeo: totally support this work, and think it would be perfect as an informational document joel jaeggli: no hat, read this document the first time around, a little while ago, think it is a really useful document, some freshening required, but appropriate under our new charter christian vogt: if not in opsec, where else? pekka: if not in opsec, probably not in ietf christian: I support it to be published in this group ron bonica: thumbs up joel: will need to seek consensus on list lucy lynch: I have read it a while ago, read it again this this morning, some of this is a moving target; may require regular refreshment joel: I wouldn't imagine it being more than informational. will require routine updates or an understanding that like fish security recommendations do start to smell bad after a while. william dixon: section 3.5 refers to ipsec and ike that is just really commentary, and I am not sure what to conclude from it. example of commentary. draft needs some work to provide concrete recommendations of work joel: also some things that require conclusions michael behring: good work, stuff that people should read, find difficult that the purpose is a bit of threat, a bit of countermeasures. would be good to have a clearer idea of what the goal of the document is. joe abley: seems to me there is room in the charter for informational travelogues on security as well as BCPs. merike: operational people are always told what to do but not why. I like Pekka's doc because it describes potential security issues along with tradeoffs for some solutions. It will help operators pick appropriate solutions in their environments since none of them individually is a silver bullet to solve all problems. pekka: intent: if it's 15 pages or more, if it's too long. some attack or countermeasure requires mengthy description, probably referred somewhere else. so tried to be concise. michael: I really like that. I also see merike's point. the danger is that you take the countermeasures out and just leave the list, which means the list needs to be more concise. joel: should close it here so we can get the remaining presentations in. when we look for consensus on the list, document might benefit from additional authors. people who like the document should consider helping out with it. 4. draft-ietf-rpsec-bgp-session-sec-req-01, Michael Behring Michael Behring gave an overview of the structure of this document, which was previously a work item in the RPSEG working group. joel: seems likely that opsec people would have things to say about this ron: this does give value, think it's appropriate merike: think work is appropriate, but was involved in rpsec and don't think there are enough people in this group that understand enough bgp potentially to come up with requirements. joel: agree with merike on that; control plane security is one element of that but the protocol itself is the other piece and I think that's slightly less core here pekka: observation here is proposed charter, bcp problem statements, taxonomies, etc. requirements explicitly out of scope. sandy murphy: I recall reading very long ago versions of your draft and versions of pekka' sdraft, and saw in your outline some items that I thought might also be included in pekka's. infrastructure hiding, for example? michael: yeah, but really compeltely different scope. lucy: to follow up on what joel was saying, cross-area review and strong support that document should continue joe: advice to operators on how to secure routers would be a clearer fit for the charter joel: maybe an additional document michael: I will continue in the routing area, and maybe return here with a BCP. 5. Any Other Business There was no other business. 6. Adjournment The meeting was closed at 1620 UTC+1. --Apple-Mail-2-830642647 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-2-830642647 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec --Apple-Mail-2-830642647-- From opsec-bounces@ietf.org Mon Aug 4 08:23:56 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2E9B3A6BAE; Mon, 4 Aug 2008 08:23:55 -0700 (PDT) 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 C24FC3A6CCA for ; Mon, 4 Aug 2008 08:23:54 -0700 (PDT) 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 qzOl-s8IhqRE for ; Mon, 4 Aug 2008 08:23:53 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 45A663A6C66 for ; Mon, 4 Aug 2008 08:23:52 -0700 (PDT) Received: from [172.168.1.101] (adsl-76-204-79-54.dsl.pltn13.sbcglobal.net [76.204.79.54]) (authenticated bits=0) by nagasaki.bogus.com (8.14.2/8.14.2) with ESMTP id m74FNtPO063133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 4 Aug 2008 15:23:56 GMT (envelope-from joelja@bogus.com) Message-ID: <48971F0A.4070604@bogus.com> Date: Mon, 04 Aug 2008 08:23:54 -0700 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Joe Abley References: <61BF1842-7DC2-49EA-9DE5-AE62AE2CED82@ca.afilias.info> <6FA17FAC-7174-4E24-A336-F7067986B579@ca.afilias.info> In-Reply-To: <6FA17FAC-7174-4E24-A336-F7067986B579@ca.afilias.info> X-Enigmail-Version: 0.95.6 Content-Type: multipart/mixed; boundary="------------090900030203000709030001" X-Virus-Scanned: ClamAV 0.93.1/7935/Mon Aug 4 12:58:49 2008 on nagasaki.bogus.com X-Virus-Status: Clean Cc: opsec@ietf.org Subject: Re: [OPSEC] draft minutes for opsec meeting today 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: , Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org This is a multi-part message in MIME format. --------------090900030203000709030001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit minor changes attached. joelja Joe Abley wrote: > > On 30 Jul 2008, at 18:32, Joe Abley wrote: > >> Please see attached. Please send comments/corrections to the list, or >> to me directly. > > Second cut attached. > > > Joe > > > ------------------------------------------------------------------------ > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec --------------090900030203000709030001 Content-Type: text/plain; name="opsec-ietf72-2.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="opsec-ietf72-2.txt" Minutes of the OPSEC meeting IETF 72, Dublin, Ireland 2008-07-30 1510 UTC+1 Note-taker: jabley Jabber proxy: jabley (no jabber scribe) The meeting opened at 1518 UTC+1. 1. Joel Jaeggli, OPSEC WG Joel Jaeggli presented on the working group rechartering and document status. There is fatigue on existing milestones, and abandonment with recharter is a more pragmatic way forward than closing the working group and chartering a new one. The new charter has passed working group last call and has been sent to the IESG. Milestones on the new charter are a bit thin. We want to keep the working group around to bring problems from the network operations space into. Ron Bonica: charter has changed -- no longer to do with requirements for vendors, now to do with BCP for operators. Old documents should be allowed to wither on the vine. Joel: An alternative might be to fold this work into OPSAWG. Dan Romanescu: conscious decision to keep opsec separate from opsawg in order to separate and maintain focus on the security aspects There are two new potential work items from Warren Kumari on blackhole communities. Danny Mcpherson: comment on warren's blackhole draft; many isps use different communities for different kinds of blackholes, different places to drop packets, etc draft-gont-opsec-icmp-filtering is a draft which has seen positive discussion on the mailing list. Mohacsi Janos: similar draft for v6 icmp fltering, around rfc 4890. I think the author should consider looking at this draft. Joel: reconciling the two is desirable There was a strong hum for adopting draft-gont-opsec-icmp-filtering as a working group document. There was no hum in dissent. The author was encouraged to resubmit the draft as an opsec working group document. 2. SAVI Overview, Christian Vogt Christian Vogt provided an overview of the problem space and approach for work starting in the SAVI working group. There was no discussion from the floor. 3. draft-savola-rtgwg-backbone-attacks-03, Pekka Savola Pekka Savola provided a brief history of this draft. Merike Kaeo: totally support this work, and think it would be perfect as an informational document Joel Jaeggli: no hat, read this document the first time around, a little while ago, think it is a really useful document, some freshening required, but appropriate under our new charter Christian Vogt: if not in opsec, where else? Pekka: if not in opsec, probably not in IETF Christian: I support it to be published in this group Ron Bonica: thumbs up Joel: will need to seek consensus on list Lucy Lynch: I have read it a while ago, read it again this this morning, some of this is a moving target; may require regular refreshment Joel: I wouldn't imagine it being more than informational. will require routine updates or an understanding that like fish security recommendations do start to smell bad after a while. William Dixon: section 3.5 refers to ipsec and ike that is just really commentary, and I am not sure what to conclude from it. example of commentary. draft needs some work to provide concrete recommendations of work Joel: also some things that require conclusions Michael Behring: good work, stuff that people should read, find difficult that the purpose is a bit of threat, a bit of countermeasures. would be good to have a clearer idea of what the goal of the document is. Joe Abley: seems to me there is room in the charter for informational travelogues on security as well as BCPs. Merike: operational people are always told what to do but not why. I like Pekka's doc because it describes potential security issues along with tradeoffs for some solutions. It will help operators pick appropriate solutions in their environments since none of them individually is a silver bullet to solve all problems. Pekka: Intent, if it's 15 pages or more, if it's too long. some attack or countermeasure requires lengthy description, probably referred somewhere else. so tried to be concise. Michael: I really like that. I also see Merike's point. the danger is that you take the countermeasures out and just leave the list, which means the list needs to be more concise. Joel: Should close it here so we can get the remaining presentations in. when we look for consensus on the list, document might benefit from additional authors. People who like the document should consider helping out with it. 4. draft-ietf-rpsec-bgp-session-sec-req-01, Michael Behring Michael Behring gave an overview of the structure of this document, which was previously a work item in the RPSEG working group. joel: Seems likely that opsec people would have things to say about this Ron: this does give value, think it's appropriate Merike: Think work is appropriate, but was involved in rpsec and don't think there are enough people in this group that understand enough bgp potentially to come up with requirements. Joel: Agree with merike on that; control plane security is one element of that but the protocol itself is the other piece and I think that's slightly less core here. Pekka: observation here is proposed charter, bcp problem statements, taxonomies, etc. requirements explicitly out of scope. Sandy Murphy: I recall reading very long ago versions of your draft and versions of Pekka' sdraft, and saw in your outline some items that I thought might also be included in Pekka's. Infrastructure hiding, for example? Michael: yeah, but really compeltely different scope. Lucy: To follow up on what joel was saying, cross-area review and strong support that document should continue Joe: advice to operators on how to secure routers would be a clearer fit for the charter Joel: maybe an additional document Michael: I will continue in the routing area, and maybe return here with a BCP. 5. Any Other Business There was no other business. 6. Adjournment The meeting was closed at 1620 UTC+1. --------------090900030203000709030001 Content-Type: text/x-patch; name="opsec-ietf72-2v1.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="opsec-ietf72-2v1.diff" --- opsec-ietf72-1.txt 2008-08-04 08:04:01.000000000 -0700 +++ opsec-ietf72-2.txt 2008-08-04 08:21:21.000000000 -0700 @@ -11,39 +11,41 @@ 1. Joel Jaeggli, OPSEC WG -Joel Gaeggli presented on the working group rechartering and document +Joel Jaeggli presented on the working group rechartering and document status. There is fatigue on existing milestones, and abandonment with recharter is a more pragmatic way forward than closing the -working group and chartering a new one. +working group and chartering a new one. The new charter has passed working group last call and has been sent to the IESG. Milestones on the new charter are a bit thin. We want to keep the working -group to bring problems from the network operations space into. +group around to bring problems from the network operations space into. -ron bonica: charter has changed -- no longer to do with requirements for +Ron Bonica: charter has changed -- no longer to do with requirements for vendors, now to do with BCP for operators. Old documents should be allowed to wither on the vine. -An alternative might be to fold this work into OPSAWG. +Joel: An alternative might be to fold this work into OPSAWG. -dan romanescu: conscious decision to keep opsec separate from opsawg in +Dan Romanescu: conscious decision to keep opsec separate from opsawg in order to separate and maintain focus on the security aspects There are two new potential work items from Warren Kumari on blackhole communities. -danny mcpherson: comment on warren's blackhole draft; many isps use +Danny Mcpherson: comment on warren's blackhole draft; many isps use different communities for different kinds of blackholes, different places to drop packets, etc -Draft-gont-opsec-icmp-filtering is a draft which has seen positive discussion +draft-gont-opsec-icmp-filtering is a draft which has seen positive discussion on the mailing list. -mohacsi janos: similar draft for v6 icmp fltering, around rfc 4890. +Mohacsi Janos: similar draft for v6 icmp fltering, around rfc 4890. I think the author should consider looking at this draft. +Joel: reconciling the two is desirable + There was a strong hum for adopting draft-gont-opsec-icmp-filtering as a working group document. There was no hum in dissent. The author was encouraged to resubmit the draft as an opsec working group @@ -61,63 +63,63 @@ Pekka Savola provided a brief history of this draft. -merike kaeo: totally support this work, and think it would be perfect +Merike Kaeo: totally support this work, and think it would be perfect as an informational document -joel jaeggli: no hat, read this document the first time around, a +Joel Jaeggli: no hat, read this document the first time around, a little while ago, think it is a really useful document, some freshening required, but appropriate under our new charter -christian vogt: if not in opsec, where else? +Christian Vogt: if not in opsec, where else? -pekka: if not in opsec, probably not in ietf +Pekka: if not in opsec, probably not in IETF -christian: I support it to be published in this group +Christian: I support it to be published in this group -ron bonica: thumbs up +Ron Bonica: thumbs up -joel: will need to seek consensus on list +Joel: will need to seek consensus on list -lucy lynch: I have read it a while ago, read it again this this +Lucy Lynch: I have read it a while ago, read it again this this morning, some of this is a moving target; may require regular refreshment -joel: I wouldn't imagine it being more than informational. +Joel: I wouldn't imagine it being more than informational. will require routine updates or an understanding that like fish security recommendations do start to smell bad after a while. -william dixon: section 3.5 refers to ipsec and ike that is just +William Dixon: section 3.5 refers to ipsec and ike that is just really commentary, and I am not sure what to conclude from it. example of commentary. draft needs some work to provide concrete recommendations of work -joel: also some things that require conclusions +Joel: also some things that require conclusions -michael behring: good work, stuff that people should read, find +Michael Behring: good work, stuff that people should read, find difficult that the purpose is a bit of threat, a bit of countermeasures. would be good to have a clearer idea of what the goal of the document is. -joe abley: seems to me there is room in the charter for informational +Joe Abley: seems to me there is room in the charter for informational travelogues on security as well as BCPs. -merike: operational people are always told what to do but not why. +Merike: operational people are always told what to do but not why. I like Pekka's doc because it describes potential security issues along with tradeoffs for some solutions. It will help operators pick appropriate solutions in their environments since none of them individually is a silver bullet to solve all problems. -pekka: intent: if it's 15 pages or more, if it's too long. some - attack or countermeasure requires mengthy description, probably +Pekka: Intent, if it's 15 pages or more, if it's too long. some + attack or countermeasure requires lengthy description, probably referred somewhere else. so tried to be concise. -michael: I really like that. I also see merike's point. the danger +Michael: I really like that. I also see Merike's point. the danger is that you take the countermeasures out and just leave the list, which means the list needs to be more concise. -joel: should close it here so we can get the remaining presentations +Joel: Should close it here so we can get the remaining presentations in. when we look for consensus on the list, document might benefit - from additional authors. people who like the document should + from additional authors. People who like the document should consider helping out with it. @@ -126,38 +128,38 @@ Michael Behring gave an overview of the structure of this document, which was previously a work item in the RPSEG working group. -joel: seems likely that opsec people would have things to say about +joel: Seems likely that opsec people would have things to say about this -ron: this does give value, think it's appropriate +Ron: this does give value, think it's appropriate -merike: think work is appropriate, but was involved in rpsec and +Merike: Think work is appropriate, but was involved in rpsec and don't think there are enough people in this group that understand enough bgp potentially to come up with requirements. -joel: agree with merike on that; control plane security is one +Joel: Agree with merike on that; control plane security is one element of that but the protocol itself is the other piece and I - think that's slightly less core here + think that's slightly less core here. -pekka: observation here is proposed charter, bcp problem statements, +Pekka: observation here is proposed charter, bcp problem statements, taxonomies, etc. requirements explicitly out of scope. -sandy murphy: I recall reading very long ago versions of your draft - and versions of pekka' sdraft, and saw in your outline some items - that I thought might also be included in pekka's. infrastructure +Sandy Murphy: I recall reading very long ago versions of your draft + and versions of Pekka' sdraft, and saw in your outline some items + that I thought might also be included in Pekka's. Infrastructure hiding, for example? -michael: yeah, but really compeltely different scope. +Michael: yeah, but really compeltely different scope. -lucy: to follow up on what joel was saying, cross-area review +Lucy: To follow up on what joel was saying, cross-area review and strong support that document should continue -joe: advice to operators on how to secure routers would be a +Joe: advice to operators on how to secure routers would be a clearer fit for the charter -joel: maybe an additional document +Joel: maybe an additional document -michael: I will continue in the routing area, and maybe return here +Michael: I will continue in the routing area, and maybe return here with a BCP. --------------090900030203000709030001 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec --------------090900030203000709030001-- From opsec-bounces@ietf.org Tue Aug 5 00:06:47 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A295F3A6A0E; Tue, 5 Aug 2008 00:06:47 -0700 (PDT) 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 E815C3A6A0E for ; Tue, 5 Aug 2008 00:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.97 X-Spam-Level: X-Spam-Status: No, score=-1.97 tagged_above=-999 required=5 tests=[AWL=0.822, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RECV_SPEEDY_AR=0.808] 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 cdrSiGaa+CS8 for ; Tue, 5 Aug 2008 00:06:45 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 1E1BB3A68EB for ; Tue, 5 Aug 2008 00:06:44 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id BB56D6B6813; Tue, 5 Aug 2008 04:07:05 -0300 (ART) Received: from notebook.gont.com.ar (201-254-32-181.speedy.com.ar [201.254.32.181] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.13.8) with ESMTP id m7576k9N030671; Tue, 5 Aug 2008 04:06:49 -0300 Message-Id: <200808050706.m7576k9N030671@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 05 Aug 2008 04:00:06 -0300 To: Mohacsi Janos , opsec@ietf.org From: Fernando Gont In-Reply-To: <20080730164108.J85867@mignon.ki.iif.hu> References: <20080730164108.J85867@mignon.ki.iif.hu> Mime-Version: 1.0 X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Tue, 05 Aug 2008 04:07:04 -0300 (ART) Subject: Re: [OPSEC] comment for draft-gont-opsec-icmp-filtering-00.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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org At 12:06 p.m. 30/07/2008, Mohacsi Janos wrote: > I would recommend for the authors of > draft-gont-opsec-icmp-filtering-00.txt to look at RFC 4890 >"Recommendations for Filtering ICMPv6 Messages in Firewalls" Point taken. 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 _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Tue Aug 5 03:16:53 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3937128C1C8; Tue, 5 Aug 2008 03:16:53 -0700 (PDT) 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 29FD528C1A4 for ; Tue, 5 Aug 2008 03:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.38 X-Spam-Level: X-Spam-Status: No, score=-2.38 tagged_above=-999 required=5 tests=[AWL=0.411, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RECV_SPEEDY_AR=0.808] 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 KP9Mij9akhwL for ; Tue, 5 Aug 2008 03:16:51 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 49E7428C186 for ; Tue, 5 Aug 2008 03:16:50 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 86A006B683D for ; Tue, 5 Aug 2008 07:17:01 -0300 (ART) Received: from notebook.gont.com.ar (201-254-32-181.speedy.com.ar [201.254.32.181] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.13.8) with ESMTP id m75AGuZY015005 for ; Tue, 5 Aug 2008 07:16:56 -0300 Message-Id: <200808051016.m75AGuZY015005@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 05 Aug 2008 07:13:16 -0300 To: opsec@ietf.org From: Fernando Gont Mime-Version: 1.0 X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Tue, 05 Aug 2008 07:16:59 -0300 (ART) Subject: [OPSEC] Working on a revision of the ICMP filtering draft 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Hello, folks, We're currently working on a revision of the icmp filtering draft (http://tools.ietf.org/id/draft-gont-opsec-icmp-filtering-00.txt). We're planning to publish a revised version of the doc (as draft-ietf) sometime next week. If you have any feedback on the doc, and proposed text in particular ;-), please send it to me or post it on the list, so that your feedback/text makes it into the next revision of the doc. Thanks so much! 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 _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Tue Aug 5 20:20:03 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58F753A69C9; Tue, 5 Aug 2008 20:20:03 -0700 (PDT) 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 86CCF3A69C9 for ; Tue, 5 Aug 2008 20:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=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 TsfxI3spLTdq for ; Tue, 5 Aug 2008 20:20:01 -0700 (PDT) Received: from iridium.nac.net (iridium.nac.net [209.123.118.212]) by core3.amsl.com (Postfix) with ESMTP id 3F2CD3A6937 for ; Tue, 5 Aug 2008 20:19:37 -0700 (PDT) Received: from webmail.nac.net (localhost.nac.net [127.0.0.1]) by iridium.nac.net (8.13.4/8.13.4) with ESMTP id m763K54j010522; Tue, 5 Aug 2008 23:20:05 -0400 (EDT) (envelope-from rfgraveman@nac.net) Received: from 72.68.68.208 (SquirrelMail authenticated user rfgraveman) by webmail.nac.net with HTTP; Tue, 5 Aug 2008 23:20:05 -0400 (EDT) Message-ID: <51786.72.68.68.208.1217992805.squirrel@webmail.nac.net> In-Reply-To: <200808051016.m75AGuZY015005@venus.xmundo.net> References: <200808051016.m75AGuZY015005@venus.xmundo.net> Date: Tue, 5 Aug 2008 23:20:05 -0400 (EDT) From: rfgraveman@nac.net To: "Fernando Gont" User-Agent: SquirrelMail/1.4.10a MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal Cc: opsec@ietf.org Subject: Re: [OPSEC] Working on a revision of the ICMP filtering draft 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org > Hello, folks, > > We're currently working on a revision of the icmp filtering draft > (http://tools.ietf.org/id/draft-gont-opsec-icmp-filtering-00.txt). > We're planning to publish a revised version of the doc (as > draft-ietf) sometime next week. > > If you have any feedback on the doc, and proposed text in particular > ;-), please send it to me or post it on the list, so that your > feedback/text makes it into the next revision of the doc. Many of the ICMPv6 message types are not defined in 4443 but in other documents. See http://www.iana.org/assignments/icmpv6-parameters for a complete list. The entire list should be at least mentioned. Some perhaps relevant work on this has been done in v6ops, right? _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Wed Aug 6 01:20:20 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD4183A6820; Wed, 6 Aug 2008 01:20:20 -0700 (PDT) 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 308D428C0ED for ; Wed, 6 Aug 2008 01:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.771 X-Spam-Level: X-Spam-Status: No, score=-1.771 tagged_above=-999 required=5 tests=[AWL=0.828, 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 RKmJ6d5wQ-Ll for ; Wed, 6 Aug 2008 01:20:18 -0700 (PDT) Received: from monster.hopcount.ca (monster.hopcount.ca [199.212.90.4]) by core3.amsl.com (Postfix) with ESMTP id 8BBFE3A67E1 for ; Wed, 6 Aug 2008 01:20:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=monster; d=ca.afilias.info; h=Received:Message-Id:From:To:In-Reply-To:Content-Type:Mime-Version:Subject:Date:References:X-Mailer; b=TFTaRvASvPyRqoYwc78/vBV1Isl4tSPm0JCooAXTkT8CcXndod5Xl/MHyVkm3EPARwhZJJyt84YrQlMDYTHAaFH0aNLUNLnj2xViR2/lwbeJZCPTOYMplnaYV4AnFELB; Received: from [199.212.90.13] (helo=calamari.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQOQQ-000P02-GV for opsec@ietf.org; Tue, 05 Aug 2008 15:26:15 +0000 Message-Id: <76E1C31C-194F-4EBF-B291-206E8BECAD90@ca.afilias.info> From: Joe Abley To: opsec@ietf.org In-Reply-To: <6FA17FAC-7174-4E24-A336-F7067986B579@ca.afilias.info> Content-Type: multipart/mixed; boundary=Apple-Mail-1--875394573 Mime-Version: 1.0 (Apple Message framework v928.1) Date: Tue, 5 Aug 2008 11:26:13 -0400 References: <61BF1842-7DC2-49EA-9DE5-AE62AE2CED82@ca.afilias.info> <6FA17FAC-7174-4E24-A336-F7067986B579@ca.afilias.info> X-Mailer: Apple Mail (2.928.1) Subject: Re: [OPSEC] draft minutes for opsec meeting today 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: , Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org --Apple-Mail-1--875394573 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 31 Jul 2008, at 08:48, Joe Abley wrote: > On 30 Jul 2008, at 18:32, Joe Abley wrote: > >> Please see attached. Please send comments/corrections to the list, >> or to me directly. > > Second cut attached. Third cut attached. This incorporates comments from Dan and Joel. If people could take the time to read through it and send me any further suggestions in the next couple of days, that would be appreciated. Thanks, Joe --Apple-Mail-1--875394573 Content-Disposition: attachment; filename=opsec-ietf72-1.txt Content-Type: text/plain; x-unix-mode=0644; name="opsec-ietf72-1.txt" Content-Transfer-Encoding: 7bit Minutes of the OPSEC meeting IETF 72, Dublin, Ireland 2008-07-30 1510 UTC+1 Note-taker: jabley Jabber proxy: jabley (no jabber scribe) The meeting opened at 1518 UTC+1. 1. Joel Jaeggli, OPSEC WG Joel Jaeggli presented on the working group rechartering and document status. There is fatigue on existing milestones, and abandonment with recharter is a more pragmatic way forward than closing the working group and chartering a new one. The new charter has passed working group last call and has been sent to the IESG. Milestones on the new charter are a bit thin. We want to keep the working group around to bring problems from the network operations space into. Ron Bonica: charter has changed -- no longer to do with requirements for vendors, now to do with BCP for operators. Old documents should be allowed to wither on the vine. Joel Jaeggli: An alternative might be to fold this work into OPSAWG. Dan Romascanu: conscious decision to keep opsec separate from opsawg in order to separate and maintain focus on the security aspects There are two new potential work items from Warren Kumari on blackhole communities. Danny McPherson: comment on warren's blackhole draft; many isps use different communities for different kinds of blackholes, different places to drop packets, etc draft-gont-opsec-icmp-filtering is a draft which has seen positive discussion on the mailing list. Mohacsi Janos: similar draft for v6 icmp fltering, around rfc 4890. I think the author should consider looking at this draft. There was a strong hum for adopting draft-gont-opsec-icmp-filtering as a working group document. There was no hum in dissent. The author was encouraged to resubmit the draft as an opsec working group document. 2. SAVI Overview, Christian Vogt Christian Vogt provided an overview of the problem space and approach for work starting in the SAVI working group. There was no discussion from the floor. 3. draft-savola-rtgwg-backbone-attacks-03, Pekka Savola Pekka Savola provided a brief history of this draft. Merike Kaeo: totally support this work, and think it would be perfect as an informational document Joel: no hat, read this document the first time around, a little while ago, think it is a really useful document, some freshening required, but appropriate under our new charter Christian Vogt: if not in opsec, where else? Pekka: if not in opsec, probably not in ietf Christian: I support it to be published in this group Ron: thumbs up Joel: will need to seek consensus on list Lucy Lynch: I have read it a while ago, read it again this this morning, some of this is a moving target; may require regular refreshment Joel: I wouldn't imagine it being more than informational. will require routine updates or an understanding that like fish security recommendations do start to smell bad after a while. William Dixon: section 3.5 refers to ipsec and ike that is just really commentary, and I am not sure what to conclude from it. example of commentary. draft needs some work to provide concrete recommendations of work Joel: also some things that require conclusions Michael Behring: good work, stuff that people should read, find difficult that the purpose is a bit of threat, a bit of counter- measures. would be good to have a clearer idea of what the goal of the document is. Joe Abley: seems to me there is room in the charter for informational travelogues on security as well as BCPs. Merike: operational people are always told what to do but not why. I like Pekka's doc because it describes potential security issues along with tradeoffs for some solutions. It will help operators pick appropriate solutions in their environments since none of them individually is a silver bullet to solve all problems. Pekka: intent: if it's 15 pages or more, if it's too long. some attack or countermeasure requires mengthy description, probably referred somewhere else. so tried to be concise. Michael: I really like that. I also see merike's point. the danger is that you take the countermeasures out and just leave the list, which means the list needs to be more concise. Joel: should close it here so we can get the remaining presentations in. when we look for consensus on the list, document might benefit from additional authors. People who like the document should consider helping out with it. 4. draft-ietf-rpsec-bgp-session-sec-req-01, Michael Behring Michael Behring gave an overview of the structure of this document, which was previously a work item in the RPSEG working group. Joel: seems likely that opsec people would have things to say about this Ron: this does give value, think it's appropriate Merike: think work is appropriate, but was involved in rpsec and don't think there are enough people in this group that understand enough bgp potentially to come up with requirements. Joel: agree with merike on that; control plane security is one element of that but the protocol itself is the other piece and I think that's slightly less core here Pekka: observation here is proposed charter, bcp problem statements, taxonomies, etc. requirements explicitly out of scope. Sandy Murphy: I recall reading very long ago versions of your draft and versions of Pekka's draft, and saw in your outline some items that I thought might also be included in Pekka's. Infrastructure hiding, for example? Michael: yeah, but really compeltely different scope. Lucy: to follow up on what joel was saying, cross-area review and strong support that document should continue Joe: advice to operators on how to secure routers would be a clearer fit for the charter Joel: maybe an additional document Michael: I will continue in the routing area, and maybe return here with a BCP. 5. Any Other Business There was no other business. 6. Adjournment The meeting was closed at 1620 UTC+1. --Apple-Mail-1--875394573 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-1--875394573 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec --Apple-Mail-1--875394573-- From opsec-bounces@ietf.org Thu Aug 14 04:37:13 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C35F3A6AD0; Thu, 14 Aug 2008 04:37:13 -0700 (PDT) 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 E72B73A6D14 for ; Thu, 14 Aug 2008 04:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 VLsrxpZv4bvG for ; Thu, 14 Aug 2008 04:37:11 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 929AB3A6841 for ; Thu, 14 Aug 2008 04:37:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,209,1217808000"; d="scan'208";a="17148005" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 14 Aug 2008 11:37:13 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m7EBbDQb018163; Thu, 14 Aug 2008 13:37:13 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m7EBbDkI009966; Thu, 14 Aug 2008 11:37:13 GMT Received: from xmb-ams-333.cisco.com ([144.254.231.78]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Aug 2008 13:37:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 14 Aug 2008 13:38:00 +0200 Message-ID: In-Reply-To: <200808051016.m75AGuZY015005@venus.xmundo.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSEC] Working on a revision of the ICMP filtering draft Thread-Index: Acj25Hmdv83gyVgvQkSiKYvqSnv7QAHFhwXQ References: <200808051016.m75AGuZY015005@venus.xmundo.net> From: "Steinthor Bjarnason (sbjarnas)" To: "Fernando Gont" X-OriginalArrivalTime: 14 Aug 2008 11:37:13.0795 (UTC) FILETIME=[18B4C930:01C8FE02] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2638; t=1218713833; x=1219577833; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sbjarnas@cisco.com; z=From:=20=22Steinthor=20Bjarnason=20(sbjarnas)=22=20 |Subject:=20RE=3A=20[OPSEC]=20Working=20on=20a=20revision=2 0of=20the=20ICMP=20filtering=20draft |Sender:=20; bh=2F4U71+LuC01KTGxxq32GUZlz66nOW7kpi8BeAWZ1KE=; b=Sb6Zba/fjq5I8dEQihuZFFZckE+uVFQJbK+IGVxdV9VjCD9y/FIHVP4CsA ZvHDP5Cud7tpnnxfH3R+uvA3N8nf4NvbIeWyZkMDVzCFbKU12raAB2y2Qypb 4TuRnn/f9o; Authentication-Results: ams-dkim-2; header.From=sbjarnas@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: opsec@ietf.org Subject: Re: [OPSEC] Working on a revision of the ICMP filtering draft 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Hi Fernando, Sorry about the late feedback but here are some comments on the 2.1.1 ICMP Destination Unreachable: For all code types (0->15) there is an risk that an attacker might bombard the device with faked packets, forcing the device to create lots of ICMP destination unreachable packets. This is already being used as an attack vector as this can very quickly lead to resource starvation as ICMP unreachable processing must happen in slow path (usually central route processor), risking CPU exhaustion as the line card ASIC's can't help in these cases. The approach used to fix this is either block ICMP Destination Unreachable messages (which is of course a bad thing to do) or to configure the device so that it will rate limit how many ICMP Unreachables it generates per second. (For further info on how Cisco does this see: http://www.cisco.com/en/US/docs/ios/12_4t/12_4t2/hticmpun.html#wp1063689 ) I would suggest you add to bottom of section 2.1.1. the following text: An attacker can potentially perform a Denial of Service (DoS) attack against the router by forcing it to generate a high volume of ICMP Destination Unreachable messages. This can be done by flooding the router with packets which the attacker knows will result in the router spending resources in generating a high volume of ICMP messages. This can be mitigated by rate limiting the rate of IMCP messages generated. For rate limiting ICMPv6 messages see RFC 4443, section 2.4.f. Regards Steinthor > -----Original Message----- > From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] > On Behalf Of Fernando Gont > Sent: 5. august 2008 12:13 > To: opsec@ietf.org > Subject: [OPSEC] Working on a revision of the ICMP filtering draft > > Hello, folks, > > We're currently working on a revision of the icmp filtering > draft > (http://tools.ietf.org/id/draft-gont-opsec-icmp-filtering-00.txt). > We're planning to publish a revised version of the doc (as > draft-ietf) sometime next week. > > If you have any feedback on the doc, and proposed text in > particular ;-), please send it to me or post it on the list, > so that your feedback/text makes it into the next revision of the doc. > > Thanks so much! > > 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 > > > > > _______________________________________________ > 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 opsec-bounces@ietf.org Wed Aug 20 18:13:30 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16D7C3A6908; Wed, 20 Aug 2008 18:13:30 -0700 (PDT) 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 73E9A3A692D for ; Wed, 20 Aug 2008 18:13:28 -0700 (PDT) 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=[AWL=0.000, 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 aU7X4aRnYKFm for ; Wed, 20 Aug 2008 18:13:27 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 66D403A6452 for ; Wed, 20 Aug 2008 18:13:27 -0700 (PDT) Received: from [192.103.16.227] ([192.103.16.227]) (authenticated bits=0) by nagasaki.bogus.com (8.14.2/8.14.2) with ESMTP id m7L1DXkw077855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 21 Aug 2008 01:13:34 GMT (envelope-from joelja@bogus.com) Message-ID: <48ACC127.2040507@bogus.com> Date: Wed, 20 Aug 2008 18:13:11 -0700 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: opsec wg mailing list X-Enigmail-Version: 0.95.7 X-Virus-Scanned: ClamAV 0.93.1/8061/Thu Aug 21 00:00:17 2008 on nagasaki.bogus.com X-Virus-Status: Clean Subject: [OPSEC] additional documents needing a home... 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Folks, Dave Ward has proposed adding: Michael Behringer's rpsec draft http://tools.ietf.org/html/draft-ietf-rpsec-bgp-session-sec-req-01 Abstract The document "BGP security requirements" (draft-ietf-rpsec-bgpsecrec) specifies general security requirements for BGP. However, specific security requirements for single BGP sessions, i.e., the connection between two BGP peers, are only touched on briefly in the section "transport layer protection". This document expands on this particular aspect of BGP security, defining the security requirements between two BGP peers. which as was presented in opsec in ireland and http://tools.ietf.org/html/draft-manral-rpsec-existing-crypto-05 Abstract Routing protocols are designed to use cryptographic mechanisms to authenticate data being received from a neighboring router to ensure that it has not been modified in transit, and actually originated from the neighboring router purporting to have originating the data. Most of the cryptographic mechanisms defined to date rely on hash algorithms applied to the data in the routing protocol packet, which means the data is transported, in the clear, along with a signature based on the data itself. These mechanisms rely on the manual configuration of the keys used to seed, or build, these hash based signatures. This document outlines some of the problems with manual keying of these cryptographic algorithms. http://tools.ietf.org/html/draft-bhatia-manral-igp-crypto-requirements-00 Abstract The interior gateway routing protocols OSPFv2 [RFC2328], IS-IS [ISO] [RFC1195] and RIP [RFC2453] currently define clear text and MD5 [RFC1321] algorithms for authenticating their protocol packets. There have recently been documents adding support of the SHA family of hash algorithms for authenticating routing protocol packets for RIP, IS-IS and OSPF. To ensure interoperability between disparate implementations, it is imperative that we specify a set of mandatory-to-implement algorithms thereby ensuring that there is at least one algorithm that all implementations will have available. which were not... As these document existing practice or problems with existing protocols I think it is conceivable that this work would fall within our proposed and soon to be official charter. I would like to hear some opinions on the subject. there was some discussion of the first document during the opsec wg meeting and I believe that the record shows some support for and against housing it in opsec. thanks joelja _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Mon Aug 25 01:07:43 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D09803A69D8; Mon, 25 Aug 2008 01:07:43 -0700 (PDT) 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 9D5433A69D8 for ; Mon, 25 Aug 2008 01:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.191 X-Spam-Level: X-Spam-Status: No, score=-0.191 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_RECV_SPEEDY_AR=0.808] 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 GXDF3ICzNlm2 for ; Mon, 25 Aug 2008 01:07:41 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 030823A6844 for ; Mon, 25 Aug 2008 01:07:40 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id EFA3F6B6775 for ; Mon, 25 Aug 2008 04:59:51 -0300 (ART) Received: from notebook.gont.com.ar (201-254-32-53.speedy.com.ar [201.254.32.53] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.13.8) with ESMTP id m7P7xkYS000744 for ; Mon, 25 Aug 2008 04:59:50 -0300 Message-Id: <200808250759.m7P7xkYS000744@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 25 Aug 2008 04:55:43 -0300 To: opsec wg mailing list From: Fernando Gont Mime-Version: 1.0 X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Mon, 25 Aug 2008 04:59:51 -0300 (ART) Subject: [OPSEC] New I-D: Security Assessment of the Internet Protocol 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Folks, I have submitted a new Internet-Draft, entitled "Security Assessment of the Internet Protocol version 4", aimed at the OPSEC WG. The I-D is available at: http://www.ietf.org/internet-drafts/draft-gont-opsec-ip-security-00.txt . Additionally, the same draft is available in other fancy formats (HTML and PDF) at: http://www.gont.com.ar/drafts/ip-security/index.html . The abstract of the document is: ---- cut here ---- 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). ---- cut here ---- This I-D is simply and IETF-I-D- formatted version of the document that was recently released by the UK's Centre for the Protection of National Infrastructure (CPNI), available at: http://www.cpni.gov.uk/Docs/InternetProtocol.pdf . That is, this I-D is our effort to bring the results of the UK's CPNI project to the IETF. FWIW, the "Preface" of the UK CPNI document describes the motivation of this project: ---- cut here ---- The TCP/IP protocols were conceived during a time that was quite different from the hostile environment they operate in now. Yet a direct result of their effectiveness and widespread early adoption is that much of today's global economy remains dependent upon them. While many textbooks and articles have created the myth that the Internet Protocols (IP) were designed for warfare environments, the top level goal for the DARPA Internet Program was the sharing of large service machines on the ARPANET. As a result, many protocol specifications focus only on the operational aspects of the protocols they specify and overlook their security implications. Though Internet technology has evolved, the building blocks are basically the same core protocols adopted by the ARPANET more than two decades ago. During the last twenty years many vulnerabilities have been identified in the TCP/IP stacks of a number of systems. Some were flaws in protocol implementations which affect only a reduced number of systems. Others were flaws in the protocols themselves affecting virtually every existing implementation. Even in the last couple of years researchers were still working on security problems in the core protocols. The discovery of vulnerabilities in the TCP/IP protocols led to reports being published by a number of CSIRTs (Computer Security Incident Response Teams) and vendors, which helped to raise awareness about the threats as well as the best mitigations known at the time the reports were published. Much of the effort of the security community on the Internet protocols did not result in official documents (RFCs) being issued by the IETF (Internet Engineering Task Force) leading to a situation in which "known" security problems have not always been addressed by all vendors. In many cases vendors have implemented quick "fixes" to protocol flaws without a careful analysis of their effectiveness and their impact on interoperability. As a result, any system built in the future according to the official TCP/IP specifications might reincarnate security flaws that have already hit our communication systems in the past. Producing a secure TCP/IP implementation nowadays is a very difficult task partly because of no single document that can serve as a security roadmap for the protocols. There is clearly a need for a companion document to the IETF specifications that discusses the security aspects and implications of the protocols, identifies the possible threats, proposes possible counter-measures, and analyses their respective effectiveness. This document is the result of an assessment of the IETF specifications of the Internet Protocol from a security point of view. Possible threats were identified and, where possible, counter-measures were proposed. Additionally, many implementation flaws that have led to security vulnerabilities have been referenced in the hope that future implementations will not incur the same problems. This document does not limit itself to performing a security assessment of the relevant IETF specification but also offers an assessment of common implementation strategies. Whilst not aiming to be the final word on the security of the IP, this document aims to raise awareness about the many security threats based on the IP protocol that have been faced in the past, those that we are currently facing, and those we may still have to deal with in the future. It provides advice for the secure implementation of the IP, and also insights about the security aspects of the IP that may be of help to the Internet operations community. Feedback from the community is more than encouraged to help this document be as accurate as possible and to keep it updated as new threats are discovered. ---- cut here ---- Any feedback will be more than welcome. 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 _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Mon Aug 25 03:57:11 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBD063A683D; Mon, 25 Aug 2008 03:57:10 -0700 (PDT) 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 7F8B83A683D for ; Mon, 25 Aug 2008 03:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.185 X-Spam-Level: X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] 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 vC4eoLe7cuYR for ; Mon, 25 Aug 2008 03:57:08 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id A59EB3A67C0 for ; Mon, 25 Aug 2008 03:57:08 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m7PAv7e7014733 for ; Mon, 25 Aug 2008 06:57:07 -0400 Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m7PAv7V6014720; Mon, 25 Aug 2008 06:57:07 -0400 Received: from [127.0.0.1] ([129.83.10.1]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Aug 2008 06:57:06 -0400 Message-ID: <48B29008.4050404@mitre.org> Date: Mon, 25 Aug 2008 06:57:12 -0400 From: George M Jones User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: Fernando Gont , opsec wg mailing list References: <200808250759.m7P7xkYS000744@venus.xmundo.net> In-Reply-To: <200808250759.m7P7xkYS000744@venus.xmundo.net> X-OriginalArrivalTime: 25 Aug 2008 10:57:06.0866 (UTC) FILETIME=[509BD120:01C906A1] Subject: Re: [OPSEC] New I-D: Security Assessment of the Internet Protocol 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org A couple thoughts/reactions: - A lot of the info about the protocols, headers, etc,. seems elementary (at least for this audience). - I can't believe that in the history of the Internet nothing like this has every been done ? - The references list looks useful. - Question: were you involved in the writing of the CPNI paper ? Thanks, ---George Jones _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Mon Aug 25 04:08:03 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 463223A68FD; Mon, 25 Aug 2008 04:08:03 -0700 (PDT) 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 E3E503A68FD for ; Mon, 25 Aug 2008 04:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.491 X-Spam-Level: X-Spam-Status: No, score=-1.491 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RECV_SPEEDY_AR=0.808] 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 nR0pfG1Y-xTi for ; Mon, 25 Aug 2008 04:08:00 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id C7FFC3A683D for ; Mon, 25 Aug 2008 04:07:59 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 66FF76B6981; Mon, 25 Aug 2008 08:07:22 -0300 (ART) Received: from notebook.gont.com.ar (201-254-32-53.speedy.com.ar [201.254.32.53] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.13.8) with ESMTP id m7PB7FWF030034; Mon, 25 Aug 2008 08:07:16 -0300 Message-Id: <200808251107.m7PB7FWF030034@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 25 Aug 2008 08:03:02 -0300 To: George M Jones , Fernando Gont , opsec wg mailing list From: Fernando Gont In-Reply-To: <48B29008.4050404@mitre.org> References: <200808250759.m7P7xkYS000744@venus.xmundo.net> <48B29008.4050404@mitre.org> Mime-Version: 1.0 X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Mon, 25 Aug 2008 08:07:22 -0300 (ART) Subject: Re: [OPSEC] New I-D: Security Assessment of the Internet Protocol 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org At 07:57 a.m. 25/08/2008, George M Jones wrote: >- A lot of the info about the protocols, headers, etc,. seems >elementary (at least for this audience). You mean the introduction, and protocol description, or what? >- I can't believe that in the history of the Internet nothing like >this has every been done ? Not that I am aware of. Nothing showed up in Google, either. And, after a few weeks of having posted the paper to bugtraq and full-disclosure, nobody pointed to such thing- >- The references list looks useful. The "References" section has required a *lot* of work. Id did my homework, and read all of them (plus many others that I thought were not relevant or worth including). >- Question: were you involved in the writing of the CPNI paper ? Yes: I wrote the paper myself. 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 _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Mon Aug 25 04:12:18 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE65C3A6940; Mon, 25 Aug 2008 04:12:18 -0700 (PDT) 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 8CDF13A6922 for ; Mon, 25 Aug 2008 04:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 KaB2eqKcTfuJ for ; Mon, 25 Aug 2008 04:12:15 -0700 (PDT) Received: from ind-iport-1.cisco.com (ind-iport-1.cisco.com [64.104.129.195]) by core3.amsl.com (Postfix) with ESMTP id C952E3A68F7 for ; Mon, 25 Aug 2008 04:12:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,264,1217808000"; d="scan'208";a="26576049" Received: from hkg-dkim-2.cisco.com ([10.75.231.163]) by ind-iport-1.cisco.com with ESMTP; 25 Aug 2008 11:12:12 +0000 Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m7PBCCTk031953 for ; Mon, 25 Aug 2008 19:12:12 +0800 Received: from [192.168.1.100] (sin-vpn-client-20-40.cisco.com [10.68.20.40]) by hkg-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m7PBCBSw019911 for ; Mon, 25 Aug 2008 11:12:11 GMT Message-Id: <71EBDC90-24E9-47EC-9A4A-41BA809BDDED@cisco.com> From: Roland Dobbins To: opsec wg mailing list In-Reply-To: <48B29008.4050404@mitre.org> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Mon, 25 Aug 2008 18:12:10 +0700 References: <200808250759.m7P7xkYS000744@venus.xmundo.net> <48B29008.4050404@mitre.org> X-Mailer: Apple Mail (2.928.1) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=502; t=1219662732; x=1220526732; c=relaxed/simple; s=hkgdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdobbins@cisco.com; z=From:=20Roland=20Dobbins=20 |Subject:=20Re=3A=20[OPSEC]=20New=20I-D=3A=20Security=20Ass essment=20of=20the=20Internet=20Protocol |Sender:=20; bh=PswJPnJOYpBDRzYr2X+4/MCRw+awMIGfzz7BGxyHvVU=; b=RZo9LtgyFi6wzLmcg7HX/f6I5SIcDDtDyVV1Pmng6LAyfOB6oiZNUvQtRw x3M+axgWhj2wgQidj5U+5Nklp6Ur6LcMIwDUwuDSSeHWHUoK97kAq7xbWWCv lP7Mlz8jQ2FnvSJQa142OaCyaRt6fdNSxPumPcrJcwaknurqeSWok=; Authentication-Results: hkg-dkim-2; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/hkgdkim2001 verified; ); Subject: Re: [OPSEC] New I-D: Security Assessment of the Internet Protocol 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org On Aug 25, 2008, at 5:57 PM, George M Jones wrote: > - I can't believe that in the history of the Internet nothing like > this has every been done ? Not to my knowledge - something of this sort has been sorely needed for quite some time, IMHO. ----------------------------------------------------------------------- Roland Dobbins // +66.83.266.6344 mobile History is a great teacher, but it also lies with impunity. -- John Robb _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Mon Aug 25 06:47:47 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0DCF3A7028; Mon, 25 Aug 2008 06:47:47 -0700 (PDT) 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 D213E3A702A for ; Mon, 25 Aug 2008 06:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] 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 XgtwwGCgyHBx for ; Mon, 25 Aug 2008 06:47:45 -0700 (PDT) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.239]) by core3.amsl.com (Postfix) with ESMTP id 94B653A686E for ; Mon, 25 Aug 2008 06:47:45 -0700 (PDT) Received: by qb-out-0506.google.com with SMTP id o24so2503421qba.1 for ; Mon, 25 Aug 2008 06:46:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=ss8K+Xb+1VWEiwewPVtlC2xdKyC/25miUawR0awfQQA=; b=K2h9aX57fjY7kqw02J4kJuewm+GUcTDIzA0U42H1Ip6O3kam5ucm9kWZwkL7AxG8CR xC0fwBTpH6zTVXCLzgJOvrBxAGqbEYb02m50rOOnazdFXP8t/nnbqfB0g7hBff/o9Hqx UHUse6LeFg65jNSBYnmI89d1NIC7IrtNyQsRA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=n2K9Q/NFnbLZZNXOQ8a4ueNtszb66bwtUhadsLiqO06q5mn5NyIAvzsiXBh6uNk5/T ZPXxbLtAs/y67vckWsYRECJ7+2oDJDRB8lHBdem47nIxdzqs25ns8Gxb2PajfKE430op e2np5d7t48r8bwHQBpsePU5QGYssdd5OrOxbg= Received: by 10.103.49.7 with SMTP id b7mr2878665muk.104.1219672016505; Mon, 25 Aug 2008 06:46:56 -0700 (PDT) Received: by 10.103.141.2 with HTTP; Mon, 25 Aug 2008 06:46:56 -0700 (PDT) Message-ID: <92c950310808250646t50c00ce0w8a778dc19c08188b@mail.gmail.com> Date: Mon, 25 Aug 2008 19:16:56 +0530 From: "Glen Kent" To: opsec@ietf.org MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [OPSEC] additional documents needing a home... 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org I strongly believe that drafts draft-ietf-rpsec-bgp-session-sec-req and draft-manral-rpsec-existing-crypto-05 very much belong here in OPSEC. Glen ---------- Forwarded message ---------- From: Joel Jaeggli Date: Thu, Aug 21, 2008 at 6:43 AM Subject: [OPSEC] additional documents needing a home... To: opsec wg mailing list Folks, Dave Ward has proposed adding: Michael Behringer's rpsec draft http://tools.ietf.org/html/draft-ietf-rpsec-bgp-session-sec-req-01 Abstract The document "BGP security requirements" (draft-ietf-rpsec-bgpsecrec) specifies general security requirements for BGP. However, specific security requirements for single BGP sessions, i.e., the connection between two BGP peers, are only touched on briefly in the section "transport layer protection". This document expands on this particular aspect of BGP security, defining the security requirements between two BGP peers. which as was presented in opsec in ireland and http://tools.ietf.org/html/draft-manral-rpsec-existing-crypto-05 Abstract Routing protocols are designed to use cryptographic mechanisms to authenticate data being received from a neighboring router to ensure that it has not been modified in transit, and actually originated from the neighboring router purporting to have originating the data. Most of the cryptographic mechanisms defined to date rely on hash algorithms applied to the data in the routing protocol packet, which means the data is transported, in the clear, along with a signature based on the data itself. These mechanisms rely on the manual configuration of the keys used to seed, or build, these hash based signatures. This document outlines some of the problems with manual keying of these cryptographic algorithms. http://tools.ietf.org/html/draft-bhatia-manral-igp-crypto-requirements-00 Abstract The interior gateway routing protocols OSPFv2 [RFC2328], IS-IS [ISO] [RFC1195] and RIP [RFC2453] currently define clear text and MD5 [RFC1321] algorithms for authenticating their protocol packets. There have recently been documents adding support of the SHA family of hash algorithms for authenticating routing protocol packets for RIP, IS-IS and OSPF. To ensure interoperability between disparate implementations, it is imperative that we specify a set of mandatory-to-implement algorithms thereby ensuring that there is at least one algorithm that all implementations will have available. which were not... As these document existing practice or problems with existing protocols I think it is conceivable that this work would fall within our proposed and soon to be official charter. I would like to hear some opinions on the subject. there was some discussion of the first document during the opsec wg meeting and I believe that the record shows some support for and against housing it in opsec. thanks joelja _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Sun Aug 31 10:04:10 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 756BB28C15F; Sun, 31 Aug 2008 10:04:10 -0700 (PDT) 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 40FF63A6B27 for ; Sun, 31 Aug 2008 10:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.28 X-Spam-Level: X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=0.511, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RECV_SPEEDY_AR=0.808] 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 bSXihNE9tRyQ for ; Sun, 31 Aug 2008 10:04:08 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 38B853A6AC0 for ; Sun, 31 Aug 2008 10:04:07 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 098D96B656C for ; Sun, 31 Aug 2008 14:04:14 -0300 (ART) Received: from notebook.gont.com.ar (201-254-54-71.speedy.com.ar [201.254.54.71] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.13.8) with ESMTP id m7VH46ZH019032 for ; Sun, 31 Aug 2008 14:04:06 -0300 Message-Id: <200808311704.m7VH46ZH019032@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 31 Aug 2008 13:58:02 -0300 To: opsec wg mailing list From: Fernando Gont Mime-Version: 1.0 X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Sun, 31 Aug 2008 14:04:13 -0300 (ART) Subject: [OPSEC] Fwd: New Version Notification for draft-gont-opsec-ip-security-01 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Folks, I have posted a revised version of UK CPNI's IP security I-D. This revision just fixes a few typo's, and fixes the author's affiliation. Any comments will be more than welcome. Thanks! Kind regards, Fernando >From: IETF I-D Submission Tool >To: fernando@gont.com.ar >Subject: New Version Notification for draft-gont-opsec-ip-security-01 >Date: Sun, 31 Aug 2008 09:59:49 -0700 (PDT) > > >A new version of I-D, draft-gont-opsec-ip-security-01.txt has been >successfuly submitted by Fernando Gont and posted to the IETF repository. > >Filename: draft-gont-opsec-ip-security >Revision: 01 >Title: Security Assessment of the Internet Protocol version 4 >Creation_date: 2008-08-31 >WG ID: Independent Submission >Number_of_pages: 72 > >Abstract: >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). > > > > >The IETF Secretariat. -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Sun Aug 31 22:24:34 2008 Return-Path: X-Original-To: opsec-archive@optimus.ietf.org Delivered-To: ietfarch-opsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F36F3A68B9; Sun, 31 Aug 2008 22:24:34 -0700 (PDT) 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 1612B3A68E3 for ; Sun, 31 Aug 2008 22:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.409, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RECV_SPEEDY_AR=0.808] 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 69iMy+P0XZnh for ; Sun, 31 Aug 2008 22:24:33 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 1541E3A68B9 for ; Sun, 31 Aug 2008 22:24:32 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 3E9166B65BF; Mon, 1 Sep 2008 02:24:43 -0300 (ART) Received: from notebook.gont.com.ar (201-254-54-71.speedy.com.ar [201.254.54.71] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.13.8) with ESMTP id m815OOQf006493; Mon, 1 Sep 2008 02:24:27 -0300 Message-Id: <200809010524.m815OOQf006493@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 01 Sep 2008 02:20:14 -0300 To: opsec wg mailing list From: Fernando Gont Mime-Version: 1.0 X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Mon, 01 Sep 2008 02:24:42 -0300 (ART) Subject: [OPSEC] ICMP filtering draft 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Folks, I've submitted a new revision of our ICMP filtering draft. This revision basically addresses a suggestion we got from Alfred Honenes (off-list) and populates some of the sections. As this is the initial version of the I-D as (draft-ietf) (draft-ietf-opsec-icmp-filtering-00.txt), the chairs must approve the doc before it shows up in the Internet-Drafts repository. Meanwhile, it's available at: http://www.gont.com.ar/drafts/icmp-filtering/draft-ietf-opsec-icmp-filtering-00.txt . You may retrieve the draft in HTML or PDF formats at: http://www.gont.com.ar/drafts/icmp-filtering/index.html Any comments/feedback will be more than welcome. P.S..: There's some stuff that's still in the pipeline, and that will hopefully make into the draft in the next revision. 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 _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec