I'm not sure about what I'm going to say... But. BMP would transfer sensible data. Then some cryptographic layer would be recommended/necessary.
Considering that, following on this approach of "fast connection", will not have time/space to negotiate some crypto on those fast reconnections. So I presume something above(separate from the transport layer) will need to deal with that cryptographic layer, right? Em qua., 10 de mar. de 2021 às 06:04, Job Snijders <job= 40fastly....@dmarc.ietf.org> escreveu: > On Wed, Mar 10, 2021 at 03:08:34AM +0000, Jakob Heitz (jheitz) wrote: > > >From the BGP speaker (client) implementation point of view, > > > > I would do it like this: > > The client keeps a ring buffer of data it sent to the server. > > The bottom of the buffer is at a certain sequence number. > > As messages are created, that bottom moves up. > > If the server were to restart, it would send its last > > received sequence number and session ID. If the buffer still > > contains the sequence number, then you're in luck, else > > big bang restart. > > The content of the buffer could be optimized by retrieving some > > of the information from the bgp table (adj-rib's are conceptual only) > > instead of literally storing it. How and if any optimization is > > done is implementation specific and not part of an RFC. > > In the 'Sent: Tuesday, March 9, 2021 4:50 PM' email sequence/serial > numbers are not required, only a 'session id' (which might remain the > same over the lifetime of the BMP client's lifetime). > > A full 'big bang' restart is achieved by the server disconnecting and > allowing reconnection twice, within the 60 second window. When combined > with TCP_FAST_OPEN resuming a session requires 2 packets (one each way) > and restarting a session requires 4 packets. > > This way BMP remains a 'read only' protocol, but I admit this is > an unconventional approach. > > Kind regards, > > Job > > _______________________________________________ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow > -- Douglas Fernando Fischer Engº de Controle e Automação
_______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
