ISE write-up for: draft-sriram-bgpsec-design-choices-14
"This document is written to capture the design rationale primarily
for the individual draft-00 version of BGPsec protocol specification
[I-D.lepinski-bgpsec-protocol-00]. However, where appropriate, the
document also provides a brief rationale and/or pointer for design
decisions that are reflected in the finalized BGPsec protocol
specification [RFC8205]. It lists the decisions that were made in
favor of or against each design choice, and presents brief summaries
of the arguments that aided the decision process."
In its initial version this draft only covered the development of bgpsec
in its early stages. Several of the reviewers pointed out that it would
be better if it also covered it's later development towards RFC 8205.
It's author has added Notes in various sections to document those later
This draft has no requests for IANA.
It was reviewed for me by Wes George and Jeff Haas.
The authors have responded to the changes suggested by the reviewers,
and also made the changes requested by the ISE.
- - - - - - -
Wes George's review:
I think that this draft is good, and could be published as-is. I think it provides some useful historical background on the rationale and discussion early in the BGPSec design phase in the SIDR WG. It summarizes a lot of discussion well, such that someone interested in this info could use this instead of reading thousands of email threads on the matter from the archives, and thus there’s value in publishing it.
That said, I think it could be much *more* useful if it didn’t limit its scope to the initial -00 draft, because the protocol evolved considerably since that point, and it would be more useful to document the places where things changed and the rationale behind those changes as well. It’s ultimately up to the authors and the ISE whether that is something that they wish to pursue, but I think there is some possibility of confusion if only the initial rationale is covered, especially where it deviates from where the protocol ultimately ended up. This is especially true when there are references to the protocol document that don’t specify a version or section – it becomes “an exercise for the reader” in a way that’s not exactly helpful.
As to a more substantive review, to my recollection, this is an accurate documentation of things, but without reviewing the archives myself, I can’t provide much in the way of third-party validation of all of the individual sections.
Would it be possible for you to extend the draft to cover the
differences between what the current version of the draft covers,
and how bgpsec was when it reached consensus?
- - - - - - -
Jeff Haas's initial comments, 28 September 2016
Here's my assessment of the current form of this draft. I've previously discussed these comments with Sriram:
- In its current form, the document covers well the issues from the perspective of -00 of the bgpsec protocol fine. Typo-wise, I only found a "rouge" router. :-)
- The benefit of carrying this document forward in its existing form is compromised by being a partial history of what it is attempting to document.
- A significant portion of the context vs. the version of bgpsec protocol that is likely to ship is still useful.
- The things that are different are different enough to be confusing. Two points in particular:
+ The removal of expiration time in the message. This had a significant number of important ripples, especially with regard to cert management.
+ Signing is done always in the current version.
A few minor points like how handling of invalid attributes is off but able to be derived from the normative text in the current version of the protocol specification.
Given the above, there is some benefit to continuing publication, but it'd be my strong recommendation to do the necessary updating to address the current differences prior to publication as an ISE.
Jeff Haas's review, 15 January 2018
I've noted the following sections as being items that would need to be updated to cover the current bgpsec proto proposal:
Issues with expire time
4.3 we don't do sas
4.4.2 details off about the packet layout.
4.5 "rouge" router.
5.1.2 packing - valid for internet case. why we're only protecting unicast ipv4/ipv6. case falls apart for vpn.
5.4 temporary suspension of signing. we don't do this.
8.5.2 - notification of fatal structural errors would terminate session. Current practice is covered by RFC 7606 and is covered in current bgpsec draft.
8.6.1 not valid instead of invalid terminology tweak.
8.7.2 - probably should use ASes from the example-as set rather than 701/702. c.f. rfc 5398.
9.2 this covers work I haven't strongly followed, but there's been a lot of work here. Requires an additional reviewer.
- - - - - - -