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

["Susan Hares" <[e-mail]>]

John and Stuart: 

Please substitute in the message below: 

/"wholes"/"holes"/  - the implied malapropism turn of phrase was a bit too
vague for multi-cultural environment with non-native speakers.  My
malapropism implied that we find the "whole truth" as well as "holes" in our
work from cross-area review. 

Sometimes writing to intelligent people (such as you and John) inspires my
creative writing skills and ironic tones. 

Sorry, 

Sue 

-----Original Message-----
From: Susan Hares [mailto:[e-mail]] 
Sent: Tuesday, July 17, 2012 11:34 AM
To: 'John G. Scudder'; [e-mail]
Cc: [e-mail]; 'Catherine Meadows'; [e-mail];
[e-mail]; [e-mail]; 'Murphy,
Sandra'
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:[e-mail]]
Sent: Tuesday, July 17, 2012 10:38 AM
To: [e-mail]
Cc: [e-mail]; 'Catherine Meadows'; [e-mail];
[e-mail]; [e-mail]; '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:[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]
>>  
> 
> 
> --
> For corporate legal information go to:
> 
> 
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
> 
> 
>