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
> On Mar 15, 2017, at 6:18 PM, Sriram, Kotikalapudi (Fed)
> 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.
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
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
...@ietf.org; sidr-cha...@ietf.org; Matthias Waehlisch; sidr wg list
Subject: Re: [sidr] BGPsec draft and extended messages
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
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
>> 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.
We are focusing here on the size of the BGPsec_Path attribute.
As I wrote in the rationale part in my other