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 14:38 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 BB46621F85CE; Tue, 17 Jul 2012 07:38:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.49
X-Spam-Level:
X-Spam-Status: No, score=-6.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, 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 tHKrw22jbXjc; Tue, 17 Jul 2012 07:38:29 -0700 (PDT)
Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 9158C21F85C2; Tue, 17 Jul 2012 07:38:15 -0700 (PDT)
Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKUAV5B8s6cD/1XhytBxDms9ECglAoUvgJ@postini.com; Tue, 17 Jul 2012 07:39:17 PDT
Received: from sa-nc-finance-32.static.jnpr.net (172.23.5.32) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Tue, 17 Jul 2012 07:37:31 -0700
MIME-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset="windows-1252"
From: "John G. Scudder" <jgs@juniper.net>
In-Reply-To: <5005132E.9000000@cisco.com>
Date: Tue, 17 Jul 2012 07:37:31 -0700
Content-Transfer-Encoding: quoted-printable
Message-ID: <F71E3EEE-3082-47F9-961C-7B78EED4A4A6@juniper.net>
References: <9BA4B53E-9772-47D4-B336-3A98FAEB4045@nrl.navy.mil> <005401cd63aa$baeac2b0$30c04810$@ndzh.com> <5005132E.9000000@cisco.com>
To: "stbryant@cisco.com" <stbryant@cisco.com>
X-Mailer: Apple Mail (2.1278)
X-Mailman-Approved-At: Tue, 17 Jul 2012 07:39:56 -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>, "draft-ietf-idr-rfc4893bis.all@tools.ietf.org" <draft-ietf-idr-rfc4893bis.all@tools.ietf.org>
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 14:38:30 -0000

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
> 
> 
>