Re: [sidr] Mirja Kühlewind's No Objection on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT)

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

Hi Mirja,



Sorry for the delay in replying.

Thank you for your careful review, and the detailed and helpful comments.

Please see my responses inline below marked with [Sriram].

Changes reflecting your suggestions as discussed below

have been incorporated in the forthcoming version-22.





>First, thanks for a well written document!





Thank you.





> A few question on the design; not to propose changes but I would like to learn the reason why the design is as it is:

> 1) Why do you need to send two different negotiation capabilities for each direction instead of just using two flags in the same capability?

> And similar why don't you just announce multiple address families in the same capability (using variable length)?

>





[Sriram] Oliver Borchert (implementer of one of two available implementations) posted his thoughts on this earlier (responding to a similar question from Russ Housley). He had preference for the way currently it is (please see “To Comment 2” in the link below):



https://www.ietf.org/mail-archive/web/sidr/current/msg08130.html





[Sriram] Also, Keyur and I talked about this issue in a phone call last week. He would have preferred combining those messages (in agreement with you), but thought it was a minor issue and could be left as is for now. He also suggested that if, down the road, router vendor implementers express strong preference for it, a bis can be published. Russ also thought it was minor and was also agreeable to leaving it as is. Please let me know if you still feel strongly.





> 2) Why are the Secure_Path elements and Signature_Block blocks not aligned but in two different lists (given there is and one to one mapping)? Wouldn't it be easier to just update one length field (at a fixed position) and attached the new information at the end? Or to ask the question differently: why is the format as shown in figure 8 not used in the message itself (->this is related to Suresh's question)?

>





[Sriram] The short answer is that the protocol designers felt that in the bytes sent on the wire, it made sense that the whole Secure_Path should be together and the set of Signatures should be together. For instance, then it is easy to convert Secure_Path to AS_PATH if the update needs to be forwarded unsigned to a non-BGPsec peer. The Secure_Path in its entirety is also used in the checks performed in the list in Section 5.2.





[Sriram] Regarding Figure 8 (format for the data to be hashed), Oliver offered the rationale for it in the following post back when we first made the switch to this format. Michael Baer (implementer of the other available implementation), Oliver, myself, and Matt Lepinski discussed/reviewed it in detail and then we proceeded to include it in the specification.



https://mailarchive.ietf.org/arch/msg/sidr/8B_e4CNxQCUKeZ_AUzsdnn2f5MU





[Sriram] Suresh and Alexey seemed to appreciate the rationale that was applied for the format in Figure 8 (after they read Oliver’s explanation):



https://www.ietf.org/mail-archive/web/sidr/current/msg08237.html





> Questions on operation:

> 1) section 5 says "a BGPsec speaker MAY temporarily defer validation of incoming BGPsec update messages".

> Does this mean it has to remember its state before applying the update message such that is can revert to this state if it later detects that die update message was not valid? Or what action is supposed to happen if the update message is detected as not valid later on





[Sriram] It is left up to an implementation the mechanism for saving the state and returning to where it was left off. If the router deferred validation, it comes back later and completes the validation. If an update message is detected not valid later, the action would be similar to what is done when update validity state change occurs due to an RPKI state change, i.e. re-run best path selection  – see excerpt below (Section 5, p.22):



   For example, when a given RPKI certificate ceases to be valid (e.g.,

   it expires or is revoked), all update messages containing a signature

   whose SKI matches the SKI in the given certificate must be re-

   assessed to determine if they are still valid.  If this reassessment

   determines that the validity state of an update has changed then,

   depending on local policy, it may be necessary to re-run best path

   selection.





> 2) sec 4.2 says "Next, the BGPsec speaker generates one or two Signature_Blocks."

> Are you sure it's at max 2? I guess this depends on the expected update cycles of the algorithm compared to the devices. Given update cycles for devices can be very slow and updates for algorithm can be fast if any security problems are detected, I wouldn't recommend to limit this to two.





[Sriram] This was discussed at an IETF SIDR meeting extensively, and the WG had consensus that two Signature_Blocks would be adequate.



> 3) In relation to the comment above, I'm not a big fan of the algo migration strategy in section 6.1. I understand the problem that all router on the path need to potentially support the algo. However, you do have an negotiation phase. So why don't you the advertise the signing algorithm in the negotiation capabilities? In this case the sender could at least choose to only send the one(s) that is/are also supported by the receiver or not use BGPsec at all if there is no match. However, I also understand that it is probably to late to change anything now and if there is wg consensus, I'm fine with that...





[Sriram] The WG has had consensus on this for quite some time now – that instead of negotiation upfront, the Signature_Block(s) in the update must indicate what algorithm(s) is(are) used.





> 4) section 8.1 says "the recipient of a valid BGPsec update message is assured that the update propagated via the sequence of ASes listed in the Secure_Path portion of the BGPsec_Path attribute."

> Is that true? It is assured that at least these ASes have been crossed but there might have been others on the path that did not sign the BGPsec_Path attribute, no?





[Sriram] Yes, it is true. Each AS in the path MUST sign to the next AS (Target AS). Section 3.1 says:





   The Secure_Path contains one Secure_Path Segment (see Figure 5) for

   each Autonomous System in the path to the originating AS of the

   prefix specified in the update message.





[Sriram] Also, Section 3.2 says:





   A Signature_Block in Figure 6 has exactly one Signature Segment (see

   Figure 7) for each Secure_Path Segment in the Secure_Path portion of

   the BGPsec_Path Attribute.







[Sriram] The following check listed in Section 5.2 make it clear as well:





   3.  Check that each Signature_Block contains one Signature segment

       for each Secure_Path Segment in the Secure_Path portion of the

       BGPsec_Path attribute.  (Note that the entirety of each

       Signature_Block must be checked to ensure that it is well formed,

       even though the validation process may terminate before all

       signatures are cryptographically verified.)





> 5) Is it really necessary to create registries for "BGPsec Capability"

> and "BGPsec_Path Flags"? Given this is a really small number of bits/flags, I think new RFCs that update this RFC are enough to define a new use for these so far unused bits.





[Sriram] This came up in the Russ Housley’s review also. But later he agreed it was OK to include these. He offered some suggestions for clarifying the bits (fields) that were already fully specified in the protocol, and hence didn’t need any IANA consideration. His suggestions were incorporated in the IANA section in version 21.





>

> Further, editorial proposals:

> 1) I would propose to add the Confed_Segment flag in figure 5 (and call the remaining flag field 'reserved')





[Sriram] Good idea. I have made the change in the forthcoming version-22.







> 2) Maybe explain Adj-RIB-In or give a reference to RFCrfc4271 section 1.1

>





[Sriram] Done. I’ve provided the reference to RFC4271.





Sriram