Hey everyone,
So, based on both a long flight, and the comments already made about this
draft, I re-read it and wanted to make the following additional comments. I
don't think these are redundant with the comments other have made, but if any
of them are, sorry for the noise.
First, I think the notion and general tone of this document are great. The
software engineer in me is very excited to see a good requirements doc at the
early stages of a system design. I hope the remainder of my comments can be
read with this high-order bit set. :)
- 3.5 is not a testable requirement. One cannot be expected to enumerate the
space of all things that are _not_ requirements, so why put any in?
- 3.6 ibid
- 3.7 is too vague. Need to specify where an adversary needs to have access to
link-layer. I have access to the link layer at home, but that doesn't help me
insert traffic between any BGP peers. Can I suggest modifying the existing text
as follows:
``... an enemy who has access to the inter-router link layer...'' the term
``inter-router link'' is borrowed from the cited RFC.
- 3.8 The word ``MAY'' is a very rough fit for the general notion of
``requirements.'' I would suggest it is reworded:
``A BGPsec design MUST be able to understand and make use of a security
infrastructure (e.g., a PKI) to distribute authenticated data used as input to
routing decisions when such a resource is available and operators wish
to configure it for use. Such data includes information about
holdings of address space and ASNs, and assertions about binding of
address space to ASNs.''
- 3.9 is also not worded as a requirement. Does the solution require that a 4k
packet even be discussed? It seems to me that this is not the right document
to discuss this.
- 3.10 also does not seem to be a requirement. It is ``requiring'' an optional
exclusion? I suggest it get yanked.
- 3.11 This also does not seem to be a requirement. Discussing a design's
status in a requirements document is backwards. I suggest this get yanked.
- 3.19 Seems like it would be hard to test as a requirement. The problem may
be the word ``MAY.'' How could this be made into a testable requirement?
- 3.20 This requirement, again, references a baked design. This should be
restated in a general way. Suggest,
``Any inter-AS use of cryptographic hashes or signatures, should (must?)
provide mechanisms for algorithm agility that take the form of...''
- 4.5 The term ``real-time'' seems to carry too many implicit/overloaded
meanings. Could we try to disambiguate with different text. Maybe we can just
drop that term ``real-time'' and leave the rest?
- 4.7 This requirement seems to preach a little bit of a design instead of
being agnostic. Could it be rephrased to be something like:
``The output of a router applying BGPsec to a received signed UPDATE MUST be
either unequivocal and conform to a fully specified state in the design.''
Thanks,
Eric
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
