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