RFC1948

[Jason Thorpe]

RFC6528 is standards-track:

https://www.rfc-editor.org/info/rfc6528

...so why this change instead?

Module Name: src
Committed By: christos
Date: Mon Mar 8 18:17:27 UTC 2021
src/sys/netinet: tcp_input.c tcp_subr.c tcp_usrreq.c tcp_var.h
Remove the unused "addin" argument (it was always 0) and go back using
a random iss by default (instead of rfc1948)
cvs rdiff -u -r1.427 -r1.428 src/sys/netinet/tcp_input.c
cvs rdiff -u -r1.286 -r1.287 src/sys/netinet/tcp_subr.c
cvs rdiff -u -r1.228 -r1.229 src/sys/netinet/tcp_usrreq.c
cvs rdiff -u -r1.194 -r1.195 src/sys/netinet/tcp_var.h
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

-- thorpej


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Christos Zoulas]

Post by Jason Thorpe
https://www.rfc-editor.org/info/rfc6528
...so why this change instead?

This change just simplified the existing code, and restored the
default randomization behavior prior without the information leak.
I will look into implementing rfc6528.

Best,

christos


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jason Thorpe]

Post by Christos Zoulas
This change just simplified the existing code, and restored the
default randomization behavior prior without the information leak.
I will look into implementing rfc6528.

6528 is an incremental change on top of 1948, so it should be pretty easy to do. Among other things, it explicitly addresses the concern I had with 1948 at the time I implemented it in our kernel (which is the reason is remained disabled by default -- discussing the issue with Steve was a roundtuit whose box never got ticked) -- specifically, the explicit suggestion to re-key and how to deal with the fact that you're in a new SN universe when a re-key occurs.

A few weeks ago Taylor had asked me what my concerns where (because the fact that concerns existed was spelled out in the commit message at the time), but it had been long enough that they had been pushed off to tertiary storage and it took a while to page them back in :-)

-- thorpej


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Fernando Gont]

Hi,

Just happened to see this one.

Note: a randomized ISN is better in terms of security, but may result in
connection establishment failures (see the RFC6528).

TL;DR; BSD have an optiomization where a new incarnation of a
previous connection is created if the four-tuple (src addr, dst addr,
src port, dst port) is the same as that of the previous incarnation, but
the ISN of the new incarnation is larger than the last SEQ seen in the
previous incarnation for that direction of the connection.

IOW "if the same four tuple is employed for the new connection, the
connection will nevertheless succeed if the ISN of the new connection is
larger than the SEQ of the previous connection2.

Cheers,
Fernando
(who happens to be a co-author of RFC6528 :-) )

Post by Jason Thorpe
https://www.rfc-editor.org/info/rfc6528
...so why this change instead?

Module Name: src
Committed By: christos
Date: Mon Mar 8 18:17:27 UTC 2021
src/sys/netinet: tcp_input.c tcp_subr.c tcp_usrreq.c tcp_var.h
Remove the unused "addin" argument (it was always 0) and go back using
a random iss by default (instead of rfc1948)
cvs rdiff -u -r1.427 -r1.428 src/sys/netinet/tcp_input.c
cvs rdiff -u -r1.286 -r1.287 src/sys/netinet/tcp_subr.c
cvs rdiff -u -r1.228 -r1.229 src/sys/netinet/tcp_usrreq.c
cvs rdiff -u -r1.194 -r1.195 src/sys/netinet/tcp_var.h
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

-- thorpej

--
Fernando Gont
SI6 Networks
e-mail: ***@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de