Skip to main content

Last Call Review of draft-ietf-sidr-bgpsec-protocol-20
review-ietf-sidr-bgpsec-protocol-20-opsdir-lc-brownlee-2016-12-12-00

Request Review of draft-ietf-sidr-bgpsec-protocol
Requested revision No specific revision (document currently at 23)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2016-12-16
Requested 2016-12-02
Authors Matt Lepinski , Kotikalapudi Sriram
I-D last updated 2016-12-12
Completed reviews Rtgdir Last Call review of -21 by Keyur Patel (diff)
Opsdir Last Call review of -20 by Nevil Brownlee (diff)
Genart Last Call review of -20 by Russ Housley (diff)
Secdir Last Call review of -20 by Russ Housley (diff)
Genart Telechat review of -21 by Russ Housley (diff)
Assignment Reviewer Nevil Brownlee
State Completed
Request Last Call review on draft-ietf-sidr-bgpsec-protocol by Ops Directorate Assigned
Reviewed revision 20 (document currently at 23)
Result Ready
Completed 2016-12-12
review-ietf-sidr-bgpsec-protocol-20-opsdir-lc-brownlee-2016-12-12-00
Hi all:

I have performed an Operations Directorate review of
   draft-ietf-sidr-bgpsec-protocol-20

  "This document describes BGPsec, an extension to the Border Gateway
   Protocol (BGP) that provides security for the path of autonomous
   systems through which a BGP update message passes.  BGPsec is
   implemented via an optional non-transitive BGP path attribute that
   carries a digital signature produced by each autonomous system that
   propagates the update message."

This draft describes in detail the BGPsec syntax, and the way in
which its various parts are constructed and used.  They are all
explained in an easily understandable order, though in some places
I had questions (e.g. for Figure2, wy can the BGP_Path attribute
have two signature blocks), but they were all answered later on
in the draft.  Clearly its users will need to read it all several
times - but that seems unavoidable!

It's clear that BGP Federations are a special case, their administrators
will need to be sure they understand the use of the pCount field, and
the various things that are subject to local policy.

I found the instructions for creating and validating a Secure_Path
well-explained and easy to follow.  The handling of validation-deferred
BGPsec update messages seems to be something that will need to be
carefully considered when setting local policy!

Section 7, 'Operation and Management Considerations" is - I think - a
short summary of the things Operators will need to consider when they
deploy BGPsec.  Section 8 'Security Considerations' is also important
for Operators; it explains clearly what guarantees BGPsec gives for
routes, and suggests strategies to mitigate various kinds of attacks on
routers.

Overall, although its quite long and detailed, this draft is
well-written, I believe it is ready for publication as an RFC.

Just one typo:
  p33 s/due to the following/for the following/

Cheers, Nevil


--
---------------------------------------------------------------------
 Nevil Brownlee                          Computer Science Department
 Phone: +64 9 373 7599 x88941             The University of Auckland
 FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand