Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-threats-07.txt
Stephen Kent <kent@bbn.com> Wed, 16 October 2013 21:08 UTC
Return-Path: <kent@bbn.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B917E11E8208 for <sidr@ietfa.amsl.com>; Wed, 16 Oct 2013 14:08:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.494
X-Spam-Level:
X-Spam-Status: No, score=-106.494 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JI7K8w6tgkCC for <sidr@ietfa.amsl.com>; Wed, 16 Oct 2013 14:08:16 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id D441211E8183 for <sidr@ietf.org>; Wed, 16 Oct 2013 14:08:07 -0700 (PDT)
Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:52505) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1VWYK6-000FbF-C7; Wed, 16 Oct 2013 17:08:06 -0400
Message-ID: <525F0036.5000200@bbn.com>
Date: Wed, 16 Oct 2013 17:08:06 -0400
From: Stephen Kent <kent@bbn.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: "George, Wes" <wesley.george@twcable.com>
References: <2671C6CDFBB59E47B64C10B3E0BD5923043D13BD22@PRVPEXVS15.corp.twcable.com>
In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD5923043D13BD22@PRVPEXVS15.corp.twcable.com>
Content-Type: multipart/alternative; boundary="------------030200000107090409000406"
Cc: sidr <sidr@ietf.org>
Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-threats-07.txt
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Oct 2013 21:08:22 -0000
Wes, The following text extracted from your response provides a good basis for what will be my final reply in this exchange. > ... I believe the fact that you/the WG included it in the discussion > means that you/the WG believe that it's a threat. first, its an attack, not a threat. second, the topic was added to acknowledge that we are aware of such attacks, even though we have chosen to not address them now. period. > I could infer based on the fact that SIDR chose not to design > protections against that exploit that it's a real threat but very low > risk, or extremely difficult to exploit, or whatever, but the document > doesn't currently say anything about the relative level of risk for > the threat being identified. and, as I noted, such inferences would be unfounded. > You're right in that the design/requirements decisions that SIDR WG > made about whether to address that threat are mostly irrelevant, but > the fact that you discuss it in terms of design scope makes that > confusing if one is to evaluate this text as purely a threats analysis. I didn't say what you suggest immediately above. Route leaks and protection for other path attributes are included because they were discussed by the WG, and the WG chairs felt it was important to acknowledge that discussion, and note briefly why these topics will not be addressed. > It goes back to a recurring issue that has happened with the order of > these documents, where we're writing a threats doc and a requirements > doc based on an existing design rather than the other around, and are > tailoring these documents based on the current design to the exclusion > of things deemed out of scope instead of documenting everything and > then deciding some of the specific scope items in the > requirements/design phase. This seems to be the telling issue. You seem to be unhappy with the scope of the WG charter, and refuse to accept it as bounding for the work that is being performed. Your earlier comment refers to the charter as "arbitrary" suggesting an unwillingness to accept a charter as a a way to bound the scope of a WG. Steve
- Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-thr… George, Wes
- [sidr] I-D Action: draft-ietf-sidr-bgpsec-threats… internet-drafts
- Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-thr… Stephen Kent
- Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-thr… George, Wes
- Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-thr… Stephen Kent
- Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-thr… George, Wes
- Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-thr… Stephen Kent
- Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-thr… Andrei Robachevsky
- Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-thr… Stewart Bryant
- Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-thr… George, Wes