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

"Murphy, Sandra" <Sandra.Murphy@sparta.com> Tue, 17 July 2012 17:10 UTC

Return-Path: <Sandra.Murphy@sparta.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 0ABFE21F86B6; Tue, 17 Jul 2012 10:10:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.539
X-Spam-Level:
X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, 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 9UaVY16-dZmY; Tue, 17 Jul 2012 10:10:19 -0700 (PDT)
Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 5044E21F8644; Tue, 17 Jul 2012 10:10:19 -0700 (PDT)
Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q6HHArp1020411; Tue, 17 Jul 2012 12:10:53 -0500
Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q6HHAhtU024570; Tue, 17 Jul 2012 12:10:43 -0500
Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) with mapi id 14.01.0355.002; Tue, 17 Jul 2012 13:11:03 -0400
From: "Murphy, Sandra" <Sandra.Murphy@sparta.com>
To: Catherine A Meadows <meadows@itd.nrl.navy.mil>, Susan Hares <shares@ndzh.com>
Thread-Topic: [secdir] Spam:*******, Secdir Review of draft-ietf-idr-rfc4893bis-07 (resend of a resend)
Thread-Index: AQHNZDlkVkR3CiI/FU+b6CcBlhRHaZctr6Bb
Date: Tue, 17 Jul 2012 17:11:03 +0000
Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F625F32E50@Hermes.columbia.ads.sparta.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> <001701cd6433$6f7fd250$4e7f76f0$@ndzh.com> <50058CE0.5010108@cisco.com>, <A1419349-1781-4787-9273-4C9766154BC2@itd.nrl.navy.mil>
In-Reply-To: <A1419349-1781-4787-9273-4C9766154BC2@itd.nrl.navy.mil>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.185.63.118]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "secdir@ietf.org" <secdir@ietf.org>, "idr-chairs@tools.ietf.org" <idr-chairs@tools.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "John G. Scudder" <jgs@juniper.net>, "draft-ietf-idr-rfc4893bis.all@tools.ietf.org" <draft-ietf-idr-rfc4893bis.all@tools.ietf.org>, "stbryant@cisco.com" <stbryant@cisco.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 17:10:21 -0000

I agree with the sentiment that misconfigurations can not be forbidden.  An approach that outlined the results of such misbehavior as Adrian mentioned is OK with me, particularly if there's no way to prevent it.  (SIDR work for path validation would prevent it, I think.)

To John: if a behavior causes damage, I do not believe that attempting to characterize it as accidental/misconfiguration vs malicious is useful.  Would you be happy with a security protection that prevented malicious behavior but not accidents?  (If such a thing were possible.)  In this case, deliberate mis-configuration is just as easy as accidental misconfiguration and the same harm.

To Catherine: the mapping from 4-byte to 2-byte and vice versa is in section 3, the last two paragraphs.  John and Sue: is there an implication in "which are not mapped from two-octets" that if you have a mapable 4 byte AS number you just use the two-byte mapping of your 4 byte ASN rather than the AS_TRANS?

To John and Sue:  In section 4.1:

  The new attributes, AS4_PATH and AS4_AGGREGATOR MUST NOT be carried
   in an UPDATE message between NEW BGP speakers.  A NEW BGP speaker
   that receives the AS4_PATH attribute or the AS4_AGGREGATOR attribute
   in an UPDATE message from another NEW BGP speaker MUST discard the
   path attribute and continue processing the UPDATE message.

wrt "MUST discard the path attribute" - *which* path attribute?  AS_PATH or AS4_PATH?  I presume AS4_PATH, as that is what the paragraph says is forbidden.

To Sue: wrt confeds within confeds.  In the SIDR consideration of confeds, the statement was made that no one nests confeds.  Does your experience differ?  The answer is important to the work we're doing.

To John&Sue: I'm confused about the loop problem.  If a 4byteASN had a 2byteASN neighbor, that would result in AS_TRANS in the AS_PATH that the 2byteASN would receive.   If the update was propagated to another 4byteASN, it would use the AS4_PATH to remap the AS_TRANS to the right 4byteASN and could detect loops.  If the update propagated to a 2byteASN, there might be multiple appearances of AS_TRANS, which might look like a loop but would not actually be a loop (the update propagated through multiple 4byteASNs at different points.).  I'm not certain what implementations do.  The not-really-a-loop would not involve the receiving 2byteASN (unless it had been misconfigured with AS_TRANS as MyASN!).  Do implementations look further back in the AS_PATH as a clean-up activity?  Is the DOS that the 2b yteASNs might be dropping updates that were actually well-formed?  Sounds similar to the first problem with AS4_PATH that caused remote session cancellation, in this case it would be remote update drop.

--Sandy
________________________________________
From: secdir-bounces@ietf.org [secdir-bounces@ietf.org] on behalf of Catherine A Meadows [meadows@itd.nrl.navy.mil]
Sent: Tuesday, July 17, 2012 12:28 PM
To: Susan Hares
Cc: secdir@ietf.org; Murphy, Sandra; idr-chairs@tools.ietf.org; iesg@ietf.org; John G. Scudder; adrian@olddog.co.uk; draft-ietf-idr-rfc4893bis.all@tools.ietf.org; Catherine A Meadows; stbryant@cisco.com
Subject: Re: [secdir] Spam:*******,     Secdir Review of draft-ietf-idr-rfc4893bis-07 (resend of a resend)

Hi  Susan:

My apologies for not responding earlier.  I had been away from my email while traveling.

My question was not so much intended to recommend specific wording.  It was simply that I didn't
understand what "misconfiguration" meant in this context, because it isn't the usual terminology used in
IETF documents.  But as I understand it from the discussion,  configurations are not really part of the
standard, so we can't mandate them, and because of that, this is to be downgraded to a recommendation, as well as
being removed from the security consideration section.   So that answers my question.


As I understand from the discussion, the security risk of looping only is an issue if an attacker can cause it
to happen, in which case it can be used in a DOS attack.  So if there is no way an attacker could cause this
looping to happen, I'm happy to have it removed from the Security Considerations section.  Otherwise, I'd recommend
you refer to it in the Security Considerations section (even if it is described in detail in another section).

As to my other question, if there is no straightforward answer to it, there's no reason to discuss it in the document.

Hope this helps,

Cathy




On Jul 17, 2012, at 12:03 PM, Stewart Bryant 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

_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview