Re: [Idr] WG adoption call for draft-abraitis-bgp-version-capability-08, to end September 25

[Robert Raszuk <[e-mail]>]

Jeff,

> My personal preference?  Capability, adopted by the WG.

Just to make sure I got it correctly ...

You are willing to send free form text as BGP Capability ?

You are ok to burn 25% of space designated for BGP Capabilites ?

You are ok to punch holes in BGP Capability Negotiation for it ?

You are willing or not willing to suppres Unsuported Capability when such
is received on non upgraded node ?

etc ...

What if tomorrow we will see another draft asking for FCFS type from
https://www.iana.org/assignments/capability-codes/capability-codes.xhtml to
support other free form text there ? I bet there is tons of other stuff
compute nodes are willing to share with the network ...

Many thx,
Robert








On Wed, Jan 11, 2023 at 2:27 PM Jeffrey Haas <[e-mail]> wrote:

> Donatas,
>
>
> On Jan 11, 2023, at 7:49 AM, Donatas Abraitis <
> [e-mail]> wrote:
>
> >Roughly the right idea, but your examples probably don't quite hit the
> level of specificity that you're looking for.  For example, Juniper has
> different products that ship as a given version number and may vary
> slightly by platform.
>
> That's why a free form is IMO just a way to go because who knows what's
> gonna happen with the format vendors are planning to use?
>
> >If we would use URL to carry a pointer to the information the URL can be
> shortened to be a fixed length of a few characters which could be really
> easy to process and presented  to users in a pretty uniformed way
> across any receiver.
>
> I don't think this is the right place to show URLs and even more, waste
> the operator's time (automated or not).
>
>
> I just flipped through some of the past commentary on this thread. The
> main reason to point you at the SBOM work is it seemed to overlap with some
> of the issues other operators who are a bit more rigorous about their
> software component work are currently working through.  Given discussions
> I'm seeing at the day-job, it's likely we'll end up with some flavor of
> that proposal sooner or later.
>
> That said, I'm not going to try to push you to put it into your draft.
> You want free-form text?  Go for it.  I'm of mixed opinion whether I'd
> recommend my employer deploy the feature in that form.  You can see the
> tension on a desire for structured content vs. free-form from the original
> thread.
>
> Taking a step back and putting on my chair hat:
> - If you want this as an optional parameter, the barrier is higher since
> the code point is IETF Review.  It's not insurmountable.
> - The capability format you had originally still has first-come,
> first-served space widely available.  If you want to deploy this
> immediately, flip your document back and just send a note to IANA to ask
> for one.  You'll likely have an allocation in a few days.  You can then
> ship in a registered code point in very short order whether or not the
> obstructionist faction in IDR wants you to or not.  Submit to ISE soon
> thereafter if you like, or feel free to take your solution through the rest
> of the WG process.
>    + I still recommend extended optional parameter support as a required
> feature.
>
> My personal preference?  Capability, adopted by the WG.  While I'd prefer
> to address the wider work the SBOM stuff will be taking IETF through over
> the next two years, that can come later.
>
> -- Jeff
>
>
>
> On Wed, Jan 11, 2023 at 2:13 AM Jakob Heitz (jheitz) <[e-mail]>
> wrote:
>
>> I think if we can settle on a way to avoid collisions, it should be fine.
>>
>> So, in my case, for example: “
>> cisco.com/XR.7.9.1/optionalstringtoencodefeatures”.
>>
>> I promise not to send my customers’ peers to malicious websites.
>>
>>
>>
>> Regards,
>>
>> Jakob.
>>
>>
>>
>> *From:* Robert Raszuk <[e-mail]>
>> *Sent:* Tuesday, January 10, 2023 3:20 PM
>> *To:* Jeffrey Haas <[e-mail]>
>> *Cc:* Donatas Abraitis <[e-mail]>; Alvaro Retana <
>> [e-mail]>; Jakob Heitz (jheitz) <[e-mail]>; Bruno
>> Decraene <[e-mail]>; IDR List <[e-mail]>; John
>> Scudder <[e-mail]>
>> *Subject:* Re: [Idr] WG adoption call for
>> draft-abraitis-bgp-version-capability-08, to end September 25
>>
>>
>>
>> Hi Jeff,
>>
>>
>>
>> Very good points.
>>
>>
>>
>> But I am not sure if they are really applicable here ?
>>
>>
>>
>> Keep in mind that we are talking about p2p BGP OPEN Msg between PE & CEs
>> (computes with lot's of machines - bare metal or virtual). Moreover what is
>> proposed is really informational with little to no bearing into operational
>> aspects of the subject BGP session.
>>
>>
>>
>> So while I am all for making right, robust and secure protocol encoding
>> decisions it seems that especially in BGP we have lot's of other security
>> holes which if exploited could have a much bigger negative impact.
>>
>>
>>
>> Regards,
>> R.
>>
>>
>>
>> On Wed, Jan 11, 2023 at 12:11 AM Jeffrey Haas <[e-mail]> wrote:
>>
>> Robert,
>>
>>
>>
>> Please note that the points I'm about to make is intended to more broadly
>> discuss the URL issue and isn't saying you're making these recommendations.
>>
>>
>>
>> On Jan 10, 2023, at 5:47 PM, Robert Raszuk <[e-mail]> wrote:
>>
>>
>>
>> I would like to just highlight one IMHO very cool property hidden in yr
>> note ... If we would use URL to carry a pointer to the information the URL
>> can be shortened to be a fixed length of a few characters which could be
>> really easy to process and presented  to users in a pretty uniformed way
>> across any receiver.
>>
>>
>>
>> Before we move forward with any specific shortened-URL proposal, it's
>> likely we'll want to get comment from those with expertise in the security
>> implications of shortened URLs.
>>
>>
>>
>> Certainly, many vendors maintain a domain name for shorter URLs for
>> various contexts.  That's likely not the main concern.
>>
>>
>>
>> URL shortening services are probably a Very Bad Idea since they're in an
>> entire vector of attacks on their own.
>>
>>
>>
>> (We also introduce all of the interesting headaches about interaction
>> with the PKIX certificate infrastructure.  See my prior comments in the BGP
>> autoconfiguration discussions if you're interested.)
>>
>>
>>
>> One possible mitigation for some of the attacks given the problem to be
>> addressed is to permit an IANA registered prefix for the URI/URL.  This
>> means rather than carrying a potentially long URL to a specific resource,
>> you carry something like the Private Enterprise Number's[1] instance of
>> your registered prefix and a suffix portion of the URL.  The rest of the
>> data is contained in the structured data at the other side of the expanded
>> URL.
>>
>>
>>
>> I'd encourage Donatas to continue the discussion on such structured data
>> before we worry over-much about how to point to it in BGP. :-)
>>
>>
>>
>> -- Jeff
>>
>>
>>
>> [1] https://www.iana.org/assignments/enterprise-numbers/
>>
>>
>
> --
>
> *Donatas Abraitis*
> *Principal Systems Engineer*
> @: [e-mail]
> W: www.hostinger.com
>
>
> This message and its attachments may contain privileged and confidential
> information. If you are not the intended recipient, do not use, copy, or
> disclose this information. Please notify the sender and permanently delete
> the message from your system.
>
>
>