Subject: Re: [sidr] BGPsec draft and extended messages

From: Randy Bush <[email-masked]>
Date: Wed, 15 Mar 2017 06:30:57 +0900

[ moved to wg list ]

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

unfortunately, existing bgp data and simple arithmetic would seem to say
otherwise.

randy

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Tue, 14 Mar 2017 22:26:46 +0000

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

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Wed, 15 Mar 2017 02:58:31 +0000

>unfortunately, existing bgp data and simple arithmetic would seem to say otherwise.

We are focusing here on the size of the BGPsec_Path attribute.

As I wrote in the rationale part in my other post (in this thread):

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 use of ECDSA 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].

Extended messages work must/will continue. We are only trying to see if BGPsec draft

can have the extended messages draft as an "Informational" reference rather than "Normative".

Sriram

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Wed, 15 Mar 2017 13:44:55 +0000

Hi!

[Speaking as AD]

The requirement for Extended Messages has been in the BGPSec draft since the beginning (at least the WG -00 version).  Changing it now would mean a significant deviation in the process – but not impossible.

Before committing to supporting any change to the document, I would like to see changes discussed in the sidr WG list.  You may even be able to convince the sidrops Chairs to give you some time in Chicago to discuss in person.  We would need the WG to reach consensus for such a change.

[Speaking as WG Participant]

I think that a possible path forward is to take any reference to the Extended Messages document out, and simply put text similar to this in (from Sriram’s message):

“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.)”

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

Thanks!

Alvaro.

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 15 Mar 2017 12:38:32 -0400

Alvaro: 

Thank you for working through these issues at this late time. 

<IDR WG chair hat on> 

IDR is talking input on this topic.  So it would be good to post a summary of your discussion to the IDR list.   If it is useful, we can still set aside time for the authors (or SIDR WG chairs) to present their needs at IDR.  If you wish this, please let the IDR chairs know so we can set-up time. 

<IDR WG chair hat off> 

Sue Hares 

From: sidr [mailto:[email-masked]] On Behalf Of Alvaro Retana (aretana)
Sent: Wednesday, March 15, 2017 9:45 AM
To: Sriram, Kotikalapudi (Fed); Randy Bush; Steve KENT
Cc: [email-masked]; [email-masked]; Matthias Waehlisch; sidr wg list
Subject: Re: [sidr] BGPsec draft and extended messages

Hi!

[Speaking as AD]  

 

 

Thanks!

Alvaro.

---

From: Wes George <[email-masked]>
Date: Wed, 15 Mar 2017 14:15:29 -0400

I’m behind on mail but Sriram suggested I pay attention to this, so here’s a drive-by comment, and if this comes up in SIDROps in Chicago I’ll do my best to attend and participate in the discussion there.

Being pragmatic, I understand that the risk is low for exceeding the max size without extended message support based on the average AS-path length, but I have concerns about the suggested solution that treats unsigned updates as a fallback path for updates that would otherwise be too large. 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. So likely the document would need some additional guidance on how that mixed mode is supposed to work. I think it’s pretty straightforward since there is already a defined process for stripping signatures and sending unsigned updates, but there’s sufficient grey area that I am not comfortable leaving this “as an exercise for the implementer” since it needs to properly interoperate. And if what is being suggested is that one update being too large drops the entire session back to unsecured mode, that seems even worse.

More generally, I have expressed concern in the past (including quite publicly at NANOG) about “failing open” and the impacts of this model. While it’s definitely the lower-risk method when we’re dealing with something as critical as routing updates, it has the net effect of creating situations where the very benefit gained by deploying the technology is negated because any number of problems can cause fallback to the unsecured model that is effectively the same as having not deployed in the first place. The deployment threshold for things like this is usually that the net improvement in protection has to be worth the increased overhead of deployment and maintenance. I have been having trouble making the argument that OV and PV fall on the right side of that line due to the amount of places where things fail open by design. Some of those concerns are addressed by work in progress to move away from rsync and address other potential failure cases, but the potential for what amounts to a silent failure where some subset of routes on a session that I expect to be secured suddenly are not seems high in this case, and thus I don’t see this as an acceptable tradeoff.

Given the headwinds for deployment of path validation - it requires a certain level of hardware support (CPU/Memory) to deploy at real scale, software features that haven’t been implemented yet, etc., I don’t see a delay while we get extended message support sorted as any really serious deal-breaker. Realistically, vendors and operators will be better served if this set of features can be implemented as a group to minimize the amount of touching and re-touching the same area of code and certifying and deploying multiple code versions to get everything. In other words, if I were deciding on a deployment timeline, I’d plan to wait until a critical mass of features is available either way, so whether that waiting happens now or later, the result is the same, and the better focus would be to get Extended Messages moved through the process with all possible haste instead of trying to pull BGPSec back for late-stage changes to reduce its dependency on the former.

Wes George

> On Mar 15, 2017, at 9:44 AM, Alvaro Retana (aretana) <[email-masked]> wrote:
> 
> Hi!
> 
> [Speaking as AD]
> 
> On 3/14/17, 6:26 PM, "Sriram, Kotikalapudi (Fed)" <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Wed, 15 Mar 2017 22:18:52 +0000

Wes,

Comments inline below marked with [ks].

>
>Being pragmatic, I understand that the risk is low for exceeding the max size without extended message support based on the average AS-path length, but I have concerns about the suggested solution that treats unsigned updates as a fallback path for updates that would otherwise be too large.
>

[ks] There seems to be some misunderstanding here. Let me try to clarify.

[ks] The proposed change is simply that BGPsec specification acknowledges that there is a maximum message size, which is provided by BGP. (That is 4096 bytes maximum size currently and in the future it may be more.) BGPsec simply abides by the maximum size. Then the design question is: What does the sending BGPsec router do when it finds that by adding its Secure_Path and Signature Segment, the size exceeds the maximum message size? (This question needs to be addressed independent of the actual value of the maximum size provided by BGP.)

[ks] The secondary question is how often does it happen (i.e. exceeding the maximum size)?  You seemed to say “risk is low for exceeding the max size without extended message support based on the **average** AS-path length.”  Actually, the worst-case AS-path length was used. Please see the analysis in my previous post.

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

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

>So likely the document would need some additional guidance on how that mixed mode is supposed to work. I think it’s pretty straightforward since there is already a defined process for stripping signatures and sending unsigned updates, but there’s sufficient grey area that I am not comfortable leaving this “as an exercise for the implementer” since it needs to properly interoperate.

[ks] Please see my response above. However, it is worth double checking to make sure that what you are suggesting is stated clearly in the document. I’ll do that.

>And if what is being suggested is that one update being too large drops the entire session back to unsecured mode, that seems even worse.

[ks] No. That is not being suggested.

Thanks.

Sriram

---

From: Wes George <[email-masked]>
Date: Sat, 18 Mar 2017 09:59:48 -0400

> On Mar 15, 2017, at 6:18 PM, Sriram, Kotikalapudi (Fed) <[email-masked]> wrote:
> 

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

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Tue, 21 Mar 2017 15:39:06 +0000

Wes,

Thanks for the clarification. My comments below.

….. snip ….

>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