Re: [sidr] BGPsec draft and extended messages

[Wes George <[e-mail]>]

> On Mar 15, 2017, at 6:18 PM, Sriram, Kotikalapudi (Fed) <[e-mail]> wrote:
> 
> >First, I don’t believe that there is any construct within the current BGPSec setup that allows for this sort of mixed mode where most updates are signed but some subset are not. Normally it’s something negotiated on session establish - either BGPSec is supported by both neighbors, or it is not - and the BGP machinery handles updates accordingly.
> 
> 
> [ks] When BGPsec is negotiated, it simply means that the router can send/receive BGPsec updates. Traditional unsigned updates can still be exchanged on that session as necessary. This was part of the design from the start. That’s because an AS may negotiate BGPsec with a peer but can have a customer that is not upgraded to BGPsec. Once a BGPsec session is established, an update may have BGPsec_Path or (unsigned) AS_PATH attribute, but not both. See section 2.2, p.5:
> 
> 
> “BGP update messages without the BGPsec_Path attribute (i.e. unsigned updates) MAY be
>    sent within a session regardless of whether or not the use of BGPsec
>    is successfully negotiated.”


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.
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.

Wes