Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-protocol-21: (with DISCUSS and COMMENT)

["Sriram, Kotikalapudi (Fed)" <[e-mail]>]

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