From joelja@bogus.com Thu Feb 5 18:22:31 2009 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A706028C177 for ; Thu, 5 Feb 2009 18:22:31 -0800 (PST) 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 Dle2WrQPklDC for ; Thu, 5 Feb 2009 18:22:31 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id A8D8028C16D for ; Thu, 5 Feb 2009 18:22:30 -0800 (PST) Received: from [192.168.1.135] (c-98-207-155-97.hsd1.ca.comcast.net [98.207.155.97]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id n162MSHX060015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 6 Feb 2009 02:22:29 GMT (envelope-from joelja@bogus.com) Message-ID: <498B9EE3.30400@bogus.com> Date: Thu, 05 Feb 2009 18:22:27 -0800 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: opsec wg mailing list References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.94.2/8957/Thu Feb 5 17:31:01 2009 on nagasaki.bogus.com X-Virus-Status: Clean Subject: Re: [OPSEC] draft-ietf-opsec-blackhole-urpf-00 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 02:22:31 -0000 Warren Kumari wrote: > Now, for the big question: > > In the draft we are are requesting a registered BGP community to be used > to signal your provider that you want destination based RTBH applied to > an announced prefix. So I presented this idea and both viewpoints in the NANOG isp security BOF and to be honest I couldn't get a rise out of anyone, They neither called me a moron nor adopted it as their own... I suppose one thought would be to carve it out and drop it in a second draft so we can proceed this document without it. Personally I think a reserved community has sufficient utility to make it a useful addition to the toolkit, but reviews here are obviously mixed. > There are two viewpoints on this -- I will try to capture them both, > apologies if I mess this up: > Viewpoint 1: > This should be removed -- different providers will implement RTBH (src > and dest) in different ways and will provide different capabilities > (drop on the "edge", only install in a specific region, etc) and so > there will need to be multiple communities. Getting this info from your > provider (and having them enable the feature), etc is (and should > remain) a required step. > > Viewpoint 2: > I'd like to keep the registered community -- while different providers > will support different subsets of this, having a well known way to > enable this seems good to me. Currently providers support different > communities for different things (e.g: announce this only to peers, set > the MED, etc) but there are still some well known (e.g NO_EXPORT) > communities that the provider probably implements. I dislike being in > the situation where I am experiencing a DoS attack and have misplaced > the napkin that I scribbled the secret community on last time. Now, > while I am down I need to fight my way through Tier 1 - Tier N trying to > find the magic community to apply for provider X. I'd rather just tag an > announcement with the registerd RTBH community. If the provider doesn't > support this, I'm no worse off, if they do, I've bought some time. From joelja@bogus.com Thu Feb 5 21:52:09 2009 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C07253A6B18 for ; Thu, 5 Feb 2009 21:52:09 -0800 (PST) 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 OKZTL-2AVB1V for ; Thu, 5 Feb 2009 21:52:08 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 954ED3A6A05 for ; Thu, 5 Feb 2009 21:52:07 -0800 (PST) Received: from [192.168.1.135] (c-98-207-155-97.hsd1.ca.comcast.net [98.207.155.97]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id n165q5LS073072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 6 Feb 2009 05:52:06 GMT (envelope-from joelja@bogus.com) Message-ID: <498BD004.5060901@bogus.com> Date: Thu, 05 Feb 2009 21:52:04 -0800 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: opsec wg mailing list X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.94.2/8957/Thu Feb 5 17:31:01 2009 on nagasaki.bogus.com X-Virus-Status: Clean Subject: [OPSEC] Some timeline items... X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 05:52:09 -0000 Significantly before the dealine I asked for a 1 hour slot in San Francisco. If you have items you'd like to place on the agenda, raising a flag in the next two weeks or so would be a good idea... If we don't have any burning issues that aren't better addressed on the mailing list it may not be critical that we convene in SF. The deadline for iterating documents for discussion in SF is March 9th. The fact that the deadline is 5 weeks away does not of course preclude us from conducting business on the working group documents in the interim. so from the important dates: February 13, 2009 Friday - Preliminary agenda published for comment. March 2, 2009 Monday - Final agenda to be published. March 2, 2009 Monday - Internet Draft Cut-off for initial document (-00) submission by 17:00 PST (01:00 Tuesday, March 3 UTC/GMT), upload using IETF ID Submission Tool. March 9, 2009 Monday - Internet Draft final submission cut-off by 17:00 PDT (24:00 UTC/GMT), upload using IETF ID Submission Tool. March 11, 2009 Wednesday - Draft Working Group agendas due by 17:00 PDT (24:00 UTC/GMT), upload using IETF Meeting Materials Management Tool. March 22-27, 2009 - 74th IETF Meeting in San Francisco, CA, USA cheers joel From Donald.Smith@qwest.com Fri Feb 6 07:50:42 2009 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17FA428C246 for ; Fri, 6 Feb 2009 07:50:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.04 X-Spam-Level: X-Spam-Status: No, score=-2.04 tagged_above=-999 required=5 tests=[AWL=-0.240, 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 UWtFGbTgPeAW for ; Fri, 6 Feb 2009 07:50:41 -0800 (PST) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by core3.amsl.com (Postfix) with ESMTP id 28E4428C0FF for ; Fri, 6 Feb 2009 07:50:41 -0800 (PST) Received: from suomp60i.qintra.com (suomp60i.qintra.com [151.117.69.27]) by sudnp799.qwest.com (8.14.0/8.14.0) with ESMTP id n16FoeAY023128; Fri, 6 Feb 2009 08:50:40 -0700 (MST) Received: from ITDENE2KSM01.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.0/8.14.0) with ESMTP id n16FoVSk013790; Fri, 6 Feb 2009 09:50:34 -0600 (CST) Received: from qtdenexhtm21.AD.QINTRA.COM ([151.119.91.230]) by ITDENE2KSM01.AD.QINTRA.COM with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Feb 2009 08:50:34 -0700 Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm21.AD.QINTRA.COM ([151.119.91.230]) with mapi; Fri, 6 Feb 2009 08:50:28 -0700 From: "Smith, Donald" To: "'Joel Jaeggli'" , "'opsec wg mailing list'" Date: Fri, 6 Feb 2009 08:50:26 -0700 Thread-Topic: [OPSEC] draft-ietf-opsec-blackhole-urpf-00 Thread-Index: AcmIAcfQhfkndigkRuqoZKOhUdnBcwAb35pQ Message-ID: References: <498B9EE3.30400@bogus.com> In-Reply-To: <498B9EE3.30400@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 06 Feb 2009 15:50:34.0545 (UTC) FILETIME=[A5C32A10:01C98872] Subject: Re: [OPSEC] draft-ietf-opsec-blackhole-urpf-00 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 15:50:42 -0000 (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com gcia =20 > -----Original Message----- > From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org]=20 > On Behalf Of Joel Jaeggli > Sent: Thursday, February 05, 2009 7:22 PM > To: opsec wg mailing list > Subject: Re: [OPSEC] draft-ietf-opsec-blackhole-urpf-00 >=20 > Warren Kumari wrote: > > Now, for the big question: > >=20 > > In the draft we are are requesting a registered BGP=20 > community to be used > > to signal your provider that you want destination based=20 > RTBH applied to > > an announced prefix. >=20 > So I presented this idea and both viewpoints in the NANOG isp security > BOF and to be honest I couldn't get a rise out of anyone, They neither > called me a moron nor adopted it as their own... >=20 > I suppose one thought would be to carve it out and drop it in a second > draft so we can proceed this document without it. Personally I think a > reserved community has sufficient utility to make it a useful addition > to the toolkit, but reviews here are obviously mixed. >=20 > > There are two viewpoints on this -- I will try to capture them both, > > apologies if I mess this up: > > Viewpoint 1: > > This should be removed -- different providers will=20 > implement RTBH (src > > and dest) in different ways and will provide different capabilities > > (drop on the "edge", only install in a specific region, etc) and so > > there will need to be multiple communities. Getting this=20 > info from your > > provider (and having them enable the feature), etc is (and should > > remain) a required step. That sounds like what I said:) I agree with 1. > >=20 > > Viewpoint 2: > > I'd like to keep the registered community -- while=20 > different providers > > will support different subsets of this, having a well known way to > > enable this seems good to me. Currently providers support different > > communities for different things (e.g: announce this only=20 > to peers, set > > the MED, etc) but there are still some well known (e.g NO_EXPORT) > > communities that the provider probably implements. I=20 > dislike being in > > the situation where I am experiencing a DoS attack and have=20 > misplaced > > the napkin that I scribbled the secret community on last time. Now, It had better be better documented then scribbled on a napkit. It should be part of a standard operations document that your NOC has avail= able to them:) > > while I am down I need to fight my way through Tier 1 -=20 > Tier N trying to > > find the magic community to apply for provider X. I'd=20 > rather just tag an > > announcement with the registerd RTBH community. If the=20 > provider doesn't > > support this, I'm no worse off, if they do, I've bought some time. If the provide supports it but only allows /32s or only allows you to adver= tise your own space (tm good idea) you might be worse off especally if you think you have done something to mi= tigate an attack only to find that the mitigation didn't work because you a= dvertised a /30 or space you don't own/route or ... So while I lean away from a reserved community the worse effect I can come = up with is you think you started mitigation but it hasn't started yet. It w= ouldn't be long before a victim realized the mitigation isn't working and c= ontacted their upstream to find out why:) > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > = From joelja@bogus.com Fri Feb 13 19:27:20 2009 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 495203A69B3; Fri, 13 Feb 2009 19:27:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBX0xXqe0rZK; Fri, 13 Feb 2009 19:27:19 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 5EE0D3A682B; Fri, 13 Feb 2009 19:27:19 -0800 (PST) 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 n1E3RMgI076517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 14 Feb 2009 03:27:23 GMT (envelope-from joelja@bogus.com) Message-ID: <49963A14.1090106@bogus.com> Date: Fri, 13 Feb 2009 19:27:16 -0800 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Keith Moore References: <4994A4EB.5030607@gmail.com> <0B030ADA-F621-4FDF-9CAF-23A27C16E26B@multicasttech.com> <49961BDB.9030905@network-heretics.com> In-Reply-To: <49961BDB.9030905@network-heretics.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.94.2/8989/Fri Feb 13 18:29:24 2009 on nagasaki.bogus.com X-Virus-Status: Clean Cc: opsec wg mailing list , Marshall Eubanks , IETF discussion list Subject: Re: [OPSEC] Fwd: Security Assessment of the Transmission Control Protocol (TCP) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2009 03:27:20 -0000 Keith Moore wrote: > Marshall Eubanks wrote: >> If I am reading this correctly the UK Centre for the Protection of >> National Infrastructure >> wants the IETF (or some other body) to produce a "companion document to >> the IETF specifications that discusses the security aspects and >> implications of the protocols, identifies the existing vulnerabilities, >> discusses the possible countermeasures, and analyses their respective >> effectiveness." > > It's difficult to imagine that these things could be adequately captured > in a static document, for TCP or any other protocol, because new threats > and countermeasures continue to be identified decades after the base > protocol is well-settled. Maybe something like an expanded version of > the RFC Editor's errata pages would be more appropriate? One might imagine an informational document which was routinely obsoleted by future iterations. Keeping it tractable is a product of necessarily limiting the scope. > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > From joelja@bogus.com Fri Feb 13 19:53:47 2009 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF5F73A6A38 for ; Fri, 13 Feb 2009 19:53:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QT7Hq3vP78GM for ; Fri, 13 Feb 2009 19:53:47 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id C68883A698F for ; Fri, 13 Feb 2009 19:53:46 -0800 (PST) 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 n1E3rpJk077754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 14 Feb 2009 03:53:52 GMT (envelope-from joelja@bogus.com) Message-ID: <49964049.4090207@bogus.com> Date: Fri, 13 Feb 2009 19:53:45 -0800 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: opsec wg mailing list X-Enigmail-Version: 0.95.7 Content-Type: multipart/mixed; boundary="------------080203020005030105010300" X-Virus-Scanned: ClamAV 0.94.2/8989/Fri Feb 13 18:29:24 2009 on nagasaki.bogus.com X-Virus-Status: Clean Subject: [OPSEC] [Fwd: OPSEC - Requested session has been scheduled for IETF 74] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2009 03:53:47 -0000 This is a multi-part message in MIME format. --------------080203020005030105010300 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit --------------080203020005030105010300 Content-Type: message/rfc822; name="OPSEC - Requested session has been scheduled for IETF 74.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="OPSEC - Requested session has been scheduled for IETF 74.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 n1E0BWN9066498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 14 Feb 2009 00:11:32 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 1LY87x-000H12-AN for joelja@bogus.com; Sat, 14 Feb 2009 00:11:26 +0000 Received: by core3.amsl.com (Postfix, from userid 30) id EF9EC3A6832; Fri, 13 Feb 2009 16:11:16 -0800 (PST) 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 74 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20090214001116.EF9EC3A6832@core3.amsl.com> Date: Fri, 13 Feb 2009 16:11:16 -0800 (PST) X-Virus-Scanned: ClamAV 0.94.2/8989/Fri Feb 13 18:29:24 2009 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 III 1710-1810 Room Name: Breakout 3 ---------------------------------------------- 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 idr Second Priority: 6lowpan opsawg Third Priority: sidr Special Requests: --------------------------------------------------------- --------------080203020005030105010300-- From moore@network-heretics.com Sat Feb 14 00:12:41 2009 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B68D63A68E1 for ; Sat, 14 Feb 2009 00:12:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tIs-7B80QA28 for ; Sat, 14 Feb 2009 00:12:41 -0800 (PST) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id 0F9023A67BD for ; Sat, 14 Feb 2009 00:12:41 -0800 (PST) Received: from lust.indecency.org (adsl-6-49-97.tys.bellsouth.net [65.6.49.97]) by m1.imap-partners.net (MOS 3.10.3-GA) with ESMTP id BJC00130 (AUTH admin@network-heretics.com) for opsec@ietf.org; Sat, 14 Feb 2009 00:12:43 -0800 (PST) Message-ID: <49967CF9.7090105@network-heretics.com> Date: Sat, 14 Feb 2009 03:12:41 -0500 From: Keith Moore User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Joel Jaeggli References: <4994A4EB.5030607@gmail.com> <0B030ADA-F621-4FDF-9CAF-23A27C16E26B@multicasttech.com> <49961BDB.9030905@network-heretics.com> <49963A14.1090106@bogus.com> In-Reply-To: <49963A14.1090106@bogus.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 14 Feb 2009 07:50:08 -0800 Cc: opsec wg mailing list , IETF discussion list Subject: Re: [OPSEC] Fwd: Security Assessment of the Transmission Control Protocol (TCP) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2009 08:12:41 -0000 Joel Jaeggli wrote: > Keith Moore wrote: >> Marshall Eubanks wrote: >>> If I am reading this correctly the UK Centre for the Protection of >>> National Infrastructure >>> wants the IETF (or some other body) to produce a "companion document to >>> the IETF specifications that discusses the security aspects and >>> implications of the protocols, identifies the existing vulnerabilities, >>> discusses the possible countermeasures, and analyses their respective >>> effectiveness." >> It's difficult to imagine that these things could be adequately captured >> in a static document, for TCP or any other protocol, because new threats >> and countermeasures continue to be identified decades after the base >> protocol is well-settled. Maybe something like an expanded version of >> the RFC Editor's errata pages would be more appropriate? > > One might imagine an informational document which was routinely > obsoleted by future iterations. Keeping it tractable is a product of > necessarily limiting the scope. I fear that our RFC approval and publication process has become so onerous that it imposes a significant barrier for dissemination of such information. Keith From jari.arkko@piuha.net Sat Feb 14 03:24:24 2009 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66ED03A69F4; Sat, 14 Feb 2009 03:24:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 xGJdBf5qRaHA; Sat, 14 Feb 2009 03:24:23 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 6FC513A68AB; Sat, 14 Feb 2009 03:24:23 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id AF9B419872A; Sat, 14 Feb 2009 13:24:27 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 4AC611986EF; Sat, 14 Feb 2009 13:24:27 +0200 (EET) Message-ID: <4996A99C.40003@piuha.net> Date: Sat, 14 Feb 2009 13:23:08 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Keith Moore References: <4994A4EB.5030607@gmail.com> <0B030ADA-F621-4FDF-9CAF-23A27C16E26B@multicasttech.com> <49961BDB.9030905@network-heretics.com> <49963A14.1090106@bogus.com> <49967CF9.7090105@network-heretics.com> In-Reply-To: <49967CF9.7090105@network-heretics.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Mailman-Approved-At: Sat, 14 Feb 2009 07:50:08 -0800 Cc: opsec wg mailing list , IETF discussion list Subject: Re: [OPSEC] Fwd: Security Assessment of the Transmission Control Protocol (TCP) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2009 11:24:24 -0000 Keith, Joel, >>> It's difficult to imagine that these things could be adequately captured >>> in a static document, for TCP or any other protocol, because new threats >>> and countermeasures continue to be identified decades after the base >>> protocol is well-settled. Maybe something like an expanded version of >>> the RFC Editor's errata pages would be more appropriate? >>> >> One might imagine an informational document which was routinely >> obsoleted by future iterations. Keeping it tractable is a product of >> necessarily limiting the scope. >> I am in favor of publishing things like these in informational RFCs. And no, we should not shoot for completeness, for obvious reasons. Jari From tglassey@earthlink.net Sat Feb 14 07:27:10 2009 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14C2F3A68A5; Sat, 14 Feb 2009 07:27:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[AWL=-0.110, 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 rV88o5PctSIZ; Sat, 14 Feb 2009 07:27:09 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 1A39A3A69C7; Sat, 14 Feb 2009 07:27:09 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=q4gQa5r99g9C82/f4KTbobk9+RoMDFNJpx2DUu4aUuC7/QPuQMGQBpzaB0qcTEwr; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [67.180.133.66] (helo=[192.168.1.101]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1LYMQ0-0003Mu-UJ; Sat, 14 Feb 2009 10:27:01 -0500 Message-ID: <4996E2C3.3030604@earthlink.net> Date: Sat, 14 Feb 2009 07:26:59 -0800 From: TSG User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Joel Jaeggli References: <4994A4EB.5030607@gmail.com> <0B030ADA-F621-4FDF-9CAF-23A27C16E26B@multicasttech.com> <49961BDB.9030905@network-heretics.com> <49963A14.1090106@bogus.com> In-Reply-To: <49963A14.1090106@bogus.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79b41deb07ca714905d2542f5e68a41e16350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.180.133.66 X-Mailman-Approved-At: Sat, 14 Feb 2009 07:50:08 -0800 Cc: opsec wg mailing list , Keith Moore , IETF discussion list Subject: Re: [OPSEC] Fwd: Security Assessment of the Transmission Control Protocol (TCP) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2009 15:27:10 -0000 Joel Jaeggli wrote: > Keith Moore wrote: > >> Marshall Eubanks wrote: >> >>> If I am reading this correctly the UK Centre for the Protection of >>> National Infrastructure >>> wants the IETF (or some other body) to produce a "companion document to >>> the IETF specifications that discusses the security aspects and >>> implications of the protocols, identifies the existing vulnerabilities, >>> discusses the possible countermeasures, and analyses their respective >>> effectiveness." >>> >> It's difficult to imagine that these things could be adequately captured >> in a static document, for TCP or any other protocol, because new threats >> and countermeasures continue to be identified decades after the base >> protocol is well-settled. Maybe something like an expanded version of >> the RFC Editor's errata pages would be more appropriate? >> > > One might imagine an informational document which was routinely > obsoleted by future iterations. Unfortunately this isnt new information - the liabilities of IP have been well identified and understood for years like the BGP4 flap as well. What the IETF still seems to fail to grasp is that it is responsible for its actions so its not taking security and the ability to produce reliable evidence of anything over a network transport are key factors and need to be built into any IETF endorsement that is issued in the form of a standard or standards-track effort. I also would suggest that the IETF be willing to support other protocols besides IP based - hell XNS was way more secure than IP is by its very design. Its not that TCP/IP is bad - its just that it wasnt designed as an evidentiary-grade data transport and that is nowadays a real issue. > > Keeping it tractable is a product of > necessarily limiting the scope. > I dont think so. Building an analysis scope which is defined to meet the evidence needs today would address this requirement and only need to be updated periodically to meet those changing evidence models. >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf >> >> > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > > From ayourtch@cisco.com Tue Feb 17 12:16:08 2009 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6046D3A6BFD for ; Tue, 17 Feb 2009 12:16:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCTWGzJFlBFX for ; Tue, 17 Feb 2009 12:16:07 -0800 (PST) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id A69853A6882 for ; Tue, 17 Feb 2009 12:16:06 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id n1HKGG101064; Tue, 17 Feb 2009 21:16:17 +0100 (CET) Received: from kk-son (dhcp-peg3-vl30-144-254-7-191.cisco.com [144.254.7.191]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id n1HKGEt04005; Tue, 17 Feb 2009 21:16:16 +0100 (CET) Date: Tue, 17 Feb 2009 21:17:22 +0100 (CET) From: Andrew Yourtchenko X-X-Sender: ayourtch@zippy.stdio.be To: Fernando Gont In-Reply-To: <20090129201501.C10D83A687E@core3.amsl.com> Message-ID: References: <20090129201501.C10D83A687E@core3.amsl.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: opsec@ietf.org Subject: Re: [OPSEC] review for draft-ietf-opsec-ip-security-01 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ayourtch@cisco.com List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 20:16:08 -0000 Hello, I've gone through the doc, below will go comments, anchored to the layout as per http://tools.ietf.org/html/draft-gont-opsec-ip-security-01 First, the references that did not get hyperlinked in the text of the document. It's a bit tedious to enumerate all, something similar to the following should list them: wget -o /dev/null -O - http://tools.ietf.org/html/draft-gont-opsec-ip-security-01 | egrep '\[ RFC1349 is obsoleted by the RFC2474 (DSCP), so this chapter needs a rewrite. [Page 9]: "3.4. Total Length..." The section talks about the corner cases with discrepancy of length value in the header and the actual packet length, but does not discuss any potential interaction with EMTU_R limitations in case there are any. 9kb limit - the document should have some specific references to the stacks that have it. Also, probably the reference to the RFC1122 (at least for the terminological definition of the EMTU_R?) [Page 11]: "3.5.2. Possible security improvements" TODO - discussion of a quality of IP ID of being able to provide a "fingerprint" of the remote host. [Page 17]: "Fingerprinting the physical device from which the packets originate" - orphan word sequence. [Page 21]: reference [Ed3f2002] is a dead link - also include http://www.phrack.org/issues.html?issue=60&id=12&mode=txt ? [Page 24]: "Enforce a limit on the maximum number of options" - to me this looks a bit of a dangerous recommendation in this form, as it would cause arbitrary hard limits set by middle devices, resulting in creation of "IP Option MTU". (Not that anyone is adding a lot of IP options anyway these days, so it is more a theoretical nitpick :-) [Page 28]: Discussion of the semantics of the "LSRR.Pointer" - might be also simpler (for some?) to say that this is a 1-based index of the starting byte which will be used as the first storage byte of the address, in an array of length LSRR.Length, starting with LSRR option type as the first element. [Page 31]: LSRR, SSRR and RR options - can their restrictions be combined as much as possible ? To me they look largely similar, and the repetition is a cause for potential mistakes, IMHO. [Page 41]: stray "" [Page 42]: Man in the middle threat mention for DSCP: is this the only field for which the MITM attacks are a concern ? [Page 51]: The sequence# check: should here be a reference to the section 3.4.3 of rfc2406 as a pointer to what constitutes the "valid sequence#" ? Step three: should there be more specifics about some randomization for the process of dropping ? Also - this algorithm omits the frequently used NAT-T (essentially IPSEC over UDP/4500) [Page 52]: "virtually impossible" - I'd replace this with "harder" :) And, as the MITM is mentioned for DSCP, I'd not make the task easier for IPSEC specifically :) the algorighm which is supposed to protect IPSEC should be able to resist the on-path attacker. "Unfortunately, some TCP/IP stacks, when performing fragmentation, send the corresponding fragments in reverse order. In such cases, at the point of flushing the fragment buffer, legitimate fragments will receive the same treatment as the possible forged fragments." Should have a reference to the stacks in question. [Page 53]: "Additionally, given that many middle-boxes such as firewalls create state according to the contents of the first fragment of a given packet, it is best that, in the event an end-system receives overlapping fragments, it honors the information contained in the fragment that was received first." received first if there was a box behind the middlebox that has reordered the packets afterwards, or if there was no such box ? :-) If the two received fragments contain conflicting information, we do not have enough info to discern which of the two is "correct", IMHO. So, we should mark the corresponding packet as "bad", treat the reassembly as usual, and then drop it with an auditable event. (not drop immediately in order to avoid the DoS where colliding fragments would be dropped and cause the accumulation of the remaining fragments till the max reassembly timeout occurs). [Page 54]: sending with high precedence values: ingress filtering ? (Also, with the DSCP/ToS duality, worth doublechecking on how does it translate to real forwarding devices?) [Page 55]: Address resolution: the passage about storing the packets for a long time on the router - isn't it something that should be directly discouraged, precisely because of its big impact ? [Page 56]: "Dropping packets": should be mentioned that all dropped packets should be *counted* somewhere ? thanks, andrew From fernando@gont.com.ar Sat Feb 21 15:37:18 2009 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B4273A6831; Sat, 21 Feb 2009 15:37:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.437 X-Spam-Level: X-Spam-Status: No, score=-1.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7mRl6x-T1-k6; Sat, 21 Feb 2009 15:37:16 -0800 (PST) Received: from smtp1.xmundo.net (unknown [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id C305A3A677D; Sat, 21 Feb 2009 15:37:14 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 4A7206B6576; Sat, 21 Feb 2009 20:37:34 -0300 (ART) Received: from [192.168.0.106] (131-131-17-190.fibertel.com.ar [190.17.131.131]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id n1LNbAXl004163; Sat, 21 Feb 2009 21:37:14 -0200 Message-ID: <49A0902B.2030906@gont.com.ar> Date: Sat, 21 Feb 2009 21:37:15 -0200 From: Fernando Gont User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: opsec@ietf.org, tcpm@ietf.org X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Sat, 21 Feb 2009 20:37:31 -0300 (ART) Subject: [OPSEC] Security Assessment of the Transmission Control Protocol (TCP) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 23:37:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello, folks, Last week the UK CPNI (United Kingdom's Centre for the Protection of National Infrastructure) released the document "Security Assessment of the Transmission Control Protocol (TCP)". The document analyzes the relevant specifications from a security point of view, and also analyzes the implications of some implementation strategies taken by popular TCP implementations. This document is available at: http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf As part of the same project, we have produced an IETF I-D version of the UK CPNI document, in the hope that the IETF works on this stuff and hopefully publishes some version of the aforementioned document. The resulting IETF I-D is entitled "Security Assessment of the Transmission Control Protocol (TCP)" (draft-gont-tcp-security-00.txt) and is available at: http://tools.ietf.org/id/draft-gont-tcp-security-00.txt Any comments 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iQEcBAEBCAAGBQJJoJAhAAoJEJbuqe/Qdv/x7AEIAKBKZUtyWYG3RZ3yYYty37wl ytw6eMKkKBk61Z6F41bVUzz6trgpHN80/m0DrwLSOCGKJjTaUJZ3ksCumD7ougjp BR5k5q90Tn2xFGpMOURvTwotmo+LDK+sR6VVDa0Tv5iIaWL2Daz91kLa/7aJCi8t TpABuCfAQ+VW08muA0nRM7CF2e1bgxSrwFp77xFkx7Sb8jCi9/L/Mk/lclg9Fzob +8kQNHMElXq1IsUAwDHfouE20MhEPVUDgqoyt0T+BHwCijdgu+QpIrnhioROIhd4 BauCRmEgFLymuodOjjpQOPt9/g1dF8Hvma6+wRIRz53F3d6HXHuql3T3CfP485Y= =UKKW -----END PGP SIGNATURE----- From vishwas.ietf@gmail.com Mon Feb 23 20:08:51 2009 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4E2F3A695F for ; Mon, 23 Feb 2009 20:08:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id au5M--8QaSJS for ; Mon, 23 Feb 2009 20:08:51 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by core3.amsl.com (Postfix) with ESMTP id D4DEC3A6960 for ; Mon, 23 Feb 2009 20:08:47 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so1205916qwe.31 for ; Mon, 23 Feb 2009 20:09:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=5ffqEtNhADaSHwF2iNAqQd93N1hWAz23mZbOVcAzXBk=; b=C/28KYXcyK/n/BQvpJW9vMwUW3y8VJUKtjWvucWJW29WWQAM4M+o+Rv+w88VPNztoz /tO+A0z1mHhf+lTpo214w7XAZHG3hwPN183WlJBwcDaUH0oIsM8eDGD1nAflKDXBz2eT AXz8P1+HAmhNg2CBd56TwXZNjEfdxEQPQ/Wzo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=DCzEb4wgAo+Clm4cPuWKWIaiuuLbJLhuuXWtkInxl38uD2j3qlz269Vn2VP3+7Mw8Z cCZlbVB1XJdFCU31/gKsXaAZRQlK6tgp3Ru294kPzsqtpIPVJXRL0VQCWckzFu1Y5d+L 1y6I1GuB7pZm1GCSLzy8cW440Xczhp+sfwLVw= MIME-Version: 1.0 Received: by 10.229.97.194 with SMTP id m2mr1759635qcn.21.1235448545165; Mon, 23 Feb 2009 20:09:05 -0800 (PST) Date: Mon, 23 Feb 2009 20:09:05 -0800 Message-ID: <77ead0ec0902232009s260cee0dn4f81390ddf698e1c@mail.gmail.com> From: Vishwas Manral To: opsec wg mailing list Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [OPSEC] draft-bhatia-manral-igp-crypto-requirements X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 04:08:51 -0000 Hi folks, We now have got some clear guidance regarding this document from the Security AD's regarding the cryptographic algorithms (Joel has been privy to those mails). The guidance seems to second what Hugo and other cryptographers have been stating all along. The crux of what has been said is: MD5 should not be used for crypto purposes. SHA-1 though stronger is also vulnerable. HMAC-MD5 though not yet vulnerable looks highly suspect and should not be reccomended. HMAC-SHA-1 for now looks ok and can be reccomended. Goinf forward we should try to reccomend the SHA-2 family of protocols. With these clear guidances matching what we have in our documents, I would like to ask the working group to look into this document further. We can then look at getting this as a WG document. Thanks, Vishwas From manav@alcatel-lucent.com Tue Feb 24 08:26:05 2009 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DCC53A67EA for ; Tue, 24 Feb 2009 08:26:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 vKDEjhMGrGeF for ; Tue, 24 Feb 2009 08:26:04 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 423733A6826 for ; Tue, 24 Feb 2009 08:26:03 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n1OGQKYq012833 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 24 Feb 2009 17:26:20 +0100 Received: from INBANSXCHHUB01.in.alcatel-lucent.com (135.250.12.32) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (135.120.45.63) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 24 Feb 2009 17:26:20 +0100 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Tue, 24 Feb 2009 21:56:18 +0530 From: "Bhatia, Manav (Manav)" To: "opsec@ietf.org" Date: Tue, 24 Feb 2009 21:56:17 +0530 Thread-Topic: draft-ietf-opsec-routing-protocols-crypto-issues-00.txt Thread-Index: AcmWnJ5cNFfMi34PQded2c6+ZnR/CA== Message-ID: <7C362EEF9C7896468B36C9B79200D8357913FE39@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Subject: [OPSEC] 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: , X-List-Received-Date: Tue, 24 Feb 2009 16:26:05 -0000 Hi, We've had some discussion in the past about this draft and we would like to= know what the WG feels about this work moving forward. Cheers, Manav -- Manav Bhatia, IP Division, Alcatel-Lucent, Bangalore - India = From rja@extremenetworks.com Tue Feb 24 09:02:21 2009 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58BEC3A6A16 for ; Tue, 24 Feb 2009 09:02:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9i6fx3kxdv5 for ; Tue, 24 Feb 2009 09:02:20 -0800 (PST) Received: from vms173019pub.verizon.net (vms173019pub.verizon.net [206.46.173.19]) by core3.amsl.com (Postfix) with ESMTP id A7F6E3A6977 for ; Tue, 24 Feb 2009 09:02:20 -0800 (PST) Received: from [10.30.20.71] ([70.104.193.39]) by vms173019.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KFK00FOBY00M800@vms173019.mailsrvcs.net> for opsec@ietf.org; Tue, 24 Feb 2009 11:02:28 -0600 (CST) Message-id: <799B94C1-0CDD-45D6-9EA5-AFBDAC3A3ABF@extremenetworks.com> From: RJ Atkinson To: opsec@ietf.org Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7bit MIME-version: 1.0 (Apple Message framework v930.3) Date: Tue, 24 Feb 2009 12:02:23 -0500 X-Mailer: Apple Mail (2.930.3) Subject: Re: [OPSEC] 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: , X-List-Received-Date: Tue, 24 Feb 2009 17:02:21 -0000 Hi, Has the draft been revised to take into account my previous comments here ? If that hasn't happened yet, that is probably a first step to take, ideally before the I-D cutoff for the next IETF meeting. Cheers, Ran rja@extremenetworks.com From glen.kent@gmail.com Tue Feb 24 09:04:12 2009 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61E123A6A89 for ; Tue, 24 Feb 2009 09:04:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lLopDRp1XN8 for ; Tue, 24 Feb 2009 09:04:11 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id 304713A6B39 for ; Tue, 24 Feb 2009 09:04:11 -0800 (PST) Received: by bwz5 with SMTP id 5so5959173bwz.13 for ; Tue, 24 Feb 2009 09:04:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=weboz/dery0d8SINfDwbDxY5KjMm7KH3xbzjvq+j0bw=; b=X2i911Uqm7GrmoeCGdhgAJznI/HYhRXn22+1BkZNae97lNycwlNrVp0kSbUZUkWwvl bJumQiLfddGsundfz+s6nHzs0ecyIAH80cNLA+lzkx4SRPdyprYC4pZs4jOT0SXYUk/e qaRKFSBJYua4SWi+8FYjTiOZdwLUincxtpQAk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=MhxhhE+y1/HvT7OkjdKH04pwYbvhxHHAwAP+jmgPzF87MmR0UpgV/hNDcwn5011aVP 7Ux77kd9/lfjuOkbnr8ir3qX5G2DMdPABVBrgWuxnIBGnpyRyv2XXxXdaGB0OUlaPWMR w8yjTW9tTr9Ju5LxoG2jX/7DUMV/ACqGpV/Zo= MIME-Version: 1.0 Received: by 10.223.124.147 with SMTP id u19mr2628far.28.1235495061918; Tue, 24 Feb 2009 09:04:21 -0800 (PST) In-Reply-To: <77ead0ec0902232009s260cee0dn4f81390ddf698e1c@mail.gmail.com> References: <77ead0ec0902232009s260cee0dn4f81390ddf698e1c@mail.gmail.com> Date: Tue, 24 Feb 2009 22:34:21 +0530 Message-ID: <92c950310902240904y31537b3cn1837b4a78ba4a40b@mail.gmail.com> From: Glen Kent To: Vishwas Manral Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: opsec wg mailing list Subject: Re: [OPSEC] draft-bhatia-manral-igp-crypto-requirements X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 17:04:12 -0000 So was there any ambiguity in recommending HMAC-SHA1 over other available options ever? I re-read the document, found it extremely simple, the recommendations look right, found it just to be what OPSEC must own up. Glen On Tue, Feb 24, 2009 at 9:39 AM, Vishwas Manral wrote: > Hi folks, > > We now have got some clear guidance regarding this document from the > Security AD's regarding the cryptographic algorithms (Joel has been > privy to those mails). The guidance seems to second what Hugo and > other cryptographers have been stating all along. The crux of what has > been said is: > > MD5 should not be used for crypto purposes. SHA-1 though stronger is > also vulnerable. HMAC-MD5 though not yet vulnerable looks highly > suspect and should not be reccomended. HMAC-SHA-1 for now looks ok and > can be reccomended. Goinf forward we should try to reccomend the SHA-2 > family of protocols. > > With these clear guidances matching what we have in our documents, I > would like to ask the working group to look into this document > further. We can then look at getting this as a WG document. > > Thanks, > Vishwas > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > From rja@extremenetworks.com Tue Feb 24 09:28:16 2009 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10C083A6804 for ; Tue, 24 Feb 2009 09:28:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkzmQy-ffCN2 for ; Tue, 24 Feb 2009 09:28:15 -0800 (PST) Received: from vms173017pub.verizon.net (vms173017pub.verizon.net [206.46.173.17]) by core3.amsl.com (Postfix) with ESMTP id 41B8F3A6B57 for ; Tue, 24 Feb 2009 09:28:06 -0800 (PST) Received: from [10.30.20.71] ([70.104.193.39]) by vms173017.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KFK00BVMZ6ULS00@vms173017.mailsrvcs.net> for opsec@ietf.org; Tue, 24 Feb 2009 11:28:11 -0600 (CST) Message-id: From: RJ Atkinson To: opsec@ietf.org In-reply-to: <7C362EEF9C7896468B36C9B79200D8357913FE45@INBANSXCHMBSA1.in.alcatel-lucent.com> Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7bit MIME-version: 1.0 (Apple Message framework v930.3) Date: Tue, 24 Feb 2009 12:28:06 -0500 References: <799B94C1-0CDD-45D6-9EA5-AFBDAC3A3ABF@extremenetworks.com> <7C362EEF9C7896468B36C9B79200D8357913FE45@INBANSXCHMBSA1.in.alcatel-lucent.com> X-Mailer: Apple Mail (2.930.3) Subject: Re: [OPSEC] 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: , X-List-Received-Date: Tue, 24 Feb 2009 17:28:16 -0000 On 24 Feb 2009, at 12:22, Bhatia, Manav (Manav) wrote: > Weren't your comments addressed to the minutes that were posted on > the list? The minutes discussing the drafts -- so they apply also to the drafts. I think revised I-Ds taking those comments into consideration would be very helpful. Thanks, Ran From manav@alcatel-lucent.com Tue Feb 24 09:35:25 2009 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CB183A6B4B for ; Tue, 24 Feb 2009 09:35:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 9AWlihzemcTe for ; Tue, 24 Feb 2009 09:35:24 -0800 (PST) Received: from smail6.alcatel.fr (gc-na5.alcatel.fr [64.208.49.5]) by core3.amsl.com (Postfix) with ESMTP id 5352C3A6A6F for ; Tue, 24 Feb 2009 09:35:23 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n1OHZZt6014205 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 24 Feb 2009 18:35:36 +0100 Received: from INBANSXCHHUB02.in.alcatel-lucent.com (135.250.12.35) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 24 Feb 2009 18:35:35 +0100 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Tue, 24 Feb 2009 23:05:33 +0530 From: "Bhatia, Manav (Manav)" To: RJ Atkinson , "opsec@ietf.org" Date: Tue, 24 Feb 2009 23:05:31 +0530 Thread-Topic: [OPSEC] draft-ietf-opsec-routing-protocols-crypto-issues-00.txt Thread-Index: AcmWobvpqku4faPeRMaIKbT5JvjVZQABIa2g Message-ID: <7C362EEF9C7896468B36C9B79200D8357913FE47@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <799B94C1-0CDD-45D6-9EA5-AFBDAC3A3ABF@extremenetworks.com> In-Reply-To: <799B94C1-0CDD-45D6-9EA5-AFBDAC3A3ABF@extremenetworks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Subject: Re: [OPSEC] 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: , X-List-Received-Date: Tue, 24 Feb 2009 17:35:25 -0000 Hi Ran, AFAIK you had not given any comments wrt this draft. Weren't your comments = addressed to the minutes that were posted on the list? Anyways, would be great if you can summarize what you want to see added to = this draft. Cheers, Manav=20 > -----Original Message----- > From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org]=20 > On Behalf Of RJ Atkinson > Sent: Tuesday, February 24, 2009 10.32 PM > To: opsec@ietf.org > Subject: Re: [OPSEC]=20 > draft-ietf-opsec-routing-protocols-crypto-issues-00.txt >=20 > Hi, >=20 > Has the draft been revised to take into account my previous comments =20 > here ? > If that hasn't happened yet, that is probably a first step to take, > ideally before the I-D cutoff for the next IETF meeting. >=20 > Cheers, >=20 > Ran > rja@extremenetworks.com >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > = From glen.kent@gmail.com Tue Feb 24 09:43:24 2009 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5940A3A6AC9 for ; Tue, 24 Feb 2009 09:43:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=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 PxJv5LPOzTkG for ; Tue, 24 Feb 2009 09:43:23 -0800 (PST) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by core3.amsl.com (Postfix) with ESMTP id 1B8823A6826 for ; Tue, 24 Feb 2009 09:43:22 -0800 (PST) Received: by fxm11 with SMTP id 11so2989185fxm.13 for ; Tue, 24 Feb 2009 09:43:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=lPPJ1YfnoQQom0zFfC8fOOeHBsw5oGgoLx4FesX92c0=; b=AQpdtn6zmu919DWea1xCyIOnNFpaj43nstMZN2Dxa9C0ggFpkcikmxixXxQREWRyBB sgtjTWCtHyA8NtNSy9PlPrBV+2NxwhiZepTzEB/emjKaDTYX1N6WdoNljqcRGNWDnPZR 4XBwQvEO9NfYlp5qmOECmaRuVM0HtSoo6kyss= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=VpGL8JRusBN7l3d+lZ8htrOSuOAfDZzW6NwLcjL9xj/kO4lhSVy6tDdXA+bGPEgDne JYfpbpBkRzlUtZNuIpIOBpdE2aqtyyai+b+1OGCb2lngyGmJKGTUNOKEGtkM8yP0KSfl Kk1DLQPdEa6HorfpQ7xyedU+IZ2hONTZJFp6k= MIME-Version: 1.0 Received: by 10.223.117.1 with SMTP id o1mr722faq.96.1235497416482; Tue, 24 Feb 2009 09:43:36 -0800 (PST) In-Reply-To: References: <799B94C1-0CDD-45D6-9EA5-AFBDAC3A3ABF@extremenetworks.com> <7C362EEF9C7896468B36C9B79200D8357913FE45@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Tue, 24 Feb 2009 23:13:36 +0530 Message-ID: <92c950310902240943o7ba2225ew8ae8e81ddf1e1932@mail.gmail.com> From: Glen Kent To: RJ Atkinson Content-Type: multipart/alternative; boundary=001636c5b680a161620463ada829 Cc: opsec@ietf.org Subject: Re: [OPSEC] 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: , X-List-Received-Date: Tue, 24 Feb 2009 17:43:24 -0000 --001636c5b680a161620463ada829 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hmm .. interesting how you keep changing your position. You had said the following just a few weeks back: > -----Original Message----- > From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] > On Behalf Of R Atkinson > Sent: Thursday, December 18, 2008 7.27 AM > To: opsec@ietf.org > Subject: Re: [OPSEC] minutes part 2 > > > On 17 Dec 2008, at 20:04, Glen Kent wrote: > > This does not address the point that i had raised. > > > >> I have no concern with the WG documenting any issues, provided: > >> - they really are technical issues rather than opinion, > > > > So, you dont think the issues mentioned in the drafts are technical? > > OK, how would you categorize those issues? > *> Let me repeat: > My comments here have been focused on the > comments reported *meeting minutes*. > > I have made no assertions about any drafts.* On Tue, Feb 24, 2009 at 10:58 PM, RJ Atkinson wrote: > > On 24 Feb 2009, at 12:22, Bhatia, Manav (Manav) wrote: >> >> Weren't your comments addressed to the minutes that were posted on the list? > *> The minutes discussing the drafts -- so they apply also > to the drafts. I think revised I-Ds taking those > comments into consideration would be very helpful. *> > Thanks, > > Ran Glen --001636c5b680a161620463ada829 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hmm .. interesting how you keep changing your position. You had said the fo= llowing just a few weeks back:

> -----Original Message-----
&g= t; From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org= ]
> On Behalf Of R Atkinson
> Sent: Thursday, December 18, 2008 7.27= AM
> To: opsec@ietf.org
>= ; Subject: Re: [OPSEC] minutes part 2
>
>
> On =A017 De= c 2008, at 20:04, Glen Kent wrote:
> > This does not address the point that i had raised.
> >> >> I have no concern with the WG documenting any issues, provi= ded:
> >> - they really are technical issues rather than opinio= n,
> >
> > So, you dont think the issues mentioned in the draft= s are technical?
> > OK, how would you categorize those issues?>
> Let me repeat:
> My comments here have been focuse= d on the
> comments reported *meeting minutes*.
>
> I have made no = assertions about any drafts.

On Tue, Feb 24, 2009 at 10:58 PM, R= J Atkinson <rja@extremenetwor= ks.com> wrote:
>
> On =A024 Feb 2009, at 12:22, Bhatia, Manav (Manav) wrote:
&= gt;>
>> Weren't your comments addressed to the minutes that= were posted on the list?
>
> The minutes discussing the dra= fts -- so they apply also
> to the drafts. =A0 I think revised I-Ds taking those
> comments = into consideration would be very helpful.
>
> Thanks,
&g= t;
> Ran

Glen
--001636c5b680a161620463ada829-- From vishwas.ietf@gmail.com Tue Feb 24 10:19:23 2009 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8662F3A63D2 for ; Tue, 24 Feb 2009 10:19:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25L+OUzxAv9s for ; Tue, 24 Feb 2009 10:19:22 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by core3.amsl.com (Postfix) with ESMTP id 857A53A69C9 for ; Tue, 24 Feb 2009 10:19:22 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so1549795qwe.31 for ; Tue, 24 Feb 2009 10:19:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+Ws4DG41zrjh9Xw9OIeOKHiRUDuEjjpPjYjwIbbwDYw=; b=A/uVPsPYeGdpuHzz0Vqj2fJVKTNF2jMTa8HSZ6BZ6s3C5sIsI4cgtHltyHIwISi70v zh5QwHQ/QrjATMHZLAaqU7O2M2CU2Tyu1EZV3d2wCkqTOu+QOu3QYeoZhedVf3a9/NI9 F31/CHadWym/db/T+FMooh6wuBmrCaUd5cL3g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=pSVEdITS4fMj21wYZuqaOw5zDlpcQbvCAecPfU+eRiL4a3PBxrc4hdTRCf77NOhPvg PPdisu8imtlHav0zePrrkxqvzEI5l7WzyhTxSCjbQzkYww5wFKNLQp9vE1DBhjQjcaJf /gVR/qDhD20jdikpjWtK7IP856YENigJuUECc= MIME-Version: 1.0 Received: by 10.229.74.68 with SMTP id t4mr2027186qcj.102.1235499581448; Tue, 24 Feb 2009 10:19:41 -0800 (PST) In-Reply-To: <92c950310902240904y31537b3cn1837b4a78ba4a40b@mail.gmail.com> References: <77ead0ec0902232009s260cee0dn4f81390ddf698e1c@mail.gmail.com> <92c950310902240904y31537b3cn1837b4a78ba4a40b@mail.gmail.com> Date: Tue, 24 Feb 2009 10:19:41 -0800 Message-ID: <77ead0ec0902241019n3342915q7777c7475b5bda5a@mail.gmail.com> From: Vishwas Manral To: Glen Kent Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: opsec wg mailing list Subject: Re: [OPSEC] draft-bhatia-manral-igp-crypto-requirements X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 18:19:23 -0000 Hi Glen, Thanks for your support of the document. There was no ambiguity as such, however Ran wanted us to look further into whether the recently announced vulnerabilities to SHA-1 and MD5 would effect the reccomendation for HMAC-SHA-1. Thanks, Vishwas On Tue, Feb 24, 2009 at 9:04 AM, Glen Kent wrote: > So was there any ambiguity in recommending HMAC-SHA1 over other > available options ever? > > I re-read the document, found it extremely simple, the recommendations > look right, found it just to be what OPSEC must own up. > > Glen > > On Tue, Feb 24, 2009 at 9:39 AM, Vishwas Manral wrote: >> Hi folks, >> >> We now have got some clear guidance regarding this document from the >> Security AD's regarding the cryptographic algorithms (Joel has been >> privy to those mails). The guidance seems to second what Hugo and >> other cryptographers have been stating all along. The crux of what has >> been said is: >> >> MD5 should not be used for crypto purposes. SHA-1 though stronger is >> also vulnerable. HMAC-MD5 though not yet vulnerable looks highly >> suspect and should not be reccomended. HMAC-SHA-1 for now looks ok and >> can be reccomended. Goinf forward we should try to reccomend the SHA-2 >> family of protocols. >> >> With these clear guidances matching what we have in our documents, I >> would like to ask the working group to look into this document >> further. We can then look at getting this as a WG document. >> >> Thanks, >> Vishwas >> _______________________________________________ >> OPSEC mailing list >> OPSEC@ietf.org >> https://www.ietf.org/mailman/listinfo/opsec >> > From manav@alcatel-lucent.com Tue Feb 24 19:40:11 2009 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56AA13A6A08 for ; Tue, 24 Feb 2009 19:40:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 u+Rs0NMPsHIx for ; Tue, 24 Feb 2009 19:40:10 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id 40E6E3A680A for ; Tue, 24 Feb 2009 19:40:09 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n1P3eKlA006520 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 25 Feb 2009 04:40:22 +0100 Received: from INBANSXCHHUB01.in.alcatel-lucent.com (135.250.12.32) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (135.120.45.64) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 25 Feb 2009 04:40:20 +0100 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Wed, 25 Feb 2009 09:09:04 +0530 From: "Bhatia, Manav (Manav)" To: RJ Atkinson , "opsec@ietf.org" Date: Wed, 25 Feb 2009 09:09:03 +0530 Thread-Topic: [OPSEC] draft-ietf-opsec-routing-protocols-crypto-issues-00.txt Thread-Index: AcmWpWSA1CerDfU3Q0eUdd4wEOcU6AAU8r7Q Message-ID: <7C362EEF9C7896468B36C9B79200D8357913FE76@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <799B94C1-0CDD-45D6-9EA5-AFBDAC3A3ABF@extremenetworks.com> <7C362EEF9C7896468B36C9B79200D8357913FE45@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Subject: Re: [OPSEC] 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: , X-List-Received-Date: Wed, 25 Feb 2009 03:40:11 -0000 Ran, I went through the archives for your comments on this draft (draft-ietf-ops= ec-routing-protocols-crypto-issues-00.txt) and could only find one, where y= ou suggested that we must also include a study of OSPF with digital signatu= res in this draft. Is this all, or am I missing something?=20 Most of the discussion in the past was around whether the WG is correct in = recommending HMAC-SHA over MD5/HMAC-MD5 or not. If you still want to addres= s this issue then please use a different thread, as that's related to the o= ther draft (draft-bhatia-manral-igp-crypto-requirements) and not the one th= at this email is originally about. Cheers, Manav > -----Original Message----- > From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org]=20 > On Behalf Of RJ Atkinson > Sent: Tuesday, February 24, 2009 10.58 PM > To: opsec@ietf.org > Subject: Re: [OPSEC]=20 > draft-ietf-opsec-routing-protocols-crypto-issues-00.txt >=20 >=20 > On 24 Feb 2009, at 12:22, Bhatia, Manav (Manav) wrote: > > Weren't your comments addressed to the minutes that were posted on =20 > > the list? >=20 > The minutes discussing the drafts -- so they apply also > to the drafts. I think revised I-Ds taking those > comments into consideration would be very helpful. >=20 > Thanks, >=20 > Ran >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > = From joelja@bogus.com Wed Feb 25 14:19:27 2009 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06B1F3A6AE0 for ; Wed, 25 Feb 2009 14:19:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9IS+bj2hewTc for ; Wed, 25 Feb 2009 14:19:26 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 084663A68E4 for ; Wed, 25 Feb 2009 14:19:25 -0800 (PST) Received: from [192.103.16.213] ([192.103.16.213]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id n1PMJgLr040223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Feb 2009 22:19:43 GMT (envelope-from joelja@bogus.com) Message-ID: <49A5C3F0.7040909@bogus.com> Date: Wed, 25 Feb 2009 14:19:28 -0800 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Vishwas Manral , opsec wg mailing list References: <77ead0ec0902232009s260cee0dn4f81390ddf698e1c@mail.gmail.com> <92c950310902240904y31537b3cn1837b4a78ba4a40b@mail.gmail.com> <77ead0ec0902241019n3342915q7777c7475b5bda5a@mail.gmail.com> In-Reply-To: <77ead0ec0902241019n3342915q7777c7475b5bda5a@mail.gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.94.2/9048/Wed Feb 25 21:08:29 2009 on nagasaki.bogus.com X-Virus-Status: Clean Subject: Re: [OPSEC] draft-bhatia-manral-igp-crypto-requirements X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 22:19:27 -0000 Vishwas Manral wrote: > Hi Glen, > > Thanks for your support of the document. > > There was no ambiguity as such, however Ran wanted us to look further > into whether the recently announced vulnerabilities to SHA-1 and MD5 > would effect the reccomendation for HMAC-SHA-1. We have the issue of vulnerable today vs problematic today, or tomorrow... I feel very comfortable saying there are some places where md5 is used today that I'd really prefer to not be using it in 5 years. That's good advice to have especially on the operational side. stating that is being proactice. joelja > Thanks, > Vishwas > > On Tue, Feb 24, 2009 at 9:04 AM, Glen Kent wrote: >> So was there any ambiguity in recommending HMAC-SHA1 over other >> available options ever? >> >> I re-read the document, found it extremely simple, the recommendations >> look right, found it just to be what OPSEC must own up. >> >> Glen >> >> On Tue, Feb 24, 2009 at 9:39 AM, Vishwas Manral wrote: >>> Hi folks, >>> >>> We now have got some clear guidance regarding this document from the >>> Security AD's regarding the cryptographic algorithms (Joel has been >>> privy to those mails). The guidance seems to second what Hugo and >>> other cryptographers have been stating all along. The crux of what has >>> been said is: >>> >>> MD5 should not be used for crypto purposes. SHA-1 though stronger is >>> also vulnerable. HMAC-MD5 though not yet vulnerable looks highly >>> suspect and should not be reccomended. HMAC-SHA-1 for now looks ok and >>> can be reccomended. Goinf forward we should try to reccomend the SHA-2 >>> family of protocols. >>> >>> With these clear guidances matching what we have in our documents, I >>> would like to ask the working group to look into this document >>> further. We can then look at getting this as a WG document. >>> >>> Thanks, >>> Vishwas >>> _______________________________________________ >>> 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 vishwas.ietf@gmail.com Wed Feb 25 20:17:58 2009 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7E293A67DF for ; Wed, 25 Feb 2009 20:17:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7ToBzf67QM3 for ; Wed, 25 Feb 2009 20:17:58 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by core3.amsl.com (Postfix) with ESMTP id D109F3A687F for ; Wed, 25 Feb 2009 20:17:57 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so531268qwe.31 for ; Wed, 25 Feb 2009 20:18:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=DFhcxjhBdB6tTESVH5ZepnxUXUnlK6uJZ+xMUt54ZQk=; b=ubnYAjpM/yxQSuSCHkZTH+8rW8JroWNcChBKbqF7hssCyJECa33NDbHC9EAUDax7Cd iA41R321MzoqthX8tpfl1Zv8VN3DgxWzrl4bIhhADL2MA0Gaqm6mrEXlJl65+6s+eXXO 6dLE4Vv7ujLZ7VmBJ/bjgA1aXB+uBgXfvzj30= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=gZV3nlKjkJfK3LispGg+KRdvexzMMDf8qnxL2AcQ4Y6fCb/0YKb00D3kRGAtDlNJ8s 8xI5sjq/uJaR+7mtdL5iOF1LbrzeqkREArFoAiUmuXQCfbzuronYOEO+JKn4ei64AXtz UA3druAiX3L/FZp0Z8CkrWhR3DWzm/WNR0GCk= MIME-Version: 1.0 Received: by 10.229.74.17 with SMTP id s17mr922077qcj.75.1235621897904; Wed, 25 Feb 2009 20:18:17 -0800 (PST) In-Reply-To: <49A5C3F0.7040909@bogus.com> References: <77ead0ec0902232009s260cee0dn4f81390ddf698e1c@mail.gmail.com> <92c950310902240904y31537b3cn1837b4a78ba4a40b@mail.gmail.com> <77ead0ec0902241019n3342915q7777c7475b5bda5a@mail.gmail.com> <49A5C3F0.7040909@bogus.com> Date: Wed, 25 Feb 2009 20:18:17 -0800 Message-ID: <77ead0ec0902252018o532b6f73qe9358c349266a6fa@mail.gmail.com> From: Vishwas Manral To: Joel Jaeggli Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: opsec wg mailing list Subject: Re: [OPSEC] draft-bhatia-manral-igp-crypto-requirements X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 04:17:59 -0000 Hi Joel, Thanks for your comment on the document. > We have the issue of vulnerable today vs problematic today, or > tomorrow... I feel very comfortable saying there are some places where > md5 is used today that I'd really prefer to not be using it in 5 years. If I understood you right, you are saying stating the fact that its used now though we would prefer it was not used. That was the exact idea of MUST-, SHOULD+ etc we had used in the document earlier. It gives an idea of direction of where the support of a particular algorithm is heading towards. However based on the comments in the list we modified the document to use standard IETF terminology. Thanks, Vishwas >> Thanks for your support of the document. >> >> There was no ambiguity as such, however Ran wanted us to look further >> into whether the recently announced vulnerabilities to SHA-1 and MD5 >> would effect the reccomendation for HMAC-SHA-1. > > We have the issue of vulnerable today vs problematic today, or > tomorrow... I feel very comfortable saying there are some places where > md5 is used today that I'd really prefer to not be using it in 5 years. > > That's good advice to have especially on the operational side. > > stating that is being proactice. > > joelja > >> Thanks, >> Vishwas >> >> On Tue, Feb 24, 2009 at 9:04 AM, Glen Kent wrote: >>> So was there any ambiguity in recommending HMAC-SHA1 over other >>> available options ever? >>> >>> I re-read the document, found it extremely simple, the recommendations >>> look right, found it just to be what OPSEC must own up. >>> >>> Glen >>> >>> On Tue, Feb 24, 2009 at 9:39 AM, Vishwas Manral wrote: >>>> Hi folks, >>>> >>>> We now have got some clear guidance regarding this document from the >>>> Security AD's regarding the cryptographic algorithms (Joel has been >>>> privy to those mails). The guidance seems to second what Hugo and >>>> other cryptographers have been stating all along. The crux of what has >>>> been said is: >>>> >>>> MD5 should not be used for crypto purposes. SHA-1 though stronger is >>>> also vulnerable. HMAC-MD5 though not yet vulnerable looks highly >>>> suspect and should not be reccomended. HMAC-SHA-1 for now looks ok and >>>> can be reccomended. Goinf forward we should try to reccomend the SHA-2 >>>> family of protocols. >>>> >>>> With these clear guidances matching what we have in our documents, I >>>> would like to ask the working group to look into this document >>>> further. We can then look at getting this as a WG document. >>>> >>>> Thanks, >>>> Vishwas >>>> _______________________________________________ >>>> 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 joelja@bogus.com Wed Feb 25 21:55:54 2009 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BFB43A6B8A for ; Wed, 25 Feb 2009 21:55:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id onzTCtsWijhp for ; Wed, 25 Feb 2009 21:55:53 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 59B5A3A6A7D for ; Wed, 25 Feb 2009 21:55:53 -0800 (PST) Received: from [192.168.1.205] (c-98-234-53-212.hsd1.ca.comcast.net [98.234.53.212]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id n1Q5uA0H063526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 26 Feb 2009 05:56:11 GMT (envelope-from joelja@bogus.com) Message-ID: <49A62EF6.9070704@bogus.com> Date: Wed, 25 Feb 2009 21:56:06 -0800 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Vishwas Manral References: <77ead0ec0902232009s260cee0dn4f81390ddf698e1c@mail.gmail.com> <92c950310902240904y31537b3cn1837b4a78ba4a40b@mail.gmail.com> <77ead0ec0902241019n3342915q7777c7475b5bda5a@mail.gmail.com> <49A5C3F0.7040909@bogus.com> <77ead0ec0902252018o532b6f73qe9358c349266a6fa@mail.gmail.com> In-Reply-To: <77ead0ec0902252018o532b6f73qe9358c349266a6fa@mail.gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.94.2/9048/Wed Feb 25 21:08:29 2009 on nagasaki.bogus.com X-Virus-Status: Clean Cc: opsec wg mailing list Subject: Re: [OPSEC] draft-bhatia-manral-igp-crypto-requirements X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 05:55:54 -0000 Vishwas Manral wrote: > Hi Joel, > > Thanks for your comment on the document. > >> We have the issue of vulnerable today vs problematic today, or >> tomorrow... I feel very comfortable saying there are some places where >> md5 is used today that I'd really prefer to not be using it in 5 years. > If I understood you right, you are saying stating the fact that its > used now though we would prefer it was not used. That was the exact > idea of MUST-, SHOULD+ etc we had used in the document earlier. I side with Sandra Murphy on the value of that particular language. If my concern is that I should not be running something in the future I want to simply state that. we take that concern expressed in an informational document back to implementation. > It gives an idea of direction of where the support of a particular > algorithm is heading towards. However based on the comments in the > list we modified the document to use standard IETF terminology. Which I concur with. joel > Thanks, > Vishwas > >>> Thanks for your support of the document. >>> >>> There was no ambiguity as such, however Ran wanted us to look further >>> into whether the recently announced vulnerabilities to SHA-1 and MD5 >>> would effect the reccomendation for HMAC-SHA-1. >> We have the issue of vulnerable today vs problematic today, or >> tomorrow... I feel very comfortable saying there are some places where >> md5 is used today that I'd really prefer to not be using it in 5 years. >> >> That's good advice to have especially on the operational side. >> >> stating that is being proactice. >> >> joelja >> >>> Thanks, >>> Vishwas >>> >>> On Tue, Feb 24, 2009 at 9:04 AM, Glen Kent wrote: >>>> So was there any ambiguity in recommending HMAC-SHA1 over other >>>> available options ever? >>>> >>>> I re-read the document, found it extremely simple, the recommendations >>>> look right, found it just to be what OPSEC must own up. >>>> >>>> Glen >>>> >>>> On Tue, Feb 24, 2009 at 9:39 AM, Vishwas Manral wrote: >>>>> Hi folks, >>>>> >>>>> We now have got some clear guidance regarding this document from the >>>>> Security AD's regarding the cryptographic algorithms (Joel has been >>>>> privy to those mails). The guidance seems to second what Hugo and >>>>> other cryptographers have been stating all along. The crux of what has >>>>> been said is: >>>>> >>>>> MD5 should not be used for crypto purposes. SHA-1 though stronger is >>>>> also vulnerable. HMAC-MD5 though not yet vulnerable looks highly >>>>> suspect and should not be reccomended. HMAC-SHA-1 for now looks ok and >>>>> can be reccomended. Goinf forward we should try to reccomend the SHA-2 >>>>> family of protocols. >>>>> >>>>> With these clear guidances matching what we have in our documents, I >>>>> would like to ask the working group to look into this document >>>>> further. We can then look at getting this as a WG document. >>>>> >>>>> Thanks, >>>>> Vishwas >>>>> _______________________________________________ >>>>> 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 manav@alcatel-lucent.com Wed Feb 25 23:04:29 2009 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CADD428C257 for ; Wed, 25 Feb 2009 23:04:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 1M0bU-cEfkvw for ; Wed, 25 Feb 2009 23:04:28 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id 52C193A67DA for ; Wed, 25 Feb 2009 23:04:27 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n1Q74b4P031773 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 26 Feb 2009 08:04:40 +0100 Received: from INBANSXCHHUB02.in.alcatel-lucent.com (135.250.12.35) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (135.120.45.63) with Microsoft SMTP Server (TLS) id 8.1.311.2; Thu, 26 Feb 2009 08:04:39 +0100 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Thu, 26 Feb 2009 12:32:37 +0530 From: "Bhatia, Manav (Manav)" To: Joel Jaeggli , Vishwas Manral Date: Thu, 26 Feb 2009 12:32:34 +0530 Thread-Topic: [OPSEC] draft-bhatia-manral-igp-crypto-requirements Thread-Index: AcmX1vUIP1ssZwlmTxy22LaiARFUYwACBwDg Message-ID: <7C362EEF9C7896468B36C9B79200D83579201541@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <77ead0ec0902232009s260cee0dn4f81390ddf698e1c@mail.gmail.com> <92c950310902240904y31537b3cn1837b4a78ba4a40b@mail.gmail.com> <77ead0ec0902241019n3342915q7777c7475b5bda5a@mail.gmail.com> <49A5C3F0.7040909@bogus.com> <77ead0ec0902252018o532b6f73qe9358c349266a6fa@mail.gmail.com> <49A62EF6.9070704@bogus.com> In-Reply-To: <49A62EF6.9070704@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: opsec wg mailing list Subject: Re: [OPSEC] draft-bhatia-manral-igp-crypto-requirements X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 07:04:29 -0000 Hi, The latest version of the above draft can be found here: http://www.ietf.org/internet-drafts/draft-bhatia-manral-igp-crypto-requirem= ents-03.txt To cite one example, the draft in section 4.2 recommends the following for = OSPFv2: "This section details the authentication algorithm requirements for standar= ds conformant OSPF implementations.=20 =20 Keyed MD5 is a MUST as defined in [RFC2328]. It is our understanding that t= his will get superseded by HMAC-SHA-1 as defined in [OSPF-HMAC]. Keyed MD5 = thus MUST be implemented, but its use may get deprecated in future. Impleme= ntations should start providing support for HMAC-SHA-1 as this will get pro= moted to a MUST in the future.=20 =20 Operators should meanwhile start migrating towards HMAC-SHA-1 if they want = to use stronger cryptographic algorithms for authenticating their OSPFv2 pa= ckets.=20 =20 Implementations may start providing support for HMAC-SHA-256/HMAC-SHA-384/H= MAC-SHA-512 as these algorithms may get upgraded to a SHOULD in the future.= " This way we've retained the IETF terminology while giving an idea of where = a particular algorithm is headed in the future. Cheers, Manav P.S. [OSPF-HMAC] Bhatia, M., Manral, V., et al., "OSPF HMAC-SHA Cryptographic Au= thentication", Work in Progress=20 This draft is very mature, and an implementation is already underway. It sh= ould be "WG last called" pretty soon in the OSPF WG. [ISIS-HMAC] mentioned = in the draft has already been published as RFC 5310 (http://tools.ietf.org/= rfc/rfc5310.txt). > -----Original Message----- > From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org]=20 > On Behalf Of Joel Jaeggli > Sent: Thursday, February 26, 2009 11.26 AM > To: Vishwas Manral > Cc: opsec wg mailing list > Subject: Re: [OPSEC] draft-bhatia-manral-igp-crypto-requirements >=20 > Vishwas Manral wrote: > > Hi Joel, > >=20 > > Thanks for your comment on the document. > >=20 > >> We have the issue of vulnerable today vs problematic today, or > >> tomorrow... I feel very comfortable saying there are some=20 > places where > >> md5 is used today that I'd really prefer to not be using=20 > it in 5 years. > > If I understood you right, you are saying stating the fact that its > > used now though we would prefer it was not used. That was the exact > > idea of MUST-, SHOULD+ etc we had used in the document earlier. >=20 > I side with Sandra Murphy on the value of that particular language. If > my concern is that I should not be running something in the future I > want to simply state that. we take that concern expressed in an > informational document back to implementation. >=20 > > It gives an idea of direction of where the support of a particular > > algorithm is heading towards. However based on the comments in the > > list we modified the document to use standard IETF terminology. >=20 > Which I concur with. >=20 > joel >=20 > > Thanks, > > Vishwas From rja@extremenetworks.com Thu Feb 26 08:25:27 2009 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74FBF28C2F5 for ; Thu, 26 Feb 2009 08:25:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 g4MWRkqA2J1Y for ; Thu, 26 Feb 2009 08:25:21 -0800 (PST) Received: from vms173001pub.verizon.net (vms173001pub.verizon.net [206.46.173.1]) by core3.amsl.com (Postfix) with ESMTP id A251C28C2E2 for ; Thu, 26 Feb 2009 08:25:15 -0800 (PST) Received: from [10.30.20.71] ([70.104.193.39]) by vms173001.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KFO009HWLLZR500@vms173001.mailsrvcs.net> for opsec@ietf.org; Thu, 26 Feb 2009 10:25:16 -0600 (CST) Message-id: <1CB6E20A-44CF-45BB-B2B1-9868D8358303@extremenetworks.com> From: RJ Atkinson To: opsec@ietf.org In-reply-to: <7C362EEF9C7896468B36C9B79200D8357913FE76@INBANSXCHMBSA1.in.alcatel-lucent.com> Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7bit MIME-version: 1.0 (Apple Message framework v930.3) Date: Thu, 26 Feb 2009 11:25:06 -0500 References: <799B94C1-0CDD-45D6-9EA5-AFBDAC3A3ABF@extremenetworks.com> <7C362EEF9C7896468B36C9B79200D8357913FE45@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8357913FE76@INBANSXCHMBSA1.in.alcatel-lucent.com> X-Mailer: Apple Mail (2.930.3) Subject: Re: [OPSEC] 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: , X-List-Received-Date: Thu, 26 Feb 2009 16:25:27 -0000 On 24 Feb 2009, at 22:39, Bhatia, Manav (Manav) wrote: > Is this all, or am I missing something? As the minutes combined multiple drafts, so the responses (which were driven by the minutes) combined multiple drafts; that was unavoidable from the situation. :-( (Aside: I did sit down and read the drafts when I had time last month. Not surprisingly I found that the comments driven by the minutes also applied to the drafts.) Several items on this draft are discussed here: Also see the top section (with "-" markers) of this note: A documented Threat Model is particularly needed, as that provides a sound basis for the other security evaluation. Here, in (1) the issue of also addressing RFC-2154 (which is also an openly specified mechanism for OSPF cryptographic authentication) came up. Separately, in (2) a recurring gap is that the authors appear to know of a case (or cases) where filtering of RIP or OSPF packets at the edge of an IGP domain can't work. One can't figure out if that is true, or when/where/how it is true, simply because sufficient detail hasn't been provided. So having one or two *very detailed* examples that clarify when/why/how edge filtering of RIP or OSPF packets is not feasible (as was claimed) would be really important to operators, and would help clarify and support some of the other claims made in the document: This last item is also important to clarify the Threat Model (noted above). If no deployments can fully filter at the edge, then external attacks are a big part of the Threat Model. If all deployments can fully filter at the edge, then external attacks aren't a big issue and the focus is on the insider threat. If one sometimes can and sometimes can't filter at the IGP domain edge, then both insider and external attacks need to be considered -- AND operators need to understand when/how/why IGP domain edge filtering does or doesn't work. Please note that neither this response, nor the threads pointed to by the URLs in that response have sufficient detail to make clear the filtering issue. There might be a real issue. If there is one, it needs to be documented in a clear and detailed way in the document. Separate from me, Donald Smith noted the potential "DOS vector" with IGP cryptographic authentication, and a mitigation for that (GTSM): I don't recall if that is in the current draft or not; if not, both items he mentions are worth adding to the list. There should also be some mention of non-cryptographic attacks that are (1) easy to mount and (2) not eliminated by any of the cryptographic authentication mechanisms; attackers generally are both smart and lazy, so use the lowest-cost-to-the-attacker attacks first. It is entirely possible that the draft already discusses some or all of these; I'm not sure off hand and I'm travelling just now. So I'd like to see a revised I-D when your time permits. Yours, Ran rja@extremenetworks.com From jsmith4112003@yahoo.co.uk Thu Feb 26 08:26:58 2009 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D004828C2FD for ; Thu, 26 Feb 2009 08:26:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49SnHOWATpev for ; Thu, 26 Feb 2009 08:26:57 -0800 (PST) Received: from web27205.mail.ukl.yahoo.com (web27205.mail.ukl.yahoo.com [217.146.182.95]) by core3.amsl.com (Postfix) with SMTP id 9641728C2F9 for ; Thu, 26 Feb 2009 08:26:57 -0800 (PST) Received: (qmail 4921 invoked by uid 60001); 26 Feb 2009 16:27:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s1024; t=1235665638; bh=I2nufyXIvcJzWtTSiU0lMls7xeRbMknNP6ZVWftNb7M=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=cZIRjMCaCI5nDSaF2PNyrir/Z4owNWDCBPK30inP6JNIi9NUanfr2z3Cubu4P+EepwV1vquY++s+FosLDmLxcglhGqGxGvV2Pu6CwTmtTF8pVh9KXyCJMZQDxG6/q3Jh97QumYtRBKbaKS3UjIaguoxXEyFS92Bxr6DvzsMbGX0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=s0Ht0VRUpCrS/VCg7WJ6ncCNKCMMHWImZlsJNC2jc8bq7q/w7v/NrKVJLIaKFyTJASXvw5PCQ3gZPjtpCPNr4s9ptXsLcJP8hWogPNuEYmtRlRzHGTY5Qm4ymuO1CnbC1G3q/6FFgitAkB7ypMV1PTAIl3Ilj6iGbPW+KAJdOzg=; Message-ID: <572083.4681.qm@web27205.mail.ukl.yahoo.com> X-YMail-OSG: eBFfe9IVM1n945SNXJm7w3pniR037AQsGEwZegr4IDX2gmV8vUGbsDPibRYqt0fcRqNaUSqojQvMBWMhhn5w2xatxUuGDB3fuL4tii9M52UoqPb.0ENzr5BYdcEcyghUNe_lvUcGba3GhgorQwo9fx.W6iQow0UNT5fA.mvzkewp_PpJn9bpNcwmix7EoGGJAqgU6iP_h6StX1WcTQzLIpb0YwWP Received: from [122.167.244.250] by web27205.mail.ukl.yahoo.com via HTTP; Thu, 26 Feb 2009 16:27:18 GMT X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.289.1 Date: Thu, 26 Feb 2009 16:27:18 +0000 (GMT) From: John Smith To: opsec@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [OPSEC] draft-bhatia-manral-igp-crypto-requirements X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 16:26:58 -0000 I concur with the idea that we should start moving towards HMAC-SHA as soon= as it starts becoming available in the vendors data sheets. A recommendati= on from OPSEC will go a long way in making sure that folks start demanding = this from their favorite vendors.=0A=0AI also see that ISIS has recently po= sted an RFC describing how HMAC-SHA can be used; am sure, OSPF is not going= to lag far behind. =0A=0AThere are similar efforts underway in the TCPM WG= to obsolete MD5 in favor of stronger algorithms.=0A=0AThanks, =0AJohn=0A= =0A> -----Original Message-----=0A> From: opsec-bounces@ietf.org [mailto:op= sec-bounces@ietf.org] =0A> On Behalf Of Vishwas Manral=0A> Sent: Tuesday, F= ebruary 24, 2009 11.50 PM=0A> To: Glen Kent=0A> Cc: opsec wg mailing list= =0A> Subject: Re: [OPSEC] draft-bhatia-manral-igp-crypto-requirements=0A> = =0A> Hi Glen,=0A> =0A> Thanks for your support of the document.=0A> =0A> Th= ere was no ambiguity as such, however Ran wanted us to look further=0A> int= o whether the recently announced vulnerabilities to SHA-1 and MD5=0A> would= effect the reccomendation for HMAC-SHA-1.=0A> =0A> Thanks,=0A> Vishwas=0A>= =0A> On Tue, Feb 24, 2009 at 9:04 AM, Glen Kent =0A> = wrote:=0A> > So was there any ambiguity in recommending HMAC-SHA1 over oth= er=0A> > available options ever?=0A> >=0A> > I re-read the document, found = it extremely simple, the =0A> recommendations=0A> > look right, found it ju= st to be what OPSEC must own up.=0A> >=0A> > Glen=0A> >=0A> > On Tue, Feb 2= 4, 2009 at 9:39 AM, Vishwas Manral =0A> wrote:=0A>= >> Hi folks,=0A> >>=0A> >> We now have got some clear guidance regarding t= his =0A> document from the=0A> >> Security AD's regarding the cryptographic= algorithms (Joel has been=0A> >> privy to those mails). The guidance seems= to second what Hugo and=0A> >> other cryptographers have been stating all = along. The crux =0A> of what has=0A> >> been said is:=0A> >>=0A> >> MD5 sho= uld not be used for crypto purposes. SHA-1 though =0A> stronger is=0A> >> a= lso vulnerable. HMAC-MD5 though not yet vulnerable looks highly=0A> >> susp= ect and should not be reccomended. HMAC-SHA-1 for now =0A> looks ok and=0A>= >> can be reccomended. Goinf forward we should try to =0A> reccomend the S= HA-2=0A> >> family of protocols.=0A> >>=0A> >> With these clear guidances m= atching what we have in our =0A> documents, I=0A> >> would like to ask the = working group to look into this document=0A> >> further. We can then look a= t getting this as a WG document.=0A> >>=0A> >> Thanks,=0A> >> Vishwas=0A> >= > _______________________________________________=0A> >> OPSEC mailing list= =0A> >> OPSEC@ietf.org=0A> >> https://www.ietf.org/mailman/listinfo/opsec= =0A> >>=0A> >=0A> _______________________________________________=0A> OPSEC= mailing list=0A> OPSEC@ietf.org=0A> https://www.ietf.org/mailman/listinfo/= opsec=0A>=0A=0A=0A=0A From joelja@bogus.com Fri Feb 27 14:14:04 2009 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AF223A69FE for ; Fri, 27 Feb 2009 14:14:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] 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 DqAmUBwxVYXQ for ; Fri, 27 Feb 2009 14:14:03 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 166273A684C for ; Fri, 27 Feb 2009 14:14:02 -0800 (PST) Received: from [192.103.16.77] ([192.103.16.77]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id n1RMEI1k091338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 27 Feb 2009 22:14:23 GMT (envelope-from joelja@bogus.com) Message-ID: <49A865B5.30604@bogus.com> Date: Fri, 27 Feb 2009 14:14:13 -0800 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: opsec wg mailing list X-Enigmail-Version: 0.95.7 Content-Type: multipart/mixed; boundary="------------080907020308070304030504" X-Virus-Scanned: ClamAV 0.94.2/9055/Fri Feb 27 20:16:01 2009 on nagasaki.bogus.com X-Virus-Status: Clean Subject: [OPSEC] feedback... [Fwd: Re: Security Assessment of the Transmission Control Protocol (TCP)] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 22:14:04 -0000 This is a multi-part message in MIME format. --------------080907020308070304030504 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------080907020308070304030504 Content-Type: message/rfc822; name="Re: Security Assessment of the Transmission Control Protocol (TCP).eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="Re: Security Assessment of the Transmission Control Protocol"; filename*1=" (TCP).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=-1.1 required=4.0 tests=AWL,RCVD_IN_DNSWL_LOW 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 n1DM3jtk059926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 13 Feb 2009 22:03:45 GMT (envelope-from nanog-bounces@nanog.org) Received: from [2001:48a8:6880:95::20] (helo=s0.nanog.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LY68J-000BkI-O0 for joelja@bogus.com; Fri, 13 Feb 2009 22:03:40 +0000 Received: from localhost ([127.0.0.1] helo=s0.nanog.org) by s0.nanog.org with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1LY68I-000B9a-7v; Fri, 13 Feb 2009 22:03:38 +0000 Received: from pcls5.std.com ([192.74.137.145] helo=TheWorld.com) by s0.nanog.org with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1LY679-0009l2-9p for nanog@nanog.org; Fri, 13 Feb 2009 22:02:27 +0000 Received: from world.std.com (nobody@world.std.com [192.74.137.5]) by TheWorld.com (8.13.6/8.13.6) with ESMTP id n1DM1Pln001782; Fri, 13 Feb 2009 17:01:28 -0500 Received: (from bzs@localhost) by world.std.com (8.13.6/8.13.6) id n1DM1MfK027061; Fri, 13 Feb 2009 17:01:22 -0500 (EST) From: Barry Shein MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18837.60849.852071.770423@world.std.com> Date: Fri, 13 Feb 2009 17:01:21 -0500 To: Fernando Gont Subject: Re: Security Assessment of the Transmission Control Protocol (TCP) In-Reply-To: <4994B5AA.4080801@gont.com.ar> References: <4994B5AA.4080801@gont.com.ar> X-Mailer: VM 7.07 under Emacs 21.2.2 Cc: nanog@nanog.org X-BeenThere: nanog@nanog.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: North American Network Operators Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nanog-bounces@nanog.org X-Virus-Scanned: ClamAV 0.94.2/8989/Fri Feb 13 18:29:24 2009 on nagasaki.bogus.com X-Virus-Status: Clean From: Fernando Gont >While many textbooks and articles have created the myth that the >Internet protocols were designed for warfare environments, the top level >goal for the DARPA Internet Program was the sharing of large service >machines on the ARPANET. This in itself has become an oft-repeated canard. It is true that an important early rationalization for funding DARPA network research was to allow researchers at different institutions to use expensive (tens of millions of dollars) supercomputers from afar and, thus, not have to buy every worthy researcher their own O($100M) supercomputer center. However, an advantage in choosing a packet protocol (eventually IP) rather than a virtual circuit protocol as was popular around the time of its inception (e.g., IBM's SNA) was that packets could be re-routed around damage, transparently to virtual circuits built on top of the underlying packet protocol (e.g., TCP.) Routing of packets could be done dynamically on a per-packet basis if needed. And it was observed that routing around damage could at least in theory have utility in a situation where circuit facilities were being damaged in warfare so long as some route between two points remained. So these two goals are not mutually exclusive by any means. Merly providing remote access to super-computer facilities could have been accomplished with existing communication (e.g., phones and modems) and networks (e.g., SNA.) There was no need to fund the R&D of a new suite of protocols. Further: >As a result, many protocol specifications focus >only on the operational aspects of the protocols they specify, and >overlook their security implications. This is a non-sequitar and not a result at all. Neither goal implied security, only integrity. This was not an oversight, security was, and to a great extent still is, thought to be a higher-level function than packetizing and packet routing, with a few exceptions where a potential security flaw truly lies in the protocol (e.g., poor choice of packet sequence numbers.) >While the Internet technology evolved since it early inception, the >Internet?s building blocks are basically the same core protocols adopted >by the ARPANET more than two decades ago. Two decades is twenty years which takes me back to 1988. Three decades would be more accurate, e.g., the great NCP changeover which I think was 1978. I suppose arguably three decades is "more than two decades". >For some reason, 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). (for some reason?) To the best of my knowledge the reason is quite simple: That is not what RFCs are used for tho occasionally some summary of the state of the art appears in an RFC. The rest seems reasonably stated. -- -Barry Shein The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Login: Nationwide Software Tool & Die | Public Access Internet | SINCE 1989 *oo* --------------080907020308070304030504--