Subject: [secdir] Secdir Review of draft-ietf-idr-rfc4893bis-07 (resend of a resend)

From: Catherine Meadows <[email-masked]>
Date: Mon, 9 Jul 2012 14:24:58 -0400

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: 202-767-3490
fax: 202-404-7942
email: [email-masked]

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 16 Jul 2012 19:28:37 -0400

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:[email-masked]] 
Sent: Monday, July 09, 2012 2:25 PM
To: [email-masked]; [email-masked];
[email-masked]
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.

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

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 17 Jul 2012 08:24:30 +0100

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
> 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:[email-masked]]
> *Sent:* Monday, July 09, 2012 2:25 PM
> *To:* [email-masked]; [email-masked]; 
> *Cc:* Catherine Meadows
> *Subject:* Spam:*******, Secdir Review of draft-ietf-idr-rfc4893bis-07 
> (resend of a resend)
>
> <mailto:[email-masked]>
>

-- 
For corporate legal information go to:

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

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 17 Jul 2012 07:37:31 -0700

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:

>> 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
>> 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
>>  
>>  
>> To: [email-masked]; [email-masked]; [email-masked]
>> Cc: Catherine Meadows
>> Subject: Spam:*******, Secdir Review of draft-ietf-idr-rfc4893bis-07 (resend of a resend)
>>

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 17 Jul 2012 15:44:24 +0100

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: [email-masked] [mailto:[email-masked]] On Behalf Of John
> G. Scudder
> Sent: 17 July 2012 15:38
> To: [email-masked]
> Cc: [email-masked]; 'Murphy, Sandra'; [email-masked];
[email-masked];
> 'Catherine Meadows'; [email-masked]
> Subject: Re: Spam:*******, Secdir Review of draft-ietf-idr-rfc4893bis-07
(resend
> (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
> 
> >> 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
> >>
conversion
correct?
> "
as
> SIDR chair can put this discussion into a different "security" specific light.
> >>
> >> Confused,
> >>
> >> Sue
> >>
> >>
> >> I managed to screw up the email address again.  Here it is for what I hope
is
> the last time.
systems
> (called New
specified.
> >> 4-octet attributes.  In the Security Configurations Section, the authors
point
> out that an
point
> out that it is
hierarchy of
> IETF.
correct?

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 17 Jul 2012 16:44:07 +0100

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

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Susan
> Hares
> Sent: 17 July 2012 16:34
> To: 'John G. Scudder'; [email-masked]
[email-masked];
> 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
> 
> From: John G. Scudder [mailto:[email-masked]]
> Sent: Tuesday, July 17, 2012 10:38 AM
> To: [email-masked]
> Cc: [email-masked]; 'Catherine Meadows'; [email-masked];
> [email-masked]; [email-masked]; 'Murphy,
> Sandra'
> 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
> 
> > 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
> >
> 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
> >>
> >> 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? "
> >>
> >> (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.
> >> 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.
> >>
> >> 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

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 17 Jul 2012 11:33:34 -0400

John and Stuart:

Sue 

-----Original Message-----
From: John G. Scudder [mailto:[email-masked]] 
Sent: Tuesday, July 17, 2012 10:38 AM
To: [email-masked]
Cc: [email-masked]; 'Catherine Meadows'; [email-masked];

Stewart,

--John

hierarchy of IETF.

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 17 Jul 2012 11:44:37 -0400

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:[email-masked]] 
Sent: Tuesday, July 17, 2012 11:34 AM
To: 'John G. Scudder'; [email-masked]
Cc: [email-masked]; 'Catherine Meadows'; [email-masked];

John and Stuart:

Sue 

-----Original Message-----
From: John G. Scudder [mailto:[email-masked]]
Sent: Tuesday, July 17, 2012 10:38 AM
To: [email-masked]
Cc: [email-masked]; 'Catherine Meadows'; [email-masked];

Stewart,

--John

>> must
hierarchy of IETF.

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 17 Jul 2012 11:47:12 -0400

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:[email-masked]] 
Sent: Tuesday, July 17, 2012 11:44 AM
To: 'Susan Hares'; 'John G. Scudder'; [email-masked]
Cc: [email-masked]; 'Murphy, Sandra'; [email-masked];
[email-masked]; 'Catherine Meadows';
[email-masked]
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. 

A

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Susan Hares
> Sent: 17 July 2012 16:34
[email-masked];
(resend
> 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.
> 
> [email-masked]; [email-masked]; 
> 'Murphy, Sandra'
> Subject: Re: Spam:*******, Secdir Review of 
> draft-ietf-idr-rfc4893bis-07 (resend of a resend)
> 
> Stewart,
> 
> (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
> 
> deal with this point.  We can all say you should not misconfigure 
> networks - but life happens.  Therefore,  I'm confused by your 
pointing happens.
> >> (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? "
> >>
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
> >>
> >>
> >> 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.
> >> security area directors.  Document editors and WG chairs should 
> >> treat these comments just like any other last call comments.
> >>
> >> 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
> >> In the Security Configurations Section, the authors point out that 
> >> an attacker might be able to exploit this in a denial of service
attack.
> >> I think that this is a good recommendation.  I just have a couple 
> >> of
> minor comments.
> >>
> >> (although one can't know for sure without knowing what the 4-octet 
> loop occurring.  Is this correct?
> >>
> >> Cathy Meadows
> >> Catherine Meadows

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 17 Jul 2012 17:03:44 +0100

It seems like a good suggestion to me

Stewart

On 17/07/2012 16:47, Susan Hares wrote:
> .

---

From: Catherine A Meadows <[email-masked]>
Date: Tue, 17 Jul 2012 12:28:48 -0400

Hi  Susan:

My apologies for not responding earlier.  I had been away from my email while traveling.

My question was not so much intended to recommend specific wording.  It was simply that I didn't
understand what "misconfiguration" meant in this context, because it isn't the usual terminology used in
IETF documents.  But as I understand it from the discussion,  configurations are not really part of the
standard, so we can't mandate them, and because of that, this is to be downgraded to a recommendation, as well as
being removed from the security consideration section.   So that answers my question.

As I understand from the discussion, the security risk of looping only is an issue if an attacker can cause it
to happen, in which case it can be used in a DOS attack.  So if there is no way an attacker could cause this
looping to happen, I'm happy to have it removed from the Security Considerations section.  Otherwise, I'd recommend
you refer to it in the Security Considerations section (even if it is described in detail in another section).  

As to my other question, if there is no straightforward answer to it, there's no reason to discuss it in the document.

Hope this helps,

Cathy

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 17 Jul 2012 12:34:08 -0400

Catherine:

An attacker with access to a trusted BGP router at the right point in the
network could cause this problem.  I suggest you discuss this point with
Sandy Murphy who has listen to operators on these issues and can speak
"security"  dialect. 

This is for your general information.  See Adrian solution for the right
viewpoint.

Sue 

-----Original Message-----
From: Catherine A Meadows [mailto:[email-masked]] 
Sent: Tuesday, July 17, 2012 12:29 PM
To: Susan Hares
Cc: Catherine A Meadows; [email-masked]; John G. Scudder;
[email-masked]; [email-masked]; Murphy, Sandra;
[email-masked]; [email-masked]; Catherine Meadows;
[email-masked]
Subject: Spam:*******, Re: Spam:*******, Secdir Review of
draft-ietf-idr-rfc4893bis-07 (resend of a resend)

Hi  Susan:

My apologies for not responding earlier.  I had been away from my email
while traveling.

My question was not so much intended to recommend specific wording.  It was
simply that I didn't understand what "misconfiguration" meant in this
context, because it isn't the usual terminology used in IETF documents.  But
as I understand it from the discussion,  configurations are not really part
of the standard, so we can't mandate them, and because of that, this is to
be downgraded to a recommendation, as well as
being removed from the security consideration section.   So that answers my
question.

As I understand from the discussion, the security risk of looping only is an
issue if an attacker can cause it to happen, in which case it can be used in
a DOS attack.  So if there is no way an attacker could cause this looping to
happen, I'm happy to have it removed from the Security Considerations
section.  Otherwise, I'd recommend you refer to it in the Security
Considerations section (even if it is described in detail in another
section).  

As to my other question, if there is no straightforward answer to it,
there's no reason to discuss it in the document.

Hope this helps,

Cathy

On Jul 17, 2012, at 12:03 PM, Stewart Bryant wrote:

>> Subject: RE: Spam:*******, Secdir Review of 
>> IMHO, you are right Sue. Stating "MUST NOT" in a specification does 
>> not prevent something from happening.
>> 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.
>>> 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.
>>> 
>>> stuff on your face.  What is the security area stating?  How does 
>>> this review match with the path validation/security in SIDR.
>>> 
>>> assumptions.  I want to make sure I understand the valuable 
>>> technical feedback the security review is providing.
>>> 
>>> 
>>> Sue
>>> 
>>> 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
>>> 
>>>>> 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? "
>>>>> I managed to screw up the email address again.  Here it is for 
>>>>> what I
>>> hope is the last time.
>>>>> 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.
>>>>> 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

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 17 Jul 2012 09:24:10 -0700

WFM. 

--John

On Jul 17, 2012, at 9:03 AM, Stewart Bryant <[email-masked]> wrote:

>>> draft-ietf-idr-rfc4893bis-07
>> (resend
>>> of a resend)
>>> 
>>> John and Stuart:
>>>

---

From: "Murphy, Sandra" <[email-masked]>
Date: Tue, 17 Jul 2012 17:11:03 +0000

I agree with the sentiment that misconfigurations can not be forbidden.  An approach that outlined the results of such misbehavior as Adrian mentioned is OK with me, particularly if there's no way to prevent it.  (SIDR work for path validation would prevent it, I think.)

To John: if a behavior causes damage, I do not believe that attempting to characterize it as accidental/misconfiguration vs malicious is useful.  Would you be happy with a security protection that prevented malicious behavior but not accidents?  (If such a thing were possible.)  In this case, deliberate mis-configuration is just as easy as accidental misconfiguration and the same harm.

To Catherine: the mapping from 4-byte to 2-byte and vice versa is in section 3, the last two paragraphs.  John and Sue: is there an implication in "which are not mapped from two-octets" that if you have a mapable 4 byte AS number you just use the two-byte mapping of your 4 byte ASN rather than the AS_TRANS?

To John and Sue:  In section 4.1:

  The new attributes, AS4_PATH and AS4_AGGREGATOR MUST NOT be carried
   in an UPDATE message between NEW BGP speakers.  A NEW BGP speaker
   that receives the AS4_PATH attribute or the AS4_AGGREGATOR attribute
   in an UPDATE message from another NEW BGP speaker MUST discard the
   path attribute and continue processing the UPDATE message.

wrt "MUST discard the path attribute" - *which* path attribute?  AS_PATH or AS4_PATH?  I presume AS4_PATH, as that is what the paragraph says is forbidden.

To Sue: wrt confeds within confeds.  In the SIDR consideration of confeds, the statement was made that no one nests confeds.  Does your experience differ?  The answer is important to the work we're doing.

To John&Sue: I'm confused about the loop problem.  If a 4byteASN had a 2byteASN neighbor, that would result in AS_TRANS in the AS_PATH that the 2byteASN would receive.   If the update was propagated to another 4byteASN, it would use the AS4_PATH to remap the AS_TRANS to the right 4byteASN and could detect loops.  If the update propagated to a 2byteASN, there might be multiple appearances of AS_TRANS, which might look like a loop but would not actually be a loop (the update propagated through multiple 4byteASNs at different points.).  I'm not certain what implementations do.  The not-really-a-loop would not involve the receiving 2byteASN (unless it had been misconfigured with AS_TRANS as MyASN!).  Do implementations look further back in the AS_PATH as a clean-up activity?  Is the DOS that the 2b yteASNs might be dropping updates that were actually well-formed?  Sounds similar to the first problem with AS4_PATH that caused remote session cancellation, in this case it would be remote update drop.

--Sandy
________________________________________
From: [email-masked] [[email-masked]] on behalf of Catherine A Meadows [[email-masked]]
Sent: Tuesday, July 17, 2012 12:28 PM
To: Susan Hares
Cc: [email-masked]; Murphy, Sandra; [email-masked]; [email-masked]; John G. Scudder; [email-masked]; [email-masked]; Catherine A Meadows; [email-masked]
Subject: Re: [secdir] Spam:*******,     Secdir Review of draft-ietf-idr-rfc4893bis-07 (resend of a resend)

Hi  Susan:

Hope this helps,

Cathy

>>>>> email: [email-masked]

_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 17 Jul 2012 13:46:11 -0400

Sandy and John: 

For just my input:

1. Adrian's behavior - ok with me
2.  security - Glad to hear from chance and malicious misconfiguration in
this view 
3. "not mapped from two octets" - your assumption from the draft - below
matches my understanding;  I'll wait for John's comment.  Maybe my memory is
failing (smile). 

John and Sue: is there an implication in "which are not mapped from
two-octets" that if you have a mapable 4 byte AS number you just use the
two-byte mapping of your 4 byte ASN rather than the AS_TRANS?

4. Agreed it is unclear.  My understanding it is AS4_PATH and/or
AS4_AGGREGATOR. 

wrt "MUST discard the path attribute" - *which* path attribute?  AS_PATH or
AS4_PATH?  I presume AS4_PATH, as that is what the paragraph says is
forbidden.

- Again,  I will await John and the authors (Enke) for additional comments. 

Thank you for taking time to review this draft.

Sue Hares

-----Original Message-----
From: Murphy, Sandra [mailto:[email-masked]] 
Sent: Tuesday, July 17, 2012 1:11 PM
To: Catherine A Meadows; Susan Hares
Cc: [email-masked]; [email-masked]; [email-masked]; John G.
Scudder; [email-masked]; [email-masked];
[email-masked]
Subject: RE: [secdir] Spam:*******, Secdir Review of
draft-ietf-idr-rfc4893bis-07 (resend of a resend)

I agree with the sentiment that misconfigurations can not be forbidden.  An
approach that outlined the results of such misbehavior as Adrian mentioned
is OK with me, particularly if there's no way to prevent it.  (SIDR work for
path validation would prevent it, I think.)

To John: if a behavior causes damage, I do not believe that attempting to
characterize it as accidental/misconfiguration vs malicious is useful.
Would you be happy with a security protection that prevented malicious
behavior but not accidents?  (If such a thing were possible.)  In this case,
deliberate mis-configuration is just as easy as accidental misconfiguration
and the same harm.

To Catherine: the mapping from 4-byte to 2-byte and vice versa is in section
3, the last two paragraphs.  John and Sue: is there an implication in "which
are not mapped from two-octets" that if you have a mapable 4 byte AS number
you just use the two-byte mapping of your 4 byte ASN rather than the
AS_TRANS?

wrt "MUST discard the path attribute" - *which* path attribute?  AS_PATH or
AS4_PATH?  I presume AS4_PATH, as that is what the paragraph says is
forbidden.

To Sue: wrt confeds within confeds.  In the SIDR consideration of confeds,
the statement was made that no one nests confeds.  Does your experience
differ?  The answer is important to the work we're doing.

To John&Sue: I'm confused about the loop problem.  If a 4byteASN had a
2byteASN neighbor, that would result in AS_TRANS in the AS_PATH that the
2byteASN would receive.   If the update was propagated to another 4byteASN,
it would use the AS4_PATH to remap the AS_TRANS to the right 4byteASN and
could detect loops.  If the update propagated to a 2byteASN, there might be
multiple appearances of AS_TRANS, which might look like a loop but would not
actually be a loop (the update propagated through multiple 4byteASNs at
different points.).  I'm not certain what implementations do.  The
not-really-a-loop would not involve the receiving 2byteASN (unless it had
been misconfigured with AS_TRANS as MyASN!).  Do implementations look
further back in the AS_PATH as a clean-up activity?  Is the DOS that the 2b
yteASNs might be dropping updates that were actually well-formed?  Sounds
similar to the first problem with AS4_PATH that caused remote session
cancellation, in this case it would be remote update drop.

--Sandy
________________________________________
From: [email-masked] [[email-masked]] on behalf of
Catherine A Meadows [[email-masked]]
Sent: Tuesday, July 17, 2012 12:28 PM
To: Susan Hares
Cc: [email-masked]; Murphy, Sandra; [email-masked];
[email-masked]; John G. Scudder; [email-masked];
[email-masked]; Catherine A Meadows;
[email-masked]
Subject: Re: [secdir] Spam:*******,     Secdir Review of
draft-ietf-idr-rfc4893bis-07 (resend of a resend)

Hi  Susan:

Hope this helps,

Cathy

be upgraded.
correct? "
comments.

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 17 Jul 2012 13:40:48 -0700

On Jul 17, 2012, at 10:11 AM, Murphy, Sandra wrote:
...
> To John: if a behavior causes damage, I do not believe that attempting to characterize it as accidental/misconfiguration vs malicious is useful.  Would you be happy with a security protection that…

No argument, but if we put any condition that can cause incorrect behavior in-scope for Security Considerations, those sections are going to get Awfully Big. I think practically speaking we have arrived at a simple modification to this section so we can probably move forward.

...
> wrt "MUST discard the path attribute" - *which* path attribute?  AS_PATH or AS4_PATH?  I presume AS4_PATH, as that is what the paragraph says is forbidden.

I guess there is some small ambiguity here though it was clear to me that AS4_* is intended. Let's make whatever edit is sufficient to remove the ambiguity. How about "MUST discard that path attribute"?

> To Sue: wrt confeds within confeds.  In the SIDR consideration of confeds, the statement was made that no one nests confeds.  Does your experience differ?  The answer is important to the work we're…

Speaking as co-author of the current confeds spec, it is simply not possible to nest confeds. 

> To John&Sue: I'm confused about the loop problem.  If a 4byteASN had a 2byteASN neighbor, that would result in AS_TRANS in the AS_PATH that the 2byteASN would receive.   If the update was propagate…

The loop scenario of concern derives from this:

   A NEW BGP speaker that receives a malformed AS4_PATH attribute in an
   UPDATE message from an OLD BGP speaker MUST discard the attribute,
   and continue processing the UPDATE message.

This makes it explicitly possible that some ASes may be lost from the path, e.g. suppose you have "old" and "new" ASes in the path as follows ("new" ASes are six-digit, "old" are three-digit) and we are considering routes to destination prefix "dest"

  200000 -- 100 -- 200 -- 300000 -- 400000 -- dest

What AS 200000 would expect to see in advertisements from 100 would be a path like

  100, 200, 23456, 23456 (recall that 23456 is AS_TRANS)

along with an AS4_PATH that carries 300000 and 400000. But if the AS4_PATH is corrupt, the final two ASes will remain 23456 forever and never have 300000 and 400000 substituted back in. Thus if we actually had the topology

  200000 -- 100 -- 200 -- 300000 -- 400000 -- dest
     |                                 |
     +---------------------------------+

We could have 200000 send routes back to 400000 and not have them loop-detected as they ought to be. In this case it is *likely* that the loop would be broken eventually when the route made it back to AS 200, the loop would be detected there, and the loop would unwind. There are pathological cases possible though, for example:

  200000 -- 100 -- 200 -- 300000 -- 400000 -- dest
     |                       |
     +-----------------------+

Suppose 300000 has a policy to prefer routes from 200000 over those from 400000. In the malformed AS4_PATH scenario, a persistent routing oscillation would ensue, as 300000 selected the route with AS_PATH 200000, 100, 200, 23456, 23456 (remember this is due to a corrupt AS4_PATH) over that with AS_PATH 400000 and propagated it to AS 200 which would loop-detect and withdraw it. 

--John

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 17 Jul 2012 19:18:37 -0400

John and Sandy: 

Agree with your points: 

Ack- security status - ok,
Ack - AS-4* - ok
Ack - proper AS Confederation per spec - no nesting by design.  Outside of
spec -not our problem.
Ack = loop scenario matches my understanding of loop

Do we need any more changes? I do not think so. 

Sue 

-----Original Message-----
From: John G. Scudder [mailto:[email-masked]] 
Sent: Tuesday, July 17, 2012 4:41 PM
To: Murphy, Sandra
Cc: Catherine A Meadows; Susan Hares; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [secdir] Spam:*******, Secdir Review of
draft-ietf-idr-rfc4893bis-07 (resend of a resend)

No argument, but if we put any condition that can cause incorrect behavior
in-scope for Security Considerations, those sections are going to get
Awfully Big. I think practically speaking we have arrived at a simple
modification to this section so we can probably move forward.

...
> wrt "MUST discard the path attribute" - *which* path attribute?  AS_PATH
or AS4_PATH?  I presume AS4_PATH, as that is what the paragraph says is
forbidden.

I guess there is some small ambiguity here though it was clear to me that
AS4_* is intended. Let's make whatever edit is sufficient to remove the
ambiguity. How about "MUST discard that path attribute"?

Speaking as co-author of the current confeds spec, it is simply not possible
to nest confeds. 

This makes it explicitly possible that some ASes may be lost from the path,
e.g. suppose you have "old" and "new" ASes in the path as follows ("new"
ASes are six-digit, "old" are three-digit) and we are considering routes to
destination prefix "dest"

What AS 200000 would expect to see in advertisements from 100 would be a
path like

along with an AS4_PATH that carries 300000 and 400000. But if the AS4_PATH
is corrupt, the final two ASes will remain 23456 forever and never have
300000 and 400000 substituted back in. Thus if we actually had the topology

We could have 200000 send routes back to 400000 and not have them
loop-detected as they ought to be. In this case it is *likely* that the loop
would be broken eventually when the route made it back to AS 200, the loop
would be detected there, and the loop would unwind. There are pathological
cases possible though, for example:

Suppose 300000 has a policy to prefer routes from 200000 over those from
400000. In the malformed AS4_PATH scenario, a persistent routing oscillation
would ensue, as 300000 selected the route with AS_PATH 200000, 100, 200,
23456, 23456 (remember this is due to a corrupt AS4_PATH) over that with
AS_PATH 400000 and propagated it to AS 200 which would loop-detect and
withdraw it. 

--John

while traveling.
> 
> My question was not so much intended to recommend specific wording.  
> It was simply that I didn't understand what "misconfiguration" meant 
> in this context, because it isn't the usual terminology used in IETF 
> documents.  But as I understand it from the discussion,  configurations
are not really part of the standard, so we can't mandate them, and because
of that, this is to be downgraded to a recommendation, as well as
> As I understand from the discussion, the security risk of looping only 
> is an issue if an attacker can cause it to happen, in which case it 
> can be used in a DOS attack.  So if there is no way an attacker could 
> cause this looping to happen, I'm happy to have it removed from the
Security Considerations section.  Otherwise, I'd recommend you refer to it
in the Security Considerations section (even if it is described in detail in
another section).
be upgraded.
>>>> From: [email-masked] [mailto:[email-masked]] On 
>>>> Behalf Of Susan Hares
>>>> Sent: 17 July 2012 16:34
>>>> (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
>>>> 
>>>>>> confederations would be much less than of their occurring within 
>>>>>> a confederation (although one can't know for sure without knowing 
correct? "
>>>> [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
>>>>>> 
>>>>>> 
>>>>>> My apologies again to everyone who receives *three* copies of 
>>>>>> this
>>>> message.
comments.
>>>>>> In the Security Configurations Section, the authors point out 
>>>>>> that an attacker might be able to exploit this in a denial of 
>>>>>> service
>>> attack.
>>>>>> confederations would be much less than of their occurring within 
>>>>>> a confederation (although one can't know for sure without knowing