Re: [secdir] SecDir Review of draft-ietf-sidr-bgpsec-protocol-20

[Russ Housley <[e-mail]>]

On Dec 22, 2016, at 10:50 AM, Sriram, Kotikalapudi (Fed) <[e-mail]> wrote:

> Hi Russ,
> 
> Thank you for your comments.
> I am preparing a version 21 of the document to be submitted soon.
> I have updated the document already to include all your comments 
> except the following thee:
> (need your further guidance on these)
> 
> 
> #1
>> In Section 3.2, the Signature Length within the Signature Segment does
> not count the length field itself.  It seems that all of the other
> length values in this specification count the size of the length too.
> Consistency will avoid implementation errors.
> 
> [Sriram] I agree. However, this change would require modifications with two existing
> implementations. If you say it doesn't matter, just do it; let the implementations catch up --
> then sure I will have no problem. I'll make the change in the spec. 

Better to point this out on the mail list and let the implementors have a say.

> #2
>> It seems a bit wasteful to repeat the whole capability for each
> direction.  Wouldn't it be better to follow the example used in
> other capability definitions (such as RFC 7911) by using one of the
> unassigned bits?  The Send/Receive pair of bits would have these
> semantics:
> 
> [Sriram] I spoke with Oliver Borchert. He thought there was some merit to
> implementing it the way it currently is in the spec
> (he already has the implementation in Quagga BGPsec).
> This change would also require modifications with the two existing
> implementations (NIST's and Parson's). 
> Again, if you feel strongly, please let me know.

Again, please point this out on the mail list and let the implementors have a say.

> #3
>> I think an additional consideration is needed in Section 6.2.  This
> protocol design assumes a signer will compute a message digest and
> then digitally sign that digest.  If someone wants to use a digital
> signature that works differently, there may be a significant change
> to this protocol.
> 
> [Sriram] Is this not already taken care of by using the same approach that is
> described in Section 6.2?  Section 6.2 says:
> 
> 
> "In the case that such a change to BGPsec were deemed desirable, it is
>   expected that a subsequent version of BGPsec would be created and
>   that this version of BGPsec would specify a new BGP path attribute,
>   let's call it BGPsec_Path_Two, which is designed to accommodate the
>   desired changes to BGPsec.”

When I read that paragraph, I did not think it was talking about the hash and sign paradigm.

Russ