Page MenuHomeFreeBSD

Implement ECN++ (draft-generalized-ecn)
Needs ReviewPublic

Authored by rscheff on Jan 17 2020, 11:28 AM.
Tags
None
Referenced Files
Unknown Object (File)
Feb 20 2024, 2:42 PM
Unknown Object (File)
Feb 15 2024, 1:20 AM
Unknown Object (File)
Jan 19 2024, 10:55 PM
Unknown Object (File)
Dec 20 2023, 1:38 AM
Unknown Object (File)
Dec 10 2023, 1:32 AM
Unknown Object (File)
Nov 30 2023, 1:13 AM
Unknown Object (File)
Nov 29 2023, 3:21 AM
Unknown Object (File)
Nov 27 2023, 1:14 PM

Details

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

Diff Detail

Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 31128
Build 28811: arc lint + arc unit

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
rscheff retitled this revision from Implement ECN+ (RFC5562) and ECN++ feature (draft-generalized-ecn) to Implement ECN++ (draft-generalized-ecn) .Feb 8 2021, 3:05 PM
rscheff edited the summary of this revision. (Show Details)
rscheff retitled this revision from Implement ECN++ (draft-generalized-ecn) to Implement ECN++ (draft-generalized-ecn).
  • updated timestamp in man file
  • rebase
  • 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
  • rebase
  • bump tcp.4 datestamp
pauamma_gundo.com added inline comments.
share/man/man4/tcp.4
659
665–666

Typo and move full stop to a more natural place.

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?

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

LGTM now.

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

Typo in man page.

share/man/man4/tcp.4
671

s/identially/identically/

OK for the manpages part of the change.

  • 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
share/man/man4/tcp.4
670–671

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.

share/man/man4/tcp.4
670–671

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.

share/man/man4/tcp.4
670–671

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.

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

Mnor wording nit, can be fixed on commit.

share/man/man4/tcp.4
491–492
rscheff marked an inline comment as done.
  • update man page wording
  • include ect0 for tcp_respond()

Manual page unchanged besides the bumped Dd.

  • rebase
  • bump man date
  • remove duplicate code
share/man/man4/tcp.4
522–523

Was removing this intended as part of this review?

share/man/man4/tcp.4
522–523

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...

  • rebase
  • use ect1 if session is using that
  • use switch statement instead of if else