From opsec-bounces@ietf.org Thu Oct 2 12:52:00 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 3941528C27C; Thu, 2 Oct 2008 12:52:00 -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 880E028C198 for ; Thu, 2 Oct 2008 12:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.791 X-Spam-Level: X-Spam-Status: No, score=-2.791 tagged_above=-999 required=5 tests=[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 wtJiG7kWj0DA for ; Thu, 2 Oct 2008 12:51:57 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 7C2D73A69C4 for ; Thu, 2 Oct 2008 12:51:56 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id D23F66B65B8; Thu, 2 Oct 2008 16:52:11 -0300 (ART) Received: from notebook.gont.com.ar (201-254-59-210.speedy.com.ar [201.254.59.210] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.13.8) with ESMTP id m92Jq0Aq016334; Thu, 2 Oct 2008 16:52:01 -0300 Message-Id: <200810021952.m92Jq0Aq016334@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 02 Oct 2008 16:47:43 -0300 To: George M Jones From: Fernando Gont In-Reply-To: <48B299DE.8020001@mitre.org> References: <200808250759.m7P7xkYS000744@venus.xmundo.net> <48B29008.4050404@mitre.org> <200808251107.m7PB7FWF030034@venus.xmundo.net> <48B299DE.8020001@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]); Thu, 02 Oct 2008 16:52:10 -0300 (ART) Cc: opsec@ietf.org 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org At 08:39 a.m. 25/08/2008, George M Jones wrote: >>You mean the introduction, and protocol description, or what? >The "this is an IP header" , "these are the fields" bits. I guess >it's got to be there >if the document is going to be self contained, but in the context of the IETF >a lot of this is/should be common knowledge. FWIW, the reason for including that "introductory material" is to avoid requiring readers to have to go to other documents for have a look a the IP header format, the ECN fields format, etc. IMHO, I would keep that stuff in the document. But wouldn't mind removing it if the wg feels so. There's is other "more introductory" stuff such as that in Section 2. But that's just some high-level information about the protocol that's going to be assessed in the rest of the document. However, as with the figures, I wouldn't mind removing them if the wg feels so. For the most part, I think that removing the figures (header syntax, etc) will mean that the reader will have to have a t hand a copy of the documents in which those figures were originally included, though. (and that's what I tried to avoid by including them in this document). 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 Fri Oct 3 19:26:37 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 855D03A684D; Fri, 3 Oct 2008 19:26:37 -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 D78923A684D for ; Fri, 3 Oct 2008 19:26:35 -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 usruXOXa5V-A for ; Fri, 3 Oct 2008 19:26:34 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id C98B83A6B6C for ; Fri, 3 Oct 2008 19:26:28 -0700 (PDT) Received: from [192.168.1.117] (c-24-130-16-195.hsd1.ca.comcast.net [24.130.16.195]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id m942QpXL024390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 4 Oct 2008 02:26:54 GMT (envelope-from joelja@bogus.com) Message-ID: <48E6D46B.7020401@bogus.com> Date: Fri, 03 Oct 2008 19:26:51 -0700 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: "Bhatia, Manav \(Manav\)" References: <92c950310808250646t50c00ce0w8a778dc19c08188b@mail.gmail.com> <77ead0ec0809302014p336614afp433ea8de040713c5@mail.gmail.com> <6D26D1FE43A66F439F8109CDD424196501ED2F61@INEXC1U01.in.lucent.com> In-Reply-To: <6D26D1FE43A66F439F8109CDD424196501ED2F61@INEXC1U01.in.lucent.com> X-Enigmail-Version: 0.95.7 X-Virus-Scanned: ClamAV 0.93.3/8372/Thu Oct 2 15:21:47 2008 on nagasaki.bogus.com X-Virus-Status: Clean Cc: opsec@ietf.org 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 Bhatia, Manav (Manav) wrote: > > I support draft-manral-rpsec-existing-crypto-05 and I think OPSEC is the > right home for this draft. Regarding: http://tools.ietf.org/html/draft-bhatia-manral-igp-crypto-requirements-00 I have concerns about this document making protocol requirements within the scope of our charter. Making this a set of protocol best practices I think hews more closely to our charter (and doesn't belong in routing). any thoughts on that? problems with manual keying seems straight up our alley. http://tools.ietf.org/html/draft-manral-rpsec-existing-crypto-05 and i have no reservations for taking that one to our ADs. joelja > Cheers, > Manav > >> -----Original Message----- >> From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] >> On Behalf Of Vishwas Manral >> Sent: Wednesday, October 01, 2008 8.44 AM >> To: Glen Kent >> Cc: opsec@ietf.org >> Subject: Re: [OPSEC] additional documents needing a home... >> >> Hi Joel, >> >> I wanted to know your opinion of the consensus, and it was for >> allowing the work in the OPSEC WG? >> >> Thanks, >> Vishwas >> >> On 8/25/08, Glen Kent wrote: >>> 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-requ >> irements-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 >>> >> _______________________________________________ >> 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 opsec-bounces@ietf.org Fri Oct 3 21:31:12 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 671903A67EE; Fri, 3 Oct 2008 21:31:12 -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 5F9E03A67FB for ; Fri, 3 Oct 2008 21:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 8BBM2SCMU1QC for ; Fri, 3 Oct 2008 21:31:10 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by core3.amsl.com (Postfix) with ESMTP id AF2C33A67EE for ; Fri, 3 Oct 2008 21:31:09 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so1262586fga.41 for ; Fri, 03 Oct 2008 21:31:37 -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:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=hi989bCPwSt0MktskZqqlfetBK4vOhqC3lwqVIyrBH0=; b=twie3BaYCfbaE+A/G/21QtZVeVhqrGF+NpRe5tgt//5smn9fjHcDu8Zf0yyMD5lhJd 0EmfHeiLJMk9t/n/hVFvQVoVxOjZyK4LD5ZD11GiLsL7Qoby0o3hn4iMe0lX3uJ1Lng7 SFeojsT/uOv8gyO2KEs5FRIqeQxHEAJGi17VE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=K/StV6AH7BfQI9Q571nqxsdjlK6w6GxDDwkTYXKPit9lUkEyQj2Ausd5cZI/hmqoXa lvTO8rWK6RV5v0FMLgmLyX7K2cLTjgyEFZjSnwW+M0onkgYUzwZ72+qel5ekJ9XhHhU1 9xDiBifRDVMuc0kmhBxRVGZVIq/yvGt8usPWU= Received: by 10.181.30.10 with SMTP id h10mr1498395bkj.41.1223094697754; Fri, 03 Oct 2008 21:31:37 -0700 (PDT) Received: by 10.180.226.2 with HTTP; Fri, 3 Oct 2008 21:31:37 -0700 (PDT) Message-ID: <77ead0ec0810032131n6551ddcagfa026bdc1ae6bf93@mail.gmail.com> Date: Sat, 4 Oct 2008 10:01:37 +0530 From: "Vishwas Manral" To: "Joel Jaeggli" In-Reply-To: <48E6D46B.7020401@bogus.com> MIME-Version: 1.0 Content-Disposition: inline References: <92c950310808250646t50c00ce0w8a778dc19c08188b@mail.gmail.com> <77ead0ec0809302014p336614afp433ea8de040713c5@mail.gmail.com> <6D26D1FE43A66F439F8109CDD424196501ED2F61@INEXC1U01.in.lucent.com> <48E6D46B.7020401@bogus.com> Cc: opsec@ietf.org 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 Hi Joel, I agree with you on this!!! Thanks, Vishwas On 10/4/08, Joel Jaeggli wrote: > Bhatia, Manav (Manav) wrote: >> >> I support draft-manral-rpsec-existing-crypto-05 and I think OPSEC is the >> right home for this draft. > > > Regarding: > > http://tools.ietf.org/html/draft-bhatia-manral-igp-crypto-requirements-00 > > I have concerns about this document making protocol requirements within > the scope of our charter. Making this a set of protocol best practices I > think hews more closely to our charter (and doesn't belong in routing). > > any thoughts on that? > > problems with manual keying seems straight up our alley. > > http://tools.ietf.org/html/draft-manral-rpsec-existing-crypto-05 > > and i have no reservations for taking that one to our ADs. > > joelja > >> Cheers, >> Manav >> >>> -----Original Message----- >>> From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] >>> On Behalf Of Vishwas Manral >>> Sent: Wednesday, October 01, 2008 8.44 AM >>> To: Glen Kent >>> Cc: opsec@ietf.org >>> Subject: Re: [OPSEC] additional documents needing a home... >>> >>> Hi Joel, >>> >>> I wanted to know your opinion of the consensus, and it was for >>> allowing the work in the OPSEC WG? >>> >>> Thanks, >>> Vishwas >>> >>> On 8/25/08, Glen Kent wrote: >>>> 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-requ >>> irements-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 >>>> >>> _______________________________________________ >>> 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 > _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Sun Oct 5 11:14:35 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 233343A692B; Sun, 5 Oct 2008 11:14:35 -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 4E37B3A692B for ; Sun, 5 Oct 2008 11:14:34 -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 osyoojC+bIFs for ; Sun, 5 Oct 2008 11:14:33 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 601263A67C0 for ; Sun, 5 Oct 2008 11:14:33 -0700 (PDT) Received: from [10.0.1.191] (adsl-76-205-27-102.dsl.pltn13.sbcglobal.net [76.205.27.102]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id m95IF0Ai028707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 5 Oct 2008 18:15:01 GMT (envelope-from joelja@bogus.com) Message-ID: <48E90424.10001@bogus.com> Date: Sun, 05 Oct 2008 11:15:00 -0700 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: opsec wg mailing list , Vishwas Manral X-Enigmail-Version: 0.95.7 X-Virus-Scanned: ClamAV 0.93.3/8375/Sun Oct 5 14:10:50 2008 on nagasaki.bogus.com X-Virus-Status: Clean Subject: [OPSEC] draft-bhatia-manral-igp-crypto-requirements-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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org I wonder if it's not worth attempting to treat ospfv3 to some attention in this document as well... rfc 4552 covers rather a lot of ground. joelja _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Sun Oct 5 18:44: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 950313A6853; Sun, 5 Oct 2008 18:44: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 1994A3A6853 for ; Sun, 5 Oct 2008 18:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 OTbxuoB55d3U for ; Sun, 5 Oct 2008 18:44:32 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by core3.amsl.com (Postfix) with ESMTP id 1A60A3A6837 for ; Sun, 5 Oct 2008 18:44:31 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so1751989fga.41 for ; Sun, 05 Oct 2008 18:45:05 -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:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=AtZMv2o3q8Up7C5VEYnuzyP5XA//uZNhEWB2iwZOHLs=; b=slOHuJEZnZAhU8nhuXsOmtoE4CQHszefnRKfxN8O7h/g1SLsS54xG7CLrUkW6ffMw0 4sD4fr9+60Qll5lBUyl1zaZIEETAqPXoOHGAJ+Bwc0wHekk0hHZOtkxKjQ1AkbToRYdV j5kvcWcMyDbyd8wlPhZaXoWT7rsQYNIefmC5U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=CCTXulQr/4pa1n9OIXes2Sts9f+xrGbuotMIglH6hgGToC5Mi315sfaQ/G/2RxL7HQ gCqDEoldoe+OxBLtYXlE4TiPgxC03f/+s5MdakDv1GoNsY8aMlYmiYJlLlbyNIt2phsL FLt9oXiojoPk3EQ55I+iJqieTX0zqyjsGjGHk= Received: by 10.181.24.14 with SMTP id b14mr3117715bkj.22.1223257505339; Sun, 05 Oct 2008 18:45:05 -0700 (PDT) Received: by 10.180.226.2 with HTTP; Sun, 5 Oct 2008 18:45:05 -0700 (PDT) Message-ID: <77ead0ec0810051845v6b589bbbqd7b0eca0b5d81a3c@mail.gmail.com> Date: Mon, 6 Oct 2008 12:45:05 +1100 From: "Vishwas Manral" To: "Joel Jaeggli" In-Reply-To: <48E90424.10001@bogus.com> MIME-Version: 1.0 Content-Disposition: inline References: <48E90424.10001@bogus.com> Cc: opsec wg mailing list Subject: Re: [OPSEC] draft-bhatia-manral-igp-crypto-requirements-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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Hi Joel, OSPFv3 unlike the protocols mentioned in the draft uses IPsec. The algorithm requirements for IPsec are mentioned in RFC4835, that is one of the reasons we have not included it in the draft. We will clarify the same in the draft as well as looking at RIPng. Thanks, Vishwas On Mon, Oct 6, 2008 at 5:15 AM, Joel Jaeggli wrote: > I wonder if it's not worth attempting to treat ospfv3 to some attention > in this document as well... > > rfc 4552 covers rather a lot of ground. > > joelja > _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Mon Oct 6 04:02: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 AD71C3A6AB3; Mon, 6 Oct 2008 04:02: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 E645728C1A1 for ; Mon, 6 Oct 2008 04:02:01 -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 ZJVjjlWtmSbK for ; Mon, 6 Oct 2008 04:02:00 -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 61A413A6AAD for ; Mon, 6 Oct 2008 04:02:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,367,1220227200"; d="scan'208";a="21718380" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 06 Oct 2008 11:02:33 +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 m96B2XCH007844; Mon, 6 Oct 2008 13:02:33 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m96B2XTI000620; Mon, 6 Oct 2008 11:02:33 GMT Received: from xmb-ams-333.cisco.com ([144.254.231.78]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Oct 2008 13:02:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 6 Oct 2008 13:02:31 +0200 Message-ID: In-Reply-To: <48E6D46B.7020401@bogus.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSEC] additional documents needing a home... Thread-Index: AcklyL0wFx8h/26sQoiIn+iEsW4zFAB2XYAQ References: <92c950310808250646t50c00ce0w8a778dc19c08188b@mail.gmail.com> <77ead0ec0809302014p336614afp433ea8de040713c5@mail.gmail.com><6D26D1FE43A66F439F8109CDD424196501ED2F61@INEXC1U01.in.lucent.com> <48E6D46B.7020401@bogus.com> From: "Steinthor Bjarnason (sbjarnas)" To: X-OriginalArrivalTime: 06 Oct 2008 11:02:33.0244 (UTC) FILETIME=[087EA5C0:01C927A3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1104; t=1223290953; x=1224154953; 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]=20additional=20documents=20need ing=20a=20home... |Sender:=20; bh=Io4ttAGXvVPdLNkjPjLiwJ5/1ITUghQqYXx9npeygbs=; b=B0q34pwiiwGVvQ3r8jTolAfEwVmKaSD8nOhttEOE7iPVz0ST83aqMZkjGe Y2Y2Cr4sllktjHp21PEeGUol3ZUpnXKxpixpJvD8DCAenJFTTkhvdUCHSsCY mMZixDzjYj; Authentication-Results: ams-dkim-2; header.From=sbjarnas@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); 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 Hi, See below for comments: > Regarding: > > http://tools.ietf.org/html/draft-bhatia-manral-igp-crypto-requ irements-00 > > I have concerns about this document making protocol > requirements within the scope of our charter. Making this a > set of protocol best practices I think hews more closely to > our charter (and doesn't belong in routing). > > any thoughts on that? > I see the benefit in having a document which recommends which routing protocol authentication schemes to use. Having such a document available, will automatically put pressure on the routing protocol developers to implement what's missing (in case there are still some implementations out there which still do not support this). So, I suggest this document should be adopted by the WG but with a more "recommend/best practice" focus. > problems with manual keying seems straight up our alley. > > http://tools.ietf.org/html/draft-manral-rpsec-existing-crypto-05 > > and I have no reservations for taking that one to our ADs. > Agree 100% Regards Steinthor _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Mon Oct 6 10:04:12 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 916973A6A48; Mon, 6 Oct 2008 10:04:12 -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 CCF3C3A6ADA for ; Mon, 6 Oct 2008 10:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] 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 4-kxFIAoGPDQ for ; Mon, 6 Oct 2008 10:04:09 -0700 (PDT) Received: from smtp-out3.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 24DE13A6A24 for ; Mon, 6 Oct 2008 10:04:08 -0700 (PDT) Received: from zps19.corp.google.com (zps19.corp.google.com [172.25.146.19]) by smtp-out.google.com with ESMTP id m96H4B9X003745; Mon, 6 Oct 2008 18:04:12 +0100 Received: from smtp.corp.google.com (spacemonkey1.corp.google.com [192.168.120.115]) by zps19.corp.google.com with ESMTP id m96H49Mr013738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 6 Oct 2008 10:04:09 -0700 Received: from [192.168.119.190] ([208.253.108.65]) (authenticated bits=0) by smtp.corp.google.com (8.13.8/8.13.8) with ESMTP id m96H477S025900 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 6 Oct 2008 10:04:08 -0700 Message-Id: <009367E2-2AA0-415D-8721-A6FEB865A393@kumari.net> From: Warren Kumari To: "Smith, Donald" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v926) Date: Mon, 6 Oct 2008 13:04:05 -0400 References: <48C95C1A.4070408@bogus.com> <178FCC47-B446-4FB6-8F60-058D70FF4F51@kumari.net> X-Mailer: Apple Mail (2.926) Cc: opsec wg mailing list Subject: Re: [OPSEC] http://www.ietf.org/internet-drafts/draft-kumari-blackhole-urpf-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"; DelSp="yes" Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org On Sep 29, 2008, at 5:04 PM, Smith, Donald wrote: > > > (coffee != sleep) & (!coffee == sleep) > Donald.Smith@qwest.com gcia > >> -----Original Message----- >> From: Warren Kumari [mailto:warren@kumari.net] >> Sent: Friday, September 26, 2008 10:39 PM >> To: Smith, Donald >> Cc: Joel Jaeggli; opsec wg mailing list >> Subject: Re: [OPSEC] >> http://www.ietf.org/internet-drafts/draft-kumari-blackhole- >> urpf-00.txt >> >> On Sep 11, 2008, at 3:00 PM, Smith, Donald wrote: >> >>> First let me say this is valuable work and it is well done. >>> It should be accepted as a WG document. >> >> >> Cool, thanks... > Minor grammer issue: > > 3: A BGP policy is configured on all routers that have the discard > route so that routes announced with with the community [IANA - > INSERT > REGISTERED COMMUNITY HERE] will have their next hop set to the > discard address. > > Too many "with"s. Thanks, fixed! > > >> >> >> >>> >>> It suffers from inconsistent use of the following teams >> which appear >>> to >>> mean the same thing I recommend Remote Triggered Black Hole >> filtering >>> but which ever term is used should be used consistently. >> >> I *think* that I have caught all occurrences of this -- the term >> "Remote Triggered Black Hole filtering" made the document feel very >> long, so I am using the acronym "RTBH filtering". Please >> let me know >> if I missed any (other than where I define it in the Abstract and >> Introduction.) > This is nearly impossible and removes some of the resilency of the > internet. > Most Peers can not filter announcements from other peers to a specific > set of cidr blocks. > If we started filtering, lost a link, had a customer come up on their > backup link with another carrier we would allow them to advertise that > to us. Most dual homed customers would be affected in a situation like > this. So peers don't filter peers announcments (much). > > "While administrators may choose to drop any prefixes they wish, it is > recommended when employing source-based RTBH inter-domain that > explicit policy be defined that enables peers to only announce > source-based RTBH routes for prefixes which they originate." Doh! I meant customers --- providers should already be filtering their customers so that they can only announce space that "belongs" to them. As I often (incorrectly) use the word "peer" to refer to any sort of BGP session where routes are exchanged, I will go check If I have made this mistake anywhere else (I must admit that I also use the phrase "class C" to refer to any network with a mask of /24, call the screen on an digital watch an "LCD display" and ask for "Coke" when I want a soda...) > > > >>> >>> >>> Triggered black-hole routing, Remote triggered black hole >> routing and >>> RTBH filtering. >>> >>> >>> If "As a matter of policy, operators SHOULD NOT accept >> source-based >>> RTBH >>> announcements from their peers or customers" then why >> bother asking >>> for >>> a registered community from IANA? >> >> >> I realized that I was not very clear here -- I have tried to reword >> bits so that it is more clear that the IANA community should only be >> used for destination RTBH filtering and that communities with the AS >> number as the first 2 octets (RFC1997-style?!) should be used and >> carefully filtered.... > I reread it. It is much better now. Cool, thanks! > > > >> >>> >>> >>> The cisco and juniper examples only covers destination based RTBH >>> filtering no urpf statements are included and therefore source based >>> RTBH is not provided by the example configs. That may have been the >>> intention of the authors but it wasn't what I expected. >>> >> >> I have included uRPF in the examples (actually I do not have >> access to >> any lab devices at the moment, so I have not pasted the configs to >> make sure that they are correct... ) >> >> >>> Does this imply that strict mode urpf can't be used for source based >>> RTBH? >>> >>> "In loose mode some vendors also verify that the destination route >>> does not point to a discard interface." >>> If so going from strict mode to loose to support source >> based RTBH has >>> some serious security implications. >> >> After having a bit more time to digest your comment, I realized that >> once again I was unclear -- if you already have strict (or feasible >> path) uRPF deployed, you are fine -- unfortunately some ASes are >> unable to deploy uRPF in this manner, but can at least deploy loose >> mode uRPF. If these ASes use a vendor that "also verify that the >> destination route does not point to a discard interface" they can >> still get the source-based RTBH benefits... I *think* hat I have now >> done a better job of wording this... > > This is how you have it now. > "By combining traditional RTBH filtering with unicast Reverse Path > Forwarding (uRPF [RFC3704]) a network operator can filter based upon > source address. uRPF performs a route lookup of the source address > of > the packet and checks to see if the ingress interface of the packet > is a valid egress interface for the packet source address (strict > mode) or if any route or the source address of the packet exists > (loose mode). If the check fails, the packet is (generally) > dropped. > In loose mode some vendors also verify that the destination route > does not point to a discard interface - this allows source based > RTBH > filtering to be deployed in networks that cannot implement strict > (or > feasible path) mode uRPF." > > > I think this is more correct, you appear to be mixxing up feasible > path > and loose mode. > "By combining traditional RTBH filtering with unicast Reverse Path > Forwarding (uRPF [RFC3704]) a network operator can filter based upon > source address. uRPF performs a route lookup of the source address > of > the packet and checks to see if the ingress interface of the packet > is a valid egress interface for the packet source address (strict > mode, feasible path), or is THE valid egress interface (strict mode, > active path) > or if any route to the source address of the packet exists > (loose mode). If the check fails, the packet is (generally) > dropped. > In strick or loose mode some vendors also verify that the > destination > route > does not point to a discard interface. This allows source based RTBH > filtering to be deployed in networks that cannot implement strict > mode uRPF but can implement loose mode." > > > You might even want to drop the entire feasible-paths vs active-paths > and just stick to strict and loose modes. I am not sure the active- > paths > | feasible-paths comes into play. Great, thank you for your text, it does a MUCH better job of explaining what I intended... I think that leaving in some mention of active / feasible / loose, etc is a good idea so that people are aware that it can be deployed even if the provider is currently running mode X... Thoughts? > > > >> >> Unfortunately some networks are unable to deploy even loose >> mode uRPF >> (due to interesting peering arrangements / scaling tricks (and / or >> during convergence) it is possible for a router to receive a packet >> and have no route for the source address of that packet) -- I have >> spoken to one vendor requesting that they implement yet another uRPF >> mode (let's call it "dos-mitigation" mode for now[0]) where the uRPF >> check is relaxed even further. The logic basically becomes: >> >> If ((route_exists_for_source) && (next_hop_for_source == DISCARD)) { >> (increment uRPF drop counter, drop packet) >> } else { >> (increment uRPF accept counter, accept packet, normal processing >> here...) >> } > > Interesting. > How about: >> If ((next_hop_for_source == DISCARD)) { >> (increment uRPF drop counter, drop packet) >> } else { >> (increment uRPF accept counter, accept packet, normal processing >> here...) >> } > That would eliminate the route check which I don't think you really > want > in this case. Hmmm... Fair enough... (the "next_hop_for_source" lookup includes the "route exists" check :-)) I will get around to posting -02 sometime soon (with your suggestions), or maybe just wait till this is officially accepted as a WG doc.... W > >> >> >> Thank you for all of your comments -- hopefully I have managed to >> integrate them into the doc (I have just posted -01) -- >> please have a >> look and let me know. >> >> Also, apologies again to everyone for taking so long to respond to >> emails, the random disjointedness of my replies, etc... My >> parents are >> visiting from South Africa and are staying with my wife and I for a >> month or so -- I have taken time off work to show them >> around, etc -- >> this has completely destroyed my routine and productivity.... >> >> >> W >> >> >>> >>> >>> Security through obscurity WORKS against some worms and ssh >> attacks:) >>> Donald.Smith@qwest.com giac >>> >>>> -----Original Message----- >>>> From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] >>>> On Behalf Of Joel Jaeggli >>>> Sent: Thursday, September 11, 2008 11:58 AM >>>> To: opsec wg mailing list >>>> Subject: >>>> [OPSEC]http://www.ietf.org/internet-drafts/draft-kumari-blackh >>>> ole-urpf-00.txt >>>> >>>> Was one of the upcoming documents mentioned in the dublin meeting. >>>> >>>> this document expands on the method in RFC3882 and I think >> much more >>>> accurately represents current operational practice. >>>> >>>> some review on it's current form and consensus as to whether we >>>> should >>>> accept it as a working group document would be appreciated. >>>> >>>> Thanks >>>> joelja >>>> _______________________________________________ >>>> 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. >>> _______________________________________________ >>> 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 Thu Oct 9 00:59: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 B94743A6C79; Thu, 9 Oct 2008 00:59: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 BBC823A6C68 for ; Thu, 9 Oct 2008 00:59:02 -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 vcGATjhkBCIA for ; Thu, 9 Oct 2008 00:58:57 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id AB7D33A6C79 for ; Thu, 9 Oct 2008 00:58:57 -0700 (PDT) Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id m997xWwb014188; Thu, 9 Oct 2008 02:59:33 -0500 (CDT) Received: from inexp02.in.lucent.com ([135.254.223.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Oct 2008 02:59:32 -0500 Received: from INEXC1U01.in.lucent.com ([135.254.223.26]) by inexp02.in.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Oct 2008 13:29:28 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 9 Oct 2008 13:29:27 +0530 Message-ID: <6D26D1FE43A66F439F8109CDD42419650200B154@INEXC1U01.in.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-bhatia-manral-igp-crypto-requirements-00.txt Thread-Index: AcklyL0wFx8h/26sQoiIn+iEsW4zFAB2XYAQAIoBOfA= References: <92c950310808250646t50c00ce0w8a778dc19c08188b@mail.gmail.com> <77ead0ec0809302014p336614afp433ea8de040713c5@mail.gmail.com><6D26D1FE43A66F439F8109CDD424196501ED2F61@INEXC1U01.in.lucent.com> <48E6D46B.7020401@bogus.com> From: "Bhatia, Manav \(Manav\)" To: "Steinthor Bjarnason \(sbjarnas\)" , X-OriginalArrivalTime: 09 Oct 2008 07:59:28.0386 (UTC) FILETIME=[F43F9620:01C929E4] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: [OPSEC] draft-bhatia-manral-igp-crypto-requirements-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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Hi, > > > > http://tools.ietf.org/html/draft-bhatia-manral-igp-crypto-requ > irements-00 > > > > I have concerns about this document making protocol > > requirements within the scope of our charter. Making this a > > set of protocol best practices I think hews more closely to > > our charter (and doesn't belong in routing). > > > > any thoughts on that? > > > I see the benefit in having a document which recommends which routing > protocol authentication schemes to use. Having such a document > available, will automatically put pressure on the routing protocol > developers to implement what's missing (in case there are still some > implementations out there which still do not support this). Agree. I think this document too falls in the purview of OPSEC as this would ensure interop between disparate router implementations where at least one strong crypto algorithm is available that's implemented by all vendors. For example, we need to move folks using OSPF away from keyed MD5 and there should be some document that suggests that. It should also be noted that an algorithm that's considered strong today can be broken tomorrow and may have vulnerabilities that can be exploited. In such cases, we must have a document that vendors/operators can look up against, before implementing/using a routing protocol security scheme. This document does exactly that - it, to cite the same example, discourages people running OSPF from using keyed MD5 (it's a MUST-) and encourages the use of HMAC-SHA-1 [x] and other stronger algorithms. > > So, I suggest this document should be adopted by the WG but > with a more > "recommend/best practice" focus. It should be a standards track document. Please look at RFC 4307, 4835, etc. > > > problems with manual keying seems straight up our alley. > > > > http://tools.ietf.org/html/draft-manral-rpsec-existing-crypto-05 > > > > and I have no reservations for taking that one to our ADs. > > > Agree 100% True. Cheers, Manav [x] http://tools.ietf.org/html/draft-ietf-ospf-hmac-sha-02 _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Fri Oct 10 13:59: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 4DDE53A6A71; Fri, 10 Oct 2008 13:59: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 A4DDB3A6A65 for ; Fri, 10 Oct 2008 13:59:01 -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 BuWL-baVGzsh for ; Fri, 10 Oct 2008 13:59:01 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id ADBCF3A6810 for ; Fri, 10 Oct 2008 13:59:00 -0700 (PDT) Received: from [192.103.16.227] ([192.103.16.227]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id m9AKxeiK050009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 10 Oct 2008 20:59:41 GMT (envelope-from joelja@bogus.com) Message-ID: <48EFC226.20002@bogus.com> Date: Fri, 10 Oct 2008 13:59:18 -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.3/8410/Fri Oct 10 19:25:22 2008 on nagasaki.bogus.com X-Virus-Status: Clean Subject: [OPSEC] Housekeeping... Fall IETF. 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 If you'd like to getting an early start on the agenda for the next meeting and have an item you'd like to present on please drop me a line... I've already heard from Fernando. _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Fri Oct 10 14:02:17 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 941803A67F4; Fri, 10 Oct 2008 14:02:17 -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 EC4C03A67F4 for ; Fri, 10 Oct 2008 14:02:15 -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 pmBTyvTNk9hs for ; Fri, 10 Oct 2008 14:02:15 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id A30363A67A7 for ; Fri, 10 Oct 2008 14:02:14 -0700 (PDT) Received: from [192.103.16.227] ([192.103.16.227]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id m9AL2xec050246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 10 Oct 2008 21:03:00 GMT (envelope-from joelja@bogus.com) Message-ID: <48EFC302.9060007@bogus.com> Date: Fri, 10 Oct 2008 14:02:58 -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.3/8410/Fri Oct 10 19:25:22 2008 on nagasaki.bogus.com X-Virus-Status: Clean Subject: [OPSEC] consensus on draft-manral-rpsec-existing-crypto-05 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 Based on input I think we have consensus to accept this document as a working group document. _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Fri Oct 10 14:08:59 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 32FA13A69D2; Fri, 10 Oct 2008 14:08:59 -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 52C6B3A69D2 for ; Fri, 10 Oct 2008 14:08:58 -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 g1PJWdRMdWsu for ; Fri, 10 Oct 2008 14:08:57 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 52BD93A67F4 for ; Fri, 10 Oct 2008 14:08:57 -0700 (PDT) Received: from [192.103.16.227] ([192.103.16.227]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id m9AL9g7f050457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 10 Oct 2008 21:09:43 GMT (envelope-from joelja@bogus.com) Message-ID: <48EFC495.3090607@bogus.com> Date: Fri, 10 Oct 2008 14:09:41 -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.3/8410/Fri Oct 10 19:25:22 2008 on nagasaki.bogus.com X-Virus-Status: Clean Subject: [OPSEC] draft-bhatia-manral-igp-crypto-requirements-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org We have at least some supporting opinion that this work should not be pursued in opsec if it defines requirements. With a recommendations or best practices focus it would be an appropriate addition. We should be willing to entertain alternative views but I think that's the current sense. joelja _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Wed Oct 22 14:15:04 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 58A7F3A6BA8; Wed, 22 Oct 2008 14:15:04 -0700 (PDT) X-Original-To: opsec@ietf.org Delivered-To: opsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E257E28C12E; Wed, 22 Oct 2008 14:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081022211501.E257E28C12E@core3.amsl.com> Date: Wed, 22 Oct 2008 14:15:01 -0700 (PDT) Cc: opsec@ietf.org Subject: [OPSEC] I-D ACTION:draft-ietf-opsec-routing-protocols-crypto-issues-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: , Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org --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 : Issues with existing Cryptographic Protection Methods for Routing Protocols Author(s) : S. Hares, M. Bhatia, V. Manral, R. White Filename : draft-ietf-opsec-routing-protocols-crypto-issues-00.txt Pages : 16 Date : 2008-10-21 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opsec-routing-protocols-crypto-issues-00.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-routing-protocols-crypto-issues-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-22140834.I-D@ietf.org> --NextPart 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 --NextPart-- From opsec-bounces@ietf.org Sat Oct 25 21:38: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 4B28F3A690B; Sat, 25 Oct 2008 21:38: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 32E963A6904 for ; Sat, 25 Oct 2008 21:38:19 -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 Y53FevI-T22X for ; Sat, 25 Oct 2008 21:38:18 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 31E2D3A6783 for ; Sat, 25 Oct 2008 21:38:18 -0700 (PDT) Received: from [192.168.1.117] (c-24-130-16-195.hsd1.ca.comcast.net [24.130.16.195]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id m9Q4dfEn018234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 26 Oct 2008 04:39:42 GMT (envelope-from joelja@bogus.com) Message-ID: <4903F48C.3090705@bogus.com> Date: Sat, 25 Oct 2008 21:39:40 -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.3/8493/Sat Oct 25 21:28:40 2008 on nagasaki.bogus.com X-Virus-Status: Clean Subject: [OPSEC] Draft deadlines... 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 Note that October 27, Monday is the Internet Draft Cut-off for initial document (-00) submission by 17:00 PDT (24:00 UTC/GMT). The deadline for draft revisions is November 3, Monday, Internet Draft final submission cut-off by 17:00 PT (01:00 Tuesday, November 4 UTC/GMT). thanks joel _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Thu Oct 30 13:28: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 8ECF93A67EA; Thu, 30 Oct 2008 13:28: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 B0E463A67EA for ; Thu, 30 Oct 2008 13:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] 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 zZNjIk4ltsVY for ; Thu, 30 Oct 2008 13:28:33 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id BB0DF3A67D6 for ; Thu, 30 Oct 2008 13:28:32 -0700 (PDT) Received: from [192.168.11.143] (c-67-171-158-173.hsd1.wa.comcast.net [67.171.158.173]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id m9UKSS6e099706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 30 Oct 2008 20:28:30 GMT (envelope-from joelja@bogus.com) Message-ID: <490A18EC.7030401@bogus.com> Date: Thu, 30 Oct 2008 13:28:28 -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.3/8544/Thu Oct 30 18:59:19 2008 on nagasaki.bogus.com X-Virus-Status: Clean Subject: [OPSEC] http://tools.ietf.org/html/draft-kumari-blackhole-urpf-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsec-bounces@ietf.org Errors-To: opsec-bounces@ietf.org Made it into the tool recently. This version addresses some of the commentary on previous versions. I except that we'll ask for consesus on accepting this as a working group document at Minneapolis. Any commentary on the revised draft would be appreciated. diffs are here: http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=http://tools.ietf.org/id/draft-kumari-blackhole-urpf-02.txt thanks joel _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Thu Oct 30 14:08:50 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 6A7ED3A6B29; Thu, 30 Oct 2008 14:08:50 -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 08D4A3A6B29 for ; Thu, 30 Oct 2008 14:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=0.400, 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 uhrMFPLYiLwE for ; Thu, 30 Oct 2008 14:08:48 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 078333A6906 for ; Thu, 30 Oct 2008 14:08:47 -0700 (PDT) Received: from [192.168.11.143] (c-67-171-158-173.hsd1.wa.comcast.net [67.171.158.173]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id m9UL8hlH001505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 30 Oct 2008 21:08:44 GMT (envelope-from joelja@bogus.com) Message-ID: <490A225A.1020504@bogus.com> Date: Thu, 30 Oct 2008 14:08:42 -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.3/8544/Thu Oct 30 18:59:19 2008 on nagasaki.bogus.com X-Virus-Status: Clean Subject: [OPSEC] Currently on deck for Minneapolis 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 Fernando wants time for: draft-gont-opsec-ip-security draft-gont-opsec-icmp-filtering I'm presuming we'll want to dicuss: draft-bhatia-manral-igp-crypto-requirements draft-ietf-opsec-routing-protocols-crypto-issues and draft-kumari-blackhole-urpf-02 anything else that should be on the agenda let me know... thanks joelja _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From opsec-bounces@ietf.org Thu Oct 30 15:21:08 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 B2C063A6B53; Thu, 30 Oct 2008 15:21:08 -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 0C6DE3A6B45 for ; Thu, 30 Oct 2008 15:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 LN8zHjBnA8QF for ; Thu, 30 Oct 2008 15:21:06 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 226B83A6B20 for ; Thu, 30 Oct 2008 15:21:05 -0700 (PDT) Received: from [192.168.11.143] (c-67-171-158-173.hsd1.wa.comcast.net [67.171.158.173]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id m9UML1OB004613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 30 Oct 2008 22:21:03 GMT (envelope-from joelja@bogus.com) Message-ID: <490A334D.9030204@bogus.com> Date: Thu, 30 Oct 2008 15:21:01 -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 Content-Type: multipart/mixed; boundary="------------050702020806000304080003" X-Virus-Scanned: ClamAV 0.93.3/8545/Thu Oct 30 21:39:18 2008 on nagasaki.bogus.com X-Virus-Status: Clean Subject: [OPSEC] FYI: OPSEC - Requested session has been scheduled for IETF 73 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. --------------050702020806000304080003 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit --------------050702020806000304080003 Content-Type: message/rfc822; name="OPSEC - Requested session has been scheduled for IETF 73.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="OPSEC - Requested session has been scheduled for IETF 73.eml" Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on nagasaki.bogus.com X-Spam-Level: X-Spam-Status: No, score=-0.5 required=4.0 tests=AWL,NO_RELAYS autolearn=disabled version=3.2.5 Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id m9UM8EGQ003988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 30 Oct 2008 22:08:14 GMT (envelope-from wwwrun@core3.amsl.com) Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvfgQ-000NbH-4f for joelja@bogus.com; Thu, 30 Oct 2008 22:08:09 +0000 Received: by core3.amsl.com (Postfix, from userid 30) id 10F1928C1C3; Thu, 30 Oct 2008 15:08:01 -0700 (PDT) From: IETF Secretariat To: joelja@bogus.com Cc: jabley@ca.afilias.info, dromasca@avaya.com, rbonica@juniper.net, session-request@ietf.org Subject: OPSEC - Requested session has been scheduled for IETF 73 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20081030220802.10F1928C1C3@core3.amsl.com> Date: Thu, 30 Oct 2008 15:08:02 -0700 (PDT) X-Virus-Scanned: ClamAV 0.93.3/8544/Thu Oct 30 18:59:19 2008 on nagasaki.bogus.com X-Virus-Status: Clean Dear Joel Jaeggli, The sessions that you have requested have been scheduled. Below is the scheduled session information followed by the information of sessions that you have requested. OPSEC Session 1 (1 hour) Tuesday, Afternoon Session II 1520-1700 Room Name: Meeting Room ---------------------------------------------- Requested Information: --------------------------------------------------------- Working Group Name: opsec Area Name: Operations and Management Area Session Requester: Joel Jaeggli Number of Sessions: 1 Length of Session(s): 1 hour Number of Attendees: 30 Conflicts to Avoid: First Priority: opsarea Second Priority: 6lowpan opsawg Third Priority: sidr Special Requests: --------------------------------------------------------- --------------050702020806000304080003 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 --------------050702020806000304080003--