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

["Adrian Farrel" <[e-mail]>]

Quibble away. It is what you are paid for.
I think you make a good point about the location of the text.
A

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of John
> G. Scudder
> Sent: 17 July 2012 15:38
> To: [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)
> 
> 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
> >
> >
> >