Re: [vpp-dev] NAT44-ed state machine

> > If the FIN was received, then this should be okey I think. Both sides are > aware that the session is closing. > > If the FIN and all of its re-transmits are lost, then this can become a > problem indeed. When the other side sends data after an hour, the packets > will be dropped and it ca

Re: [vpp-dev] NAT44-ed state machine

On 18 Mar 2022, at 18:46, Klement Sekera mailto:klem...@graphiant.com>> wrote: On 18 Mar 2022, at 18:43, Ole Troan mailto:otr...@employees.org>> wrote: On 18 Mar 2022, at 17:40, Klement Sekera mailto:klem...@graphiant.com>> wrote: I like the idea of VPP sending RST for cases where the s

Re: [vpp-dev] NAT44-ed state machine

> On 18 Mar 2022, at 18:43, Ole Troan wrote: > > > >> On 18 Mar 2022, at 17:40, Klement Sekera wrote: >> >> I like the idea of VPP sending RST for cases where the session doesn’t exist >> or for some reason the state is invalid. >> >> It might also be a good idea to implement VPP sending

Re: [vpp-dev] NAT44-ed state machine

> On 18 Mar 2022, at 17:29, Miklós Tirpák wrote: > >  > Getting back to some of the topics, > >> >> The main concern about RST was to recover from a 3rd party sending RSTs into >> the session. > This would require the sender to spoof the src IP, right? > Are you aware of any scenario when a

Re: [vpp-dev] NAT44-ed state machine

> On 18 Mar 2022, at 17:40, Klement Sekera wrote: > > I like the idea of VPP sending RST for cases where the session doesn’t exist > or for some reason the state is invalid. > > It might also be a good idea to implement VPP sending TCP keepalives for idle > sessions to discover whether the p

Re: [vpp-dev] NAT44-ed state machine

On 18 Mar 2022, at 17:28, Miklós Tirpák mailto:miklos.tir...@emnify.com>> wrote: Getting back to some of the topics, The main concern about RST was to recover from a 3rd party sending RSTs into the session. This would require the sender to spoof the src IP, right? Are you aware of any scenar

Re: [vpp-dev] NAT44-ed state machine

Getting back to some of the topics, The main concern about RST was to recover from a 3rd party sending RSTs into the session. This would require the sender to spoof the src IP, right? Are you aware of any scenario when an RST followed by subsequent data could happen during a "normal" session an

Re: [vpp-dev] NAT44-ed state machine

Hi, > On 18 Mar 2022, at 12:18, otr...@employees.org wrote: > > Klement, > >>> Following up on this thread. >>> The changes in 34877 led to some undesired behaviour in the "real >>> world(tm)". >>> In the close pattern below it left sessions in established state, and >>> with

Re: [vpp-dev] NAT44-ed state machine

> On 18 Mar 2022, at 12:18, otr...@employees.org wrote: > > Klement, > >>> Following up on this thread. >>> The changes in 34877 led to some undesired behaviour in the "real >>> world(tm)". >>> In the close pattern below it left sessions in established state, and >>> with

Re: [vpp-dev] NAT44-ed state machine

Klement, >> Following up on this thread. >> The changes in 34877 led to some undesired behaviour in the "real >> world(tm)". >> In the close pattern below it left sessions in established state, and >> with a relatively low cps >> would consume the whole session table. >>

Re: [vpp-dev] NAT44-ed state machine

On 18 Mar 2022, at 11:46, otr...@employees.org wrote: Klement, Following up on this thread. The changes in 34877 led to some undesired behaviour in the "real world(tm)". In the close pattern below it left sessions in established state, and with a relatively low c

Re: [vpp-dev] NAT44-ed state machine

Klement, Following up on this thread. The changes in 34877 led to some undesired behaviour in the "real world(tm)". In the close pattern below it left sessions in established state, and with a relatively low cps would consume the whole session table. Th

Re: [vpp-dev] NAT44-ed state machine

> On 18 Mar 2022, at 11:22, otr...@employees.org wrote: > > Thanks for quick replies Klement! > >>> Following up on this thread. >>> The changes in 34877 led to some undesired behaviour in the "real >>> world(tm)". >>> In the close pattern below it left sessions in established state, and with

Re: [vpp-dev] NAT44-ed state machine

Thanks for quick replies Klement! >> Following up on this thread. >> The changes in 34877 led to some undesired behaviour in the "real world(tm)". >> In the close pattern below it left sessions in established state, and with a >> relatively low cps >> would consume the whole session table. >> >

Re: [vpp-dev] NAT44-ed state machine

On 18 Mar 2022, at 10:49, Ole Troan via lists.fd.io mailto:otroan=employees@lists.fd.io>> wrote: Hi, Following up on this thread. The changes in 34877 led to some undesired behaviour in the "real world(tm)". In the close pattern below it left sessions in established st

Re: [vpp-dev] NAT44-ed state machine

Hi, Following up on this thread. The changes in 34877 led to some undesired behaviour in the "real world(tm)". In the close pattern below it left sessions in established state, and with a relatively low cps would consume the whole session table. The change here https://gerrit.fd.io/r/c/vpp/+/35

Re: [vpp-dev] NAT44-ed state machine

Dear vpp-dev, Based on below and after discussion with both Miklos and Andrew I have implemented new TCP state tracking for endpoint-dependent NAT44. Most of the behavior is in line with RFC 7857 and 6146 except for VPP supporting session reopening while an old session is closed (meaning, both

Re: [vpp-dev] NAT44-ed state machine

From: Klement Sekera -X (ksekera - PANTHEON TECH SRO at Cisco) Sent: Monday, January 10, 2022 12:35 PM To: Miklós Tirpák ; vpp-dev Subject: Re: [vpp-dev] NAT44-ed state machine CAUTION: This email originated from outside of the organization. Do not click links or open

Re: [vpp-dev] NAT44-ed state machine

@lists.fd.io on behalf of Miklos Tirpak Date: Monday, January 10, 2022 at 12:33 PM To: vpp-dev , Miklós Tirpák Subject: Re: [vpp-dev] NAT44-ed state machine Hi, I have opened the review https://gerrit.fd.io/r/c/vpp/+/34851 for the first issue, the [SYN, ACK] retransmission. Could you please have a look

Re: [vpp-dev] NAT44-ed state machine

Hi, I have opened the review https://gerrit.fd.io/r/c/vpp/+/34851 for the first issue, the [SYN, ACK] retransmission. Could you please have a look? Thanks, Miklos From: vpp-dev@lists.fd.io on behalf of Miklos Tirpak via lists.fd.io Sent: Wednesday, January 5,