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

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

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]