Hey Randy, Sorry for the delay. I know we're passed the deadline (totally my bad, sorry), but here are my comments:
On Mar 10, 2012, at 6:07 PM, Randy Bush wrote: >> I just noticed that none of the comments I made in 11/11: >> http://www.ietf.org/mail-archive/web/sidr/current/msg03671.html >> seem to be addressed in this revision. > > great review. and again my apologies for having missed it. i now have > an internal ticket system so i hope to lose less. > > i have hacked as per following, and will push -03 to repository. this > will leave two days for further discussion and another version before > the dreadline. > >> - 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 > > because these two serve as warnings, to which people might even object. > > though 3.6, can not fix data-plane, seems obvious to me, to others it > might not be. I totally understand the sentiment behind these items, but in a pedantic sense, they aren't requirements. Could there be another section for something like ``considerations?'' If I build a toaster, I fulfill the above ``reqs,'' right? > >> - 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. > > thanks > >> - 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.'' > > hmm, you are suggesting > > OLD: > 3.8 A BGPsec design MAY make use of a security infrastructure > (e.g., a PKI) to distribute authenticated data used as input to > routing decisions. Such data include information about > holdings of address space and ASNs, and assertions about > binding of address space to ASNs. > > NEW: > 3.8 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. > > i think you are just moving the point of equivocation. our wording was > meant to leave open the idea that there might be other means than a PKI. > yours seems to leave open the operator's ability to enable or not. for > me, the operator's freedom to decide was assumed. > > otoh, the OLD wording could indeed be improved. how about > > 3.8 It is assumed that a BGPsec design will require information > about holdings of address space and ASNs, and assertions about > binding of address space to ASNs. A BGPsec design MAY make use > of a security infrastructure (e.g., a PKI) to distribute such > authenticated data. > > i think that catches our intent. i am less sure it catches yours. While I may be being pedantic again (it's the software engineer in me, sorry), I think a requirement should prescribe something that is necessary for a system in order for its design to be judged as being correct. The optional nature of ``MAY'' seems counter to this. If we start from the question, ``why does a BGPsec design need 3.8'' we should be able to construct the necessary requirement. Maybe something like: 3.8 A BGPsec design must be able to ``verify'' the correctness of the holdings of address space, the holdings of ASNs, and the binding between address space and ASNs. Then, the notion of how verification can be done can be externalized to this document in the afore mentioned ``considerations'' section. Maybe something like: ``Verification'' can be defined in many ways, including [cite rpki]... THis is very hand wavy, and I know it's pedantic, but requirements analysis is the foundation of a system's design, so I've always been kind of hung up on it. :) > >> - 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. > > fair point. i'll leave a marker in the next version so as not to change > numbering so folk can follow the discussion. > >> - 3.10 also does not seem to be a requirement. It is ``requiring'' an >> optional exclusion? I suggest it get yanked. > > making explicit that the design need not cover an existing feature fo > BGP, AS-SET, seems important Is that fundamental to securing BGP, or more of a system design issue? If the latter, I would suggest it get addressed there. I had thought that ensuring the proper semantics of origin validation and path validation didn't inherently care about AS-SETs? I do understand that many want to address this, I just felt it ought to be elsewhere to maintain the focus on requirements analysis. A design doc can always make the same statements that carry just as much weight... > >> - 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. > > making explicit that a design need not maintain the update packing > feature of current bgp would seem important. But requirements come before a design, so it's like putting the cart before the horse. Requirements, to really properly do their job, need to be design-agnostic. > >> - 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? > > i am not sure testability is the issue. if one can look inside the > router, that the database is kept current would seem to be testable. > if the router is a black box, not. > > if you are suggesting that the MAY should be a MUST, i agree and will > make that change. I have to say, it makes much more sense (to me) w/ that change. :) > >> - 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...'' > > how about > > 3.20 Any inter-AS use of cryptographic hashes or signatures, MUST > provide mechanisms for algorithm agility. I like this much better, but can we just think about adding something that explains (very quickly) what the point is? Maybe something like: s/algorithm agility./algorithm agility, so that specific hashes or sigs can be changed without degrading the global system's security protections./ Or something? > >> - 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? > > sure > >> - 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.'' > > sure. > > deep thanks for the thoughtful review, and apologies for having lost it. My pleasure, and no worries (we all get busy). :) Eric _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
