> 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.
> - 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.
> - 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
> - 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.
> - 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.
> - 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.
> - 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.
randy
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
