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

[Stewart Bryant <[e-mail]>]

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:[e-mail]]
> Sent: Tuesday, July 17, 2012 11:44 AM
> To: 'Susan Hares'; 'John G. Scudder'; [e-mail]
> Cc: [e-mail]; 'Murphy, Sandra'; [e-mail];
> [e-mail]; 'Catherine Meadows';
> [e-mail]
> 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: [e-mail] [mailto:[e-mail]] On Behalf
>> Of Susan Hares
>> Sent: 17 July 2012 16:34
>> To: 'John G. Scudder'; [e-mail]
>> Cc: [e-mail]; 'Murphy, Sandra'; [e-mail];
> [e-mail];
>> 'Catherine Meadows'; [e-mail]
>> 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
>>>
>>>
>>>
>
>
> .
>


-- 
For corporate legal information go to:

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