ISE write-up for: draft-sriram-bgpsec-design-choices-14
Abstract:
"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
decisions.
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.
Wes </comment>
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.
- - - - - - -