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

"Susan Hares" <shares@ndzh.com> Tue, 17 July 2012 15:46 UTC

Return-Path: <shares@ndzh.com>
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 6784321F8601; Tue, 17 Jul 2012 08:46:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 WkdW6BFqjOfe; Tue, 17 Jul 2012 08:46:28 -0700 (PDT)
Received: from hickoryhill-consulting.com (hhc-web.hickoryhill-consulting.com [64.9.205.140]) by ietfa.amsl.com (Postfix) with ESMTP id DD18921F85D4; Tue, 17 Jul 2012 08:46:27 -0700 (PDT)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=63.133.198.20;
Received: from SKH2012HPLT (unverified [63.133.198.20]) by hickoryhill-consulting.com (SurgeMail 5.2a) with ESMTP id 3460947-1945496 for multiple; Tue, 17 Jul 2012 11:47:14 -0400
From: "Susan Hares" <shares@ndzh.com>
To: <adrian@olddog.co.uk>, "'John G. Scudder'" <jgs@juniper.net>, <stbryant@cisco.com>
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>
In-Reply-To: <079e01cd6433$00f04b30$02d0e190$@olddog.co.uk>
Date: Tue, 17 Jul 2012 11:47:12 -0400
Message-ID: <001701cd6433$6f7fd250$4e7f76f0$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJKmuJjwEjeN+Alq24qu8oI3WgY1gDXd0BoAZu+ckcBR6c4qgLA7GuwApI1dQuV6sC0cA==
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
X-Mailman-Approved-At: Tue, 17 Jul 2012 08:47:19 -0700
Cc: secdir@ietf.org, "'Murphy, Sandra'" <Sandra.Murphy@sparta.com>, idr-chairs@tools.ietf.org, iesg@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 15:46:29 -0000

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