Mirja Kühlewind has entered the following ballot position for draft-ietf-sidr-bgpsec-protocol-21: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- First, thanks for a well written document! 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)? 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)? 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 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. 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... 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? 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. Further, editorial proposals: 1) I would propose to add the Confed_Segment flag in figure 5 (and call the remaining flag field 'reserved') 2) Maybe explain Adj-RIB-In or give a reference to RFCrfc4271 section 1.1 _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
