SEO

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



``RFC 1323, TCP Extensions for High Performance, Appendix A'' contains a
recommendation respected by OpenBSD but not optimally applied also
in the SYN packets:

[ Network Working Group V. Jacobson
[ Request for Comments: 1323 LBL
[ Obsoletes: RFC 1072, RFC 1185 R. Braden
[ ISI
[ D. Borman
[ Cray Research
[ May 1992
[
[
[ TCP Extensions for High Performance

....

[ APPENDIX A: IMPLEMENTATION SUGGESTIONS
[
] The following layouts are recommended for sending options on non-SYN
] segments, to achieve maximum feasible alignment of 32-bit and 64-bit
] machines.
]
]
] +--------+--------+--------+--------+
] | NOP | NOP | TSopt | 10 |
] +--------+--------+--------+--------+
] | TSval timestamp |
] +--------+--------+--------+--------+
] | TSecr timestamp |
] +--------+--------+--------+--------+

I think that the NOP aspect of ``Appendix A'' is not recommendable,
so the presence of NOP options is only valid as an example,
the alignment of timestamp is the real recommendable aspect.


The layout, equivalent in efficiency, should be:

[The ``octects binary network addresses'' are specified as pattern
for each columns in the headline]

...00 ...01 ...10 ...11
+--------+--------+--------+--------+
| . . . | . . . | TSopt | 10 |
+--------+--------+--------+--------+ network address +100(=+4)
| TSval timestamp |
+--------+--------+--------+--------+
| TSecr timestamp |
+--------+--------+--------+--------+

Where the unspecified part could be efficiently filled with
(in order of preference):
one 2-octets in length option,
two 1-octet in length options,
one 1-octet in length option followed by NOP(0x01) or
a double NOP.

So, in the non-SYN packets the preference of NOP for alignment
is opportune because the TS is typically the only option.


32bit-only-minimum machines have just to filter the NOPs (or other
options) in the alignment position with one bitwise operation.

The agreeable part of the appendix A, is to avoid the following
impolite alignment (in theory permitted by TCP):
+--------+--------+--------+--------+
| TSopt | 10 | TSval timestampH..
+--------+--------+--------+--------+
..TSval timestampL| TSecr timestampH..
+--------+--------+--------+--------+
..TSecr timestampL|
+--------+--------+

which is only 16 bits shorter, but in an expensive way.


The proof is in the code, my modification to an Operating
System respecting the appendix. (resulting more efficient
on 16bit-also architectures because it access pieces of
16bits of memory insted of 32, 4 byte less are sent to the network
each syn packet, and more interoperative because it identifies
the TSopt header with the 16 bit value of TSopt header).

I applied to OpenBSD, CVS from :ext:anoncvs@anoncvs.ca.openbsd.org:/cvs
$ grep openbsd /home/mar/.ssh/known_hosts
anoncvs.ca.openbsd.org,129.128.5.191 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAsQpVyGYI7vjnNUfWBSQe2j q9Fdgv/S4/yvBSIcRhPpuyPeUlNxLf9Vey9paxbowhcCyu+xk/Mwz+L15UPg9If2PYN0NG7+ayNqTpS+eP6bE6rbqtCdFSBEM9zR uZUln14kGwSgJYQqcT/qDt80Ro8Z+zSh9MCQuLbIrspSKYx88=

the operating system fingerprint can be identified with the following:
16384:64:1:60:M*,N,W0,S,T: OpenBSD:3.8:mm-obsd:OpenBSD 3.8 (MunARi)



The improvement described above in the OpenBSD TCP/IP code, involves
the files tcp_input.c, tcp_output.c and tcp.h.

I prefere to publish the link (following) for the patch for trace logging,
(this mail is mirrored and published)

http://mm.homeunix.org:8380/pub/impr...rnel/tcp.patch

Dear developers, thanks for the wonderful work, OpenBSD is a great
Operating System.

Some of other my improvements are available at
http://mm.homeunix.org:8380/allerta/

Saluti,
MARco
- --
x(t),y(t) = th(3t-34.5)*e^[-(3t-34.5)^2]/2-4.3+e^(-1.8/t^2)/(.8*atg(t-
3)+2)(t-1.8)-.3th(5t-42.5),(1.4e^[-(3t-34.5)^2]+1-sgn[|t-8.5|-.5]*1.5*
|sin(pi*t)|^[2e^(-(t-11.5)^2)+.5+e^(-(.6t-3.3)^2)])/(.5+t)+1 ; 0<t<14
PGP key (5056R/47EC1B7A): A04A 7CEA E600 4776 B8AF D868 B71F F74D 47EC 1B7A
iQKNAwUBQ9Y7hLcf901H7Bt6AQIygxPAk0BTkrZ5Oezkfe5mjq guVl13xScWjC+1
qOKLmOKExtB3sYXVpenFBykfLf+93AlicV4+47uAdNBdM8tkJL cZZAyZgeZLQQCo
sDHT8bVCxPIISF+tn7gpMdTCEF8k0sQl+em/o/CjUN5Rgbj+MeZrQo0Gosey+UyU
xhUbYiiyneCyi7n46bIxDjoR7fdq5uB4WviqHTc50gPG6Qb0nP +8NAG8LOUVzjMl
UZD27ShEuZu3Y9WA+wS/k3ebjfgIMLDHNrRTEhMBAOQtTgC4YNS2x1z2o6R2ebBU
q0rR5lzHvLqpcRdntauMag918AUKWhjgXcrMNkBihpID9fks0A lyzDrM0QggP5e6
QXxKLCLNrxWGQ6F4RAhQ3D6pTYwvJmuN/98TmaTuJQmmf+vuQTt1k7wKJsn4ZXda
KtkQdv9X8Z/UUDk8x1wP2w9xOOwsg/jo09YsKSV1twYConVU8caEIis8MZt/d0iV
fKI3xw9+BptX26kaAXqeTd3WTeHQj05ufRUQwlrRMsfv7bCxMp E+9ufMrrZEhARF
ZLyFXtGitF52qULKs8ne87mQC+CYrVTrXUS6bQ3krN0IbMxNS0 awk1vYfVPj0Z06
i3HOeTWdmmGkfmEWnN66CDsZaV3vxgjvQboY2O/WESgJTtw3kZvhe46cOyeyHAII
XPSzn6ODwNayvn7WgDtEg4xQp+Rq3imXf23v5QGNZMizNRpEYu W0AdAyVpLlZ3S+
MhPNhhkydT5qhdF1BlFqjQca/DGwWd5YZJiBGCaJhXFx8OqRl2U5Jlzm3PCoQoEV
dIaiahdC8gxu35usvFKILAeTDKZE3fs0h7IhHzbpui0=
=Gv/h
-----END PGP SIGNATURE-----