Hi,
David Sommerseth wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 16/04/10 19:48, Jan Just Keijser wrote:
man page patch to fix (based on the git page).
- explicit-exit-notify text is misleading : parameter [n] is the number
of attempts not the number of retries
- I would make a statement that a section starting with 'so I would make
a statement' does not belong in a man page
--- new-openvpn.8 2010-04-16 19:16:08.427860657 +0200
+++ jjk-openvpn.8 2010-04-16 19:46:01.374609848 +0200
@@ -3308,8 +3308,8 @@
option will tell the server to immediately close its client instance object
rather than waiting for a timeout. The
.B n
-parameter (default=1) controls the maximum number of retries that the
client
-will attempt to resend the exit notification message.
+parameter (default=1) controls the maximum number of attempts that the
client
+will make to send the exit notification message.
ACK
.\"*********************************************************
.SS Data Channel Encryption Options:
These options are meaningful for both Static & TLS-negotiated key modes
@@ -3591,7 +3591,7 @@
OpenVPN adds to the IPSec model by limiting the window size in time as
well as
sequence space.
-OpenVPN also adds TCP transport as an option (not offered by IPSec) in
which
+OpenVPN also adds TCP transport as an option (not offered by plain
IPSec) in which
Does some IPSec implementations support TCP transport? I thought that
IPSec was OSI layer 3 (network) traffic, while TCP starts on OSI layer 4
(transport).
at least Cisco support IPSec-over-TCP , similarly to IPSec-over-UDP (aka
NAT traversal)
case OpenVPN can adopt a very strict attitude towards message deletion and
reordering: Don't allow it. Since TCP guarantees reliability, any packet
loss or reordering event can be assumed to be an attack.
@@ -3601,11 +3601,6 @@
message deletion or reordering attack which falls within the normal
operational parameters of IP networks.
-So I would make the statement that one should never tunnel a non-IP
protocol
-or UDP application protocol over UDP, if the protocol might be
vulnerable to a
-message deletion or reordering attack that falls within the normal
operating
-parameters of what is to be expected from the physical IP layer. The
problem
-is easily fixed by simply using TCP as the VPN transport layer.
Even though I do agree with you that a "personal message" should not be
in a man page, I also do see the importance of the message given here.
But it can be understood as controversial for some, as it is formulated
in a biased way. If the message given is false, it should be removed as
well. But I'd rather see this whole paragraph being rephrased, reworked
and become a bit more unbiased towards the TCP/UDP discussion.
Now it can be understood that TCP is the best security solution - but
that's when you only read this little paragraph. Changing from TCP to
UDP also got it's fair share of advantages and disadvantages as well,
which should be covered somehow in the man page.
to me the last paragraph seems like a rehash of the previous one, with
wording like "I would make a statement bla bla" . I don't know who wrote
the original paragraph but at the very least the wording should be
changed such that
- it is no longer a personal message
- it adds value to the paragraph above.
I tried rewriting the Personal Message paragraph myself but ended up
with something almost identical to the paragraph right above it.
Could we please split these three changes into three different patches,
as they cover three different parts of the man page and tracking their
changes separately is cleaner when people try to figure out what was
discussed and which conclusions was made.
no problem; I'll send another man page patch.
cheers,
JJK
