Subject: Re: [secdir] SECDIR Review of draft-ietf-idr-bgp-enhanced-route-refresh-06

From: "Keyur Patel (keyupate)" <[email-masked]>
Date: Tue, 3 Jun 2014 17:11:02 +0000

Hi Dacheng,

Thanks a lot for the draft review. My comments are inlined. #Keyur

On 5/31/14 12:06 AM, "Zhangdacheng (Dacheng)" <[email-masked]>
wrote:

>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 short document tries to enhance the existing BGP route refresh
>mechanisms to provide for the demarcation of the beginning and the ending
>of a route refresh. In order to achieve this, the "Reserved" field of the
>ROUTE-REFRESH message is redefined to indicate the beginning and the
>ending of a route refresh. I agree this extension will not introduce new
>security issues to the BGP protocol.
>
>The document is clear. I consider it ready with a few issues:
>
>I suggest defining how a BGP speaker should handle a EoRR without
>receiving the associated BoRR especially when the peer does not support
>graceful start.

#Keyur: The received EoRR message without an associated BoRR message would
pretty much be a no-op operation (as no routes are marked Stale). This
behavior is consistent with/without GR.

How about if we add the following line (Section 4, end of 5th paragraph
after: "Such purged routes MAY be logged for future analysis.")

A BGP speaker MAY ignore any EoRR message received without a prior receipt
of an associated BoRR message. Such
messages MAY be logged for future analysis.

> 
>
>The description in the last paragraph of section 4 is not very clear. It
>would be better to briefly explain why the introduced procedures can
>simplify the interaction with the BGP Graceful Restart. In addition, the
>EOR and EoR messages (the typos of EoRR?) mentioned in this paragraph are
>not defined elsewhere.

Keyur: Good Point. How about adding the 2nd (clarification) line to the
last paragraph of section 4:

The following procedures are specified in order to simplify the
   interaction with the BGP Graceful Restart [RFC4724].  In particular,
   these procedures ensure that
   End-of-RIB (³EoR²) defined in Graceful Restart and EoRR as defined
   in this specification
   are kept separate, thereby avoiding any premature cleanup of stale
routes.
   For a BGP
   speaker that supports the BGP Graceful Restart, it MUST NOT send a
   BoRR for an AFI/SAFI to a neighbor before it sends the EoR for the
   AFI/SAFI to the neighbor.  A BGP speaker that has received the
   Graceful Restart Capability from its neighbor, MUST ignore any BoRRs
   for an AFI/SAFI from the neighbor before the speaker receives the EoR
   for the given AFI/SAFI from the neighbor.  The BGP speaker SHOULD log
   an error of the condition for further analysis.

Regards,
Keyur

>Cheers
>Dacheng

---

From: "Zhangdacheng (Dacheng)" <[email-masked]>
Date: Mon, 9 Jun 2014 09:28:54 +0000

> -----Original Message-----
> From: Keyur Patel (keyupate) [mailto:[email-masked]]
> Sent: Wednesday, June 04, 2014 1:11 AM
> To: Zhangdacheng (Dacheng); [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: SECDIR Review of draft-ietf-idr-bgp-enhanced-route-refresh-06
> 
> Hi Dacheng,
> 
> >mechanisms to provide for the demarcation of the beginning and the
> >ending of a route refresh. In order to achieve this, the "Reserved"
> >field of the ROUTE-REFRESH message is redefined to indicate the
> >beginning and the ending of a route refresh. I agree this extension
> >will not introduce new security issues to the BGP protocol.
> >
> #Keyur: The received EoRR message without an associated BoRR message
> would pretty much be a no-op operation (as no routes are marked Stale). This
> of an associated BoRR message. Such messages MAY be logged for future
> analysis.
> 
[Dacheng Zhang:] That is good. 
> 
> >
> >
> >The description in the last paragraph of section 4 is not very clear.
> >It would be better to briefly explain why the introduced procedures can
> >simplify the interaction with the BGP Graceful Restart. In addition,
> >the EOR and EoR messages (the typos of EoRR?) mentioned in this
> >paragraph are not defined elsewhere.
> 
> Keyur: Good Point. How about adding the 2nd (clarification) line to the last
> paragraph of section 4:
> 
> 
>    are kept separate, thereby avoiding any premature cleanup of stale routes.
>    For a BGP
[Dacheng Zhang:] The new paragraph is much better. Thanks. ^_^