Skip to main content

Last Call Review of draft-ietf-sidr-bgpsec-protocol-21

Request Review of draft-ietf-sidr-bgpsec-protocol
Requested revision No specific revision (document currently at 23)
Type Last Call Review
Team Routing Area Directorate (rtgdir)
Deadline 2016-12-16
Requested 2016-12-01
Requested by Alvaro Retana
Authors Matt Lepinski , Kotikalapudi Sriram
I-D last updated 2017-01-10
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 Keyur Patel
State Completed
Request Last Call review on draft-ietf-sidr-bgpsec-protocol by Routing Area Directorate Assigned
Reviewed revision 21 (document currently at 23)
Result Has issues
Completed 2017-01-10
[adding routing-ads]

From: Keyur Patel <>
Date: Wednesday, January 4, 2017 at 2:17 PM
To: Jonathan Hardwick <>, "Alvaro Retana
(aretana)" <>, Zhangxian Xian <>, Jon
Hudson <> Cc: rtg-dir <>,
"" <>, sidr <>,
"Sriram, Kotikalapudi (Fed)" <>,
"" <> Subject: draft-ietf-sidr-bgpsec-protocol


Apologies for the delayed response.

I have been selected as the Routing Directorate QA reviewer for

The Routing Directorate QA reviews are intended to be a support to improve the
quality of RTG Area documents as they pass through the IETF process. This is
the QA review at the time of the WG document adoption poll.


This document describes BGPsec, an extension to the Border Gateway  Protocol
(BGP) that provides security for the path of autonomous systems (ASes) through
which a BGP update message passes. The document is well written, easy to read
and follow. Some minor comments are listed below:

Comments for the authors:

1)      Section 4.1 “The BGPsec Path attribute and the AS_PATH attribute are
mutually exclusive. That is, any update message containing the BGPsec Path
attribute MUST NOT contain the AS_PATH attribute”.  For any restarting speakers
in a GR mode, where the bgp capability is not exchanged, the existing stale
routes won’t have an AS_PATH attribute. We could add some clarifying that helps
to indicate that such routes should be considered valid in stale mode (till
they get refreshed)?

2)       4.1 4th paragraph: “Note also that new signatures are only added to a
BGPsec update message when a BGPsec speaker is generating an update message to
send to an external peer (i.e., when the AS number of the peer is not equal to
the BGPsec speaker's own AS number).  Therefore, a BGPsec speaker who only
sends BGPsec update messages to peers within its own AS does not need to
possess any private signature keys.” This text doesn’t seem to apply to confed
peers? If so, it would be nice to clarify that this text doesn’t apply to any
confed peers.

3)      Section 5 and Section 5.2, 1st paragraph: RFC4271 considers update
message received without a wellknown AS_PATH attribute as an error.  We need
some text to clarify the (error handling if any) behavior when an update
message is received without a bgpsec and an aspath attribute. The current draft
text seems unclear about generation of bgpsec attribute as well (in a ibgp
scenario). Is it a requirement to generate an empty bgpsec attribute?

4)      With an AS_PATH attribute in 4271 there was loop detection in place. 
With BGPSec I don’t see that being called explicitly other than a passing
remark in section 5. Section 5.2 should have a check that allows a BGPsec
speaker to bail out of a validation procedure when a aspath loop is detected.

Best Regards,