Hi Robert, We write standards to serve those who implement, deploy, and manage the technology. That means among other things, that our documents need to be specific enough to enable interoperable implementations to be written. Simply saying “the intention is to run BGP over TLS” (or some variation on that theme) is not sufficient to let two implementors, working in isolation, produce two implementations that interoperate.
In many cases the necessary details will be quite brief — the I-D you pointed to earlier in the thread is a total of 6 pages, of which only about a page is the core. [1] But without them, you can’t say you’ve written a complete specification. One possible way around this is to write something to the effect of “details of how to secure this protocol are beyond the scope of this document”, and leave it as an exercise for the reader to fill in the needed parts. That approach might run into other objections, though, I’m not recommending it. I don’t entirely understand the point you’re making in your final paragraph, but perhaps you’re suggesting that my position is a slippery slope leading to a requirement to spec every protocol over every other protocol. If so, that is a misunderstanding. What I’m saying is, if a spec takes the position that the security architecture for foo is to run over transport bar, then there need to be sufficient details of how to run foo over bar, either in the document or referenced. That doesn’t imply that foo also has to be specified over baz, faz, and qux, even if it’s technically feasible to run it that way. —John [1] This is not an endorsement of that I-D. > On Feb 6, 2024, at 3:40 PM, Robert Raszuk <rob...@raszuk.net> wrote: > > Hi John, > > I think I am getting to what you are saying ... or maybe not. > > If I am reading it correctly you say that running BGP over TLS or DTLS is not > standardized hence we should be very careful in putting this in the new > documents. > > Would you be of a different opinion if authors say instead that the intention > is to run BGP over TCP over TLS or DTLS ? > > If so for clarity I would think this could be a helpful editorial change. > > If however you are saying that when defining a new transport be it some form > of tunnel (EVPN, SR, MPLS over IP, MPLS over MPLS etc ...) we need to recycle > all protocols which run over TCP or UDP to sort of bless them for running on > such new transport then I think this is not achievable in our short life > time. > > Best, > R. > > > > > On Tue, Feb 6, 2024 at 9:30 PM John Scudder <j...@juniper.net> wrote: > > On Feb 6, 2024, at 2:48 PM, Robert Raszuk <rob...@raszuk.net> wrote: > > > > I have been using BGP over TCP over TLS and BGP over TCP over DTLS for > > years testing Sproute's SDWAN solution. Works perfectly fine. In fact it > > performs much better then BGP over TCP over IPSec. > > Cool. There are a great many things in the world that work and are nice but > haven’t been standardized. We tend to avoid basing standards on them. > Sometimes we do say “oh hey I’d like to base a standard on foo” and so we > make an RFC for foo so that we have something to cite. But AFAICT that is not > currently the case with the present example. > > —John _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
