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

[Jeffrey Haas <[e-mail]>]

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] <mailto:[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 <http://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] <mailto:[e-mail]>> 
> Sent: Tuesday, January 10, 2023 3:20 PM
> To: Jeffrey Haas <[e-mail] <mailto:[e-mail]>>
> Cc: Donatas Abraitis <[e-mail] <mailto:[e-mail]>>; Alvaro Retana <[e-mail] <mailto:[e-mail]>>; Jakob Heitz (jheitz) <[e-mail] <mailto:[e-mail]>>; Bruno Decraene <[e-mail] <mailto:[e-mail]>>; IDR List <[e-mail] <mailto:[e-mail]>>; John Scudder <[e-mail] <mailto:[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] <mailto:[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] <mailto:[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/ <https://www.iana.org/assignments/enterprise-numbers/>
> 
> -- 
> Donatas Abraitis
> Principal Systems Engineer
> @: [e-mail] <mailto:[e-mail]>
> W: www.hostinger.com <https://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.