Stephen, Thank you for the detailed review and comments. Please see my responses marked with [Sriram] inline below.
[Sriram] Your DISCUSS points (1) and (3) were already discussed /being discussed in separate threads. > (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. [Sriram] Signer's ASN is indeed included in the signed data. In Figure 8, "Secure_Path Segment : N" corresponds to the signing AS (current AS) and that is where the signer's ASN is included along with its pCount and Flags. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > - Figures 2 and 5 present the fields in different orders. That seems like a bad idea. [Sriram] Good catch. Already fixed in my editor copy of version-22. > - 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. [Sriram] Again, a good catch. Already fixed in my editor copy of version-22. > - 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. [Sriram] I think it is well understood. But when I push version-22 out, I’ll consider if I should simply just use "iBGP peer" consistently and avoid using "internal peer". > - 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." [Sriram] Seems like a bit of a pathological case. Could happen only if the sender behavior was incorrect. Sender is not required to know which algorithms a peer supports but sender's expected behavior is this: MUST include a Signature_Block for the "current" algorithm (which every BGPsec speaker MUST support through the transition period), and if the sender supports the "next" algorithm, then it MUST include a Signature_Block for the "next" algorithm also. So the peer BGPsec receiver (who MUST support at least the "current" algorithm) is not expected to be starved of a Signature_Block it can work with. > - 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. [Sriram] I will include wording to cover this in Section 7 in version-22. Sriram _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
