Just so that everyone on the list is aware of the background info.... I sent this suggestion (email copied below) to Alvaro.
Alvaro replied to me in detail. I would request him to post that response on this list as well so everyone has the full context. Alvaro asked me to invite comments on the WG list. Please read the proposal below, and share your thoughts. Thanks. Sriram ________________________________________ From: Sriram, Kotikalapudi (Fed) Sent: Monday, March 13, 2017 4:57 PM To: Alvaro Retana (aretana) Subject: BGPsec draft and extended messages Hi Alvaro, Just trying to think aloud about a possible way to have wording in the BGPsec draft that does not require normative dependence on the extended message draft. I think it can be done in a rational way as follows. Please feel free to shoot this down if the rationale seems weak. Currently the draft reads in Section 2.2: Note that BGPsec update messages can be quite large, therefore any BGPsec speaker announcing the capability to receive BGPsec messages SHOULD also announce support for the capability to receive BGP extended messages [I-D.ietf-idr-bgp-extended-messages]. Please see related operational guidance in Section 7. Suggestion: Remove the above paragraph from Section 2.2 and add the following in Section 4.2 (Constructing the BGPsec_Path Attribute): BGPsec update size is subject to a maximum BGP update size. The maximum size at present is 4096 bytes [RFC4271], and it may be extended to a larger size in the future. If the sending router determines that adding its Secure_Path Segment and Signature Segment causes the BGPsec update to exceed the maximum size, then it will convert the BGPsec update to an unsigned traditional BGP update [using the procedure in Section 4.4] and send the unsigned update. (Note: Please see related discussion in Section 7.) Then the existing discussion paragraph in Section 7 (operations) related to extended messages can be replaced with the following: BGPsec update size is subject to “current” maximum BGP update size, noting that “current” maximum size may increase in the future. The maximum size at present is 4096 bytes [RFC4271], and it is expected be extended to a larger size in the future [I-D.ietf-idr-bgp-extended-messages]. Given the ECDSA with curve P-256 for the signature algorithm [I-D.ietf-sidr-bgpsec-algs], each AS in an AS path adds approximately 100 bytes of BGPsec data (i.e. Secure_Path Segment and Signature Segment). Hence, the maximum size of 4096 bytes is exceeded only if there are 40 or more distinct ASes in the AS path. (Note: AS prepends are compressed out with the use of pCount as described in Section 3.1.) Currently, the average and maximum AS path lengths in the Internet are 3.8 and 14, respectively, and have remained in this ball park for many years [Huston]. [Huston] G. Huston, “AS6447 BGP Routing Table Analysis Report,” March 13, 2017. http://bgp.potaroo.net/as6447/ (BTW, the above wording perhaps also makes it independent of the form extended messages takes eventually – separate RFC that updates BGP-4 or as default in BGP-5 OPEN(?) etc. ) I look forward to hearing your thoughts on this. Thank you. Sriram
_______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
