Re: [secdir] Spam:*******, Secdir Review of draft-ietf-idr-rfc4893bis-07 (resend of a resend)

"John G. Scudder" <jgs@juniper.net> Tue, 17 July 2012 16:25 UTC

Return-Path: <jgs@juniper.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08A5D21F86B2; Tue, 17 Jul 2012 09:25:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.796
X-Spam-Level:
X-Spam-Status: No, score=-5.796 tagged_above=-999 required=5 tests=[AWL=-0.593, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
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 IUhrVW5ZMmCo; Tue, 17 Jul 2012 09:25:41 -0700 (PDT)
Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 5036321F8507; Tue, 17 Jul 2012 09:25:14 -0700 (PDT)
Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKUAWR9FcjATHiYZaxtQUyCvmtGjzb4gL7@postini.com; Tue, 17 Jul 2012 09:26:29 PDT
Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 17 Jul 2012 09:24:25 -0700
Received: from [172.19.168.5] ([172.19.168.5]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q6HGOHh87649; Tue, 17 Jul 2012 09:24:21 -0700 (PDT) (envelope-from jgs@juniper.net)
References: <9BA4B53E-9772-47D4-B336-3A98FAEB4045@nrl.navy.mil> <005401cd63aa$baeac2b0$30c04810$@ndzh.com> <5005132E.9000000@cisco.com> <F71E3EEE-3082-47F9-961C-7B78EED4A4A6@juniper.net> <001301cd6431$87944a30$96bcde90$@ndzh.com> <079e01cd6433$00f04b30$02d0e190$@olddog.co.uk> <001701cd6433$6f7fd250$4e7f76f0$@ndzh.com> <50058CE0.5010108@cisco.com>
In-Reply-To: <50058CE0.5010108@cisco.com>
MIME-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="us-ascii"
Message-ID: <FF8CF343-B2C4-4F22-B3CB-ED382000D79B@juniper.net>
X-Mailer: iPhone Mail (9B206)
From: "John G. Scudder" <jgs@juniper.net>
Date: Tue, 17 Jul 2012 09:24:10 -0700
To: "stbryant@cisco.com" <stbryant@cisco.com>
X-Mailman-Approved-At: Tue, 17 Jul 2012 10:04:53 -0700
Cc: "secdir@ietf.org" <secdir@ietf.org>, "Murphy, Sandra" <Sandra.Murphy@sparta.com>, "idr-chairs@tools.ietf.org" <idr-chairs@tools.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "draft-ietf-idr-rfc4893bis.all@tools.ietf.org" <draft-ietf-idr-rfc4893bis.all@tools.ietf.org>, Susan Hares <shares@ndzh.com>
Subject: Re: [secdir] Spam:*******, Secdir Review of draft-ietf-idr-rfc4893bis-07 (resend of a resend)
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Jul 2012 16:25:43 -0000

WFM. 

--John

On Jul 17, 2012, at 9:03 AM, Stewart Bryant <stbryant@cisco.com> wrote:

> It seems like a good suggestion to me
> 
> Stewart
> 
> On 17/07/2012 16:47, Susan Hares wrote:
>> Adrian:
>> 
>> 100% agree with your viewpoint and next steps.
>> 
>> John and Stuart - can we change to this view point.
>> 
>> Sue
>> 
>> -----Original Message-----
>> From: Adrian Farrel [mailto:adrian@olddog.co.uk]
>> Sent: Tuesday, July 17, 2012 11:44 AM
>> To: 'Susan Hares'; 'John G. Scudder'; stbryant@cisco.com
>> Cc: secdir@ietf.org; 'Murphy, Sandra'; idr-chairs@tools.ietf.org;
>> iesg@ietf.org; 'Catherine Meadows';
>> draft-ietf-idr-rfc4893bis.all@tools.ietf.org
>> Subject: RE: Spam:*******, Secdir Review of draft-ietf-idr-rfc4893bis-07
>> (resend of a resend)
>> 
>> IMHO, you are right Sue. Stating "MUST NOT" in a specification does not
>> prevent something from happening.
>> Using "MUST NOT" for a specification is fine because we can test for
>> conformance to that and strike an implementation that does not respect the
>> language.
>> Using "MUST NOT" in a description of an operator process is not as strong or
>> useful.
>> 
>> I think that "weakening" loop detection is a bad thing, but it is also a
>> price an operator might want to pay to get moved to 4byte AS numbers quickly
>> when a few corner boxes might take another 12 months to be upgraded.
>> 
>> I agree with John that the text is not security-related.
>> 
>> So, I would rephrase and reposition the text.
>> - Do explain the risk of switching to 4bytes before everyone is upgraded.
>> - Do explain the boundaries to the risk
>> - Do expect operators to consider the implications
>> - Don't mandate what an operator does in the privacy of their own bedroom
>> 
>> A
>> 
>> 
>> 
>>> -----Original Message-----
>>> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf
>>> Of Susan Hares
>>> Sent: 17 July 2012 16:34
>>> To: 'John G. Scudder'; stbryant@cisco.com
>>> Cc: secdir@ietf.org; 'Murphy, Sandra'; idr-chairs@tools.ietf.org;
>> iesg@ietf.org;
>>> 'Catherine Meadows'; draft-ietf-idr-rfc4893bis.all@tools.ietf.org
>>> Subject: RE: Spam:*******, Secdir Review of
>>> draft-ietf-idr-rfc4893bis-07
>> (resend
>>> of a resend)
>>> 
>>> John and Stuart:
>>> 
>>> This an acceptable text, and we can go on with this draft.
>>> 
>>> However,  my question to Catherine was substantive.  I wish to discuss
>>> with the Routing AD(s), Security people, and Benoit/Ron to understand
>>> the Routing/Operational issues.
>>> 
>>> "Must Not" configure is unrealistic.  People misconfigure. Yankee
>>> Group and other research houses places have indicated year-on-year
>>> 15-30% outages are caused by this misconfigured.  It's like the statement
>> "stuff happens."
>>> Stating "Must not" is like spitting into the wind.  You end up with
>>> stuff on your face.  What is the security area stating?  How does this
>>> review match with the path validation/security in SIDR.
>>> 
>>> Can we get Catherine or other security people to respond to my question?
>>> Cross-area review is useful to find wholes in our process and our
>>> assumptions.  I want to make sure I understand the valuable technical
>>> feedback the security review is providing.
>>> 
>>> 
>>> Sue
>>> 
>>> -----Original Message-----
>>> From: John G. Scudder [mailto:jgs@juniper.net]
>>> Sent: Tuesday, July 17, 2012 10:38 AM
>>> To: stbryant@cisco.com
>>> Cc: idr-chairs@tools.ietf.org; 'Catherine Meadows'; iesg@ietf.org;
>>> secdir@ietf.org; draft-ietf-idr-rfc4893bis.all@tools.ietf.org;
>>> 'Murphy, Sandra'
>>> Subject: Re: Spam:*******, Secdir Review of
>>> draft-ietf-idr-rfc4893bis-07 (resend of a resend)
>>> 
>>> Stewart,
>>> 
>>> I'm fine with the text you propose.
>>> 
>>> (I do find it a little odd to have this text -- either old or new --
>>> in the Security section since routing loops aren't normally though of
>>> as a security issue unless maliciously triggered -- which this one
>>> isn't described as being. So I would also be fine with changing the
>>> text but moving it to a different section. But that is quibbling.)
>>> 
>>> --John
>>> 
>>> On Jul 17, 2012, at 12:24 AM, Stewart Bryant wrote:
>>> 
>>>> Sue, John,
>>>> 
>>>> Is there any reason not to reword the text concerned to more
>>>> conventional format:
>>>> 
>>>> OLD
>>>> It is a misconfiguration to assign a non-mappable four-octet AS
>>>>    number as the "Member AS Number" in a BGP confederation before all
>>>>    the BGP speakers within the confederation have transitioned to
>>>>    support four-octet AS numbers.  Such a misconfiguration would weaken
>>>>    the AS path loop detection within a confederation.
>>>> 
>>>> NEW
>>>> 
>>>> A network operator MUST NOT assign a non-mappable four-octet AS
>>>> number as the "Member AS Number" in a BGP confederation before all
>>>> the BGP speakers within the confederation have transitioned to
>>>> support four-octet AS numbers, as such an assignment would weaken
>>>> the AS path loop detection within a confederation.
>>>> 
>>>> Stewart
>>>> 
>>>> On 17/07/2012 00:28, Susan Hares wrote:
>>>>> Catherine:
>>>>> 
>>>>> I've read and re-read this email for a week (7/9 - 7/16).
>>>>> 
>>>>> Misconfiguration is a fact of life in networks.  Security profiles
>>>>> must
>>> deal with this point.  We can all say you should not misconfigure
>>> networks - but life happens.  Therefore,  I'm confused by your
>>> question.  I would consider it is just a security event the authors
>> pointing happens.
>>>>> On your second comment
>>>>> 
>>>>> "I would also expect that the chance of routing loops arising out
>>>>> conversion from 4-octet to 2-octet occurring between confederations
>>>>> would be much less than of their occurring within a confederation
>>>>> (although one can't know for sure without knowing what the 4-octet
>>>>> to 2-octet mapping is), so following the recommendations in the
>>>>> Security Considerations would greatly reduce the probability of
>>>>> such a routing loop occurring.  Is this correct? "
>>>>> 
>>>>> It depends if someone configures a confederation within a
>> confederation.
>>> [see earlier comment on mis-configuration.] I've copied Sandy Murphy
>>> in case as SIDR chair can put this discussion into a different
>>> "security" specific light.
>>>>> Confused,
>>>>> 
>>>>> Sue
>>>>> 
>>>>> 
>>>>> From: Catherine Meadows [mailto:catherine.meadows@nrl.navy.mil]
>>>>> Sent: Monday, July 09, 2012 2:25 PM
>>>>> To: iesg@ietf.org; secdir@ietf.org;
>>>>> draft-ietf-idr-rfc4893bis.all@tools.ietf.org
>>>>> Cc: Catherine Meadows
>>>>> Subject: Spam:*******, Secdir Review of
>>>>> draft-ietf-idr-rfc4893bis-07 (resend of a resend)
>>>>> 
>>>>> I managed to screw up the email address again.  Here it is for what
>>>>> I
>>> hope is the last time.
>>>>> My apologies again to everyone who receives *three* copies of this
>>> message.
>>>>> I have reviewed this document as part of the security directorate's
>>>>> ongoing effort to review all IETF documents being processed by the
>>>>> IESG.  These comments were written primarily for the benefit of the
>>>>> security area directors.  Document editors and WG chairs should
>>>>> treat these comments just like any other last call comments.
>>>>> 
>>>>> This document describes an added capability for four-octet
>>>>> Autonomous System
>>>>> (AS) numbers in BGP.  This is intended to  replace the older
>>>>> two-octet AS numbers, since that space is filling up.
>>>>> 
>>>>> In order to preserve backward compatibility, AS's using the
>>>>> four-octet systems (called New BGP speakers in the document) must
>>> advertise both four-octet and two-octet AS numbers.
>>>>> This is the case even if the New BGP Speaker does not have a
>>>>> globally
>>> unique two-octet number.
>>>>> The document says that in this case the two-octet number is
>>>>> obtained by mapping the four-octet number to the two-octet space.
>>>>> The procedure
>>> for doing this is not specified.
>>>>> The authors identify a risk of routing loops developing when
>>>>> ambiguities develops as a result of a BGP speaker using the old
>>>>> system aggregating two or more routes carrying 4-octet attributes.
>>>>> In the Security Configurations Section, the authors point out that
>>>>> an attacker might be able to exploit this in a denial of service
>> attack.
>>>>> They point out that it is a misconfiguration to assign 4-octet
>>>>> Member AS
>>> Numbers in a BGP confederation until all BGP speakers within the
>>> confederation have transitioned to support 4-octet numbers.
>>>>> I think that this is a good recommendation.  I just have a couple
>>>>> of
>>> minor comments.
>>>>> It's not clear to me what the status of "misconfiguration" is in
>>>>> the
>>> hierarchy of IETF.
>>>>> Is it more like SHALL NOT or SHOULD NOT?  Is there a reason why
>>>>> you're saying "misconfiguration" instead of one of those?
>>>>> 
>>>>> I would also expect that the chance of routing loops arising out
>>>>> conversion from 4-octet to 2-octet occurring between confederations
>>>>> would be much less than of their occurring within a confederation
>>>>> (although one can't know for sure without knowing what the 4-octet
>>>>> to 2-octet mapping is), so following the recommendations in the
>>>>> Security
>>> Considerations would greatly reduce the probability of such a routing
>>> loop occurring.  Is this correct?
>>>>> Cathy Meadows
>>>>> Catherine Meadows
>>>>> Naval Research Laboratory
>>>>> Code 5543
>>>>> 4555 Overlook Ave., S.W.
>>>>> Washington DC, 20375
>>>>> phone: 202-767-3490
>>>>> fax: 202-404-7942
>>>>> email: catherine.meadows@nrl.navy.mil
>>>>> 
>>>> 
>>>> --
>>>> For corporate legal information go to:
>>>> 
>>>> 
>>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>>>> 
>>>> 
>>>> 
>> 
>> 
>> .
>> 
> 
> 
> -- 
> For corporate legal information go to:
> 
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>