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

[Stewart Bryant <[e-mail]>]

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:[e-mail]]
> *Sent:* Monday, July 09, 2012 2:25 PM
> *To:* [e-mail]; [e-mail]; 
> [e-mail]
> *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: [phone]
> fax: [phone]
> email: [e-mail] 
> <mailto:[e-mail]>
>


-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html