Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs

"George, Wes" <wesley.george@twcable.com> Fri, 24 January 2014 16:15 UTC

Return-Path: <wesley.george@twcable.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 977F31A0037 for <sidr@ietfa.amsl.com>; Fri, 24 Jan 2014 08:15:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.3
X-Spam-Level:
X-Spam-Status: No, score=-0.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vUA7iV3W89n for <sidr@ietfa.amsl.com>; Fri, 24 Jan 2014 08:15:44 -0800 (PST)
Received: from cdcipgw02.twcable.com (cdcipgw02.twcable.com [165.237.91.111]) by ietfa.amsl.com (Postfix) with ESMTP id 437C81A0010 for <sidr@ietf.org>; Fri, 24 Jan 2014 08:15:44 -0800 (PST)
X-SENDER-IP: 10.136.163.11
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="4.95,713,1384318800"; d="scan'208";a="58704510"
Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdcipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 24 Jan 2014 11:15:16 -0500
Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Fri, 24 Jan 2014 11:15:42 -0500
From: "George, Wes" <wesley.george@twcable.com>
To: Warren Kumari <warren@kumari.net>
Date: Fri, 24 Jan 2014 11:15:41 -0500
Thread-Topic: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs
Thread-Index: Ac8ZH4dfm5MM00eYTaCxYhQqEd5RGQ==
Message-ID: <CF07F97A.AFC8%wesley.george@twcable.com>
References: <52D072F6.9030304@ops-netman.net> <52D0A0AC.5040903@ops-netman.net> <CF07E61E.AF86%wesley.george@twcable.com> <CAHw9_iL94_h7xyncvsbpxrmNMdH2jLJV5-ir5tdpnVUVidEwnQ@mail.gmail.com>
In-Reply-To: <CAHw9_iL94_h7xyncvsbpxrmNMdH2jLJV5-ir5tdpnVUVidEwnQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.9.131030
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "draft-ietf-sidr-bgpsec-reqs@tools.ietf.org" <draft-ietf-sidr-bgpsec-reqs@tools.ietf.org>, sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 24 Jan 2014 16:15:45 -0000

On 1/24/14, 10:04 AM, "Warren Kumari" <warren@kumari.net> wrote:


>Would simply:
>"issues of business relationship conformance (of which routing 'leaks'
>are a subset), while important to operators, are outside the scope of
>this document.”
>
>cover things well enough?

It would at least address the concern about declaring them not to be
security concerns, and is enough for the intro, IMO

>
>>My issue with this text is the reason it provides as to why they’re
>> considered out of scope. I don’t think that it’s entirely accurate to
>> assert that route leaks are not security issues. While not all route
>>leaks
>> are security issues, some are. It would be more accurate to reflect the
>> discussion that led us to the conclusion that we can’t secure them
>>because
>> we don’t know what “them” is yet, and are awaiting GROW to define them
>>in
>> such a way so that we can evaluate if it’s even possible to secure them
>>in
>> this framework. That may be a longer discussion that doesn’t belong in
>>the
>> intro, I don’t know.
>>
>
>I suspect it is. It somewhat seems like a non-terminating discussion....

I think it might be appropriate to add a new req in the form of req 3.3 to
explain why this is out of scope, or bolster 3.22 to expand on intent as
it relates to this, perhaps with some reference to the fact that route
leaks are currently not well-enough defined to consistently (and more
importantly, systematically) identify them and secure the right BGP
attributes to help prevent them

Thanks
Wes


This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.