Implement ECN++ (draft-generalized-ecn)

[rscheff]

Summary

RFC3168 only allows regular data segments to be sent as
ECN-capable transport (ECT). Control (RST, FIN), pure ACK
and retransmissions are explicitly not to be sent with ECT.

However, it has been shown over the years, that this
approach stifles the usefulness of ECN, in particular when
deploying DCTCP in controlled environments.

Current work in the IETF (draft-generalized-ecn, also known
as ECN++) aims to allow all control and retransmission
packets to be marked ECT. In the case of retransmissions,
the only standardized recourse when one of those is dropped,
is to wait for the RTO timer to expire - including the
penalty imposed by having to suffer an RTO.

Furthermore, allowing control and pure ACKs to convey
additional congestion signals on the return path enables
features like AckCC (RFC5690).

Also, adding code to make non-session related control packets
(eg. RST to non-listening ports) appear idential with those in
response to recently used sessions, to prevent sidechannel
information leakage.

Test Plan

Attaching packetdrill scripts for full coverage

[rscheff]

• updated timestamp in man file

[rscheff]

• rebase
• streamline fastpath check
• update man date

[rscheff]

• have to explicitly check for ECN SYN

[rscheff]

• add TF2_ECN_PLUSPLUS flag to reduce cacheline churn in fastpath when checking V_ecn_generalized

[rscheff]

• rebase

[rscheff]

• rebase
• bump tcp.4 datestamp

[pauamma_gundo.com]

share/man/man4/tcp.4

717

723–724

Typo and move full stop to a more natural place.

[bjk]

Current work in the IETF (draft-generalized-ecn, also known as ECN++)

http://datatracker.ietf.org/doc/draft-generalized-ecn does not return a document.
The IETF TSV WG is where I would expect any such work to be done, but
https://datatracker.ietf.org/wg/tsvwg/documents/ does not appear to show
any documents that might be given the moniker "ECN++". Could you provide
a better reference or link for the draft specification that is being implemented?

[rscheff]

Interesting. I could find this right away: ECN++: Adding Explicit Congestion Notification (ECN) to TCP Control Packets

Here is the history

[rscheff]

• fix man page typos

[rscheff]

Thanks!

[bjk]

In D23230#771332, @rscheff wrote:

Interesting. I could find this right away: ECN++: Adding Explicit Congestion Notification (ECN) to TCP Control Packets

Here is the history

Ah, a TCP-specific draft, not generic to all ECN usage. So I was looking in the wrong place :)
Thanks for the pointer.

[pauamma_gundo.com]

LGTM now.

[pauamma_gundo.com]

In D23230#771360, @pauamma_gundo.com wrote:

LGTM now.

By which I mean, the language in the manual page change does. Can't say more.

[bcr]

Typo in man page.

share/man/man4/tcp.4

729

s/identially/identically/

[rscheff]

• fix typo in man page

[bcr]

OK for the manpages part of the change.

[rscheff]

• rebase
• simplify the fastpath check if ECT should be set.
• streamline fastpath check
• update man date
• have to explicitly check for ECN SYN
• add TF2_ECN_PLUSPLUS flag to reduce cacheline churn in fastpath when checking V_ecn_generalized
• bump tcp.4 datestamp
• fix man page typos
• fix typo in man page
• update to use the common tcp_ecn.c sourcefile
• fix types

[pauamma_gundo.com]

share/man/man4/tcp.4

728–729

Can you explain what you mean by that? I'm arguably not the indended audience, but if I don't understand it, there's a chance some of the intended audience and or some interested readers won't either.

[rscheff]

share/man/man4/tcp.4

728–729

When a host receives a TCP packet to a port which is not listening, or no connection exists, or the header information is in some other way not acceptable, the host may respond with a RST (reset) packet. Some of these RST packets are sent from "regular" TCP processing (e.g. outside the sequence window) and others from non-open ports. Making these distinctable by carrying different markings - depending which code path was sending them - would give clues as to what ports/services may be reachable, and give rise to more targetted attacks.
As part if this change, when introducing this new capability (modified TCP header markings for sessions), the irregular codepath is addressed too, such that a 3rd party can not deduct which of the two different paths was sending out the RST, reducing an information side-channel.

[pauamma_gundo.com]

share/man/man4/tcp.4

728–729

Gotcha, thanks. Would "This value also uses ECN for RST replies to probes of non-open ports." mean the same? It looks clearer to me.

[rscheff]

• rebase
• make tcp_ecn_get_ace static inline
• include accecn for ecn++
• fix ecn bits in timewait
• fix syn-sent ip_ecn marking

[pauamma_gundo.com]

Mnor wording nit, can be fixed on commit.

share/man/man4/tcp.4

707–708

[rscheff]

• update man page wording

[rscheff]

• include ect0 for tcp_respond()

[rscheff]

• remove logging

[pauamma_gundo.com]

Manual page unchanged besides the bumped Dd.

[rscheff]

• rebase
• bump man date
• remove duplicate code

[pauamma_gundo.com]

share/man/man4/tcp.4

911–912

Was removing this intended as part of this review?

[rscheff]

share/man/man4/tcp.4

911–912

I'm confused, there is no change here on reviews.freebsd.org; it may be that this diff was uploaded just prior to a flurry of tcp related (including man page) changes, which I have not yet rebased the patch to...

[rscheff]

• rebase
• use ect1 if session is using that

[rscheff]

• use switch statement instead of if else

[rscheff]

• rebase and align

[rscheff]

• rebase main

[rscheff]

• rebase main