Re: [tcpm] Comments to draft-ietf-tcpm-tcp-edo-13

["D. Wythe" <[e-mail]>]

On 11/24/23 12:44 PM, Yoshifumi Nishida wrote:
> Hi Wythe,
>
> On Wed, Nov 22, 2023 at 10:25 PM D. Wythe <[e-mail]> 
> wrote:
>
>
>     Hi Yoshi,
>
>     Thanks for you comments.
>
>     On 11/23/23 3:26 AM, Yoshifumi Nishida wrote:
>     > Hi Wythe,
>     >
>     > I'm not the author of the draft. But, there are the following
>     texts in
>     > the draft.
>     >
>     > "Once enabled on a connection, all segments in both directions MUST
>     > include the EDO Extension option."
>     > "If EDO has been negotiated, any subsequent segments arriving
>     without
>     > the EDO Extension option MUST be silently ignored."
>     >
>     > So, I think you'll probably see connection timeouts in such cases.
>     > This may look suboptimal behavior, but at the same time, we
>     probably
>     > don't want to think about buggy implementations too much because it
>     > can be endless. The behavior you describe is prohibited by RFC9293.
>
>     I believe that in that case, connections may not end with timeouts
>     but
>     instead receive an erroneous application
>     response from the server. This is because the server does not support
>     EDO, and an incorrectly implemented middlebox
>     copies the EDO support option, which misleading the client.
>
>
> Do you mean incorrectly implemented middle box attaches EDO supported 
> options used in SYN to data packets from the server?
> Or,  the middle box copies EDO extension options to the ACKs from the 
> server for the data packets from the client?
> It's a bit hard for me to believe such behavior.. Because I think it 
> can be complicated to implement such behavior.

I believe that the syn-proxy works similar to following :

real_client proxy_server----proxy_client                         real_server

syn,options(edo_support)
     ----->
            syn,ack,options(edo_support)             (due to the reflecting)
               <------
     ack
     ----->
                                     syn,options(nop)
                                              ----->
                                             syn,ack,options(nop)
                                                    <------
                                     ack
                                     ---->
push, options(edo, large_opt), data(any)
     ------->
(adjust the seq,pass-through)
read()  -> data(large_opt, any)

In this scenario, neither the syn-proxy nor the server support with EDO.
However, due to the incorrectly reflection, the client wrongly assumes 
that the server supports it.

As a result, a fragment containing extensive TCP options and application 
data is transmitted to the server,
then the server misinterprets the extensive TCP options as application data.

>
>     > BTW, I'm curious about how frequently we see this kind of behavior.
>
>     Previously, I had the belief that this might was a widespread
>     scenario,
>     but as I conducted further investigation,
>     I realized that this issue may only exist in specific
>     organizations or
>     regions..
>
>     We are now convinced that this issue is caused by a type of incorrect
>     syn-proxy implementation, who
>     acts as an intermediary to protect against SYN flood attacks by
>     completing TCP handshakes on behalf of clients,
>     preventing server overload.
>
>     The problem is that when the syn-proxy receives a syn from the
>     client,
>     in order to avoid memory allocation and copying,
>     some implementations reuse the SYN packets, exchange IP addresses and
>     ports, and send it out as SYN/ACK to client.
>     Unfortunately, it did not consider the impact of TCP options being
>     simply copied.
>
>     A example I found is:
>
>     https://github.com/iqiyi/dpvs/blob/master/src/ipvs/ip_vs_synproxy.c
>
>      From this perspective, it is worth considering that these issues may
>     only affect certain organizations and regions.
>     I agree with your point about buggy implementations, as these
>     types of
>     issues can be never-ending and are
>     beyond the protocol's control or responsibility to handle.
>
>
> Thanks for the info. But, does it copy options other than SYN or 
> SYN/ACK packets?

After the handshake, it will only adjust the seq and ack-seq.  it only 
acts as a proxy for syn.

Best wishes,
D. Wythe

> --
> Yoshi