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

[Stephen Farrell <[e-mail]>]

Hiya,

On 05/01/17 14:10, Sriram, Kotikalapudi (Fed) wrote:
> 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.

Yep, thanks. I need to check back to see how close we are
to resolving those, but I had thought the ball wasn't in my
court at the moment:-) I'm sure we'll sort 'em soon though.

> 
>> (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.

Hmm. That's the target ASN of the previous signer though.
I thought there were cases where they could differ? But
if not, then you probably need to state that as a rule
for checking signatures, is that there already? (Happy to
check later, but don't have time right now.)

One other thing below...

> 
>> ----------------------------------------------------------------------
>> 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. 

Yes, but 5.2 is verifier behaviour and out not
assume a correct signer, so I do thing the alg
presented here needs to cover such things.

> 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), 

Where does it say that the current/next thing applies
to the entire world of BGPsec? I didn't read it that
way as it happens, but rather that the current/next
could involve different algorithms at different nodes
at the same time.

So e.g. I read it to be allowed that a migration from
rsa/sha256 then to ecdsa then to eddsa could occur
with some non-updated nodes still signing with rsa/sha256
whilst some shiny new nodes are doing ecdsa and eddsa and
others are in between.

I do agree that a global current/next pair of algs
is nicer, if that is what's wanted. But I don't recall
the text saying that. (Again happy to check later, but
no time right now;-)

Cheers,
S.


> 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 
>