Re: [sidr] BGPsec draft and extended messages

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

Wes,

Thanks for the clarification. My comments below.


….. snip ….
>WG] My original email was insufficiently precise when expressing my concern on this, as it was written in relative haste. I’ll try again. I always interpreted this as allowing for updates that were never secured (because the downstream neighbor doesn’t support it) to be sent between BGPSec capable neighbors, as you explain above. This makes perfect sense given BGPSec’s decision to not allow partially-signed updates.


>WG] My concern is that using this text as justification for updates that otherwise would be secured (because they came through a path of neighbors that all support BGPSec end to end) dropping back to insecure on account of the size of the update violates the principle of least astonishment and again allows for degraded security by failing open.


BGPsec_Path attribute size does not exceed 4K.
ECDSA P-256 signature size is 64 bytes.
So, #bytes added to BGPsec_Path are about 100 bytes per AS.
Extended message was thought to be needed when RSA-2048 (256 bytes sig) was initially proposed.
With P-256, BGPsec_Path attribute does not exceed 4K up to 40 ASes in the path.
(Note: AS prepends are compressed out due to use of pCount.)
In the Internet, the observed maximum AS path length is 14 [Huston].
The maximum AS path length has remained in this ball park for many years now.
Therefore, it doesn’t appear that “dropping back to “insecure on account of
the size of the update”  would happen in practice.


So, the question is: Does the WG agree that the extended messages draft
can be an Informative rather than a Normative reference?


Alvaro (speaking as WG Participant) suggested:


“I would even just mention the “maximum message size” (with no specific numbers) and leave out mention of any future changes.  This way the BGPSec documents (1) don’t depend on the Extended Messages document, and (2) they depend on whatever BGP can do.  If/when Extended Messages are settled and implemented then BGPSec can make use of them (as can any other application using BGP).”


Steve Kent said earlier in the thread:


“I think it makes sense to omit the extended message feature, given the use of ECDSA P-256.”


Sriram