Stephen Farrell has entered the following ballot position for draft-ietf-sidr-bgpsec-protocol-21: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I have a couple of fairly straightforward things I'd like to briefly discuss... (1) 3.2/Figure 7: A fixed 20 byte SKI being a sha-1 hash of the public key is a bad plan, for all the usual reasons. Why is it ok for that to be hardcoded here when it could change if/when new alg choices are made for the RPKI? If it is not too late then I think you should add a length or alg field to that. If it is too late to do that, then are we really ok that you will need to rev the BGPsec version number in order to get rid of all sha-1 code from your implementation? That seems like a bad plan for a new protocol. (2) Figure 8: It seems to me to be an error to omit the signer's ASN from the signed data and only have that included in the signer's certificate. Why is that intimate level of binding to the RPKI desirable? There may well be reasons but I'm not seeing 'em, and I am recalling that it took a chunk of effort to make CMS less dependent on X.509 for similar reasons (meaning identifying signers exclusively via cert issuer and serial in that case). I would expect that there could be demand to have some level of independence between BGPsec and RPKI for at least internal uses such as those noted in the spec already. (3) section 8: Is there a potential exposure here in that a relying party who emits e.g. certificate status checks or cert retrieval queries for an RPKI cert they've not previously seen is exposing something about the set of paths its traffic is likely to follow. (This is similar to why we have OCSP stapling in the web.) IIRC the RPKI specs may cover this but I suspect it'd be worth noting here as well even if so as this represents exposing something about BGP announcement content to off-path parties which I think is new for BGP. Is that a new thing for BGP? (I think the new aspect to the attack is that a bad actor who has already compromised some AS could more easily spot that traffic from the relying party's AS is likely to transit the compromised AS.) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - (Non actionable comment really aimed at the IESG and not the authors/WG...) I'm kinda sad that even today we don't appear to have learned to value deploy-ability more highly. I fear that BGPsec and RPKI will suffer a similar lack of deployment as seen with S/MIME and DNSSEC and for possibly similar reasons (complexity, not starting with modest improvements, requiring a number of parties to change before seeing benefits). I hope I'm wrong about that, but equally, if I'm not and RPKI/BGPsec deployment turns out to be very very slow, (as opposed to the optimistic, "just slow";-) then I also hope the IESG at that time will be willing to consider alternatives - it's too easy for the IETF to just get stuck when a technology like this fails to deploy. But maybe I'm wrong and this'll all be fine and will be widely deployed and used in a few years. - Figures 2 and 5 present the fields in different orders. That seems like a bad idea. - 3.2: The reference to the pki profile doc is not precise enough, the string "key identifier" does not occur in that draft - it's in RFC6487, 4.8.2. - 4.1, last para: is the distinction between an "internal peer" and "iBGP peer" sufficiently clear to routing folk? For me they sound similar but I assume it's ok. - 5.2, I think you need to say something to the effect that every Secure_Path MUST have a signature with an algorithm that is supported. As I read the text, the algorithm as stated here could be read to not require that. E.g. the para before the bullets on p25 could be read to mean "drop all stuff involving unsupported algs and then continue to process the rest of the stuff." - section 7: WRT non-deterministic signature algorithms, I think it'd be useful to note here that all such algorithms require good random number generation on the signer's system and that failing in that respect can expose the signer's private key. IMO deterministic signature schemes are better for this reason but the need for a good RNG is I think a real operational issue worthy of note. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr