From fooologist@gmail.com Tue Jan 4 02:24:06 2011 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 E38423A6B78 for ; Tue, 4 Jan 2011 02:24:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m99JmspL9ZHI for ; Tue, 4 Jan 2011 02:24:05 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 824233A6B77 for ; Tue, 4 Jan 2011 02:24:04 -0800 (PST) Received: by qyj19 with SMTP id 19so15288410qyj.10 for ; Tue, 04 Jan 2011 02:26:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=NQJyqt6TzIgqhNPnEPH4Y09yYR4Y63fyNYrzAM30tsQ=; b=aIIPohZ5lp5BlP/+85RxgHOfJDUaPCtBqRmogpkUKCf24kp8JyyIwGEAG/sEEteLtl zxIGUN6HDxlGOqZYqhBGSeVdhntoYhLF+Mtl3B6tvpdYdxsJ16eUdQwAlgpPJCzo4SfQ Xc6cYnc36ApFC4hA6ldiq6aB7qLkOlGPRAoyA= 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=LXiwHVWMm0su/SHo9/ZkE43TmIZH5Voc/c5ZOHoqcntF4lXw0WMLgweh+zYB2V7dbk 63jp4bvt5OaKwc0AvYrvR9bgfnvRL6SDVDfezw4H2SHi6KyPKMDvV6V2AJJXHcgA99gu Akkmt1AEPnTJuM9s8z8ehPQjmPfwW1yPy3usc= MIME-Version: 1.0 Received: by 10.224.67.142 with SMTP id r14mr9018519qai.166.1294136770105; Tue, 04 Jan 2011 02:26:10 -0800 (PST) Received: by 10.220.98.85 with HTTP; Tue, 4 Jan 2011 02:26:10 -0800 (PST) In-Reply-To: <64E1A73D-2221-4035-8E77-79A6515A0DC3@kumari.net> References: <20101223193418.26547.34582.idtracker@localhost> <64E1A73D-2221-4035-8E77-79A6515A0DC3@kumari.net> Date: Tue, 4 Jan 2011 05:26:10 -0500 Message-ID: From: George Jones To: Warren Kumari Content-Type: multipart/alternative; boundary=0015175ca948790fc0049902b2f5 Cc: "opsec@ietf.org mailing list" Subject: Re: [OPSEC] Fwd: ID Tracker State Update Notice: 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, 04 Jan 2011 10:24:07 -0000 --0015175ca948790fc0049902b2f5 Content-Type: text/plain; charset=ISO-8859-1 There were a couple of things banging around under the previous charter that you might want to revisit: the capabilities (filtering, etc.) and testing. The grand vision (where RFC3871 came from) was the desire to be able to take gear into the lab, beat on it and say "yup, it can do FOO [logging, filtering, authentication...]" or not. I had some discussions with the benchmark working group about overlap. They have a pretty well refined testing methodology. ---George Jones On Thu, Dec 23, 2010 at 3:22 PM, Warren Kumari wrote: > Yet another congratulations (and thanks) is in order... > > So, our active queue is beginning to look very sparse... I have a draft > that I started writing a while ago that Chris Morrow and Danny McPherson > have agreed to fix / update (poke...), does anyone have anything else that > they are working on? > > Please? > W > > Begin forwarded message: > > From: IETF Secretariat >> Date: December 23, 2010 2:34:18 PM EST >> To: opsec-chairs@tools.ietf.org, >> draft-ietf-opsec-protect-control-plane@tools.ietf.org >> Subject: ID Tracker State Update Notice: >> >> >> State changed to RFC Ed Queue from Approved-announcement sent. >> ID Tracker URL: >> http://datatracker.ietf.org/doc/draft-ietf-opsec-protect-control-plane/ >> > > -- > "Real children don't go hoppity-skip unless they are on drugs." > > -- Susan, the ultimate sensible governess (Terry Pratchett, Hogfather) > > > > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > --0015175ca948790fc0049902b2f5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There were a couple of things banging around under the previous charter tha= t you
might want to revisit:=A0=A0 the capabilities (filtering, etc.) an= d testing.=A0 The grand vision
(where RFC3871 came from) was the desire = to be able to take gear into the lab,
beat on it and say "yup, it can do FOO [logging, filtering, authentica= tion...]" or not.
I had some discussions with the benchmark working= group about overlap.
They have a pretty well refined testing methodolog= y.

---George Jones

On Thu, Dec 23, 2010 = at 3:22 PM, Warren Kumari <warren@kumari.net> wrote:
Yet another congratulations (and thanks) is in order...

So, our active queue is beginning to look very sparse... I have a draft tha= t I started writing a while ago that Chris Morrow and Danny McPherson have = agreed to fix / update (poke...), does anyone have anything else that they = are working on?

Please?
W

Begin forwarded message:

From: IETF Secretariat <ietf-secretariat-reply@ietf.org>
Date: December 23, 2010 2:34:18 PM EST
To: opsec-= chairs@tools.ietf.org, draft-ietf-opsec-protect-control= -plane@tools.ietf.org
Subject: ID Tracker State Update Notice: <draft-ietf-opsec-protect-contr= ol-plane-06.txt>

State changed to RFC Ed Queue from Approved-announcement sent.
ID Tracker URL: http://datatracker.ietf.org/doc/= draft-ietf-opsec-protect-control-plane/

--
"Real children don't go hoppity-skip unless they are on drugs.&quo= t;

=A0 =A0-- Susan, the ultimate sensible governess (Terry Pratchett, Hogfath= er)




_______________________________________________
OPSEC mailing list
OPSEC@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/opsec

--0015175ca948790fc0049902b2f5-- From jtk@cymru.com Tue Jan 4 07:20:53 2011 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 013B73A6C80 for ; Tue, 4 Jan 2011 07:20:53 -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 tFKbHeXzKLdh for ; Tue, 4 Jan 2011 07:20:51 -0800 (PST) Received: from obelisk11.ord01.cymru.com (obelisk11.ord01.cymru.com [38.229.66.8]) by core3.amsl.com (Postfix) with ESMTP id C34BE3A6C7D for ; Tue, 4 Jan 2011 07:20:51 -0800 (PST) Received: from t61p (vpn-21-35.svcs.iad01.cymru.com [192.168.21.35]) by obelisk11.ord01.cymru.com (Postfix) with ESMTP id 42BCEB045F; Tue, 4 Jan 2011 15:22:58 +0000 (GMT) Date: Tue, 4 Jan 2011 09:22:57 -0600 From: John Kristoff To: Warren Kumari Message-ID: <20110104092257.2ff16390@t61p> In-Reply-To: <64E1A73D-2221-4035-8E77-79A6515A0DC3@kumari.net> References: <20101223193418.26547.34582.idtracker@localhost> <64E1A73D-2221-4035-8E77-79A6515A0DC3@kumari.net> X-Mailer: Claws Mail Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "opsec@ietf.org mailing list" Subject: Re: [OPSEC] Fwd: ID Tracker State Update Notice: 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, 04 Jan 2011 15:20:53 -0000 On Thu, 23 Dec 2010 15:22:22 -0500 Warren Kumari wrote: > So, our active queue is beginning to look very sparse... I have a > draft that I started writing a while ago that Chris Morrow and Danny > McPherson have agreed to fix / update (poke...), does anyone have > anything else that they are working on? I had started a port filtering draft. A second revision has been started, but we haven't spent much time on it lately. I can endeavor to get this work going again this week. John From Donald.Smith@qwest.com Tue Jan 4 08:04:30 2011 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 8F9A03A6CD5 for ; Tue, 4 Jan 2011 08:04:30 -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 fjn75z1xtZ0W for ; Tue, 4 Jan 2011 08:04:29 -0800 (PST) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by core3.amsl.com (Postfix) with ESMTP id 88DFF3A6CD4 for ; Tue, 4 Jan 2011 08:04:29 -0800 (PST) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id p04G6Yi8009811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Jan 2011 09:06:34 -0700 (MST) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 838521E0058; Tue, 4 Jan 2011 09:06:29 -0700 (MST) Received: from suomp61i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 58B1F1E0049; Tue, 4 Jan 2011 09:06:29 -0700 (MST) Received: from qtdenexhtm22.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id p04G6SNB028839; Tue, 4 Jan 2011 10:06:28 -0600 (CST) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm22.AD.QINTRA.COM ([151.119.91.231]) with mapi; Tue, 4 Jan 2011 09:06:28 -0700 From: "Smith, Donald" To: George Jones , Warren Kumari Date: Tue, 4 Jan 2011 09:04:59 -0700 Thread-Topic: [OPSEC] Fwd: ID Tracker State Update Notice: Thread-Index: Acur+dJx7PekVSYHSjejm4R0V0wFgwAL1DzH Message-ID: References: <20101223193418.26547.34582.idtracker@localhost> <64E1A73D-2221-4035-8E77-79A6515A0DC3@kumari.net>, 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "opsec@ietf.org mailing list" Subject: Re: [OPSEC] Fwd: ID Tracker State Update Notice: 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, 04 Jan 2011 16:04:30 -0000 I was thinking it might be worth while to write an rfc about testing cpp. I= t could be part of the control plane draft but I was considering it an addi= tional draft. (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com ________________________________ From: opsec-bounces@ietf.org [opsec-bounces@ietf.org] On Behalf Of George J= ones [fooologist@gmail.com] Sent: Tuesday, January 04, 2011 3:26 AM To: Warren Kumari Cc: opsec@ietf.org mailing list Subject: Re: [OPSEC] Fwd: ID Tracker State Update Notice: There were a couple of things banging around under the previous charter tha= t you might want to revisit: the capabilities (filtering, etc.) and testing. T= he grand vision (where RFC3871 came from) was the desire to be able to take gear into the l= ab, beat on it and say "yup, it can do FOO [logging, filtering, authentication.= ..]" or not. I had some discussions with the benchmark working group about overlap. They have a pretty well refined testing methodology. ---George Jones On Thu, Dec 23, 2010 at 3:22 PM, Warren Kumari > wrote: Yet another congratulations (and thanks) is in order... So, our active queue is beginning to look very sparse... I have a draft tha= t I started writing a while ago that Chris Morrow and Danny McPherson have = agreed to fix / update (poke...), does anyone have anything else that they = are working on? Please? W Begin forwarded message: From: IETF Secretariat > Date: December 23, 2010 2:34:18 PM EST To: opsec-chairs@tools.ietf.org, draft-= ietf-opsec-protect-control-plane@tools.ietf.org Subject: ID Tracker State Update Notice: State changed to RFC Ed Queue from Approved-announcement sent. ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-opsec-protect-co= ntrol-plane/ -- "Real children don't go hoppity-skip unless they are on drugs." -- Susan, the ultimate sensible governess (Terry Pratchett, Hogfather) _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec ________________________________ This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From Donald.Smith@qwest.com Tue Jan 4 10:16:19 2011 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 D7B8C3A6B73; Tue, 4 Jan 2011 10:16:19 -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 bNHmfUuag94H; Tue, 4 Jan 2011 10:16:19 -0800 (PST) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by core3.amsl.com (Postfix) with ESMTP id E65453A699F; Tue, 4 Jan 2011 10:16:18 -0800 (PST) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id p04IIOGk021920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Jan 2011 11:18:25 -0700 (MST) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id C65661E006C; Tue, 4 Jan 2011 12:18:19 -0600 (CST) Received: from suomp60i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 92F181E0059; Tue, 4 Jan 2011 12:18:19 -0600 (CST) Received: from qtdenexhtm21.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id p04IIFuJ007679; Tue, 4 Jan 2011 12:18:19 -0600 (CST) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm21.AD.QINTRA.COM ([151.119.91.230]) with mapi; Tue, 4 Jan 2011 11:18:18 -0700 From: "Smith, Donald" To: "Internet-Drafts@ietf.org" , "i-d-announce@ietf.org" Date: Tue, 4 Jan 2011 11:18:17 -0700 Thread-Topic: [OPSEC] I-D Action:draft-ietf-opsec-efforts-12.txt Thread-Index: Acry2SJ6aABoDktpSwu/Ro/S3Sn79i5YbU9f Message-ID: References: <20100513201508.0344D3A6989@core3.amsl.com> In-Reply-To: <20100513201508.0344D3A6989@core3.amsl.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-CFilter-Loop: Reflected Cc: "opsec@ietf.org" Subject: Re: [OPSEC] I-D Action:draft-ietf-opsec-efforts-12.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, 04 Jan 2011 18:16:19 -0000 Given that opsec's charter is operational security of networks, wouldn't nearly every draft coming out of the opsec group be listed in this= rfc? So shouldn't every draft listed here be in the opsec efforts draft? https://datatracker.ietf.org/wg/opsec/charter/ (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com ________________________________________ From: opsec-bounces@ietf.org [opsec-bounces@ietf.org] On Behalf Of Internet= -Drafts@ietf.org [Internet-Drafts@ietf.org] Sent: Thursday, May 13, 2010 2:15 PM To: i-d-announce@ietf.org Cc: opsec@ietf.org Subject: [OPSEC] I-D Action:draft-ietf-opsec-efforts-12.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Operational Security Capabilities for IP N= etwork Infrastructure Working Group of the IETF. Title : Security Best Practices Efforts and Documents Author(s) : C. Lonvick, D. Spak Filename : draft-ietf-opsec-efforts-12.txt Pages : 35 Date : 2010-05-13 This document provides a snapshot of the current efforts to define or apply security requirements in various Standards Developing Organizations (SDO). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opsec-efforts-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From fooologist@gmail.com Tue Jan 4 15:31:43 2011 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 563443A6D1D for ; Tue, 4 Jan 2011 15:31:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFugiDyjqEfb for ; Tue, 4 Jan 2011 15:31:42 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id EC7273A6BD6 for ; Tue, 4 Jan 2011 15:31:41 -0800 (PST) Received: by vws7 with SMTP id 7so6096365vws.31 for ; Tue, 04 Jan 2011 15:33:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=LC/4FozV9Mj+xHuveJppEchwl8am9cmDVckKmgT0RaY=; b=NVnaOeiAqUfnkjm0Nqey9wghQYi5b5Uo5aO7pKvkekUuyymsIMaSohXtVFRG4KDRc9 GTNyfBVT7lnxQp457QfuoK9MaiV0b4u/2kSFy/rQyo6tyaeorcpNHhzhxLmy4Y538eGK Ft3yyFdkYbX12O7BmpVdXnD8Z0qts1ng+sMhs= 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=ebFXwu9RLyUHtvVwu/U7Hv3CiiPoaA48sppJHj63NOwUHh9m7aS0IZJNiO8yJvekcV UEYsUsJfLzLXIvW1mLXVLf7wrYS4ets7jhl9BjduGz+19cTiCXAKlF/cj1GeShXsmTcQ 5SevU7TacbHoT2oXTftlN54udh3tcpbvQ3JcI= MIME-Version: 1.0 Received: by 10.220.181.6 with SMTP id bw6mr5260558vcb.11.1294184027854; Tue, 04 Jan 2011 15:33:47 -0800 (PST) Received: by 10.220.98.85 with HTTP; Tue, 4 Jan 2011 15:33:47 -0800 (PST) In-Reply-To: <20110104092257.2ff16390@t61p> References: <20101223193418.26547.34582.idtracker@localhost> <64E1A73D-2221-4035-8E77-79A6515A0DC3@kumari.net> <20110104092257.2ff16390@t61p> Date: Tue, 4 Jan 2011 18:33:47 -0500 Message-ID: From: George Jones To: John Kristoff Content-Type: multipart/alternative; boundary=90e6ba53a9ce4117ba04990db347 Cc: "opsec@ietf.org mailing list" , Warren Kumari Subject: Re: [OPSEC] Fwd: ID Tracker State Update Notice: 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, 04 Jan 2011 23:31:43 -0000 --90e6ba53a9ce4117ba04990db347 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jan 4, 2011 at 10:22 AM, John Kristoff wrote: > On Thu, 23 Dec 2010 15:22:22 -0500 > Warren Kumari wrote: > > > So, our active queue is beginning to look very sparse... I have a > > draft that I started writing a while ago that Chris Morrow and Danny > > McPherson have agreed to fix / update (poke...), does anyone have > > anything else that they are working on? > > I had started a port filtering draft. A second revision has been > started, but we haven't spent much time on it lately. I can endeavor > to get this work going again this week. > > > Looks like you were tackling the "what to filter and why" + gotchas. Noble. Useful. But if the device just can't do it, not sufficient. Again, what I had in mind was as series of docs that provide testable security features, possibly paired with a test methodology. Before diving into any serious work, though, it would be worth asking the question, would anybody care/be positively impacted if the docs were finished. Does anybody do this sort of testing? Would they? Would a list in the form of RFCs help ? ----George Jones --90e6ba53a9ce4117ba04990db347 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Jan 4, 2011 at 10:22 AM, John Kr= istoff <jtk@cymru.com= > wrote:
On Thu, 23 Dec 2010 15:22:22 -0500
Warren Kumari <wa= rren@kumari.net> wrote:

> So, our active queue is beginning to look very= sparse... I have a
> draft that I started writing a while ago that Chris Morrow and Danny > McPherson have agreed to fix / update (poke...), does anyone have
> anything else that they are working on?

I had started a port filtering draft. =A0A second revision has been started, but we haven't spent much time on it lately. =A0I can endeavor=
to get this work going again this week.

=A0<http://tools.ietf.org/html/draft-kristoff-opse= c-port-filtering-00>


Looks like you wer= e tackling the "what to filter and why" + gotchas.=A0=A0 Noble.= =A0 Useful.
But if the device just can't do it, not sufficient.

Again, what = I had in mind was as series of docs that provide testable security features= ,
possibly paired with a test methodology.

Before diving into any= serious work, though, it would be worth asking the question,
would anybody care/be positively impacted if the docs were finished.=A0=A0 = Does anybody
do this sort of testing?=A0 Would they?=A0=A0 Would a list = in the form of RFCs help ?

----George Jones
--90e6ba53a9ce4117ba04990db347-- From joelja@bogus.com Tue Jan 4 16:11:05 2011 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 0CFA43A6DD6 for ; Tue, 4 Jan 2011 16:11:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id feRTlfEjRV0x for ; Tue, 4 Jan 2011 16:11:00 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 876C43A6DD1 for ; Tue, 4 Jan 2011 16:10:57 -0800 (PST) Received: from joelja-mac.local (adsl-71-134-252-204.dsl.pltn13.pacbell.net [71.134.252.204]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p050Cu81096025 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 5 Jan 2011 00:12:57 GMT (envelope-from joelja@bogus.com) Message-ID: <4D23B783.4080008@bogus.com> Date: Tue, 04 Jan 2011 16:12:51 -0800 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: George Jones References: <20101223193418.26547.34582.idtracker@localhost> <64E1A73D-2221-4035-8E77-79A6515A0DC3@kumari.net> <20110104092257.2ff16390@t61p> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "opsec@ietf.org mailing list" , Warren Kumari Subject: Re: [OPSEC] Fwd: ID Tracker State Update Notice: 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, 05 Jan 2011 00:11:05 -0000 On 1/4/11 3:33 PM, George Jones wrote: > > > On Tue, Jan 4, 2011 at 10:22 AM, John Kristoff > wrote: > > On Thu, 23 Dec 2010 15:22:22 -0500 > Warren Kumari > wrote: > > > So, our active queue is beginning to look very sparse... I have a > > draft that I started writing a while ago that Chris Morrow and Danny > > McPherson have agreed to fix / update (poke...), does anyone have > > anything else that they are working on? > > I had started a port filtering draft. A second revision has been > started, but we haven't spent much time on it lately. I can endeavor > to get this work going again this week. > > > > > > Looks like you were tackling the "what to filter and why" + gotchas. > Noble. Useful. > But if the device just can't do it, not sufficient. So another thought has to do with how port filtering is done, and essentially this is a control plane policy exercise. If filtering a port in an acl is less expensive than passing a packet up to the control plane (where it ends up being discarded because there's no listening service) do you win? > Again, what I had in mind was as series of docs that provide testable > security features, > possibly paired with a test methodology. > > Before diving into any serious work, though, it would be worth asking > the question, > would anybody care/be positively impacted if the docs were finished. > Does anybody > do this sort of testing? Would they? Would a list in the form of RFCs > help ? > > ----George Jones > > > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec From fernando.gont.netbook.win@gmail.com Wed Jan 5 16:29:41 2011 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 E53683A6DC6 for ; Wed, 5 Jan 2011 16:29:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.038 X-Spam-Level: X-Spam-Status: No, score=-3.038 tagged_above=-999 required=5 tests=[AWL=-0.439, 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 MJkC+3xYcgbL for ; Wed, 5 Jan 2011 16:29:41 -0800 (PST) Received: from mail-yi0-f66.google.com (mail-yi0-f66.google.com [209.85.218.66]) by core3.amsl.com (Postfix) with ESMTP id E35143A6D79 for ; Wed, 5 Jan 2011 16:29:40 -0800 (PST) Received: by yic24 with SMTP id 24so2191347yic.1 for ; Wed, 05 Jan 2011 16:31:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=iiXwGM3aSwuODS/kiPtyGSAyY8Bsuf8qm9aThY9BXNA=; b=mecW/qnd+Qd5ACX0leO7f9fx9YWdi70NKe9zGNhat/i8YXLZGjMj476+UXeHfafPAR +oiuE2maNZVHWgJ++s/GickEKmCfncSPxgWGrev/vz4wwQJ7+4B0hiGdall1J53Mvx2G L6E9v5nBd2BnlQbqyhwDG5MKncfIMYp/OJlMg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=rGeVCRgnpeBvj2Zs60ubbmIh4vaMeoy8C7npABGri6e0owSwsM7fFg5yYXxrXNL0GL d0XTzWA1IAO1Iig5VUzsQhp9T9wSQbYZ/NxCH6vt3N5SR4LHFa+6v+TiKWL/niIT1M5z 2YDu4OPkE137tlrIQESxi6Ai5OKC23xye5S+A= Received: by 10.150.225.18 with SMTP id x18mr19963623ybg.258.1294273907471; Wed, 05 Jan 2011 16:31:47 -0800 (PST) Received: from [192.168.0.143] (61-128-17-190.fibertel.com.ar [190.17.128.61]) by mx.google.com with ESMTPS id j64sm14162007yha.35.2011.01.05.16.31.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 05 Jan 2011 16:31:46 -0800 (PST) Sender: Fernando Gont Message-ID: <4D24EDFD.2020406@gont.com.ar> Date: Wed, 05 Jan 2011 19:17:33 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Warren Kumari References: <20101223193418.26547.34582.idtracker@localhost> <64E1A73D-2221-4035-8E77-79A6515A0DC3@kumari.net> In-Reply-To: <64E1A73D-2221-4035-8E77-79A6515A0DC3@kumari.net> X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "opsec@ietf.org mailing list" Subject: Re: [OPSEC] Fwd: ID Tracker State Update Notice: 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, 06 Jan 2011 00:29:42 -0000 Hi, Warren, On 23/12/2010 05:22 p.m., Warren Kumari wrote: > So, our active queue is beginning to look very sparse... I have a draft > that I started writing a while ago that Chris Morrow and Danny McPherson > have agreed to fix / update (poke...), does anyone have anything else > that they are working on? I'm currently working on: * a revision of draft-ietf-opsec-icmp-filtering (together with Carlos Pignataro, Guillermo Gont, and Andrew Yourtchenko) * a revision of draft-gont-opsec-ip-options-filtering (this one was generated upong request from Ron at the Hiroshima IETF) * a revision of draft-kristoff-opsec-port-filtering (as already indicated by John) Thanks! Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From christopher.morrow@gmail.com Wed Jan 5 17:46:43 2011 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 7F43C3A6E51 for ; Wed, 5 Jan 2011 17:46:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IznuXxI+r1Md for ; Wed, 5 Jan 2011 17:46:42 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 1FD4B3A6E50 for ; Wed, 5 Jan 2011 17:46:41 -0800 (PST) Received: by ewy8 with SMTP id 8so7239379ewy.31 for ; Wed, 05 Jan 2011 17:48:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=oB05R6Suu6EG6eLrSWMTIaExzvumS0Cn9K6bz5Zva7U=; b=VsruVlUqfp4BjF1p9qMouLz1L8ohU64BjEizFpVZ2R+wU/uB7bmXM+ASJIdefKUDI0 9O6TzcHZ16AaHXC6eVmWNmR5oc23LIW5exce8hEjOulhRMDbJK2SPeO7sNF3/ML7nTKx 3p7zbZKDYYBXy6CfjIjzegFQRpxsz6ZuG0clA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=cu3HY9Llw1/wlLxZ2HtuuJthBAyd/fvszY9I1aMNAi2GtoRWU0DUolVTqrkuEQnc2/ 2tKzjQ2JypXkIfGVlrt5nHGgHWjffpfRgxZcqzn9vnvJJlxuPBDqQlsfD4k8fEzugJBE LHa1Y1t0qQZj3s7K6QL5nVz5d84u87IOYoBx0= MIME-Version: 1.0 Received: by 10.213.28.14 with SMTP id k14mr9134342ebc.24.1294278526694; Wed, 05 Jan 2011 17:48:46 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.213.16.71 with HTTP; Wed, 5 Jan 2011 17:48:46 -0800 (PST) In-Reply-To: <20110104092257.2ff16390@t61p> References: <20101223193418.26547.34582.idtracker@localhost> <64E1A73D-2221-4035-8E77-79A6515A0DC3@kumari.net> <20110104092257.2ff16390@t61p> Date: Wed, 5 Jan 2011 20:48:46 -0500 X-Google-Sender-Auth: wJpQtNvOoTPIZ9A3IOvX78o6fqU Message-ID: From: Christopher Morrow To: John Kristoff Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "opsec@ietf.org mailing list" , Warren Kumari Subject: Re: [OPSEC] Fwd: ID Tracker State Update Notice: 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, 06 Jan 2011 01:46:43 -0000 On Tue, Jan 4, 2011 at 10:22 AM, John Kristoff wrote: > On Thu, 23 Dec 2010 15:22:22 -0500 > Warren Kumari wrote: > >> So, our active queue is beginning to look very sparse... I have a >> draft that I started writing a while ago that Chris Morrow and Danny >> McPherson have agreed to fix / update (poke...), does anyone have >> anything else that they are working on? > > I had started a port filtering draft. =A0A second revision has been > started, but we haven't spent much time on it lately. =A0I can endeavor > to get this work going again this week. > > =A0 I hate to a) sign up for work, b) beat a horsey carcass, but... there is/was a filtering capabilities draft that made it to IESG review, then the author(s) (me mostly) ran out of time to work on it. I can dust that off, re-submit it and get the comments addressed if it'd help? -Chris (I happen to believe in the purpose/need for the draft, but a job change and work took away ietf time from me) From jared@puck.nether.net Wed Jan 5 18:35:41 2011 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 13A3F3A6BB4 for ; Wed, 5 Jan 2011 18:35: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 MQhFRNWCyrex for ; Wed, 5 Jan 2011 18:35:40 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by core3.amsl.com (Postfix) with ESMTP id B926F3A67B4 for ; Wed, 5 Jan 2011 18:35:39 -0800 (PST) Received: from [10.0.0.137] (173-167-0-106-michigan.hfc.comcastbusiness.net [173.167.0.106]) (authenticated bits=0) by puck.nether.net (8.14.4/8.12.9) with ESMTP id p062bbb7092012 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Jan 2011 21:37:40 -0500 (EST) (envelope-from jared@puck.nether.net) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jared Mauch In-Reply-To: Date: Wed, 5 Jan 2011 21:37:35 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <375AD4F0-D5EB-4821-A43E-D6F14B43A758@puck.nether.net> References: <20101223193418.26547.34582.idtracker@localhost> <64E1A73D-2221-4035-8E77-79A6515A0DC3@kumari.net> <20110104092257.2ff16390@t61p> To: Christopher Morrow X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Wed, 05 Jan 2011 21:37:43 -0500 (EST) Cc: "opsec@ietf.org mailing list" , Warren Kumari Subject: Re: [OPSEC] Fwd: ID Tracker State Update Notice: 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, 06 Jan 2011 02:35:41 -0000 On Jan 5, 2011, at 8:48 PM, Christopher Morrow wrote: > On Tue, Jan 4, 2011 at 10:22 AM, John Kristoff wrote: >> On Thu, 23 Dec 2010 15:22:22 -0500 >> Warren Kumari wrote: >>=20 >>> So, our active queue is beginning to look very sparse... I have a >>> draft that I started writing a while ago that Chris Morrow and Danny >>> McPherson have agreed to fix / update (poke...), does anyone have >>> anything else that they are working on? >>=20 >> I had started a port filtering draft. A second revision has been >> started, but we haven't spent much time on it lately. I can endeavor >> to get this work going again this week. >>=20 >> >=20 > I hate to a) sign up for work, b) beat a horsey carcass, but... there > is/was a filtering capabilities draft that made it to IESG review, > then the author(s) (me mostly) ran out of time to work on it. I can > dust that off, re-submit it and get the comments addressed if it'd > help? >=20 > -Chris > (I happen to believe in the purpose/need for the draft, but a job > change and work took away ietf time from me) Not that I want more work either, but John, Warren and Chris, you can = always count on me to read/comment with unicast mail. - Jared From joelja@bogus.com Wed Jan 5 19:21:04 2011 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 3A71B3A67E3 for ; Wed, 5 Jan 2011 19:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.17 X-Spam-Level: X-Spam-Status: No, score=-102.17 tagged_above=-999 required=5 tests=[AWL=0.429, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uy9NJ5p5Pa78 for ; Wed, 5 Jan 2011 19:21:02 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 7543C3A67E2 for ; Wed, 5 Jan 2011 19:21:01 -0800 (PST) Received: from joelja-mac.lan (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p063N0pG082394 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Thu, 6 Jan 2011 03:23:05 GMT (envelope-from joelja@bogus.com) Message-ID: <4D253592.40803@bogus.com> Date: Wed, 05 Jan 2011 19:22:58 -0800 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: "opsec@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [OPSEC] Fwd: Announcing the Community FlowSpec trial 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, 06 Jan 2011 03:21:04 -0000 -------- Original Message -------- Subject: Announcing the Community FlowSpec trial Date: Wed, 5 Jan 2011 17:46:36 -0600 From: John Kristoff To: nanog@nanog.org Friends and colleagues, At NANOG 48 I talked about a community flow-spec service we were looking at trying to make work. This is the idea of using IETF RFC 5575 to pass around flow-based rules, in this case, primarily for dropping unwanted packets. This technology is not as widely deployed as traditional RTBH techniques for a number of reasons. However, we thought perhaps it was widely used enough, or could be, to justify what might be a helpful and free 3rd party feed of flow-spec routes to keep our networks a little bit cleaner. A trial of this feed based on the traditional bogon routes can be had by contacting me directly. We realize the traditional IPv4 reserved, special and unallocated IPv4 bogon address is dwindling. Maybe there is room for some other type of feed, but to justify that, we're looking to see if even enough people would set up this presumably simpler feed to help us and the community get some more experience with multi-hop flow-spec. Details in getting it up and running in your own test networks are here: John From fooologist@gmail.com Thu Jan 6 04:40:26 2011 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 4E8403A6F02 for ; Thu, 6 Jan 2011 04:40:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UV8BOkKLzZlb for ; Thu, 6 Jan 2011 04:40:25 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 755413A6F06 for ; Thu, 6 Jan 2011 04:40:25 -0800 (PST) Received: by qyk34 with SMTP id 34so18522164qyk.10 for ; Thu, 06 Jan 2011 04:42:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=rdaKcFcRfL7su8tgWyZu2Wr1lQW5pLuiUkUpBG0jd9s=; b=pGUzKBuy9PMq0KvOlzFP2zv2RyLgzuOvFl8fguqDl1+phaBf3xnGoBlEIxMl6f2xEA +lGqLCl+COIU+pubGbtOWceHqb6LyWICo92uiSHEy0k9RRDDSAOlYHHAHAN619e3siiH RZ1vIDjOpiWDxvByh9zdRoB6XVRj/e4sK4VhQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=T8IBVDCG7aEUKlZodfV+SlEWQh5KRf0TpKWudjUVOhYOjG/w47EfkoxZ+UpIn0qHKF z3lk1ylZQ6+WYpaEyeno309ZZuYvwie+ZJBCxv4KkB+2T4r6TCMArjrXd/UefxvReCaU FP5hLGe0N6n0J9dS4eoFSAHbSsOXtA4cP7k50= MIME-Version: 1.0 Received: by 10.224.67.85 with SMTP id q21mr11113081qai.116.1294317752188; Thu, 06 Jan 2011 04:42:32 -0800 (PST) Received: by 10.220.98.85 with HTTP; Thu, 6 Jan 2011 04:42:32 -0800 (PST) Date: Thu, 6 Jan 2011 07:42:32 -0500 Message-ID: From: George Jones To: "opsec@ietf.org mailing list" Content-Type: multipart/alternative; boundary=0015175cd202d8814704992cd582 Subject: [OPSEC] Just because you can... 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, 06 Jan 2011 12:40:26 -0000 --0015175cd202d8814704992cd582 Content-Type: text/plain; charset=ISO-8859-1 So, I think we need a little WG Chair input and reflection on charter before we go rushing off to write/finish a bunch of capability drafts. Also, a reality/usefulness check. Should we do a bunch of disconnected capability drafts ? Way back when, I had plans for a large series of connected drafts with similar style, reinforcing each other and feeding a formal test process (a la the benchmark WG). Maybe to much. Overcome By Events? Maybe it's better to pick off bite size pieces that people have passion for and do them ? And, before we go to far, we should ask the "So What?" question. Lets say the drafts were finished and published. Who would use them? Would the actually improve securtiy/products/operational practices? How? Thoughts? ---George Jones --0015175cd202d8814704992cd582 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable So= , I think we need a little WG Chair input and reflection on charter before = we go
rushing off to write/finish a bunch of capability drafts. =A0 Als= o, a reality/usefulness check.

Should we do a bunch of disconnected capability drafts = ? =A0Way back when, I had plans
for a large series of connected d= rafts with similar style, reinforcing each other and feeding
a fo= rmal test process (a la the benchmark WG). =A0 Maybe to much. =A0Overcome B= y Events?
Maybe it's better to pick off bite size pieces that people have pa= ssion for and do them ?

And, before we go to far, = we should ask the "So What?" question. =A0 Lets say the drafts
were finished and published. =A0 Who would use them? =A0 Would the act= ually improve
securtiy/products/operational practices? =A0How?

Thoughts? =A0

---George Jon= es
--0015175cd202d8814704992cd582-- From rbonica@juniper.net Thu Jan 6 12:42:18 2011 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 A85F53A6CFF for ; Thu, 6 Jan 2011 12:42:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.498 X-Spam-Level: X-Spam-Status: No, score=-106.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZ1kVDx3Pn+8 for ; Thu, 6 Jan 2011 12:42:13 -0800 (PST) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id 3E1653A6A94 for ; Thu, 6 Jan 2011 12:42:10 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKTSYpoQ0WjmoI/qVS61NxlMEOM7wKijD4@postini.com; Thu, 06 Jan 2011 12:44:20 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 6 Jan 2011 12:41:14 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::8002:d3e7:4146:af5f]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Thu, 6 Jan 2011 15:41:13 -0500 From: Ronald Bonica To: George Jones , John Kristoff Date: Thu, 6 Jan 2011 15:41:12 -0500 Thread-Topic: [OPSEC] Fwd: ID Tracker State Update Notice: Thread-Index: AcusZ94Jq//Jq/+uQ4SFHxYKlNWARgBeYg0A Message-ID: <13205C286662DE4387D9AF3AC30EF456B03C23767C@EMBX01-WF.jnpr.net> References: <20101223193418.26547.34582.idtracker@localhost> <64E1A73D-2221-4035-8E77-79A6515A0DC3@kumari.net> <20110104092257.2ff16390@t61p> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_13205C286662DE4387D9AF3AC30EF456B03C23767CEMBX01WFjnprn_" MIME-Version: 1.0 Cc: "opsec@ietf.org mailing list" , Warren Kumari Subject: Re: [OPSEC] Fwd: ID Tracker State Update Notice: 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, 06 Jan 2011 20:42:18 -0000 --_000_13205C286662DE4387D9AF3AC30EF456B03C23767CEMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Response inline...... From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf Of G= eorge Jones Sent: Tuesday, January 04, 2011 6:34 PM To: John Kristoff Cc: opsec@ietf.org mailing list; Warren Kumari Subject: Re: [OPSEC] Fwd: ID Tracker State Update Notice: On Tue, Jan 4, 2011 at 10:22 AM, John Kristoff > wrote: On Thu, 23 Dec 2010 15:22:22 -0500 Warren Kumari > wrote: > So, our active queue is beginning to look very sparse... I have a > draft that I started writing a while ago that Chris Morrow and Danny > McPherson have agreed to fix / update (poke...), does anyone have > anything else that they are working on? I had started a port filtering draft. A second revision has been started, but we haven't spent much time on it lately. I can endeavor to get this work going again this week. This is very important work! Please continue. Looks like you were tackling the "what to filter and why" + gotchas. Nobl= e. Useful. But if the device just can't do it, not sufficient. I recommend that you continue on these lines. If the device can't fulfill y= ou requirements, maybe the RFC will motivate the vendors to enhance the dev= ice's filtering capabilities. Again, what I had in mind was as series of docs that provide testable secur= ity features, possibly paired with a test methodology. Before diving into any serious work, though, it would be worth asking the q= uestion, would anybody care/be positively impacted if the docs were finished. I believe that this would be helpful both to the operator and vendor commun= ities, New operators would learn what to filter. Application and protocol d= evelopers would learn what is likely to be filtered. Ron Does anybody do this sort of testing? Would they? Would a list in the form of RFCs he= lp ? ----George Jones --_000_13205C286662DE4387D9AF3AC30EF456B03C23767CEMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Response inline……

 

From: opsec-bounces= @ietf.org [mailto:opsec-bounces@ietf.org] On Behalf Of George Jones
Sent: Tuesday, January 04, 2011 6:34 PM
To: John Kristoff
Cc: opsec@ietf.org mailing list; Warren Kumari
Subject: Re: [OPSEC] Fwd: ID Tracker State Update Notice: <draft-ietf-opsec-protect-control-plane-06.txt>

 

 

On Tue, Jan 4, 2011 at 10:22 AM, John Kristoff <jtk@cymru.com> wrote:

On Thu, 23 Dec 2010 15:22:22 -0500

Warren Kumari <warren@kumari.net> wrote:

> So, our active que= ue is beginning to look very sparse... I have a
> draft that I started writing a while ago that Chris Morrow and Danny > McPherson have agreed to fix / update (poke...), does anyone have
> anything else that they are working on?

I had started a port filtering draft.  A second revision has been
started, but we haven't spent much time on it lately.  I can endeavor<= br> to get this work going again this week.

 <http://tools.ietf.org/html/draft-kristoff-opsec-port-filt= ering-00>

 

This is very important work! Please continue.



Looks like you were tackling the "what to filter and why" + gotchas.   Noble.  Useful.
But if the device just can't do it, not sufficient.

 

I recommend that you continue on these lines. If the device = can’t fulfill you requirements, maybe the RFC will motivate the vendors to enhanc= e the device’s filtering capabilities.



Again, what I had in mind was as series of docs that provide testable secur= ity features,
possibly paired with a test methodology.

Before diving into any serious work, though, it would be worth asking the question,
would anybody care/be positively impacted if the docs were finished.  

 

I believe that this would be helpful both to the operator an= d vendor communities, New operators would learn what to filter. Application a= nd protocol developers would learn what is likely to be filtered.

 

          =             &nb= sp;    Ron

 

Does anybody
do this sort of testing?  Would they?   Would a list in the = form of RFCs help ?

----George Jones

--_000_13205C286662DE4387D9AF3AC30EF456B03C23767CEMBX01WFjnprn_-- From Donald.Smith@qwest.com Thu Jan 6 21:43:34 2011 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 616123A677C for ; Thu, 6 Jan 2011 21:43:34 -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 Gc8ONmtWozfu for ; Thu, 6 Jan 2011 21:43:32 -0800 (PST) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by core3.amsl.com (Postfix) with ESMTP id 642AC3A6405 for ; Thu, 6 Jan 2011 21:43:32 -0800 (PST) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id p075jZPs019967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Jan 2011 22:45:35 -0700 (MST) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 606681E0049; Thu, 6 Jan 2011 22:45:30 -0700 (MST) Received: from suomp60i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 2F4331E0035; Thu, 6 Jan 2011 22:45:30 -0700 (MST) Received: from qtdenexhtm20.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id p075jScO018058; Thu, 6 Jan 2011 23:45:29 -0600 (CST) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm20.AD.QINTRA.COM ([151.119.91.229]) with mapi; Thu, 6 Jan 2011 22:45:29 -0700 From: "Smith, Donald" To: Ronald Bonica , George Jones , John Kristoff Date: Thu, 6 Jan 2011 22:43:23 -0700 Thread-Topic: [OPSEC] Fwd: ID Tracker State Update Notice: Thread-Index: AcusZ94Jq//Jq/+uQ4SFHxYKlNWARgBeYg0AABMZiis= Message-ID: References: <20101223193418.26547.34582.idtracker@localhost> <64E1A73D-2221-4035-8E77-79A6515A0DC3@kumari.net> <20110104092257.2ff16390@t61p> , <13205C286662DE4387D9AF3AC30EF456B03C23767C@EMBX01-WF.jnpr.net> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456B03C23767C@EMBX01-WF.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "opsec@ietf.org mailing list" , Warren Kumari Subject: Re: [OPSEC] Fwd: ID Tracker State Update Notice: 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, 07 Jan 2011 05:43:34 -0000 We do that kind of testing:) Testing methods and practices are nearly forgotten amongst many shops today= but we still find enough to do fairly through testing (and reap the benefi= ts of it:) (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com ________________________________ From: opsec-bounces@ietf.org [opsec-bounces@ietf.org] On Behalf Of Ronald B= onica [rbonica@juniper.net] Sent: Thursday, January 06, 2011 1:41 PM To: George Jones; John Kristoff Cc: opsec@ietf.org mailing list; Warren Kumari Subject: Re: [OPSEC] Fwd: ID Tracker State Update Notice: Response inline=85=85 From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf Of G= eorge Jones Sent: Tuesday, January 04, 2011 6:34 PM To: John Kristoff Cc: opsec@ietf.org mailing list; Warren Kumari Subject: Re: [OPSEC] Fwd: ID Tracker State Update Notice: On Tue, Jan 4, 2011 at 10:22 AM, John Kristoff > wrote: On Thu, 23 Dec 2010 15:22:22 -0500 Warren Kumari > wrote: > So, our active queue is beginning to look very sparse... I have a > draft that I started writing a while ago that Chris Morrow and Danny > McPherson have agreed to fix / update (poke...), does anyone have > anything else that they are working on? I had started a port filtering draft. A second revision has been started, but we haven't spent much time on it lately. I can endeavor to get this work going again this week. This is very important work! Please continue. Looks like you were tackling the "what to filter and why" + gotchas. Nobl= e. Useful. But if the device just can't do it, not sufficient. I recommend that you continue on these lines. If the device can=92t fulfill= you requirements, maybe the RFC will motivate the vendors to enhance the d= evice=92s filtering capabilities. Again, what I had in mind was as series of docs that provide testable secur= ity features, possibly paired with a test methodology. Before diving into any serious work, though, it would be worth asking the q= uestion, would anybody care/be positively impacted if the docs were finished. I believe that this would be helpful both to the operator and vendor commun= ities, New operators would learn what to filter. Application and protocol d= evelopers would learn what is likely to be filtered. Ron Does anybody do this sort of testing? Would they? Would a list in the form of RFCs he= lp ? ----George Jones ________________________________ This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From fooologist@gmail.com Fri Jan 7 05:38:28 2011 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 2F9DA3A68BE for ; Fri, 7 Jan 2011 05:38:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTSkAUdaSiTl for ; Fri, 7 Jan 2011 05:38:27 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 46E4A3A68BC for ; Fri, 7 Jan 2011 05:38:27 -0800 (PST) Received: by qyk34 with SMTP id 34so462709qyk.10 for ; Fri, 07 Jan 2011 05:40:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=teuCt9qG4AtWp6xWo2fTJhQt3E43Pthjtl7X8F7loqs=; b=da7JtaWpf7AsvmRO6DYKQzMtH5LXUl61eLm6aKa+XZe0WA05su4m7nWVSTeyGjykHJ oneHIBGeuCz5msKZfAIBVnToQhXobAuMXMQijLPI8R0TZZJTxfcMfrcgmQCBXtfQV4tD iKuHqv5MUxK/1uOn2/NvLTVLpnze+qry5cz9U= 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=XoMX6/XxCGtQ5mm+X/jif7cgjWJVeDCY3oz3IOHKzAG2rMB20C/i9zdmDzl6KNWYeF jwHBVhGZ9ToHzabHk2e0/1OIZKtt5NwlsksKXzygnpLQZN05hxN0FlVbhyEJsu+ySfny 3cqtnnKGWEtTiC3oeXDDflpeoRlTZhFBbShho= MIME-Version: 1.0 Received: by 10.229.241.84 with SMTP id ld20mr9718791qcb.128.1294407633818; Fri, 07 Jan 2011 05:40:33 -0800 (PST) Received: by 10.220.98.85 with HTTP; Fri, 7 Jan 2011 05:40:33 -0800 (PST) In-Reply-To: References: <20101223193418.26547.34582.idtracker@localhost> <64E1A73D-2221-4035-8E77-79A6515A0DC3@kumari.net> <20110104092257.2ff16390@t61p> <13205C286662DE4387D9AF3AC30EF456B03C23767C@EMBX01-WF.jnpr.net> Date: Fri, 7 Jan 2011 08:40:33 -0500 Message-ID: From: George Jones To: "Smith, Donald" Content-Type: multipart/alternative; boundary=00163630f443355577049941c3ba Cc: "opsec@ietf.org mailing list" , Warren Kumari Subject: Re: [OPSEC] Fwd: ID Tracker State Update Notice: 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, 07 Jan 2011 13:38:28 -0000 --00163630f443355577049941c3ba Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jan 7, 2011 at 12:43 AM, Smith, Donald wrote: > We do that kind of testing:) > Testing methods and practices are nearly forgotten amongst many shops today > but we still find enough to do fairly through testing (and reap the benefits > of it:) > Then do you care to comment on what forms of docs would be helpful? Does anyone else on the list (or that people on the list know) do testing ? ---George --00163630f443355577049941c3ba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On= Fri, Jan 7, 2011 at 12:43 AM, Smith, Donald=A0<Donald.Smith@qwest.com>= =A0wrote:
We do that kind of testing:)
Testing methods and practices are nearly fo= rgotten amongst many shops today but we still find enough to do fairly thro= ugh testing (and reap the benefits of it:)

Then do you care to comment on what forms of docs would be helpful?

Does anyone else on the list (or that people on the = list know) do testing ?

---George

--00163630f443355577049941c3ba-- From fooologist@gmail.com Fri Jan 7 05:45:07 2011 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 21A293A68C8 for ; Fri, 7 Jan 2011 05:45:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80FPyUWfWmUd for ; Fri, 7 Jan 2011 05:45:05 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 0C1F73A68C2 for ; Fri, 7 Jan 2011 05:45:04 -0800 (PST) Received: by qwi2 with SMTP id 2so2032345qwi.31 for ; Fri, 07 Jan 2011 05:47:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=dpJYLyM56uO28h/t9ovLbGWFsu58XXKq14Wwro+wS3M=; b=FDV614KS+GZw2J/P4wOyhiGkGr40KX7t7feXOqGtZJQqXQ+zNDB7TeRE2fSH06jRt9 i8lS1Vi3BW1OuOPH8HbuIeDIAkXK2iarDHllrEjyslJm3AkAYWLZFeS03W0dJqWxr9S5 0IghhsOFAKM51g2KdiuKZm1cZJmbX+07/YUCs= 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=JdRfN6H1Q31MAeEOzua2SLvZ8KaO5c25X8XFUObmMTKBn8XcANd/X0BmuoyEjXs61N wWelLzVnxywQIsaYbcwvOteb51TmDEkfGoyN5Nxg/FtgNOsOWE1RKzgm9SxG4KMEzt2D Lg4fzsqtdtng8t9ktZefY6/+W0iAKIzm1PjTc= MIME-Version: 1.0 Received: by 10.229.218.197 with SMTP id hr5mr9105837qcb.14.1294408029883; Fri, 07 Jan 2011 05:47:09 -0800 (PST) Received: by 10.220.98.85 with HTTP; Fri, 7 Jan 2011 05:47:09 -0800 (PST) In-Reply-To: <13205C286662DE4387D9AF3AC30EF456B03C23767C@EMBX01-WF.jnpr.net> References: <20101223193418.26547.34582.idtracker@localhost> <64E1A73D-2221-4035-8E77-79A6515A0DC3@kumari.net> <20110104092257.2ff16390@t61p> <13205C286662DE4387D9AF3AC30EF456B03C23767C@EMBX01-WF.jnpr.net> Date: Fri, 7 Jan 2011 08:47:09 -0500 Message-ID: From: George Jones To: Ronald Bonica Content-Type: multipart/alternative; boundary=0016361e80a8d0cc44049941daea Cc: "opsec@ietf.org mailing list" , Warren Kumari Subject: Re: [OPSEC] Fwd: ID Tracker State Update Notice: 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, 07 Jan 2011 13:45:07 -0000 --0016361e80a8d0cc44049941daea Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, Jan 6, 2011 at 3:41 PM, Ronald Bonica wrote: > Response inline=85=85 > > has been > > started, but we haven't spent much time on it lately. I can endeavor > to get this work going again this week. > > > > > > This is very important work! Please continue. > > > > I believe that this would be helpful both to the operator and vendor > communities, New operators would learn what to filter. Application and > protocol developers would learn what is likely to be filtered. > > > I'm just thinking that if we spin up capability drafts ("the device is capable of ....") it would be useful to have a common rational/list of motivators ("help in testing", etc.) and possibly a common format. Before we run off an write/finish a bunch of drafts I think we (the WG Chairs/ADs/WG members) should at least have that discussion so that we can say why we're writing drafts and how we anticipate them being useful. ---George Jones --0016361e80a8d0cc44049941daea Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, Jan 6, 2011 at 3:41 PM, Ronald Bonica <rbonica@juniper.net> wrote:

Respo= nse inline=85=85

=A0has been

started, but we haven't spent much time on it lately. =A0I can endeavor=
to get this work going again this week.

=A0<http://tools.ietf.org/html/draft-kristoff-opsec= -port-filtering-00>

=A0

This is very important work! Please continue.



I believe that this would be helpful both to the operator and vendor communities, New operators would learn what to filter. Application a= nd protocol developers would learn what is likely to be filtered.

=A0


I'm just thinking that if we spin up capability drafts (&qu= ot;the device is=A0capable=A0of ....") it would be useful=A0
to have a common rational/list of motivators ("help in testing&qu= ot;, etc.) and possibly a common format.

Before we= run off an write/finish a bunch of drafts I think we (the WG Chairs/ADs/WG= members)
should at least have that discussion so that we can say why we're = writing drafts and how
we anticipate them being useful.

---George Jones
--0016361e80a8d0cc44049941daea-- From Donald.Smith@qwest.com Fri Jan 7 05:57:17 2011 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 7BD693A68D4 for ; Fri, 7 Jan 2011 05:57:17 -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 kvYjlulLogbH for ; Fri, 7 Jan 2011 05:57:16 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by core3.amsl.com (Postfix) with ESMTP id 5AC373A68D2 for ; Fri, 7 Jan 2011 05:57:16 -0800 (PST) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id p07DxKBD019069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Jan 2011 07:59:20 -0600 (CST) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 685ED1E0050; Fri, 7 Jan 2011 07:59:15 -0600 (CST) Received: from sudnp796.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 32F6B1E0032; Fri, 7 Jan 2011 07:59:15 -0600 (CST) Received: from qtdenexhtm21.AD.QINTRA.COM (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id p07DxEpI000398; Fri, 7 Jan 2011 06:59:14 -0700 (MST) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm21.AD.QINTRA.COM ([151.119.91.230]) with mapi; Fri, 7 Jan 2011 06:59:14 -0700 From: "Smith, Donald" To: George Jones Date: Fri, 7 Jan 2011 06:59:13 -0700 Thread-Topic: [OPSEC] Fwd: ID Tracker State Update Notice: Thread-Index: AcuucHbSmRgvpN6STcmQukHDg1h+nAAAdnaj Message-ID: References: <20101223193418.26547.34582.idtracker@localhost> <64E1A73D-2221-4035-8E77-79A6515A0DC3@kumari.net> <20110104092257.2ff16390@t61p> <13205C286662DE4387D9AF3AC30EF456B03C23767C@EMBX01-WF.jnpr.net> , 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "opsec@ietf.org mailing list" , Warren Kumari Subject: Re: [OPSEC] Fwd: ID Tracker State Update Notice: 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, 07 Jan 2011 13:57:17 -0000 I have always thought a set of test cases that could be reformatted/used by= others but with standard test elements. Pre condition, post conditions/expectations, tool, parameters, requiremen= t your testing against,, rfc or other bcp that your testing towards etc... You could take 3871 as the base requirement and give examples/samples of ho= w to test each element of that bcp. We have a set of these for our mgmt plane testing using opensource tools wh= ich is loosely based on rfc3871. (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com ________________________________ From: George Jones [fooologist@gmail.com] Sent: Friday, January 07, 2011 6:40 AM To: Smith, Donald Cc: Ronald Bonica; John Kristoff; opsec@ietf.org mailing list; Warren Kumar= i Subject: Re: [OPSEC] Fwd: ID Tracker State Update Notice: On Fri, Jan 7, 2011 at 12:43 AM, Smith, Donald > wrote: We do that kind of testing:) Testing methods and practices are nearly forgotten amongst many shops today= but we still find enough to do fairly through testing (and reap the benefi= ts of it:) Then do you care to comment on what forms of docs would be helpful? Does anyone else on the list (or that people on the list know) do testing ? ---George ________________________________ This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From warren@kumari.net Sat Jan 8 17:51:09 2011 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 6266528C15D for ; Sat, 8 Jan 2011 17:51:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFvCNcif5iGQ for ; Sat, 8 Jan 2011 17:51:08 -0800 (PST) Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id 0142928C0D8 for ; Sat, 8 Jan 2011 17:51:04 -0800 (PST) Received: from [192.168.0.227] (unknown [64.13.52.115]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id 26031228454C; Sat, 8 Jan 2011 20:53:13 -0500 (EST) Message-Id: <32EF1B17-B78C-47FC-B1A6-8B6CD3C50D6F@kumari.net> From: Warren Kumari To: Christopher Morrow In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 8 Jan 2011 20:53:11 -0500 References: <20101223193418.26547.34582.idtracker@localhost> <64E1A73D-2221-4035-8E77-79A6515A0DC3@kumari.net> <20110104092257.2ff16390@t61p> X-Mailer: Apple Mail (2.936) Cc: "opsec@ietf.org mailing list" Subject: Re: [OPSEC] Fwd: ID Tracker State Update Notice: X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 01:51:09 -0000 On Jan 5, 2011, at 8:48 PM, Christopher Morrow wrote: > On Tue, Jan 4, 2011 at 10:22 AM, John Kristoff wrote: >> On Thu, 23 Dec 2010 15:22:22 -0500 >> Warren Kumari wrote: >> >>> So, our active queue is beginning to look very sparse... I have a >>> draft that I started writing a while ago that Chris Morrow and Danny >>> McPherson have agreed to fix / update (poke...), Poke again :-P >>> does anyone have >>> anything else that they are working on? >> >> I had started a port filtering draft. A second revision has been >> started, but we haven't spent much time on it lately. I can endeavor >> to get this work going again this week. >> >> > > I hate to a) sign up for work, b) beat a horsey carcass, but... there > is/was a filtering capabilities draft that made it to IESG review, > then the author(s) (me mostly) ran out of time to work on it. I can > dust that off, re-submit it and get the comments addressed if it'd > help? Yah, I remember this doc, and think that it would be great if you could resurrect it. AFAIR there was not much that needed doing to make it happy... > > -Chris > (I happen to believe in the purpose/need for the draft, but a job > change and work took away ietf time from me) Make you a deal -- I'll bring you an espresso for each rev of a draft you submit... And try harder to keep my headphones on.... > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec From joelja@bogus.com Sun Jan 9 08:42:14 2011 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 E3BC63A6813 for ; Sun, 9 Jan 2011 08:42:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.607 X-Spam-Level: X-Spam-Status: No, score=-101.607 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oe2YvZ6XDU8W for ; Sun, 9 Jan 2011 08:42:14 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id B9F0F3A6812 for ; Sun, 9 Jan 2011 08:42:13 -0800 (PST) Received: from 58b035843c84.netpoint.com ([213.221.117.228]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p09Gi7Pg057666 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sun, 9 Jan 2011 16:44:18 GMT (envelope-from joelja@bogus.com) Message-ID: <4D2933D7.5050105@bogus.com> Date: Sat, 08 Jan 2011 20:04:39 -0800 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Christopher Morrow References: <20101223193418.26547.34582.idtracker@localhost> <64E1A73D-2221-4035-8E77-79A6515A0DC3@kumari.net> <20110104092257.2ff16390@t61p> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "opsec@ietf.org mailing list" , Warren Kumari Subject: Re: [OPSEC] Fwd: ID Tracker State Update Notice: X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 16:42:15 -0000 On 1/5/11 5:48 PM, Christopher Morrow wrote: > On Tue, Jan 4, 2011 at 10:22 AM, John Kristoff wrote: >> On Thu, 23 Dec 2010 15:22:22 -0500 >> Warren Kumari wrote: >> >>> So, our active queue is beginning to look very sparse... I have a >>> draft that I started writing a while ago that Chris Morrow and Danny >>> McPherson have agreed to fix / update (poke...), does anyone have >>> anything else that they are working on? >> >> I had started a port filtering draft. A second revision has been >> started, but we haven't spent much time on it lately. I can endeavor >> to get this work going again this week. >> >> > > I hate to a) sign up for work, b) beat a horsey carcass, but... there > is/was a filtering capabilities draft that made it to IESG review, > then the author(s) (me mostly) ran out of time to work on it. I can > dust that off, re-submit it and get the comments addressed if it'd > help? speaking as the guy who removed the caps documents from the charter. I think there was a lack of stomach for the work that would have taken a completed capabiliteis document and matched it with a product development cycle and produced the router/firewall etc... That said operational recomendations on port filtering sounds like a worthwhile activity. > -Chris > (I happen to believe in the purpose/need for the draft, but a job > change and work took away ietf time from me) > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > From rbonica@juniper.net Tue Jan 11 09:28:13 2011 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 A874D28C274 for ; Tue, 11 Jan 2011 09:28:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.504 X-Spam-Level: X-Spam-Status: No, score=-106.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FP2sOGCDoWSp for ; Tue, 11 Jan 2011 09:28:13 -0800 (PST) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id F113528C0CE for ; Tue, 11 Jan 2011 09:28:08 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKTSyTspyG+dgCJkgEnNZKg2ZPrsrYh1O4@postini.com; Tue, 11 Jan 2011 09:30:26 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 11 Jan 2011 09:26:00 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::8002:d3e7:4146:af5f]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Tue, 11 Jan 2011 12:25:59 -0500 From: Ronald Bonica To: "opsec@ietf.org" Date: Tue, 11 Jan 2011 12:25:56 -0500 Thread-Topic: New Work: Protecting the control plane Thread-Index: AcuxtJtljSTAlzM/SmybuJ8p31Q9Qw== Message-ID: <13205C286662DE4387D9AF3AC30EF456B03C46D9F2@EMBX01-WF.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: cC8= ve8= ANfN AaK+ AqnX BjMn CiNN CufA DG5m DQ11 DcL8 D28+ EuEz H6TS IdrH IthN; 1; bwBwAHMAZQBjAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {F7103C1E-8019-4EC9-A4A2-6B0B3B4BDB99}; cgBiAG8AbgBpAGMAYQBAAGoAdQBuAGkAcABlAHIALgBuAGUAdAA=; Tue, 11 Jan 2011 17:25:57 GMT; TgBlAHcAIABXAG8AcgBrADoAIABQAHIAbwB0AGUAYwB0AGkAbgBnACAAdABoAGUAIABjAG8AbgB0AHIAbwBsACAAcABsAGEAbgBlAA== x-cr-puzzleid: {F7103C1E-8019-4EC9-A4A2-6B0B3B4BDB99} acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OPSEC] New Work: Protecting the control plane 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, 11 Jan 2011 17:28:13 -0000 Folks, RFC-to-be draft-ietf-opsec-protect-control-plane recommends methods for pro= tecting a router's control plane from outsider attack. However, the methods= proposed in draft-ietf-opsec-protect-control-plane do not protect against: - attacks from those spoofing the source address of a legitimate control pl= ane peer - attacks from legitimate control plane peers (that might be compromised or= otherwise misbehaving) Is anyone interested in authoring a draft to address these issues? Ron From vishwas.ietf@gmail.com Tue Jan 11 09:44:20 2011 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 1C0683A6A5E for ; Tue, 11 Jan 2011 09:44:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.13 X-Spam-Level: X-Spam-Status: No, score=-3.13 tagged_above=-999 required=5 tests=[AWL=0.469, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WbLuu+MiWNlY for ; Tue, 11 Jan 2011 09:44:19 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 101813A6A55 for ; Tue, 11 Jan 2011 09:44:18 -0800 (PST) Received: by eyd10 with SMTP id 10so9218564eyd.31 for ; Tue, 11 Jan 2011 09:46:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=i6H2x57L45kc8EIy+HDcL/117leMLqiTxSvdQKWDsQs=; b=hHaC9woTnpIennLt98iETl3avhDWmc2dYLnZ1TlbL1SAQ5e8Fn0vQewsbCprXcP3vl 5OTidN5QLsM0CGr01U7S03A7XqtO3QZ0KAtZNA9tsiXR2fOirE6Stoj5dPkKSFyW44Ff yStjtdPxh5nklG6hQA8+B1fEiKHT0WzEJo5YE= 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=XyCn/cImS7XpDL/peP6E1CPbRsBA+aegCulMPlOe+gBEEzQ0UKEYT+oWf57I3vYCM6 JwJib8fi67F2Q6bjmA3+1HPjwXPuQoBKPXxKpxo9A/ZT1EZGOKUKJsIkLd2xhkL7PQ9K EPnHej+mj1Ult5iaReuT3n+vRyBWe51On9mp8= MIME-Version: 1.0 Received: by 10.216.27.202 with SMTP id e52mr5427972wea.75.1294767995309; Tue, 11 Jan 2011 09:46:35 -0800 (PST) Received: by 10.216.139.219 with HTTP; Tue, 11 Jan 2011 09:46:35 -0800 (PST) In-Reply-To: <13205C286662DE4387D9AF3AC30EF456B03C46D9F2@EMBX01-WF.jnpr.net> References: <13205C286662DE4387D9AF3AC30EF456B03C46D9F2@EMBX01-WF.jnpr.net> Date: Tue, 11 Jan 2011 09:46:35 -0800 Message-ID: From: Vishwas Manral To: Ronald Bonica Content-Type: text/plain; charset=ISO-8859-1 Cc: "opsec@ietf.org" Subject: Re: [OPSEC] New Work: Protecting the control plane 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, 11 Jan 2011 17:44:20 -0000 Hi Ron, > - attacks from those spoofing the source address of a legitimate control plane peer This can be caught by authentication, mechanisms also using the source address as a part of the hash. > - attacks from legitimate control plane peers (that might be compromised or otherwise misbehaving) This is considerably harder to know for IGP's. For BGP we can verify the origin . One thing that can be done is Public Key Cryptography. There are mechanisms available for the same already, however the documents are experimental. The question however is how important are these issues for the operators to tackle? Thanks, Vishwas From jared@puck.nether.net Tue Jan 11 09:52:29 2011 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 8D4F628C28A for ; Tue, 11 Jan 2011 09:52:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGxJj3yu4Dx3 for ; Tue, 11 Jan 2011 09:52:28 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by core3.amsl.com (Postfix) with ESMTP id CB97B3A6A62 for ; Tue, 11 Jan 2011 09:52:27 -0800 (PST) Received: from [10.0.0.137] (173-167-0-106-michigan.hfc.comcastbusiness.net [173.167.0.106]) (authenticated bits=0) by puck.nether.net (8.14.4/8.12.9) with ESMTP id p0BHsfZ4074634 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 Jan 2011 12:54:41 -0500 (EST) (envelope-from jared@puck.nether.net) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jared Mauch In-Reply-To: Date: Tue, 11 Jan 2011 12:54:40 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3CF48DFA-83C4-4DE0-AF48-A783B3CAC1F6@puck.nether.net> References: <13205C286662DE4387D9AF3AC30EF456B03C46D9F2@EMBX01-WF.jnpr.net> To: Vishwas Manral X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Tue, 11 Jan 2011 12:54:41 -0500 (EST) Cc: "opsec@ietf.org" Subject: Re: [OPSEC] New Work: Protecting the control plane 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, 11 Jan 2011 17:52:29 -0000 On Jan 11, 2011, at 12:46 PM, Vishwas Manral wrote: > Hi Ron, >=20 >=20 >> - attacks from those spoofing the source address of a legitimate = control plane peer > This can be caught by authentication, mechanisms also using the source > address as a part of the hash. maybe with something like gtsh. people generate all sorts of garbage on = the internet, using ONLY the src_ip+dst_ip is not enough, but a good = starting point. >=20 >> - attacks from legitimate control plane peers (that might be = compromised or otherwise misbehaving) > This is considerably harder to know for IGP's. For BGP we can verify > the origin . One thing that can be done is Public Key Cryptography. > There are mechanisms available for the same already, however the > documents are experimental. >=20 > The question however is how important are these issues for the > operators to tackle? Based on real-life attacks, it's important to insure the attacks don't = overwhelm the underpowered cpus that are in some devices. Suggesting = crypto as part of that is only useful if there is a dedicated crypto = engine that is now required. - Jared= From rbonica@juniper.net Tue Jan 11 10:04:19 2011 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 244B63A6A3F for ; Tue, 11 Jan 2011 10:04:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.505 X-Spam-Level: X-Spam-Status: No, score=-106.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONdwvKmsoikt for ; Tue, 11 Jan 2011 10:04:18 -0800 (PST) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by core3.amsl.com (Postfix) with ESMTP id E000D3A6832 for ; Tue, 11 Jan 2011 10:04:16 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKTSycKTPuW2sCQjfWGJnaKh3gFYOzGREF@postini.com; Tue, 11 Jan 2011 10:06:35 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 11 Jan 2011 10:01:13 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::8002:d3e7:4146:af5f]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 11 Jan 2011 13:01:12 -0500 From: Ronald Bonica To: Vishwas Manral Date: Tue, 11 Jan 2011 13:01:11 -0500 Thread-Topic: [OPSEC] New Work: Protecting the control plane Thread-Index: Acuxt38uUmxj8duKRnSy9kbMjDGAugAAe7sw Message-ID: <13205C286662DE4387D9AF3AC30EF456B03C46DA5B@EMBX01-WF.jnpr.net> References: <13205C286662DE4387D9AF3AC30EF456B03C46D9F2@EMBX01-WF.jnpr.net> 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 Cc: "opsec@ietf.org" Subject: Re: [OPSEC] New Work: Protecting the control plane 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, 11 Jan 2011 18:04:19 -0000 There are a few simple things that we can do (e.g., rate limit TCP SYNs) Ron > -----Original Message----- > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > Sent: Tuesday, January 11, 2011 12:47 PM > To: Ronald Bonica > Cc: opsec@ietf.org > Subject: Re: [OPSEC] New Work: Protecting the control plane >=20 > Hi Ron, >=20 >=20 > > - attacks from those spoofing the source address of a legitimate > control plane peer > This can be caught by authentication, mechanisms also using the source > address as a part of the hash. >=20 > > - attacks from legitimate control plane peers (that might be > compromised or otherwise misbehaving) > This is considerably harder to know for IGP's. For BGP we can verify > the origin . One thing that can be done is Public Key Cryptography. > There are mechanisms available for the same already, however the > documents are experimental. >=20 > The question however is how important are these issues for the > operators to tackle? >=20 > Thanks, > Vishwas From vishwas.ietf@gmail.com Tue Jan 11 10:16:38 2011 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 617A03A6A3F for ; Tue, 11 Jan 2011 10:16:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.405 X-Spam-Level: X-Spam-Status: No, score=-3.405 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1eEHKdIaMTqj for ; Tue, 11 Jan 2011 10:16:37 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 5958B3A6A65 for ; Tue, 11 Jan 2011 10:16:37 -0800 (PST) Received: by wyf23 with SMTP id 23so21871388wyf.31 for ; Tue, 11 Jan 2011 10:18:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=iIj0liAr2iLUdpGnQ7Fb3NO729Y5wcuFJ74TSgM1MDY=; b=lWNCKuLVyUk4R7if01MUyNlOOowtZFzPe4roLg+8yts3ysxyIdvSc22XdYr+rT0WgP jusYBKK43ChsxtCU65/hm33ye4ug1PxcZykWDRUZzX7saqTuJCo9gNW1xG7WRSRd5vPf cN0kK+QJYdgYxfzRgDagLAhwgTJiwFYlTl5r0= 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=ZVPYkihSSK6KIu/zRy3boSyUs8P4dPaZNcMUSgSv88+prTZmaXA3IakeXJI1SBVwtO UAtemAl/UIb2D19X7hyZ7M7OKv6YRli/RVsjmVoyccpkqDnTC4QrDDN+3WdfekxUqhZu +t5cNOdO94z0D25Wrt9ddhmjxlESY2sPdatyY= MIME-Version: 1.0 Received: by 10.216.205.213 with SMTP id j63mr3129844weo.60.1294769933403; Tue, 11 Jan 2011 10:18:53 -0800 (PST) Received: by 10.216.139.219 with HTTP; Tue, 11 Jan 2011 10:18:53 -0800 (PST) In-Reply-To: <13205C286662DE4387D9AF3AC30EF456B03C46DA5B@EMBX01-WF.jnpr.net> References: <13205C286662DE4387D9AF3AC30EF456B03C46D9F2@EMBX01-WF.jnpr.net> <13205C286662DE4387D9AF3AC30EF456B03C46DA5B@EMBX01-WF.jnpr.net> Date: Tue, 11 Jan 2011 10:18:53 -0800 Message-ID: From: Vishwas Manral To: Ronald Bonica Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "opsec@ietf.org" Subject: Re: [OPSEC] New Work: Protecting the control plane 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, 11 Jan 2011 18:16:38 -0000 Hi Ron, We already had a draft with that and a lot more: http://tools.ietf.org/html/draft-ietf-opsec-filter-caps-09 We could resurrect it, if that is a requirement. It had gone all the way to the IESG. Thanks, Vishwas On Tue, Jan 11, 2011 at 10:01 AM, Ronald Bonica wrote= : > There are a few simple things that we can do (e.g., rate limit TCP SYNs) > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Ro= n > > >> -----Original Message----- >> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] >> Sent: Tuesday, January 11, 2011 12:47 PM >> To: Ronald Bonica >> Cc: opsec@ietf.org >> Subject: Re: [OPSEC] New Work: Protecting the control plane >> >> Hi Ron, >> >> >> > - attacks from those spoofing the source address of a legitimate >> control plane peer >> This can be caught by authentication, mechanisms also using the source >> address as a part of the hash. >> >> > - attacks from legitimate control plane peers (that might be >> compromised or otherwise misbehaving) >> This is considerably harder to know for IGP's. For BGP we can verify >> the origin . One thing that can be done is Public Key Cryptography. >> There are mechanisms available for the same already, however the >> documents are experimental. >> >> The question however is how important are these issues for the >> operators to tackle? >> >> Thanks, >> Vishwas > From Donald.Smith@qwest.com Tue Jan 11 10:25:14 2011 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 6F4923A684C for ; Tue, 11 Jan 2011 10:25:14 -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 xIBtgEr4vwAn for ; Tue, 11 Jan 2011 10:25:09 -0800 (PST) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by core3.amsl.com (Postfix) with ESMTP id B1EFA3A6A65 for ; Tue, 11 Jan 2011 10:25:04 -0800 (PST) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id p0BIRIA2014997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Jan 2011 11:27:18 -0700 (MST) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 59ED01E0071; Tue, 11 Jan 2011 12:27:13 -0600 (CST) Received: from suomp60i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 3ECA41E0066; Tue, 11 Jan 2011 12:27:13 -0600 (CST) Received: from qtdenexhtm20.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id p0BIRAt9011064; Tue, 11 Jan 2011 12:27:12 -0600 (CST) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm20.AD.QINTRA.COM ([151.119.91.229]) with mapi; Tue, 11 Jan 2011 11:27:12 -0700 From: "Smith, Donald" To: Vishwas Manral , Ronald Bonica Date: Tue, 11 Jan 2011 11:25:01 -0700 Thread-Topic: [OPSEC] New Work: Protecting the control plane Thread-Index: AcuxvASJagqaGsS5RO2mdwvIE8pSewAANd/x Message-ID: References: <13205C286662DE4387D9AF3AC30EF456B03C46D9F2@EMBX01-WF.jnpr.net> <13205C286662DE4387D9AF3AC30EF456B03C46DA5B@EMBX01-WF.jnpr.net>, 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-CFilter-Loop: Reflected Cc: "opsec@ietf.org" Subject: Re: [OPSEC] New Work: Protecting the control plane 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, 11 Jan 2011 18:25:14 -0000 GTSM would be much better for this part. >> > - attacks from those spoofing the source address of a legitimate >> control plane peer >> This can be caught by authentication, mechanisms also using the source >> address as a part of the hash. Its really hard to spoof a "large" ttl. It is also cheep compared to hashing. (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com ________________________________________ From: opsec-bounces@ietf.org [opsec-bounces@ietf.org] On Behalf Of Vishwas = Manral [vishwas.ietf@gmail.com] Sent: Tuesday, January 11, 2011 11:18 AM To: Ronald Bonica Cc: opsec@ietf.org Subject: Re: [OPSEC] New Work: Protecting the control plane Hi Ron, We already had a draft with that and a lot more: http://tools.ietf.org/html/draft-ietf-opsec-filter-caps-09 We could resurrect it, if that is a requirement. It had gone all the way to the IESG. Thanks, Vishwas On Tue, Jan 11, 2011 at 10:01 AM, Ronald Bonica wrote= : > There are a few simple things that we can do (e.g., rate limit TCP SYNs) > > Ron > > >> -----Original Message----- >> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] >> Sent: Tuesday, January 11, 2011 12:47 PM >> To: Ronald Bonica >> Cc: opsec@ietf.org >> Subject: Re: [OPSEC] New Work: Protecting the control plane >> >> Hi Ron, >> >> >> > - attacks from those spoofing the source address of a legitimate >> control plane peer >> This can be caught by authentication, mechanisms also using the source >> address as a part of the hash. >> >> > - attacks from legitimate control plane peers (that might be >> compromised or otherwise misbehaving) >> This is considerably harder to know for IGP's. For BGP we can verify >> the origin . One thing that can be done is Public Key Cryptography. >> There are mechanisms available for the same already, however the >> documents are experimental. >> >> The question however is how important are these issues for the >> operators to tackle? >> >> Thanks, >> Vishwas > _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From vishwas.ietf@gmail.com Tue Jan 11 10:35:27 2011 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 9E82F28C274 for ; Tue, 11 Jan 2011 10:35:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.417 X-Spam-Level: X-Spam-Status: No, score=-3.417 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8itCU3bhe73 for ; Tue, 11 Jan 2011 10:35:26 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 4A9A728B56A for ; Tue, 11 Jan 2011 10:35:26 -0800 (PST) Received: by wyf23 with SMTP id 23so21891987wyf.31 for ; Tue, 11 Jan 2011 10:37:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=XkIFruCQO9ZGEoN1BJVs25YRlXaLgUGR5nBnt+Zsv/o=; b=JIM8Rwk0uxCqbP0pwT/9OOHvtz0V5aWUWZICctJPQtnxoasVBrQdrMJ/5xNH6fEdGS B7JTTWJafi91xBnxtbH5Q8uXKnxm4u4JqwwKa2pAGhxGJiHnjenHQHO//kf8lGiA5er5 164/o+37SEJXAhqyxBrlwvXfRjVRpmuQ5Q0ls= 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=WM3Ynu7VVnlNSsj3G6G/HoWfKNGOznDIYGMyybyMO1XbQ0Pp/sjjDrVg9BgLvCl5nE Z3ilfRLJtCmc7TvzWmbDGWDs/CYzx0TxDrPFq25yTODaSD72J2UsN0xr2BnEFnMzo5YS gPoB4SKWp5sa5le8kG+ndo/iTvm6V8oqdmCcM= MIME-Version: 1.0 Received: by 10.216.159.69 with SMTP id r47mr3055390wek.105.1294771062348; Tue, 11 Jan 2011 10:37:42 -0800 (PST) Received: by 10.216.139.219 with HTTP; Tue, 11 Jan 2011 10:37:42 -0800 (PST) In-Reply-To: References: <13205C286662DE4387D9AF3AC30EF456B03C46D9F2@EMBX01-WF.jnpr.net> <13205C286662DE4387D9AF3AC30EF456B03C46DA5B@EMBX01-WF.jnpr.net> Date: Tue, 11 Jan 2011 10:37:42 -0800 Message-ID: From: Vishwas Manral To: "Smith, Donald" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "opsec@ietf.org" Subject: Re: [OPSEC] New Work: Protecting the control plane 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, 11 Jan 2011 18:35:27 -0000 Hi Don, You are right for a lot of cases. However GTSM may not be able to work in all cases. Take the case of OSPF Virtual link or IBGP session. The number of hops are determined at run time. GTSM also does not protect in a switched network case where one of the machines, one IP hop away is spoofing for another machine on the same network. Thanks, Vishwas On Tue, Jan 11, 2011 at 10:25 AM, Smith, Donald wr= ote: > GTSM would be much better for this part. > >>> > - attacks from those spoofing the source address of a legitimate >>> control plane peer >>> This can be caught by authentication, mechanisms also using the source >>> address as a part of the hash. > > Its really hard to spoof a "large" ttl. > It is also cheep compared to hashing. > > (coffee !=3D sleep) & (!coffee =3D=3D sleep) > =A0Donald.Smith@qwest.com > ________________________________________ > From: opsec-bounces@ietf.org [opsec-bounces@ietf.org] On Behalf Of Vishwa= s Manral [vishwas.ietf@gmail.com] > Sent: Tuesday, January 11, 2011 11:18 AM > To: Ronald Bonica > Cc: opsec@ietf.org > Subject: Re: [OPSEC] New Work: Protecting the control plane > > Hi Ron, > > We already had a draft with that and a lot more: > http://tools.ietf.org/html/draft-ietf-opsec-filter-caps-09 > > We could resurrect it, if that is a requirement. It had gone all the > way to the IESG. > > Thanks, > Vishwas > > On Tue, Jan 11, 2011 at 10:01 AM, Ronald Bonica wro= te: >> There are a few simple things that we can do (e.g., rate limit TCP SYNs) >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0R= on >> >> >>> -----Original Message----- >>> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] >>> Sent: Tuesday, January 11, 2011 12:47 PM >>> To: Ronald Bonica >>> Cc: opsec@ietf.org >>> Subject: Re: [OPSEC] New Work: Protecting the control plane >>> >>> Hi Ron, >>> >>> >>> > - attacks from those spoofing the source address of a legitimate >>> control plane peer >>> This can be caught by authentication, mechanisms also using the source >>> address as a part of the hash. >>> >>> > - attacks from legitimate control plane peers (that might be >>> compromised or otherwise misbehaving) >>> This is considerably harder to know for IGP's. For BGP we can verify >>> the origin . One thing that can be done is Public Key Cryptography. >>> There are mechanisms available for the same already, however the >>> documents are experimental. >>> >>> The question however is how important are these issues for the >>> operators to tackle? >>> >>> Thanks, >>> Vishwas >> > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > > This communication is the property of Qwest and may contain confidential = or > privileged information. Unauthorized use of this communication is strictl= y > prohibited and may be unlawful. =A0If you have received this communicatio= n > in error, please immediately notify the sender by reply e-mail and destro= y > all copies of the communication and any attachments. > From jared@puck.nether.net Tue Jan 11 10:42:37 2011 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 B470C28C17D for ; Tue, 11 Jan 2011 10:42:37 -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 qGEfWFkDB19l for ; Tue, 11 Jan 2011 10:42:36 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by core3.amsl.com (Postfix) with ESMTP id 1365928C287 for ; Tue, 11 Jan 2011 10:42:35 -0800 (PST) Received: from [10.0.0.137] (173-167-0-106-michigan.hfc.comcastbusiness.net [173.167.0.106]) (authenticated bits=0) by puck.nether.net (8.14.4/8.12.9) with ESMTP id p0BIinTq083895 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 Jan 2011 13:44:49 -0500 (EST) (envelope-from jared@puck.nether.net) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jared Mauch In-Reply-To: Date: Tue, 11 Jan 2011 13:44:48 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4A218D82-EB2D-437B-A2BD-A659FC77B1BF@puck.nether.net> References: <13205C286662DE4387D9AF3AC30EF456B03C46D9F2@EMBX01-WF.jnpr.net> <13205C286662DE4387D9AF3AC30EF456B03C46DA5B@EMBX01-WF.jnpr.net> To: Vishwas Manral X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Tue, 11 Jan 2011 13:44:49 -0500 (EST) Cc: "opsec@ietf.org" Subject: Re: [OPSEC] New Work: Protecting the control plane 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, 11 Jan 2011 18:42:37 -0000 On Jan 11, 2011, at 1:37 PM, Vishwas Manral wrote: > Hi Don, >=20 > You are right for a lot of cases. >=20 > However GTSM may not be able to work in all cases. Take the case of > OSPF Virtual link or IBGP session. The number of hops are determined > at run time. >=20 > GTSM also does not protect in a switched network case where one of the > machines, one IP hop away is spoofing for another machine on the same > network. Perhaps I am not understanding what you are talking about, but = protecting the control plane is best done with the simple checks first. = Certainly it's not going to help with the OSPF case, or necessarily with = the iBGP case, but the ranging of these can help significantly. OSPF I = would view as an architectural fail on the part of a SP if they allowed = the injection or reception of messages on untrusted links. Certainly = the concept of baseline filtering should be the first step. GTSM does not prevent some of the layer-2 attacks that are feasible, but = layer-2 switching and filtering can address this without the packets = reaching the control-plane of a target device. I don't want to presume to be an expert here, but in this case I don't = see where those concerns can't be addressed with a layer-2 filtering = technique. (Not all switches may have this, but I can't make people = actually abide by best practices either, so boiling that ocean is a step = too far imho). - Jared= From vishwas.ietf@gmail.com Tue Jan 11 10:49:31 2011 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 6546C3A682F for ; Tue, 11 Jan 2011 10:49:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.427 X-Spam-Level: X-Spam-Status: No, score=-3.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pl9WweQkCBBl for ; Tue, 11 Jan 2011 10:49:30 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 455053A6A67 for ; Tue, 11 Jan 2011 10:49:30 -0800 (PST) Received: by wwa36 with SMTP id 36so20882254wwa.13 for ; Tue, 11 Jan 2011 10:51:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=B5XTHHA5Eua20+IiqY85OcAsLW/E3uKlWKlpumGawzA=; b=Tm+xmZUN8fN7TtMsaYqJbx9/pjQpfJwWA7PDQi/bRG58O5ZYplh8wKo+XYhzP/jS/O EqulaXUF3gOrP1txZ54ChR0cXk4mtz7lIiA/DIsz1iqaZzlYDI5AkLsKybpkaVGpQCzq lG4t6tYJB3aRBqCAllvM4XlN6PoU2ZbwTRQ0M= 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=Ubr5YIZ3pqLr1BrzL4qFz90rj6IIYqx1WbNAXoAXUKhfmbeDrwhkCScYsh1y+06oQL f0FSf3g4o+LEFQ7SMVKUe6PM75crsExadwn7F8LTFaiU1GvqiqcS4xzCU40DvJQTC6fi L2DGSKK5DvLjN7INUIw31gUHZqj/sU5QIF9rw= MIME-Version: 1.0 Received: by 10.216.205.213 with SMTP id j63mr3160411weo.60.1294771905775; Tue, 11 Jan 2011 10:51:45 -0800 (PST) Received: by 10.216.139.219 with HTTP; Tue, 11 Jan 2011 10:51:45 -0800 (PST) In-Reply-To: <4A218D82-EB2D-437B-A2BD-A659FC77B1BF@puck.nether.net> References: <13205C286662DE4387D9AF3AC30EF456B03C46D9F2@EMBX01-WF.jnpr.net> <13205C286662DE4387D9AF3AC30EF456B03C46DA5B@EMBX01-WF.jnpr.net> <4A218D82-EB2D-437B-A2BD-A659FC77B1BF@puck.nether.net> Date: Tue, 11 Jan 2011 10:51:45 -0800 Message-ID: From: Vishwas Manral To: Jared Mauch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "opsec@ietf.org" Subject: Re: [OPSEC] New Work: Protecting the control plane 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, 11 Jan 2011 18:49:31 -0000 Hi Jared, Assume if there are 3 OSPF devices A, B, C attached to a network (broadcast network - this is what I meant switched network). Now GTSM cannot prevent A to spoof the source address C to be sent in the packet to B even for single hop cases. This can happen if A is compromised. It would be the same case if in an IXP we allowed multiple EBGP sessions over the same broadcast/ switched network. This could happen an ISP is malicious. Thanks, Vishwas On Tue, Jan 11, 2011 at 10:44 AM, Jared Mauch wrote= : > > On Jan 11, 2011, at 1:37 PM, Vishwas Manral wrote: > >> Hi Don, >> >> You are right for a lot of cases. >> >> However GTSM may not be able to work in all cases. Take the case of >> OSPF Virtual link or IBGP session. The number of hops are determined >> at run time. >> >> GTSM also does not protect in a switched network case where one of the >> machines, one IP hop away is spoofing for another machine on the same >> network. > > Perhaps I am not understanding what you are talking about, but protecting= the control plane is best done with the simple checks first. =A0Certainly = it's not going to help with the OSPF case, or necessarily with the iBGP cas= e, but the ranging of these can help significantly. =A0OSPF I would view as= an architectural fail on the part of a SP if they allowed the injection or= reception of messages on untrusted links. =A0Certainly the concept of base= line filtering should be the first step. > > GTSM does not prevent some of the layer-2 attacks that are feasible, but = layer-2 switching and filtering can address this without the packets reachi= ng the control-plane of a target device. > > I don't want to presume to be an expert here, but in this case I don't se= e where those concerns can't be addressed with a layer-2 filtering techniqu= e. =A0(Not all switches may have this, but I can't make people actually abi= de by best practices either, so boiling that ocean is a step too far imho). > > - Jared From jared@puck.nether.net Tue Jan 11 10:59:52 2011 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 45A6D3A6A74 for ; Tue, 11 Jan 2011 10:59:52 -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 qI1qmxLHj3Es for ; Tue, 11 Jan 2011 10:59:51 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by core3.amsl.com (Postfix) with ESMTP id E8A8F3A67FF for ; Tue, 11 Jan 2011 10:59:50 -0800 (PST) Received: from [10.0.0.137] (173-167-0-106-michigan.hfc.comcastbusiness.net [173.167.0.106]) (authenticated bits=0) by puck.nether.net (8.14.4/8.12.9) with ESMTP id p0BJ1usq086984 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 Jan 2011 14:01:56 -0500 (EST) (envelope-from jared@puck.nether.net) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jared Mauch In-Reply-To: Date: Tue, 11 Jan 2011 14:01:55 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <31148449-4BBB-428D-B06E-56F6571E310A@puck.nether.net> References: <13205C286662DE4387D9AF3AC30EF456B03C46D9F2@EMBX01-WF.jnpr.net> <13205C286662DE4387D9AF3AC30EF456B03C46DA5B@EMBX01-WF.jnpr.net> <4A218D82-EB2D-437B-A2BD-A659FC77B1BF@puck.nether.net> To: Vishwas Manral X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Tue, 11 Jan 2011 14:01:57 -0500 (EST) Cc: "opsec@ietf.org" Subject: Re: [OPSEC] New Work: Protecting the control plane 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, 11 Jan 2011 18:59:52 -0000 On Jan 11, 2011, at 1:51 PM, Vishwas Manral wrote: > Hi Jared, >=20 > Assume if there are 3 OSPF devices A, B, C attached to a network > (broadcast network - this is what I meant switched network). Sure, and if you are allowing devices outside your control in the same = broadcast domain to participate in your IGP, you have a much larger = problem than just spoofed packets coming into the control plane. > Now GTSM cannot prevent A to spoof the source address C to be sent in > the packet to B even for single hop cases. This can happen if A is > compromised. Agree. > It would be the same case if in an IXP we allowed multiple EBGP > sessions over the same broadcast/ switched network. This could happen > an ISP is malicious. Yes, this is a challenge, but there is nothing preventing us from = leveraging capabilities of dhcp, ra guard, etc.. to have packets = filtered out at layer-2 that come from untrusted/unauthenticated ports. = The folks at AMS-IX, LINX, etc.. are highly professional and know where = those IP <-> MAC entries appear. Saying proto=3D=3D6&&ip.ttl=3D=3D255 = && s.mac=3D=3DHHHH.HHHH.HHHH is much easier than if (crypto_pass()); Crypto is not always the solution for every problem. That being said, = crypto does solve other problems. It's much easier to get someone to do = the 3-4 checks vs crypto when dealing with a slow processor in some = platforms/vendors, and starts to become something that can be done in = TCAM and FPGA much easier. - Jared >=20 > Thanks, > Vishwas >=20 > On Tue, Jan 11, 2011 at 10:44 AM, Jared Mauch = wrote: >>=20 >> On Jan 11, 2011, at 1:37 PM, Vishwas Manral wrote: >>=20 >>> Hi Don, >>>=20 >>> You are right for a lot of cases. >>>=20 >>> However GTSM may not be able to work in all cases. Take the case of >>> OSPF Virtual link or IBGP session. The number of hops are determined >>> at run time. >>>=20 >>> GTSM also does not protect in a switched network case where one of = the >>> machines, one IP hop away is spoofing for another machine on the = same >>> network. >>=20 >> Perhaps I am not understanding what you are talking about, but = protecting the control plane is best done with the simple checks first. = Certainly it's not going to help with the OSPF case, or necessarily with = the iBGP case, but the ranging of these can help significantly. OSPF I = would view as an architectural fail on the part of a SP if they allowed = the injection or reception of messages on untrusted links. Certainly = the concept of baseline filtering should be the first step. >>=20 >> GTSM does not prevent some of the layer-2 attacks that are feasible, = but layer-2 switching and filtering can address this without the packets = reaching the control-plane of a target device. >>=20 >> I don't want to presume to be an expert here, but in this case I = don't see where those concerns can't be addressed with a layer-2 = filtering technique. (Not all switches may have this, but I can't make = people actually abide by best practices either, so boiling that ocean is = a step too far imho). >>=20 >> - Jared From vishwas.ietf@gmail.com Tue Jan 11 11:11:15 2011 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 0D5C43A6A88 for ; Tue, 11 Jan 2011 11:11:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.436 X-Spam-Level: X-Spam-Status: No, score=-3.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OFBYBUi8ByvX for ; Tue, 11 Jan 2011 11:11:08 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 7A3DC3A69A1 for ; Tue, 11 Jan 2011 11:11:06 -0800 (PST) Received: by wyf23 with SMTP id 23so21925946wyf.31 for ; Tue, 11 Jan 2011 11:13:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=2zbE8nu5XnhdRqG3FyiBSy1RZzgUODErQmTU1EKtNjc=; b=B4uOqBS5HRFrHc7ba8ence4AQpyfGa3Hm/FCxKY/8rSq1RlKNKMBGmsBLj9yk92nPP iqsnQEtE9fkoiQMIGa5ksMY53NMNWls+WHWma1WGBG2Z/TzwNB6+uebImMqAd05JHyp5 N1FgdQ3Crn/yXxwvniv70HpT+h7KjvsF/OruM= 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=JBkKAe7SniR+/8+naat8NZEYW7kfFzPWgSaEqsAqCR+y//SMM5/vK+dRTIpKAang5Q b+X6hoCE6FPVx2BmK3ie91iNUkSVbbhO38P/zeXQfPDWcyhzAKVz39hFZRG/E5bncikc NsjsaoyMbxa+2v3+e2KsPNdpgFcwG9Q7GhTZ8= MIME-Version: 1.0 Received: by 10.216.176.138 with SMTP id b10mr3148730wem.75.1294773203024; Tue, 11 Jan 2011 11:13:23 -0800 (PST) Received: by 10.216.139.219 with HTTP; Tue, 11 Jan 2011 11:13:22 -0800 (PST) In-Reply-To: <31148449-4BBB-428D-B06E-56F6571E310A@puck.nether.net> References: <13205C286662DE4387D9AF3AC30EF456B03C46D9F2@EMBX01-WF.jnpr.net> <13205C286662DE4387D9AF3AC30EF456B03C46DA5B@EMBX01-WF.jnpr.net> <4A218D82-EB2D-437B-A2BD-A659FC77B1BF@puck.nether.net> <31148449-4BBB-428D-B06E-56F6571E310A@puck.nether.net> Date: Tue, 11 Jan 2011 11:13:22 -0800 Message-ID: From: Vishwas Manral To: Jared Mauch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "opsec@ietf.org" Subject: Re: [OPSEC] New Work: Protecting the control plane 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, 11 Jan 2011 19:11:15 -0000 Hi Jared, I agree Crypto is not the solution for everything. It is for that purpose I talked about the criticality of the requirement in the first case. It increases CPU load and also makes considerably worse the attacks on the = CPU. Thanks, Vishwas On Tue, Jan 11, 2011 at 11:01 AM, Jared Mauch wrote= : > > On Jan 11, 2011, at 1:51 PM, Vishwas Manral wrote: > >> Hi Jared, >> >> Assume if there are 3 OSPF devices A, B, C attached to a network >> (broadcast network - this is what I meant switched network). > > Sure, and if you are allowing devices outside your control in the same br= oadcast domain to participate in your IGP, you have a much larger problem t= han just spoofed packets coming into the control plane. > >> Now GTSM cannot prevent A to spoof the source address C to be sent in >> the packet to B even for single hop cases. This can happen if A is >> compromised. > > Agree. > >> It would be the same case if in an IXP we allowed multiple EBGP >> sessions over the same broadcast/ switched network. This could happen >> an ISP is malicious. > > Yes, this is a challenge, but there is nothing preventing us from leverag= ing capabilities of dhcp, ra guard, etc.. to have packets filtered out at l= ayer-2 that come from untrusted/unauthenticated ports. =A0The folks at AMS-= IX, LINX, etc.. are highly professional and know where those IP <-> MAC ent= ries appear. =A0Saying proto=3D=3D6&&ip.ttl=3D=3D255 && s.mac=3D=3DHHHH.HHH= H.HHHH is much easier than if (crypto_pass()); > > Crypto is not always the solution for every problem. =A0That being said, = crypto does solve other problems. =A0It's much easier to get someone to do = the 3-4 checks vs crypto when dealing with a slow processor in some platfor= ms/vendors, and starts to become something that can be done in TCAM and FPG= A much easier. > > - Jared > >> >> Thanks, >> Vishwas >> >> On Tue, Jan 11, 2011 at 10:44 AM, Jared Mauch wr= ote: >>> >>> On Jan 11, 2011, at 1:37 PM, Vishwas Manral wrote: >>> >>>> Hi Don, >>>> >>>> You are right for a lot of cases. >>>> >>>> However GTSM may not be able to work in all cases. Take the case of >>>> OSPF Virtual link or IBGP session. The number of hops are determined >>>> at run time. >>>> >>>> GTSM also does not protect in a switched network case where one of the >>>> machines, one IP hop away is spoofing for another machine on the same >>>> network. >>> >>> Perhaps I am not understanding what you are talking about, but protecti= ng the control plane is best done with the simple checks first. =A0Certainl= y it's not going to help with the OSPF case, or necessarily with the iBGP c= ase, but the ranging of these can help significantly. =A0OSPF I would view = as an architectural fail on the part of a SP if they allowed the injection = or reception of messages on untrusted links. =A0Certainly the concept of ba= seline filtering should be the first step. >>> >>> GTSM does not prevent some of the layer-2 attacks that are feasible, bu= t layer-2 switching and filtering can address this without the packets reac= hing the control-plane of a target device. >>> >>> I don't want to presume to be an expert here, but in this case I don't = see where those concerns can't be addressed with a layer-2 filtering techni= que. =A0(Not all switches may have this, but I can't make people actually a= bide by best practices either, so boiling that ocean is a step too far imho= ). >>> >>> - Jared > > From Donald.Smith@qwest.com Tue Jan 11 14:12:11 2011 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 91D4A3A6855 for ; Tue, 11 Jan 2011 14:12:11 -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 J5lF-CFIIaOR for ; Tue, 11 Jan 2011 14:12:10 -0800 (PST) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by core3.amsl.com (Postfix) with ESMTP id 53A0C3A67EC for ; Tue, 11 Jan 2011 14:12:10 -0800 (PST) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id p0BMEPRj008745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Jan 2011 15:14:25 -0700 (MST) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 9100C1E0065; Tue, 11 Jan 2011 16:14:20 -0600 (CST) Received: from sudnp796.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 621B51E005B; Tue, 11 Jan 2011 16:14:20 -0600 (CST) Received: from qtdenexhtm20.AD.QINTRA.COM (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id p0BME1Rf018478; Tue, 11 Jan 2011 15:14:19 -0700 (MST) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm20.AD.QINTRA.COM ([151.119.91.229]) with mapi; Tue, 11 Jan 2011 15:14:12 -0700 From: "Smith, Donald" To: Vishwas Manral , Ronald Bonica Date: Tue, 11 Jan 2011 15:13:43 -0700 Thread-Topic: [OPSEC] New Work: Protecting the control plane Thread-Index: AcuxvASJagqaGsS5RO2mdwvIE8pSewAIMpLk Message-ID: References: <13205C286662DE4387D9AF3AC30EF456B03C46D9F2@EMBX01-WF.jnpr.net> <13205C286662DE4387D9AF3AC30EF456B03C46DA5B@EMBX01-WF.jnpr.net>, 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-CFilter-Loop: Reflected Cc: "opsec@ietf.org" Subject: Re: [OPSEC] New Work: Protecting the control plane 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, 11 Jan 2011 22:12:11 -0000 Why didn't this one go forward? It looks pretty good. (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com ________________________________________ From: opsec-bounces@ietf.org [opsec-bounces@ietf.org] On Behalf Of Vishwas = Manral [vishwas.ietf@gmail.com] Sent: Tuesday, January 11, 2011 11:18 AM To: Ronald Bonica Cc: opsec@ietf.org Subject: Re: [OPSEC] New Work: Protecting the control plane Hi Ron, We already had a draft with that and a lot more: http://tools.ietf.org/html/draft-ietf-opsec-filter-caps-09 We could resurrect it, if that is a requirement. It had gone all the way to the IESG. Thanks, Vishwas On Tue, Jan 11, 2011 at 10:01 AM, Ronald Bonica wrote= : > There are a few simple things that we can do (e.g., rate limit TCP SYNs) > > Ron > > >> -----Original Message----- >> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] >> Sent: Tuesday, January 11, 2011 12:47 PM >> To: Ronald Bonica >> Cc: opsec@ietf.org >> Subject: Re: [OPSEC] New Work: Protecting the control plane >> >> Hi Ron, >> >> >> > - attacks from those spoofing the source address of a legitimate >> control plane peer >> This can be caught by authentication, mechanisms also using the source >> address as a part of the hash. >> >> > - attacks from legitimate control plane peers (that might be >> compromised or otherwise misbehaving) >> This is considerably harder to know for IGP's. For BGP we can verify >> the origin . One thing that can be done is Public Key Cryptography. >> There are mechanisms available for the same already, however the >> documents are experimental. >> >> The question however is how important are these issues for the >> operators to tackle? >> >> Thanks, >> Vishwas > _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From rbonica@juniper.net Tue Jan 11 15:00:44 2011 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 873B33A6AC1 for ; Tue, 11 Jan 2011 15:00:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.507 X-Spam-Level: X-Spam-Status: No, score=-106.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkDXiPwhviOX for ; Tue, 11 Jan 2011 15:00:43 -0800 (PST) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id 41FC93A67F2 for ; Tue, 11 Jan 2011 15:00:42 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTSzhpFaj8PJMmv24R97IJoDEQ2g7N/Tw@postini.com; Tue, 11 Jan 2011 15:03:01 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 11 Jan 2011 15:00:23 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::8002:d3e7:4146:af5f]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 11 Jan 2011 18:00:22 -0500 From: Ronald Bonica To: Vishwas Manral Date: Tue, 11 Jan 2011 18:00:21 -0500 Thread-Topic: [OPSEC] New Work: Protecting the control plane Thread-Index: AcuxvAL4+EH8izr1QFm31XHPIggqsQAJgdiQ Message-ID: <13205C286662DE4387D9AF3AC30EF456B03C46DE6D@EMBX01-WF.jnpr.net> References: <13205C286662DE4387D9AF3AC30EF456B03C46D9F2@EMBX01-WF.jnpr.net> <13205C286662DE4387D9AF3AC30EF456B03C46DA5B@EMBX01-WF.jnpr.net> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "opsec@ietf.org" Subject: Re: [OPSEC] New Work: Protecting the control plane 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, 11 Jan 2011 23:00:44 -0000 Vishwas, I think that draft-ietf-opsec-filter-caps answers a slightly different ques= tion. It has been three years since I looked at that draft, but as I recall= , it attempts to describe all filtering capabilities that should be availab= le on a router. Today, we are asking a more specific question. Specifically we want to know= what we should do to protect a router's control plane from either a) insid= er attack or b) attack from outsiders spoofing inside source addresses. That said, I would be very happy to see somebody resume work on draft-ietf-= opsec-filter-caps. As I recall, the IESG comments were extensive. So, the p= erson signing up for that task should be ready for lots of work. Ron > -----Original Message----- > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > Sent: Tuesday, January 11, 2011 1:19 PM > To: Ronald Bonica > Cc: opsec@ietf.org > Subject: Re: [OPSEC] New Work: Protecting the control plane >=20 > Hi Ron, >=20 > We already had a draft with that and a lot more: > http://tools.ietf.org/html/draft-ietf-opsec-filter-caps-09 >=20 > We could resurrect it, if that is a requirement. It had gone all the > way to the IESG. >=20 > Thanks, > Vishwas >=20 > On Tue, Jan 11, 2011 at 10:01 AM, Ronald Bonica > wrote: > > There are a few simple things that we can do (e.g., rate limit TCP > SYNs) > > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= Ron > > > > > >> -----Original Message----- > >> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > >> Sent: Tuesday, January 11, 2011 12:47 PM > >> To: Ronald Bonica > >> Cc: opsec@ietf.org > >> Subject: Re: [OPSEC] New Work: Protecting the control plane > >> > >> Hi Ron, > >> > >> > >> > - attacks from those spoofing the source address of a legitimate > >> control plane peer > >> This can be caught by authentication, mechanisms also using the > source > >> address as a part of the hash. > >> > >> > - attacks from legitimate control plane peers (that might be > >> compromised or otherwise misbehaving) > >> This is considerably harder to know for IGP's. For BGP we can verify > >> the origin . One thing that can be done is Public Key Cryptography. > >> There are mechanisms available for the same already, however the > >> documents are experimental. > >> > >> The question however is how important are these issues for the > >> operators to tackle? > >> > >> Thanks, > >> Vishwas > > From Donald.Smith@qwest.com Tue Jan 11 15:17:34 2011 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 62E893A6AC6 for ; Tue, 11 Jan 2011 15:17:34 -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 PTSSOHWzzlU1 for ; Tue, 11 Jan 2011 15:17:33 -0800 (PST) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by core3.amsl.com (Postfix) with ESMTP id 528BE3A659C for ; Tue, 11 Jan 2011 15:17:33 -0800 (PST) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id p0BNJnwc005781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Jan 2011 16:19:49 -0700 (MST) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id B3B291E004E; Tue, 11 Jan 2011 16:19:44 -0700 (MST) Received: from suomp61i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 8F78D1E0065; Tue, 11 Jan 2011 16:19:44 -0700 (MST) Received: from qtdenexhtm21.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id p0BNJWcJ008456; Tue, 11 Jan 2011 17:19:43 -0600 (CST) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm21.AD.QINTRA.COM ([151.119.91.230]) with mapi; Tue, 11 Jan 2011 16:19:37 -0700 From: "Smith, Donald" To: Ronald Bonica , Vishwas Manral Date: Tue, 11 Jan 2011 16:18:15 -0700 Thread-Topic: [OPSEC] New Work: Protecting the control plane Thread-Index: AcuxvAL4+EH8izr1QFm31XHPIggqsQAJgdiQAADyJcQ= Message-ID: References: <13205C286662DE4387D9AF3AC30EF456B03C46D9F2@EMBX01-WF.jnpr.net> <13205C286662DE4387D9AF3AC30EF456B03C46DA5B@EMBX01-WF.jnpr.net> , <13205C286662DE4387D9AF3AC30EF456B03C46DE6D@EMBX01-WF.jnpr.net> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456B03C46DE6D@EMBX01-WF.jnpr.net> 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-CFilter-Loop: Reflected Cc: "opsec@ietf.org" Subject: Re: [OPSEC] New Work: Protecting the control plane 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, 11 Jan 2011 23:17:34 -0000 We could probably add some of what your asking for to the cpp draft or call= out that sharing a broadcast domain in your igp is risky and layer 2 secur= ity should be implemented. Add GTSM and we should be able to address most o= f the issues. (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com ________________________________________ From: opsec-bounces@ietf.org [opsec-bounces@ietf.org] On Behalf Of Ronald B= onica [rbonica@juniper.net] Sent: Tuesday, January 11, 2011 4:00 PM To: Vishwas Manral Cc: opsec@ietf.org Subject: Re: [OPSEC] New Work: Protecting the control plane Vishwas, I think that draft-ietf-opsec-filter-caps answers a slightly different ques= tion. It has been three years since I looked at that draft, but as I recall= , it attempts to describe all filtering capabilities that should be availab= le on a router. Today, we are asking a more specific question. Specifically we want to know= what we should do to protect a router's control plane from either a) insid= er attack or b) attack from outsiders spoofing inside source addresses. That said, I would be very happy to see somebody resume work on draft-ietf-= opsec-filter-caps. As I recall, the IESG comments were extensive. So, the p= erson signing up for that task should be ready for lots of work. Ron > -----Original Message----- > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > Sent: Tuesday, January 11, 2011 1:19 PM > To: Ronald Bonica > Cc: opsec@ietf.org > Subject: Re: [OPSEC] New Work: Protecting the control plane > > Hi Ron, > > We already had a draft with that and a lot more: > http://tools.ietf.org/html/draft-ietf-opsec-filter-caps-09 > > We could resurrect it, if that is a requirement. It had gone all the > way to the IESG. > > Thanks, > Vishwas > > On Tue, Jan 11, 2011 at 10:01 AM, Ronald Bonica > wrote: > > There are a few simple things that we can do (e.g., rate limit TCP > SYNs) > > > > Ron > > > > > >> -----Original Message----- > >> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > >> Sent: Tuesday, January 11, 2011 12:47 PM > >> To: Ronald Bonica > >> Cc: opsec@ietf.org > >> Subject: Re: [OPSEC] New Work: Protecting the control plane > >> > >> Hi Ron, > >> > >> > >> > - attacks from those spoofing the source address of a legitimate > >> control plane peer > >> This can be caught by authentication, mechanisms also using the > source > >> address as a part of the hash. > >> > >> > - attacks from legitimate control plane peers (that might be > >> compromised or otherwise misbehaving) > >> This is considerably harder to know for IGP's. For BGP we can verify > >> the origin . One thing that can be done is Public Key Cryptography. > >> There are mechanisms available for the same already, however the > >> documents are experimental. > >> > >> The question however is how important are these issues for the > >> operators to tackle? > >> > >> Thanks, > >> Vishwas > > _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From vishwas.ietf@gmail.com Tue Jan 11 15:25:29 2011 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 BE4CB3A67D7 for ; Tue, 11 Jan 2011 15:25:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.444 X-Spam-Level: X-Spam-Status: No, score=-3.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Xvmatmke22p for ; Tue, 11 Jan 2011 15:25:28 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 42A203A6403 for ; Tue, 11 Jan 2011 15:25:28 -0800 (PST) Received: by wwa36 with SMTP id 36so21131535wwa.13 for ; Tue, 11 Jan 2011 15:27:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=jgQLmODEAQUEg+kxdKrVOtuL+Xgy4YL/mhq0ZJXwvAM=; b=rAhqxIrXm91JOUmJJBioULjxrEZzxubYYSSdAm9sX6Pz9pf3wTg1LXk1BdCf3/gIhh 6jzwwRx0mXKJufbDaDkP6ZOyO9UGZC0zQPeJKkq0AAqwuehcRTaQk685LS3x3u9odRLw ygGg32y0c5C5fQGULE0u1SEWMZ1p3v2vz3nT8= 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=R3t/gqDQUnWdE0f2nrLtv6pjUCaA2YjwO5903K9ptVUfEU2wDd5slOWyUU5EId2cm1 7QV2N3aTScL3Ly8c55VDDLYVc4Ux6kM2xt0LoFH0lyC18oamtFR0e5FjI2kFiRW7xokH AtUdK4n7jHQS8QUrgz9sdWARyTrTqaoom0Zvo= MIME-Version: 1.0 Received: by 10.216.205.213 with SMTP id j63mr3366940weo.60.1294788465182; Tue, 11 Jan 2011 15:27:45 -0800 (PST) Received: by 10.216.139.219 with HTTP; Tue, 11 Jan 2011 15:27:45 -0800 (PST) In-Reply-To: References: <13205C286662DE4387D9AF3AC30EF456B03C46D9F2@EMBX01-WF.jnpr.net> <13205C286662DE4387D9AF3AC30EF456B03C46DA5B@EMBX01-WF.jnpr.net> <13205C286662DE4387D9AF3AC30EF456B03C46DE6D@EMBX01-WF.jnpr.net> Date: Tue, 11 Jan 2011 15:27:45 -0800 Message-ID: From: Vishwas Manral To: "Smith, Donald" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "opsec@ietf.org" Subject: Re: [OPSEC] New Work: Protecting the control plane 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, 11 Jan 2011 23:25:29 -0000 Hi Ron, I agree more work is required to the last version of the draft. However IMHO, I think older version of the drafts may be more comprehensive and better, we could start with them. Like Donald mentioned we can add the things you have referred to. Thanks, Vishwas On Tue, Jan 11, 2011 at 3:18 PM, Smith, Donald wro= te: > We could probably add some of what your asking for to the cpp draft or ca= ll out that sharing a broadcast domain in your igp is risky and layer 2 sec= urity should be implemented. Add GTSM and we should be able to address most= of the issues. > > > > (coffee !=3D sleep) & (!coffee =3D=3D sleep) > =A0Donald.Smith@qwest.com > ________________________________________ > From: opsec-bounces@ietf.org [opsec-bounces@ietf.org] On Behalf Of Ronald= Bonica [rbonica@juniper.net] > Sent: Tuesday, January 11, 2011 4:00 PM > To: Vishwas Manral > Cc: opsec@ietf.org > Subject: Re: [OPSEC] New Work: Protecting the control plane > > Vishwas, > > I think that draft-ietf-opsec-filter-caps answers a slightly different qu= estion. It has been three years since I looked at that draft, but as I reca= ll, it attempts to describe all filtering capabilities that should be avail= able on a router. > > Today, we are asking a more specific question. Specifically we want to kn= ow what we should do to protect a router's control plane from either a) ins= ider attack or b) attack from outsiders spoofing inside source addresses. > > That said, I would be very happy to see somebody resume work on draft-iet= f-opsec-filter-caps. As I recall, the IESG comments were extensive. So, the= person signing up for that task should be ready for lots of work. > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ron > > > >> -----Original Message----- >> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] >> Sent: Tuesday, January 11, 2011 1:19 PM >> To: Ronald Bonica >> Cc: opsec@ietf.org >> Subject: Re: [OPSEC] New Work: Protecting the control plane >> >> Hi Ron, >> >> We already had a draft with that and a lot more: >> http://tools.ietf.org/html/draft-ietf-opsec-filter-caps-09 >> >> We could resurrect it, if that is a requirement. It had gone all the >> way to the IESG. >> >> Thanks, >> Vishwas >> >> On Tue, Jan 11, 2011 at 10:01 AM, Ronald Bonica >> wrote: >> > There are a few simple things that we can do (e.g., rate limit TCP >> SYNs) >> > >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0Ron >> > >> > >> >> -----Original Message----- >> >> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] >> >> Sent: Tuesday, January 11, 2011 12:47 PM >> >> To: Ronald Bonica >> >> Cc: opsec@ietf.org >> >> Subject: Re: [OPSEC] New Work: Protecting the control plane >> >> >> >> Hi Ron, >> >> >> >> >> >> > - attacks from those spoofing the source address of a legitimate >> >> control plane peer >> >> This can be caught by authentication, mechanisms also using the >> source >> >> address as a part of the hash. >> >> >> >> > - attacks from legitimate control plane peers (that might be >> >> compromised or otherwise misbehaving) >> >> This is considerably harder to know for IGP's. For BGP we can verify >> >> the origin . One thing that can be done is Public Key Cryptography. >> >> There are mechanisms available for the same already, however the >> >> documents are experimental. >> >> >> >> The question however is how important are these issues for the >> >> operators to tackle? >> >> >> >> Thanks, >> >> Vishwas >> > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > > This communication is the property of Qwest and may contain confidential = or > privileged information. Unauthorized use of this communication is strictl= y > prohibited and may be unlawful. =A0If you have received this communicatio= n > in error, please immediately notify the sender by reply e-mail and destro= y > all copies of the communication and any attachments. > From pekkas@netcore.fi Tue Jan 11 23:20:45 2011 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 9F96A3A6AF9 for ; Tue, 11 Jan 2011 23:20:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.518 X-Spam-Level: X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfHhqjRCz8tt for ; Tue, 11 Jan 2011 23:20:43 -0800 (PST) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 6011A3A6AF8 for ; Tue, 11 Jan 2011 23:20:42 -0800 (PST) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id p0C7MpJe031419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Jan 2011 09:22:51 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id p0C7Mohn031416; Wed, 12 Jan 2011 09:22:50 +0200 Date: Wed, 12 Jan 2011 09:22:50 +0200 (EET) From: Pekka Savola To: Vishwas Manral In-Reply-To: Message-ID: References: <13205C286662DE4387D9AF3AC30EF456B03C46D9F2@EMBX01-WF.jnpr.net> <13205C286662DE4387D9AF3AC30EF456B03C46DA5B@EMBX01-WF.jnpr.net> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Virus-Scanned: clamav-milter 0.96.5 at otso.netcore.fi X-Virus-Status: Clean Cc: "opsec@ietf.org" Subject: Re: [OPSEC] New Work: Protecting the control plane 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, 12 Jan 2011 07:20:45 -0000 On Tue, 11 Jan 2011, Vishwas Manral wrote: > However GTSM may not be able to work in all cases. Take the case of > OSPF Virtual link or IBGP session. The number of hops are determined > at run time. > > GTSM also does not protect in a switched network case where one of the > machines, one IP hop away is spoofing for another machine on the same > network. IBGP sessions can be trivially protected by blocking source address spoofing of {all, the addressed used in IBGP} at your borders. I have not done the analysis for OSPF on this. It's true that on your border EBGP session the spoofing may harm you, especially towards transit or an IX (your second point). There GTSM helps you, as well as TCP MD5 (or similar). In transit case, your upstream's similar filtering may also help. A long time ago, I wrote about this in: http://tools.ietf.org/html/draft-savola-rtgwg-backbone-attacks-03 So, getting back to Ron's original questions: - attacks from those spoofing the source address of a legitimate control plane peer - attacks from legitimate control plane peers (that might be compromised or otherwise misbehaving) ... I think the first point can be reasonably well operationally addressed. The second point more tricky, but as mentioned, some form of rate-limiting or CPU upper bound per neighbor could help here as well. But that is by design a tradeoff between resources and convergence time in a normal case. For example, when you're legitimately establishing a BGP session where you get 350K routes, it's expected and desired that your router uses _almost_ all CPU on processing those routes as fast as it can. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From ayourtch@cisco.com Wed Jan 12 06:18:36 2011 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 6162E28C11A for ; Wed, 12 Jan 2011 06:18:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.853 X-Spam-Level: X-Spam-Status: No, score=-1.853 tagged_above=-999 required=5 tests=[AWL=0.746, 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 qOqDHTTOq-ph for ; Wed, 12 Jan 2011 06:18:35 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 269B928C112 for ; Wed, 12 Jan 2011 06:18:34 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p0CDmZKm020576; Wed, 12 Jan 2011 14:48:36 +0100 (CET) Received: from sweet-brew-4.cisco.com (sweet-brew-4.cisco.com [144.254.10.205]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p0CDmWco008197; Wed, 12 Jan 2011 14:48:32 +0100 (CET) Date: Wed, 12 Jan 2011 14:48:32 +0100 (CET) From: Andrew Yourtchenko To: Ronald Bonica In-Reply-To: <13205C286662DE4387D9AF3AC30EF456B03C46DE6D@EMBX01-WF.jnpr.net> Message-ID: References: <13205C286662DE4387D9AF3AC30EF456B03C46D9F2@EMBX01-WF.jnpr.net> <13205C286662DE4387D9AF3AC30EF456B03C46DA5B@EMBX01-WF.jnpr.net> <13205C286662DE4387D9AF3AC30EF456B03C46DE6D@EMBX01-WF.jnpr.net> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1483920592-1294839952=:3156" Content-ID: Cc: "opsec@ietf.org" Subject: Re: [OPSEC] New Work: Protecting the control plane 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, 12 Jan 2011 14:18:36 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1483920592-1294839952=:3156 Content-Type: TEXT/PLAIN; CHARSET=X-UNKNOWN; FORMAT=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: Ron, On Tue, 11 Jan 2011, Ronald Bonica wrote: > Vishwas, > > I think that draft-ietf-opsec-filter-caps answers a slightly different qu= estion. It has been three years since I looked at that draft, but as I reca= ll, it attempts to describe all filtering capabilities that should be avail= able on a router. > > Today, we are asking a more specific question. Specifically we want to kn= ow=20 > what we should do to protect a router's control plane from either > a) insider attack or Maybe I am too much into conspiracy theories - but why kill the cow that gi= ves=20 the milk ? If I were a blackhat and I had a control over a router - I'd use= it=20 to selectively redirect traffic to the place where I could capture/MITM it,= or=20 to collect the credentials of the operators that log in, or social-engineer= =20 them. Not DoS the peer router and thus reveal myself. That consideration aside: rate-limiting SYNs would not prevent from ACK flo= ods,=20 nor RST floods. So this would bring in the need to have a built-in stateful= =20 firewall in front of control plane. Which assumes that this firewall would = be=20 capable at handling the full state at line-rate. Which means then we solved= the=20 problem "at its root": the performance tradeoff in the control plane that= =20 creates this problem. > b) attack from outsiders spoofing inside source addresses. I would think that blocking one's infrastructure address space on ingress to one's AS should take care of this. What am I missing ? cheers, andrew > > That said, I would be very happy to see somebody resume work on=20 >draft-ietf-opsec-filter-caps. As I recall, the IESG comments were extensiv= e.=20 >So, the person signing up for that task should be ready for lots of work. > > Ron > > > >> -----Original Message----- >> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] >> Sent: Tuesday, January 11, 2011 1:19 PM >> To: Ronald Bonica >> Cc: opsec@ietf.org >> Subject: Re: [OPSEC] New Work: Protecting the control plane >> >> Hi Ron, >> >> We already had a draft with that and a lot more: >> http://tools.ietf.org/html/draft-ietf-opsec-filter-caps-09 >> >> We could resurrect it, if that is a requirement. It had gone all the >> way to the IESG. >> >> Thanks, >> Vishwas >> >> On Tue, Jan 11, 2011 at 10:01 AM, Ronald Bonica >> wrote: >>> There are a few simple things that we can do (e.g., rate limit TCP >> SYNs) >>> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= Ron >>> >>> >>>> -----Original Message----- >>>> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] >>>> Sent: Tuesday, January 11, 2011 12:47 PM >>>> To: Ronald Bonica >>>> Cc: opsec@ietf.org >>>> Subject: Re: [OPSEC] New Work: Protecting the control plane >>>> >>>> Hi Ron, >>>> >>>> >>>>> - attacks from those spoofing the source address of a legitimate >>>> control plane peer >>>> This can be caught by authentication, mechanisms also using the >> source >>>> address as a part of the hash. >>>> >>>>> - attacks from legitimate control plane peers (that might be >>>> compromised or otherwise misbehaving) >>>> This is considerably harder to know for IGP's. For BGP we can verify >>>> the origin . One thing that can be done is Public Key Cryptography. >>>> There are mechanisms available for the same already, however the >>>> documents are experimental. >>>> >>>> The question however is how important are these issues for the >>>> operators to tackle? >>>> >>>> Thanks, >>>> Vishwas >>> > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > ---559023410-1483920592-1294839952=:3156-- From fooologist@gmail.com Wed Jan 12 06:51:52 2011 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 6341028C12B for ; Wed, 12 Jan 2011 06:51:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id go0HULfL0nC8 for ; Wed, 12 Jan 2011 06:51:49 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 6428628C108 for ; Wed, 12 Jan 2011 06:51:49 -0800 (PST) Received: by qwi2 with SMTP id 2so688690qwi.31 for ; Wed, 12 Jan 2011 06:54:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=124l05dYbexxFxbOmirYrjuUfjxxonGjVdlSJmDsDAQ=; b=ogh4lx8+V96oSYydv/VCjVlWwtsZKVKAAelW9o8U9XjB3KWWTJCd9510ZTIQPRL354 KUAbV2AFq8x1MqTfHxINy+SR7qXppy4elBwTw6XrFjw05l2O0aD6U/zEm/VLb62qIdNv LKDNoQ5zDCFiA2SCfGVZVTivb9mUYhjzd45rY= 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=V9ZKDtiaHBnBP4ol0+dofaU2D+kMGBnubmkYISbJTcEcJqu2e2+uKIvnnouJRyOcPs +W118v4+X6C7Fhym1NUq6hryArZM4cqQIfL3pZS9xZjbPBUjy1sXPLMKhzFFS0Dt1JyK nnDVcyYEWoq3X/I3LS2Oe5WvIre5/PubA+Pbo= MIME-Version: 1.0 Received: by 10.224.11.137 with SMTP id t9mr1004292qat.138.1294844048902; Wed, 12 Jan 2011 06:54:08 -0800 (PST) Received: by 10.220.164.146 with HTTP; Wed, 12 Jan 2011 06:54:08 -0800 (PST) In-Reply-To: <13205C286662DE4387D9AF3AC30EF456B03C46DE6D@EMBX01-WF.jnpr.net> References: <13205C286662DE4387D9AF3AC30EF456B03C46D9F2@EMBX01-WF.jnpr.net> <13205C286662DE4387D9AF3AC30EF456B03C46DA5B@EMBX01-WF.jnpr.net> <13205C286662DE4387D9AF3AC30EF456B03C46DE6D@EMBX01-WF.jnpr.net> Date: Wed, 12 Jan 2011 14:54:08 +0000 Message-ID: From: George Jones To: Ronald Bonica Content-Type: multipart/alternative; boundary=0015175cd02a9309bc0499a75f61 Cc: "opsec@ietf.org mailing list" Subject: Re: [OPSEC] New Work: Protecting the control plane 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, 12 Jan 2011 14:51:52 -0000 --0015175cd02a9309bc0499a75f61 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jan 11, 2011 at 11:00 PM, Ronald Bonica wrote: > Vishwas, > > I think that draft-ietf-opsec-filter-caps answers a slightly different > question. It has been three years since I looked at that draft, but as I > recall, it attempts to describe all filtering capabilities that should be > available on a router. > The capabilities drafts were all about "The Router Can do X [filtering]" to enable testing. > > Today, we are asking a more specific question. Specifically we want to know > what we should do to protect a router's control plane from either a) insider > attack or b) attack from outsiders spoofing inside source addresses. > Filtering things aimed at the control plane, using features enumerated in the capabilities drafts, would be one use case. > > That said, I would be very happy to see somebody resume work on > draft-ietf-opsec-filter-caps. As I recall, the IESG comments were extensive. > So, the person signing up for that task should be ready for lots of work. > > I'll go back and have a look at the IESG comments....but I think, at a WG/AD/Charter level we'd need to revisit the roll of capabilities drafts ... do they fit in the current charter ? Are they useful ? Will they be used/change anything for the better ? Perhaps you, I, Chris, Joel and Joe should *talk* ? ---George > Ron > > > > > -----Original Message----- > > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > > Sent: Tuesday, January 11, 2011 1:19 PM > > To: Ronald Bonica > > Cc: opsec@ietf.org > > Subject: Re: [OPSEC] New Work: Protecting the control plane > > > > Hi Ron, > > > > We already had a draft with that and a lot more: > > http://tools.ietf.org/html/draft-ietf-opsec-filter-caps-09 > > > > We could resurrect it, if that is a requirement. It had gone all the > > way to the IESG. > > > > Thanks, > > Vishwas > > > > On Tue, Jan 11, 2011 at 10:01 AM, Ronald Bonica > > wrote: > > > There are a few simple things that we can do (e.g., rate limit TCP > > SYNs) > > > > > > Ron > > > > > > > > >> -----Original Message----- > > >> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > > >> Sent: Tuesday, January 11, 2011 12:47 PM > > >> To: Ronald Bonica > > >> Cc: opsec@ietf.org > > >> Subject: Re: [OPSEC] New Work: Protecting the control plane > > >> > > >> Hi Ron, > > >> > > >> > > >> > - attacks from those spoofing the source address of a legitimate > > >> control plane peer > > >> This can be caught by authentication, mechanisms also using the > > source > > >> address as a part of the hash. > > >> > > >> > - attacks from legitimate control plane peers (that might be > > >> compromised or otherwise misbehaving) > > >> This is considerably harder to know for IGP's. For BGP we can verify > > >> the origin . One thing that can be done is Public Key Cryptography. > > >> There are mechanisms available for the same already, however the > > >> documents are experimental. > > >> > > >> The question however is how important are these issues for the > > >> operators to tackle? > > >> > > >> Thanks, > > >> Vishwas > > > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > --0015175cd02a9309bc0499a75f61 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Jan 11, 2011 at 11:00 PM, Ronald= Bonica <rbonic= a@juniper.net> wrote:
Vishwas,

I think that draft-ietf-opsec-filter-caps answers a slightly different ques= tion. It has been three years since I looked at that draft, but as I recall= , it attempts to describe all filtering capabilities that should be availab= le on a router.

The capabilities drafts were all about "The Rout= er Can do X [filtering]" to enable testing.

=A0

Today, we are asking a more specific question. Specifically we want to know= what we should do to protect a router's control plane from either a) i= nsider attack or b) attack from outsiders spoofing inside source addresses.=


Filtering things aimed at the control plane, usin= g features enumerated in the capabilities drafts, would be one use case.
=A0

That said, I would be very happy to see somebody resume work on draft-ietf-= opsec-filter-caps. As I recall, the IESG comments were extensive. So, the p= erson signing up for that task should be ready for lots of work.


I'll go back and have= a look at the IESG comments....but I think, at a WG/AD/Charter level we= 9;d need to revisit the roll of capabilities drafts ... do they fit in the = current charter ?=A0 Are they useful ?=A0 Will they
be used/change anything for the better ?=A0=A0=A0 Perhaps you, I, Chris, Jo= el and Joe should *talk* ?

---George



=A0
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ron



> -----Original Message-----
> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]
> Sent: Tuesday, January 11, 201= 1 1:19 PM
> To: Ronald Bonica
> Cc: opsec@ietf.org
> Subject: Re: [OPSEC] New Work: Protecting the control plane
>
> Hi Ron,
>
> We already had a draft with that and a lot more:
> http://tools.ietf.org/html/draft-ietf-opsec-filter-caps-= 09
>
> We could resurrect it, if that is a requirement. It had gone all the > way to the IESG.
>
> Thanks,
> Vishwas
>
> On Tue, Jan 11, 2011 at 10:01 AM, Ronald Bonica <rbonica@juniper.net>
> wrote:
> > There are a few simple things that we can do (e.g., rate limit TC= P
> SYNs)
> >
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0Ron
> >
> >
> >> -----Original Message-----
> >> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]
> >> Sent: Tuesday, January 11, 2011 12:47 PM
> >> To: Ronald Bonica
> >> Cc: opsec@ietf.org
> >> Subject: Re: [OPSEC] New Work: Protecting the control plane > >>
> >> Hi Ron,
> >>
> >>
> >> > - attacks from those spoofing the source address of a le= gitimate
> >> control plane peer
> >> This can be caught by authentication, mechanisms also using t= he
> source
> >> address as a part of the hash.
> >>
> >> > - attacks from legitimate control plane peers (that migh= t be
> >> compromised or otherwise misbehaving)
> >> This is considerably harder to know for IGP's. For BGP we= can verify
> >> the origin . One thing that can be done is Public Key Cryptog= raphy.
> >> There are mechanisms available for the same already, however = the
> >> documents are experimental.
> >>
> >> The question however is how important are these issues for th= e
> >> operators to tackle?
> >>
> >> Thanks,
> >> Vishwas
> >
_______________________________________________
OPSEC mailing list
OPSEC@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/opsec

--0015175cd02a9309bc0499a75f61-- From rbonica@juniper.net Wed Jan 12 08:43:58 2011 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 3B7FF3A6B39 for ; Wed, 12 Jan 2011 08:43:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.508 X-Spam-Level: X-Spam-Status: No, score=-106.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCDlhOpgINki for ; Wed, 12 Jan 2011 08:43:57 -0800 (PST) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id 7567A3A6A4A for ; Wed, 12 Jan 2011 08:43:54 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTS3a1uPq27EFQsKeEkvkinj2h6lyjYra@postini.com; Wed, 12 Jan 2011 08:46:17 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 12 Jan 2011 08:42:36 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::8002:d3e7:4146:af5f]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 12 Jan 2011 11:42:35 -0500 From: Ronald Bonica To: Vishwas Manral , "Smith, Donald" Date: Wed, 12 Jan 2011 11:42:33 -0500 Thread-Topic: [OPSEC] New Work: Protecting the control plane Thread-Index: Acux5yhH23+WGqYGQDGIzfXcn8/noQAkG9AQ Message-ID: <13205C286662DE4387D9AF3AC30EF456B03C659C90@EMBX01-WF.jnpr.net> References: <13205C286662DE4387D9AF3AC30EF456B03C46D9F2@EMBX01-WF.jnpr.net> <13205C286662DE4387D9AF3AC30EF456B03C46DA5B@EMBX01-WF.jnpr.net> <13205C286662DE4387D9AF3AC30EF456B03C46DE6D@EMBX01-WF.jnpr.net> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "opsec@ietf.org" Subject: Re: [OPSEC] New Work: Protecting the control plane 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, 12 Jan 2011 16:43:58 -0000 Vishwas, I am happy to see someone revive the old draft. However, be mindful of the = old IESG comments. As I recall, they called or a considerable amount of wor= k. Ron > -----Original Message----- > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > Sent: Tuesday, January 11, 2011 6:28 PM > To: Smith, Donald > Cc: Ronald Bonica; opsec@ietf.org > Subject: Re: [OPSEC] New Work: Protecting the control plane >=20 > Hi Ron, >=20 > I agree more work is required to the last version of the draft. > However IMHO, I think older version of the drafts may be more > comprehensive and better, we could start with them. >=20 > Like Donald mentioned we can add the things you have referred to. >=20 > Thanks, > Vishwas >=20 > On Tue, Jan 11, 2011 at 3:18 PM, Smith, Donald > wrote: > > We could probably add some of what your asking for to the cpp draft > or call out that sharing a broadcast domain in your igp is risky and > layer 2 security should be implemented. Add GTSM and we should be able > to address most of the issues. > > > > > > > > (coffee !=3D sleep) & (!coffee =3D=3D sleep) > > =A0Donald.Smith@qwest.com > > ________________________________________ > > From: opsec-bounces@ietf.org [opsec-bounces@ietf.org] On Behalf Of > Ronald Bonica [rbonica@juniper.net] > > Sent: Tuesday, January 11, 2011 4:00 PM > > To: Vishwas Manral > > Cc: opsec@ietf.org > > Subject: Re: [OPSEC] New Work: Protecting the control plane > > > > Vishwas, > > > > I think that draft-ietf-opsec-filter-caps answers a slightly > different question. It has been three years since I looked at that > draft, but as I recall, it attempts to describe all filtering > capabilities that should be available on a router. > > > > Today, we are asking a more specific question. Specifically we want > to know what we should do to protect a router's control plane from > either a) insider attack or b) attack from outsiders spoofing inside > source addresses. > > > > That said, I would be very happy to see somebody resume work on > draft-ietf-opsec-filter-caps. As I recall, the IESG comments were > extensive. So, the person signing up for that task should be ready for > lots of work. > > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ron > > > > > > > >> -----Original Message----- > >> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > >> Sent: Tuesday, January 11, 2011 1:19 PM > >> To: Ronald Bonica > >> Cc: opsec@ietf.org > >> Subject: Re: [OPSEC] New Work: Protecting the control plane > >> > >> Hi Ron, > >> > >> We already had a draft with that and a lot more: > >> http://tools.ietf.org/html/draft-ietf-opsec-filter-caps-09 > >> > >> We could resurrect it, if that is a requirement. It had gone all the > >> way to the IESG. > >> > >> Thanks, > >> Vishwas > >> > >> On Tue, Jan 11, 2011 at 10:01 AM, Ronald Bonica > > >> wrote: > >> > There are a few simple things that we can do (e.g., rate limit TCP > >> SYNs) > >> > > >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0Ron > >> > > >> > > >> >> -----Original Message----- > >> >> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > >> >> Sent: Tuesday, January 11, 2011 12:47 PM > >> >> To: Ronald Bonica > >> >> Cc: opsec@ietf.org > >> >> Subject: Re: [OPSEC] New Work: Protecting the control plane > >> >> > >> >> Hi Ron, > >> >> > >> >> > >> >> > - attacks from those spoofing the source address of a > legitimate > >> >> control plane peer > >> >> This can be caught by authentication, mechanisms also using the > >> source > >> >> address as a part of the hash. > >> >> > >> >> > - attacks from legitimate control plane peers (that might be > >> >> compromised or otherwise misbehaving) > >> >> This is considerably harder to know for IGP's. For BGP we can > verify > >> >> the origin . One thing that can be done is Public Key > Cryptography. > >> >> There are mechanisms available for the same already, however the > >> >> documents are experimental. > >> >> > >> >> The question however is how important are these issues for the > >> >> operators to tackle? > >> >> > >> >> Thanks, > >> >> Vishwas > >> > > > _______________________________________________ > > OPSEC mailing list > > OPSEC@ietf.org > > https://www.ietf.org/mailman/listinfo/opsec > > > > This communication is the property of Qwest and may contain > confidential or > > privileged information. Unauthorized use of this communication is > strictly > > prohibited and may be unlawful. =A0If you have received this > communication > > in error, please immediately notify the sender by reply e-mail and > destroy > > all copies of the communication and any attachments. > > From rbonica@juniper.net Wed Jan 12 09:52:44 2011 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 323ED3A6817 for ; Wed, 12 Jan 2011 09:52:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.509 X-Spam-Level: X-Spam-Status: No, score=-106.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVhCxDu-OFXu for ; Wed, 12 Jan 2011 09:52:43 -0800 (PST) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by core3.amsl.com (Postfix) with ESMTP id 772F93A6A6F for ; Wed, 12 Jan 2011 09:52:42 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTS3q9sgNt/1tLX9XSS4THweDTbK/mtFV@postini.com; Wed, 12 Jan 2011 09:55:03 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 12 Jan 2011 09:48:22 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::8002:d3e7:4146:af5f]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 12 Jan 2011 12:48:22 -0500 From: Ronald Bonica To: Andrew Yourtchenko Date: Wed, 12 Jan 2011 12:48:20 -0500 Thread-Topic: [OPSEC] New Work: Protecting the control plane Thread-Index: AcuyYHbjL6JJ5IhERvaaR2TL816NcQAH8zag Message-ID: <13205C286662DE4387D9AF3AC30EF456B03C659D35@EMBX01-WF.jnpr.net> References: <13205C286662DE4387D9AF3AC30EF456B03C46D9F2@EMBX01-WF.jnpr.net> <13205C286662DE4387D9AF3AC30EF456B03C46DA5B@EMBX01-WF.jnpr.net> <13205C286662DE4387D9AF3AC30EF456B03C46DE6D@EMBX01-WF.jnpr.net> 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 Cc: "opsec@ietf.org" Subject: Re: [OPSEC] New Work: Protecting the control plane 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, 12 Jan 2011 17:52:44 -0000 >=20 > > b) attack from outsiders spoofing inside source addresses. >=20 > I would think that blocking one's infrastructure address space > on ingress to one's AS should take care of this. What am I missing ? >=20 Hi Andrew, While I agree that everyone should filter infrastructure addresses at the e= dge, it don't believe that edge filtering is sufficient. Reasons follow: - some edge gear may not be capable of filtering - if a single edge box is misconfigured (i.e., a single filter is missing),= the entire core is vulnerable - if a single edge box is compromised, the entire core is vulnerable. So, I think that some operators may require multiple layers of protection. = If the inner layer is cheap, it would be a very good idea to deploy it. Ron /speaking as individual contribut= or From Donald.Smith@qwest.com Wed Jan 12 14:09:53 2011 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 87DB73A67CC for ; Wed, 12 Jan 2011 14:09:53 -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 mgDIsH4g3YjV for ; Wed, 12 Jan 2011 14:09:52 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by core3.amsl.com (Postfix) with ESMTP id 7AC2F3A6810 for ; Wed, 12 Jan 2011 14:09:52 -0800 (PST) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id p0CMCBGl022279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Jan 2011 16:12:11 -0600 (CST) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 8D8D81E005A; Wed, 12 Jan 2011 16:12:06 -0600 (CST) Received: from suomp60i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 731DB1E003F; Wed, 12 Jan 2011 16:12:06 -0600 (CST) Received: from qtdenexhtm20.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id p0CMC57B012591; Wed, 12 Jan 2011 16:12:05 -0600 (CST) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm20.AD.QINTRA.COM ([151.119.91.229]) with mapi; Wed, 12 Jan 2011 15:12:01 -0700 From: "Smith, Donald" To: "'Ronald Bonica'" , "'Andrew Yourtchenko'" Date: Wed, 12 Jan 2011 15:11:59 -0700 Thread-Topic: [OPSEC] New Work: Protecting the control plane Thread-Index: AcuyYHbjL6JJ5IhERvaaR2TL816NcQAH8zagAAlWJsA= Message-ID: References: <13205C286662DE4387D9AF3AC30EF456B03C46D9F2@EMBX01-WF.jnpr.net> <13205C286662DE4387D9AF3AC30EF456B03C46DA5B@EMBX01-WF.jnpr.net> <13205C286662DE4387D9AF3AC30EF456B03C46DE6D@EMBX01-WF.jnpr.net> <13205C286662DE4387D9AF3AC30EF456B03C659D35@EMBX01-WF.jnpr.net> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456B03C659D35@EMBX01-WF.jnpr.net> 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-CFilter-Loop: Reflected Cc: "'opsec@ietf.org'" Subject: Re: [OPSEC] New Work: Protecting the control plane 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, 12 Jan 2011 22:09:53 -0000 Defense in depth is a basic principle of security so I agree:) "Pampers use multiple layers of protection to prevent leakage. Rommel used defense in depth to defend European fortresses." (A.White) Donald.Smith@qwest.com gcia > -----Original Message----- > From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] > On Behalf Of Ronald Bonica > Sent: Wednesday, January 12, 2011 10:48 AM > To: Andrew Yourtchenko > Cc: opsec@ietf.org > Subject: Re: [OPSEC] New Work: Protecting the control plane > > > > > > b) attack from outsiders spoofing inside source addresses. > > > > I would think that blocking one's infrastructure address space > > on ingress to one's AS should take care of this. What am I missing ? > > > > > Hi Andrew, > > While I agree that everyone should filter infrastructure > addresses at the edge, it don't believe that edge filtering > is sufficient. Reasons follow: > > - some edge gear may not be capable of filtering > - if a single edge box is misconfigured (i.e., a single > filter is missing), the entire core is vulnerable > - if a single edge box is compromised, the entire core is vulnerable. > > So, I think that some operators may require multiple layers > of protection. If the inner layer is cheap, it would be a > very good idea to deploy it. > > Ron > /speaking as > individual contributor > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From jared@puck.nether.net Wed Jan 12 14:24:39 2011 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 B6F603A67EE for ; Wed, 12 Jan 2011 14:24:39 -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 QGX4vfTTJaxq for ; Wed, 12 Jan 2011 14:24:39 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by core3.amsl.com (Postfix) with ESMTP id 2A7743A67AF for ; Wed, 12 Jan 2011 14:24:38 -0800 (PST) Received: from [10.0.0.137] (173-167-0-106-michigan.hfc.comcastbusiness.net [173.167.0.106]) (authenticated bits=0) by puck.nether.net (8.14.4/8.12.9) with ESMTP id p0CMQYaq073029 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Jan 2011 17:26:34 -0500 (EST) (envelope-from jared@puck.nether.net) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jared Mauch In-Reply-To: Date: Wed, 12 Jan 2011 17:26:32 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <13205C286662DE4387D9AF3AC30EF456B03C46D9F2@EMBX01-WF.jnpr.net> <13205C286662DE4387D9AF3AC30EF456B03C46DA5B@EMBX01-WF.jnpr.net> <13205C286662DE4387D9AF3AC30EF456B03C46DE6D@EMBX01-WF.jnpr.net> To: Andrew Yourtchenko X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Wed, 12 Jan 2011 17:26:35 -0500 (EST) Cc: "opsec@ietf.org" Subject: Re: [OPSEC] New Work: Protecting the control plane 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, 12 Jan 2011 22:24:39 -0000 On Jan 12, 2011, at 8:48 AM, Andrew Yourtchenko wrote: > I would think that blocking one's infrastructure address space > on ingress to one's AS should take care of this. What am I missing ? Easier said then entered after 'conf t' or 'configure;commit' sadly :( - Jared From warren@kumari.net Wed Jan 12 16:56:53 2011 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 6DA063A67E3 for ; Wed, 12 Jan 2011 16:56:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igxd+5COLiNE for ; Wed, 12 Jan 2011 16:56:52 -0800 (PST) Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id 0E1BC3A65A6 for ; Wed, 12 Jan 2011 16:56:52 -0800 (PST) Received: from [172.19.119.184] (unknown [64.13.52.115]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id 01AD522847D8; Wed, 12 Jan 2011 19:59:11 -0500 (EST) Message-Id: From: Warren Kumari To: Andrew Yourtchenko In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 12 Jan 2011 19:59:09 -0500 References: <13205C286662DE4387D9AF3AC30EF456B03C46D9F2@EMBX01-WF.jnpr.net> <13205C286662DE4387D9AF3AC30EF456B03C46DA5B@EMBX01-WF.jnpr.net> <13205C286662DE4387D9AF3AC30EF456B03C46DE6D@EMBX01-WF.jnpr.net> X-Mailer: Apple Mail (2.936) Cc: "opsec@ietf.org" Subject: Re: [OPSEC] New Work: Protecting the control plane 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, 13 Jan 2011 00:56:53 -0000 On Jan 12, 2011, at 8:48 AM, Andrew Yourtchenko wrote: > Ron, > > On Tue, 11 Jan 2011, Ronald Bonica wrote: > >> Vishwas, >> >> I think that draft-ietf-opsec-filter-caps answers a slightly >> different question. It has been three years since I looked at that >> draft, but as I recall, it attempts to describe all filtering >> capabilities that should be available on a router. >> >> Today, we are asking a more specific question. Specifically we want >> to know what we should do to protect a router's control plane from >> either >> a) insider attack or > > Maybe I am too much into conspiracy theories - but why kill the cow > that gives the milk ? If I were a blackhat and I had a control over > a router - I'd use it to selectively redirect traffic to the place > where I could capture/MITM it, or to collect the credentials of the > operators that log in, or social-engineer them. Not DoS the peer > router and thus reveal myself. In many enterprises everything with the enterprise is viewed as "inside" and no real protection (CPP or otherwise) is provided from address space within the enterprise. > > That consideration aside: rate-limiting SYNs would not prevent from > ACK floods, nor RST floods. So this would bring in the need to have > a built-in stateful firewall in front of control plane. Which > assumes that this firewall would be capable at handling the full > state at line-rate. Which means then we solved the problem "at its > root": the performance tradeoff in the control plane that creates > this problem. > >> b) attack from outsiders spoofing inside source addresses. > > I would think that blocking one's infrastructure address space > on ingress to one's AS should take care of this. What am I missing ? Well, for one, you are making the assumption that folk have actually numbered their infrastructure out of "infrastructure space", and not just chosen IPs out of whatever block happened to be nearby.... ;-) W > > cheers, > andrew > > >> >> That said, I would be very happy to see somebody resume work on >> draft-ietf-opsec-filter-caps. As I recall, the IESG comments were >> extensive. So, the person signing up for that task should be ready >> for lots of work. >> >> Ron >> >> >> >>> -----Original Message----- >>> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] >>> Sent: Tuesday, January 11, 2011 1:19 PM >>> To: Ronald Bonica >>> Cc: opsec@ietf.org >>> Subject: Re: [OPSEC] New Work: Protecting the control plane >>> >>> Hi Ron, >>> >>> We already had a draft with that and a lot more: >>> http://tools.ietf.org/html/draft-ietf-opsec-filter-caps-09 >>> >>> We could resurrect it, if that is a requirement. It had gone all the >>> way to the IESG. >>> >>> Thanks, >>> Vishwas >>> >>> On Tue, Jan 11, 2011 at 10:01 AM, Ronald Bonica >>> >>> wrote: >>>> There are a few simple things that we can do (e.g., rate limit TCP >>> SYNs) >>>> >>>> Ron >>>> >>>> >>>>> -----Original Message----- >>>>> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] >>>>> Sent: Tuesday, January 11, 2011 12:47 PM >>>>> To: Ronald Bonica >>>>> Cc: opsec@ietf.org >>>>> Subject: Re: [OPSEC] New Work: Protecting the control plane >>>>> >>>>> Hi Ron, >>>>> >>>>> >>>>>> - attacks from those spoofing the source address of a legitimate >>>>> control plane peer >>>>> This can be caught by authentication, mechanisms also using the >>> source >>>>> address as a part of the hash. >>>>> >>>>>> - attacks from legitimate control plane peers (that might be >>>>> compromised or otherwise misbehaving) >>>>> This is considerably harder to know for IGP's. For BGP we can >>>>> verify >>>>> the origin . One thing that can be done is Public Key >>>>> Cryptography. >>>>> There are mechanisms available for the same already, however the >>>>> documents are experimental. >>>>> >>>>> The question however is how important are these issues for the >>>>> operators to tackle? >>>>> >>>>> 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 ayourtch@cisco.com Thu Jan 13 02:02:22 2011 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 D36CF3A6B61 for ; Thu, 13 Jan 2011 02:02:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.946 X-Spam-Level: X-Spam-Status: No, score=-1.946 tagged_above=-999 required=5 tests=[AWL=0.653, 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 uLJATggEh28m for ; Thu, 13 Jan 2011 02:02:22 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id BB9043A6AE3 for ; Thu, 13 Jan 2011 02:02:21 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p0DA4hOm020072; Thu, 13 Jan 2011 11:04:43 +0100 (CET) Received: from sweet-brew-3.cisco.com (sweet-brew-3.cisco.com [144.254.10.204]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p0DA4gIP003281; Thu, 13 Jan 2011 11:04:42 +0100 (CET) Date: Thu, 13 Jan 2011 11:04:42 +0100 (CET) From: Andrew Yourtchenko To: Ronald Bonica In-Reply-To: <13205C286662DE4387D9AF3AC30EF456B03C659D35@EMBX01-WF.jnpr.net> Message-ID: References: <13205C286662DE4387D9AF3AC30EF456B03C46D9F2@EMBX01-WF.jnpr.net> <13205C286662DE4387D9AF3AC30EF456B03C46DA5B@EMBX01-WF.jnpr.net> <13205C286662DE4387D9AF3AC30EF456B03C46DE6D@EMBX01-WF.jnpr.net> <13205C286662DE4387D9AF3AC30EF456B03C659D35@EMBX01-WF.jnpr.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "opsec@ietf.org" Subject: Re: [OPSEC] New Work: Protecting the control plane 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, 13 Jan 2011 10:02:22 -0000 Hi Ron, On Wed, 12 Jan 2011, Ronald Bonica wrote: >> >>> b) attack from outsiders spoofing inside source addresses. >> >> I would think that blocking one's infrastructure address space >> on ingress to one's AS should take care of this. What am I missing ? >> > > > Hi Andrew, > > While I agree that everyone should filter infrastructure addresses at the edge, it don't believe that edge filtering is sufficient. Reasons follow: > > - some edge gear may not be capable of filtering > - if a single edge box is misconfigured (i.e., a single filter is missing), the entire core is vulnerable > - if a single edge box is compromised, the entire core is vulnerable. > > So, I think that some operators may require multiple layers of protection. If > the inner layer is cheap, it would be a very good idea to deploy it. Agreed, if it is there, shame not to use it. I think what was causing the question in me, is this. I would say what we would do depends on 3 factors: 1) the threat model 2) means of identification for the traffic ("legit"/"illegit") 3) means of enforcing the policy of allowing only legit traffic. I think (1) is somewhat defined, while possibly we have different pictures in mind for (2)/(3). I was thinking of the latter in terms of a simple ACL-like mechanism before the traffic exits the data plane, while it is definitely not the only way, and you had in mind something different ? cheers, andrew > > Ron > /speaking as individual contributor > > From ayourtch@cisco.com Thu Jan 13 02:15:16 2011 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 788943A6B6B for ; Thu, 13 Jan 2011 02:15:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[AWL=0.580, 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 ASFpizLv4BEb for ; Thu, 13 Jan 2011 02:15:15 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 2FB973A6B6A for ; Thu, 13 Jan 2011 02:15:15 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p0DAHakG021073; Thu, 13 Jan 2011 11:17:36 +0100 (CET) Received: from sweet-brew-3.cisco.com (sweet-brew-3.cisco.com [144.254.10.204]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p0DAHWjq021432; Thu, 13 Jan 2011 11:17:32 +0100 (CET) Date: Thu, 13 Jan 2011 11:17:32 +0100 (CET) From: Andrew Yourtchenko To: Warren Kumari In-Reply-To: Message-ID: References: <13205C286662DE4387D9AF3AC30EF456B03C46D9F2@EMBX01-WF.jnpr.net> <13205C286662DE4387D9AF3AC30EF456B03C46DA5B@EMBX01-WF.jnpr.net> <13205C286662DE4387D9AF3AC30EF456B03C46DE6D@EMBX01-WF.jnpr.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "opsec@ietf.org" Subject: Re: [OPSEC] New Work: Protecting the control plane 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, 13 Jan 2011 10:15:16 -0000 On Wed, 12 Jan 2011, Warren Kumari wrote: > > On Jan 12, 2011, at 8:48 AM, Andrew Yourtchenko wrote: > >> Ron, >> >> On Tue, 11 Jan 2011, Ronald Bonica wrote: >> >>> Vishwas, >>> >>> I think that draft-ietf-opsec-filter-caps answers a slightly different >>> question. It has been three years since I looked at that draft, but as I >>> recall, it attempts to describe all filtering capabilities that should be >>> available on a router. >>> >>> Today, we are asking a more specific question. Specifically we want to >>> know what we should do to protect a router's control plane from either >>> a) insider attack or >> >> Maybe I am too much into conspiracy theories - but why kill the cow that >> gives the milk ? If I were a blackhat and I had a control over a router - >> I'd use it to selectively redirect traffic to the place where I could >> capture/MITM it, or to collect the credentials of the operators that log >> in, or social-engineer them. Not DoS the peer router and thus reveal >> myself. > > In many enterprises everything with the enterprise is viewed as "inside" and > no real protection (CPP or otherwise) is provided from address space within > the enterprise. > Right. But does this invalidate my point ? i.e. the fact that the mere access to the control plane (DoS-resistant or not) is much more important than DoS protection per se. Foot-shooting aside, of course. > >> >> That consideration aside: rate-limiting SYNs would not prevent from ACK >> floods, nor RST floods. So this would bring in the need to have a built-in >> stateful firewall in front of control plane. Which assumes that this >> firewall would be capable at handling the full state at line-rate. Which >> means then we solved the problem "at its root": the performance tradeoff in >> the control plane that creates this problem. >> >>> b) attack from outsiders spoofing inside source addresses. >> >> I would think that blocking one's infrastructure address space >> on ingress to one's AS should take care of this. What am I missing ? > > Well, for one, you are making the assumption that folk have actually numbered > their infrastructure out of "infrastructure space", and not just chosen IPs > out of whatever block happened to be nearby.... ;-) touche ;-) cheers, andrew > > W > >> >> cheers, >> andrew >> >> >>> >>> That said, I would be very happy to see somebody resume work on >>> draft-ietf-opsec-filter-caps. As I recall, the IESG comments were >>> extensive. So, the person signing up for that task should be ready for >>> lots of work. >>> >>> Ron >>> >>> >>> >>>> -----Original Message----- >>>> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] >>>> Sent: Tuesday, January 11, 2011 1:19 PM >>>> To: Ronald Bonica >>>> Cc: opsec@ietf.org >>>> Subject: Re: [OPSEC] New Work: Protecting the control plane >>>> >>>> Hi Ron, >>>> >>>> We already had a draft with that and a lot more: >>>> http://tools.ietf.org/html/draft-ietf-opsec-filter-caps-09 >>>> >>>> We could resurrect it, if that is a requirement. It had gone all the >>>> way to the IESG. >>>> >>>> Thanks, >>>> Vishwas >>>> >>>> On Tue, Jan 11, 2011 at 10:01 AM, Ronald Bonica >>>> wrote: >>>>> There are a few simple things that we can do (e.g., rate limit TCP >>>> SYNs) >>>>> >>>>> Ron >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] >>>>>> Sent: Tuesday, January 11, 2011 12:47 PM >>>>>> To: Ronald Bonica >>>>>> Cc: opsec@ietf.org >>>>>> Subject: Re: [OPSEC] New Work: Protecting the control plane >>>>>> >>>>>> Hi Ron, >>>>>> >>>>>> >>>>>>> - attacks from those spoofing the source address of a legitimate >>>>>> control plane peer >>>>>> This can be caught by authentication, mechanisms also using the >>>> source >>>>>> address as a part of the hash. >>>>>> >>>>>>> - attacks from legitimate control plane peers (that might be >>>>>> compromised or otherwise misbehaving) >>>>>> This is considerably harder to know for IGP's. For BGP we can verify >>>>>> the origin . One thing that can be done is Public Key Cryptography. >>>>>> There are mechanisms available for the same already, however the >>>>>> documents are experimental. >>>>>> >>>>>> The question however is how important are these issues for the >>>>>> operators to tackle? >>>>>> >>>>>> 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 warren@kumari.net Thu Jan 13 06:03:24 2011 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 D684B3A6B2B for ; Thu, 13 Jan 2011 06:03:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B893EfUZUuEV for ; Thu, 13 Jan 2011 06:03:23 -0800 (PST) Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id 4B9573A6B27 for ; Thu, 13 Jan 2011 06:03:23 -0800 (PST) Received: from [172.19.119.184] (unknown [64.13.52.115]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id 43E89DEE326; Thu, 13 Jan 2011 09:05:44 -0500 (EST) Message-Id: <4B0F2D12-498B-4023-BF45-F8A79886C89F@kumari.net> From: Warren Kumari To: Andrew Yourtchenko In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 13 Jan 2011 09:05:41 -0500 References: <13205C286662DE4387D9AF3AC30EF456B03C46D9F2@EMBX01-WF.jnpr.net> <13205C286662DE4387D9AF3AC30EF456B03C46DA5B@EMBX01-WF.jnpr.net> <13205C286662DE4387D9AF3AC30EF456B03C46DE6D@EMBX01-WF.jnpr.net> X-Mailer: Apple Mail (2.936) Cc: "opsec@ietf.org" Subject: Re: [OPSEC] New Work: Protecting the control plane 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, 13 Jan 2011 14:03:25 -0000 On Jan 13, 2011, at 5:17 AM, Andrew Yourtchenko wrote: > > > On Wed, 12 Jan 2011, Warren Kumari wrote: > >> >> On Jan 12, 2011, at 8:48 AM, Andrew Yourtchenko wrote: >> >>> Ron, >>> On Tue, 11 Jan 2011, Ronald Bonica wrote: >>>> Vishwas, >>>> I think that draft-ietf-opsec-filter-caps answers a slightly >>>> different question. It has been three years since I looked at >>>> that draft, but as I recall, it attempts to describe all >>>> filtering capabilities that should be available on a router. >>>> Today, we are asking a more specific question. Specifically we >>>> want to know what we should do to protect a router's control >>>> plane from either >>>> a) insider attack or >>> Maybe I am too much into conspiracy theories - but why kill the >>> cow that gives the milk ? If I were a blackhat and I had a control >>> over a router - I'd use it to selectively redirect traffic to the >>> place where I could capture/MITM it, or to collect the credentials >>> of the operators that log in, or social-engineer them. Not DoS the >>> peer router and thus reveal myself. >> >> In many enterprises everything with the enterprise is viewed as >> "inside" and no real protection (CPP or otherwise) is provided from >> address space within the enterprise. >> > > Right. But does this invalidate my point ? i.e. the fact that the > mere access to the control plane (DoS-resistant or not) is much more > important than DoS protection per se. Oh no, not at all... Just that both are important and should be secured / protected... W > Foot-shooting aside, of course. > >> >>> That consideration aside: rate-limiting SYNs would not prevent >>> from ACK floods, nor RST floods. So this would bring in the need >>> to have a built-in stateful firewall in front of control plane. >>> Which assumes that this firewall would be capable at handling the >>> full state at line-rate. Which means then we solved the problem >>> "at its root": the performance tradeoff in the control plane that >>> creates this problem. >>>> b) attack from outsiders spoofing inside source addresses. >>> I would think that blocking one's infrastructure address space >>> on ingress to one's AS should take care of this. What am I missing ? >> >> Well, for one, you are making the assumption that folk have >> actually numbered their infrastructure out of "infrastructure >> space", and not just chosen IPs out of whatever block happened to >> be nearby.... ;-) > > touche ;-) > > cheers, > andrew > > >> >> W >> >>> cheers, >>> andrew >>>> That said, I would be very happy to see somebody resume work on >>>> draft-ietf-opsec-filter-caps. As I recall, the IESG comments were >>>> extensive. So, the person signing up for that task should be >>>> ready for lots of work. >>>> >>>> Ron >>>>> -----Original Message----- >>>>> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] >>>>> Sent: Tuesday, January 11, 2011 1:19 PM >>>>> To: Ronald Bonica >>>>> Cc: opsec@ietf.org >>>>> Subject: Re: [OPSEC] New Work: Protecting the control plane >>>>> Hi Ron, >>>>> We already had a draft with that and a lot more: >>>>> http://tools.ietf.org/html/draft-ietf-opsec-filter-caps-09 >>>>> We could resurrect it, if that is a requirement. It had gone all >>>>> the >>>>> way to the IESG. >>>>> Thanks, >>>>> Vishwas >>>>> On Tue, Jan 11, 2011 at 10:01 AM, Ronald Bonica >>>> > >>>>> wrote: >>>>>> There are a few simple things that we can do (e.g., rate limit >>>>>> TCP >>>>> SYNs) >>>>>> >>>>>> Ron >>>>>>> -----Original Message----- >>>>>>> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] >>>>>>> Sent: Tuesday, January 11, 2011 12:47 PM >>>>>>> To: Ronald Bonica >>>>>>> Cc: opsec@ietf.org >>>>>>> Subject: Re: [OPSEC] New Work: Protecting the control plane >>>>>>> Hi Ron, >>>>>>>> - attacks from those spoofing the source address of a >>>>>>>> legitimate >>>>>>> control plane peer >>>>>>> This can be caught by authentication, mechanisms also using the >>>>> source >>>>>>> address as a part of the hash. >>>>>>>> - attacks from legitimate control plane peers (that might be >>>>>>> compromised or otherwise misbehaving) >>>>>>> This is considerably harder to know for IGP's. For BGP we can >>>>>>> verify >>>>>>> the origin . One thing that can be done is Public Key >>>>>>> Cryptography. >>>>>>> There are mechanisms available for the same already, however the >>>>>>> documents are experimental. >>>>>>> The question however is how important are these issues for the >>>>>>> operators to tackle? >>>>>>> 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 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec From jabley@hopcount.ca Thu Jan 20 13:49:59 2011 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 4A2093A6836 for ; Thu, 20 Jan 2011 13:49:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9NasPzl1D89 for ; Thu, 20 Jan 2011 13:49:58 -0800 (PST) Received: from monster.hopcount.ca (monster.hopcount.ca [216.235.14.38]) by core3.amsl.com (Postfix) with ESMTP id 5E7053A6834 for ; Thu, 20 Jan 2011 13:49:58 -0800 (PST) Received: from [199.212.90.28] (helo=dh28.r1.owls.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Pg2Uz-000HYj-ND for opsec@ietf.org; Thu, 20 Jan 2011 21:56:59 +0000 From: Joe Abley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 20 Jan 2011 16:52:38 -0500 Message-Id: <66E13FB1-270A-4E66-87D2-83E9FE0EDAC9@hopcount.ca> To: "opsec@ietf.org mailing list" Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-SA-Exim-Connect-IP: 199.212.90.28 X-SA-Exim-Mail-From: jabley@hopcount.ca X-SA-Exim-Scanned: No (on monster.hopcount.ca); SAEximRunCond expanded to false Subject: [OPSEC] of possible interest to opsec 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, 20 Jan 2011 21:49:59 -0000 Hi all, http://www.ietf.org/id/draft-shahid-protect-edge-devices-00.txt I gather the author is amenable to the idea that this could become a = working group document, if the working group is inclined to spend time = on it. Joe= From Internet-Drafts@ietf.org Wed Jan 26 21:30:07 2011 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 E3E2E28C107; Wed, 26 Jan 2011 21:30:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdF+rlgP8eLs; Wed, 26 Jan 2011 21:30:03 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06BA828C0E1; Wed, 26 Jan 2011 21:30:03 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110127053003.9380.94247.idtracker@localhost> Date: Wed, 26 Jan 2011 21:30:03 -0800 Cc: opsec@ietf.org Subject: [OPSEC] I-D Action:draft-ietf-opsec-ip-security-06.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, 27 Jan 2011 05:30:07 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operational Security Capabilities for IP Network Infrastructure Working Group of the IETF. Title : Security Assessment of the Internet Protocol version 4 Author(s) : F. Gont Filename : draft-ietf-opsec-ip-security-06.txt Pages : 77 Date : 2011-01-26 This document contains a security assessment of the IETF specifications of the Internet Protocol version 4, and of a number of mechanisms and policies in use by popular IPv4 implementations. It is based on the results of a project carried out by the UK's Centre for the Protection of National Infrastructure (CPNI). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opsec-ip-security-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-opsec-ip-security-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-26211942.I-D@ietf.org> --NextPart-- From joelja@bogus.com Fri Jan 28 15:32:49 2011 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 249C93A6954 for ; Fri, 28 Jan 2011 15:32:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.446 X-Spam-Level: X-Spam-Status: No, score=-102.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNjvHIe7uLyf for ; Fri, 28 Jan 2011 15:32:47 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 141683A68B7 for ; Fri, 28 Jan 2011 15:32:46 -0800 (PST) Received: from dhcp-176.nokia.net (dhcp-176.nokia.net [192.103.16.176] (may be forged)) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p0SNZpbN053499 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 28 Jan 2011 23:35:51 GMT (envelope-from joelja@bogus.com) Message-ID: <4D4352D7.30105@bogus.com> Date: Fri, 28 Jan 2011 15:35:51 -0800 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Andrew Yourtchenko References: <13205C286662DE4387D9AF3AC30EF456B03C46D9F2@EMBX01-WF.jnpr.net> <13205C286662DE4387D9AF3AC30EF456B03C46DA5B@EMBX01-WF.jnpr.net> <13205C286662DE4387D9AF3AC30EF456B03C46DE6D@EMBX01-WF.jnpr.net> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "opsec@ietf.org" Subject: Re: [OPSEC] New Work: Protecting the control plane 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, 28 Jan 2011 23:32:49 -0000 On 1/12/11 5:48 AM, Andrew Yourtchenko wrote: > Ron, > That consideration aside: rate-limiting SYNs would not prevent from ACK > floods, nor RST floods. So this would bring in the need to have a > built-in stateful firewall in front of control plane. Which assumes that > this firewall would be capable at handling the full state at line-rate. > Which means then we solved the problem "at its root": the performance > tradeoff in the control plane that creates this problem. It not necessary to have a stateful device to rate-limit syns... the problem you have really is if your rate-limiting is in effect, and one of your valid tcp connections goes down, it needs to not get clobbered by the rate limiter... Like many kinds of policers if deployed wrongly it can make it easier rather than harder to take out the box (think arp policer as another example) >> b) attack from outsiders spoofing inside source addresses. > > I would think that blocking one's infrastructure address space > on ingress to one's AS should take care of this. What am I missing ? > > cheers, > andrew > > >> >> That said, I would be very happy to see somebody resume work on >> draft-ietf-opsec-filter-caps. As I recall, the IESG comments were >> extensive. So, the person signing up for that task should be ready for >> lots of work. >> >> Ron >> >> >> >>> -----Original Message----- >>> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] >>> Sent: Tuesday, January 11, 2011 1:19 PM >>> To: Ronald Bonica >>> Cc: opsec@ietf.org >>> Subject: Re: [OPSEC] New Work: Protecting the control plane >>> >>> Hi Ron, >>> >>> We already had a draft with that and a lot more: >>> http://tools.ietf.org/html/draft-ietf-opsec-filter-caps-09 >>> >>> We could resurrect it, if that is a requirement. It had gone all the >>> way to the IESG. >>> >>> Thanks, >>> Vishwas >>> >>> On Tue, Jan 11, 2011 at 10:01 AM, Ronald Bonica >>> wrote: >>>> There are a few simple things that we can do (e.g., rate limit TCP >>> SYNs) >>>> >>>> � � � � � � � � � � � � � � � � � �Ron >>>> >>>> >>>>> -----Original Message----- >>>>> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] >>>>> Sent: Tuesday, January 11, 2011 12:47 PM >>>>> To: Ronald Bonica >>>>> Cc: opsec@ietf.org >>>>> Subject: Re: [OPSEC] New Work: Protecting the control plane >>>>> >>>>> Hi Ron, >>>>> >>>>> >>>>>> - attacks from those spoofing the source address of a legitimate >>>>> control plane peer >>>>> This can be caught by authentication, mechanisms also using the >>> source >>>>> address as a part of the hash. >>>>> >>>>>> - attacks from legitimate control plane peers (that might be >>>>> compromised or otherwise misbehaving) >>>>> This is considerably harder to know for IGP's. For BGP we can verify >>>>> the origin . One thing that can be done is Public Key Cryptography. >>>>> There are mechanisms available for the same already, however the >>>>> documents are experimental. >>>>> >>>>> The question however is how important are these issues for the >>>>> operators to tackle? >>>>> >>>>> 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 Donald.Smith@qwest.com Sat Jan 29 06:07:46 2011 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 CB4F23A67B6 for ; Sat, 29 Jan 2011 06:07:46 -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 z206YDyBmW5v for ; Sat, 29 Jan 2011 06:07:45 -0800 (PST) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by core3.amsl.com (Postfix) with ESMTP id C3C323A67B5 for ; Sat, 29 Jan 2011 06:07:45 -0800 (PST) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id p0TEAk6Y023510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 29 Jan 2011 07:10:47 -0700 (MST) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id D507A1E004D; Sat, 29 Jan 2011 07:10:41 -0700 (MST) Received: from suomp61i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id B33D01E0035; Sat, 29 Jan 2011 07:10:41 -0700 (MST) Received: from qtdenexhtm20.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id p0TEAd09006554; Sat, 29 Jan 2011 08:10:40 -0600 (CST) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm20.AD.QINTRA.COM ([151.119.91.229]) with mapi; Sat, 29 Jan 2011 07:10:40 -0700 From: "Smith, Donald" To: Joel Jaeggli , Andrew Yourtchenko Date: Sat, 29 Jan 2011 07:07:48 -0700 Thread-Topic: [OPSEC] New Work: Protecting the control plane Thread-Index: Acu/RCDxXWttmUjWQlKu+p7IBcl3ngAeceQ/ Message-ID: References: <13205C286662DE4387D9AF3AC30EF456B03C46D9F2@EMBX01-WF.jnpr.net> <13205C286662DE4387D9AF3AC30EF456B03C46DA5B@EMBX01-WF.jnpr.net> <13205C286662DE4387D9AF3AC30EF456B03C46DE6D@EMBX01-WF.jnpr.net> , <4D4352D7.30105@bogus.com> In-Reply-To: <4D4352D7.30105@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "opsec@ietf.org" Subject: Re: [OPSEC] New Work: Protecting the control plane 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, 29 Jan 2011 14:07:47 -0000 DQooY29mZmVlICE9IHNsZWVwKSAmICghY29mZmVlID09IHNsZWVwKQ0KIERvbmFsZC5TbWl0aEBx d2VzdC5jb20NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206 IG9wc2VjLWJvdW5jZXNAaWV0Zi5vcmcgW29wc2VjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBKb2VsIEphZWdnbGkgW2pvZWxqYUBib2d1cy5jb21dDQpTZW50OiBGcmlkYXksIEphbnVh cnkgMjgsIDIwMTEgNDozNSBQTQ0KVG86IEFuZHJldyBZb3VydGNoZW5rbw0KQ2M6IG9wc2VjQGll dGYub3JnDQpTdWJqZWN0OiBSZTogW09QU0VDXSBOZXcgV29yazogUHJvdGVjdGluZyB0aGUgY29u dHJvbCBwbGFuZQ0KDQpPbiAxLzEyLzExIDU6NDggQU0sIEFuZHJldyBZb3VydGNoZW5rbyB3cm90 ZToNCj4gUm9uLA0KDQo+IFRoYXQgY29uc2lkZXJhdGlvbiBhc2lkZTogcmF0ZS1saW1pdGluZyBT WU5zIHdvdWxkIG5vdCBwcmV2ZW50IGZyb20gQUNLDQo+IGZsb29kcywgbm9yIFJTVCBmbG9vZHMu IFNvIHRoaXMgd291bGQgYnJpbmcgaW4gdGhlIG5lZWQgdG8gaGF2ZSBhDQo+IGJ1aWx0LWluIHN0 YXRlZnVsIGZpcmV3YWxsIGluIGZyb250IG9mIGNvbnRyb2wgcGxhbmUuIFdoaWNoIGFzc3VtZXMg dGhhdA0KPiB0aGlzIGZpcmV3YWxsIHdvdWxkIGJlIGNhcGFibGUgYXQgaGFuZGxpbmcgdGhlIGZ1 bGwgc3RhdGUgYXQgbGluZS1yYXRlLg0KPiBXaGljaCBtZWFucyB0aGVuIHdlIHNvbHZlZCB0aGUg cHJvYmxlbSAiYXQgaXRzIHJvb3QiOiB0aGUgcGVyZm9ybWFuY2UNCj4gdHJhZGVvZmYgaW4gdGhl IGNvbnRyb2wgcGxhbmUgdGhhdCBjcmVhdGVzIHRoaXMgcHJvYmxlbS4NCg0KSXQgbm90IG5lY2Vz c2FyeSB0byBoYXZlIGEgc3RhdGVmdWwgZGV2aWNlIHRvIHJhdGUtbGltaXQgc3lucy4uLiB0aGUN CnByb2JsZW0geW91IGhhdmUgcmVhbGx5IGlzIGlmIHlvdXIgcmF0ZS1saW1pdGluZyBpcyBpbiBl ZmZlY3QsIGFuZCBvbmUNCm9mIHlvdXIgdmFsaWQgdGNwIGNvbm5lY3Rpb25zIGdvZXMgZG93biwg aXQgbmVlZHMgdG8gbm90IGdldCBjbG9iYmVyZWQNCmJ5IHRoZSByYXRlIGxpbWl0ZXIuLi4gTGlr ZSBtYW55IGtpbmRzIG9mIHBvbGljZXJzIGlmIGRlcGxveWVkIHdyb25nbHkNCml0IGNhbiBtYWtl IGl0IGVhc2llciByYXRoZXIgdGhhbiBoYXJkZXIgdG8gdGFrZSBvdXQgdGhlIGJveCAodGhpbmsg YXJwDQpwb2xpY2VyIGFzIGFub3RoZXIgZXhhbXBsZSkNCg0KDQpUaGlzIHJpc2sgaXMgYXQgbGVh c3QgcGFydGlhbGx5IG1pdGlnYXRlZCBieSBoYXZpbmcgYW4gT09CUiBtZ210IG5ldHdvcmsgc28g dGhhdCBzaG91bGQgYmUgcGFydCBvZiB0aGUgcmlzayBtaXRpZ2F0aW9uIHJlY29tbWVuZGF0aW9u czspDQoNCg0KPj4gYikgYXR0YWNrIGZyb20gb3V0c2lkZXJzIHNwb29maW5nIGluc2lkZSBzb3Vy Y2UgYWRkcmVzc2VzLg0KPg0KPiBJIHdvdWxkIHRoaW5rIHRoYXQgYmxvY2tpbmcgb25lJ3MgaW5m cmFzdHJ1Y3R1cmUgYWRkcmVzcyBzcGFjZQ0KPiBvbiBpbmdyZXNzIHRvIG9uZSdzIEFTIHNob3Vs ZCB0YWtlIGNhcmUgb2YgdGhpcy4gV2hhdCBhbSBJIG1pc3NpbmcgPw0KPg0KPiBjaGVlcnMsDQo+ IGFuZHJldw0KPg0KPg0KPj4NCj4+IFRoYXQgc2FpZCwgSSB3b3VsZCBiZSB2ZXJ5IGhhcHB5IHRv IHNlZSBzb21lYm9keSByZXN1bWUgd29yayBvbg0KPj4gZHJhZnQtaWV0Zi1vcHNlYy1maWx0ZXIt Y2Fwcy4gQXMgSSByZWNhbGwsIHRoZSBJRVNHIGNvbW1lbnRzIHdlcmUNCj4+IGV4dGVuc2l2ZS4g U28sIHRoZSBwZXJzb24gc2lnbmluZyB1cCBmb3IgdGhhdCB0YXNrIHNob3VsZCBiZSByZWFkeSBm b3INCj4+IGxvdHMgb2Ygd29yay4NCj4+DQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgUm9uDQo+Pg0KPj4NCj4+DQo+Pj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBWaXNod2FzIE1hbnJhbCBbbWFpbHRvOnZpc2h3YXMu aWV0ZkBnbWFpbC5jb21dDQo+Pj4gU2VudDogVHVlc2RheSwgSmFudWFyeSAxMSwgMjAxMSAxOjE5 IFBNDQo+Pj4gVG86IFJvbmFsZCBCb25pY2ENCj4+PiBDYzogb3BzZWNAaWV0Zi5vcmcNCj4+PiBT dWJqZWN0OiBSZTogW09QU0VDXSBOZXcgV29yazogUHJvdGVjdGluZyB0aGUgY29udHJvbCBwbGFu ZQ0KPj4+DQo+Pj4gSGkgUm9uLA0KPj4+DQo+Pj4gV2UgYWxyZWFkeSBoYWQgYSBkcmFmdCB3aXRo IHRoYXQgYW5kIGEgbG90IG1vcmU6DQo+Pj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1vcHNlYy1maWx0ZXItY2Fwcy0wOQ0KPj4+DQo+Pj4gV2UgY291bGQgcmVzdXJyZWN0 IGl0LCBpZiB0aGF0IGlzIGEgcmVxdWlyZW1lbnQuIEl0IGhhZCBnb25lIGFsbCB0aGUNCj4+PiB3 YXkgdG8gdGhlIElFU0cuDQo+Pj4NCj4+PiBUaGFua3MsDQo+Pj4gVmlzaHdhcw0KPj4+DQo+Pj4g T24gVHVlLCBKYW4gMTEsIDIwMTEgYXQgMTA6MDEgQU0sIFJvbmFsZCBCb25pY2EgPHJib25pY2FA anVuaXBlci5uZXQ+DQo+Pj4gd3JvdGU6DQo+Pj4+IFRoZXJlIGFyZSBhIGZldyBzaW1wbGUgdGhp bmdzIHRoYXQgd2UgY2FuIGRvIChlLmcuLCByYXRlIGxpbWl0IFRDUA0KPj4+IFNZTnMpDQo+Pj4+ DQo+Pj4+IO+/vSDvv70g77+9IO+/vSDvv70g77+9IO+/vSDvv70g77+9IO+/vSDvv70g77+9IO+/ vSDvv70g77+9IO+/vSDvv70g77+9Um9uDQo+Pj4+DQo+Pj4+DQo+Pj4+PiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPj4+Pj4gRnJvbTogVmlzaHdhcyBNYW5yYWwgW21haWx0bzp2aXNod2Fz LmlldGZAZ21haWwuY29tXQ0KPj4+Pj4gU2VudDogVHVlc2RheSwgSmFudWFyeSAxMSwgMjAxMSAx Mjo0NyBQTQ0KPj4+Pj4gVG86IFJvbmFsZCBCb25pY2ENCj4+Pj4+IENjOiBvcHNlY0BpZXRmLm9y Zw0KPj4+Pj4gU3ViamVjdDogUmU6IFtPUFNFQ10gTmV3IFdvcms6IFByb3RlY3RpbmcgdGhlIGNv bnRyb2wgcGxhbmUNCj4+Pj4+DQo+Pj4+PiBIaSBSb24sDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+PiAt IGF0dGFja3MgZnJvbSB0aG9zZSBzcG9vZmluZyB0aGUgc291cmNlIGFkZHJlc3Mgb2YgYSBsZWdp dGltYXRlDQo+Pj4+PiBjb250cm9sIHBsYW5lIHBlZXINCj4+Pj4+IFRoaXMgY2FuIGJlIGNhdWdo dCBieSBhdXRoZW50aWNhdGlvbiwgbWVjaGFuaXNtcyBhbHNvIHVzaW5nIHRoZQ0KPj4+IHNvdXJj ZQ0KPj4+Pj4gYWRkcmVzcyBhcyBhIHBhcnQgb2YgdGhlIGhhc2guDQo+Pj4+Pg0KPj4+Pj4+IC0g YXR0YWNrcyBmcm9tIGxlZ2l0aW1hdGUgY29udHJvbCBwbGFuZSBwZWVycyAodGhhdCBtaWdodCBi ZQ0KPj4+Pj4gY29tcHJvbWlzZWQgb3Igb3RoZXJ3aXNlIG1pc2JlaGF2aW5nKQ0KPj4+Pj4gVGhp cyBpcyBjb25zaWRlcmFibHkgaGFyZGVyIHRvIGtub3cgZm9yIElHUCdzLiBGb3IgQkdQIHdlIGNh biB2ZXJpZnkNCj4+Pj4+IHRoZSBvcmlnaW4gLiBPbmUgdGhpbmcgdGhhdCBjYW4gYmUgZG9uZSBp cyBQdWJsaWMgS2V5IENyeXB0b2dyYXBoeS4NCj4+Pj4+IFRoZXJlIGFyZSBtZWNoYW5pc21zIGF2 YWlsYWJsZSBmb3IgdGhlIHNhbWUgYWxyZWFkeSwgaG93ZXZlciB0aGUNCj4+Pj4+IGRvY3VtZW50 cyBhcmUgZXhwZXJpbWVudGFsLg0KPj4+Pj4NCj4+Pj4+IFRoZSBxdWVzdGlvbiBob3dldmVyIGlz IGhvdyBpbXBvcnRhbnQgYXJlIHRoZXNlIGlzc3VlcyBmb3IgdGhlDQo+Pj4+PiBvcGVyYXRvcnMg dG8gdGFja2xlPw0KPj4+Pj4NCj4+Pj4+IFRoYW5rcywNCj4+Pj4+IFZpc2h3YXMNCj4+Pj4NCj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBPUFNF QyBtYWlsaW5nIGxpc3QNCj4+IE9QU0VDQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29wc2VjDQo+Pg0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBPUFNFQyBtYWlsaW5nIGxpc3QNCj4gT1BT RUNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vcHNl Yw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT1BT RUMgbWFpbGluZyBsaXN0DQpPUFNFQ0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vcHNlYw0KDQpUaGlzIGNvbW11bmljYXRpb24gaXMgdGhlIHByb3BlcnR5 IG9mIFF3ZXN0IGFuZCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3INCnByaXZpbGVnZWQgaW5m b3JtYXRpb24uIFVuYXV0aG9yaXplZCB1c2Ugb2YgdGhpcyBjb21tdW5pY2F0aW9uIGlzIHN0cmlj dGx5DQpwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuICBJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIGNvbW11bmljYXRpb24NCmluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkgbm90aWZ5 IHRoZSBzZW5kZXIgYnkgcmVwbHkgZS1tYWlsIGFuZCBkZXN0cm95DQphbGwgY29waWVzIG9mIHRo ZSBjb21tdW5pY2F0aW9uIGFuZCBhbnkgYXR0YWNobWVudHMuDQo=