On 8/21/2014 9:22 AM, Christian Grothoff wrote:
On 08/21/14 06:16, Joe Touch wrote:
On 8/18/2014 3:07 PM, Scheffenegger, Richard wrote:
Hi Alfie,
my concern is with the use of a static ISN for each 4-tuple; this
significantly increases the chance of a collision between sessions (ie.
when the sender terminates a sluggish earlier session, some segments of
that last session will very likely be in-window for a session that was
started a short time later).
+1, and I haven't seen a satisfactory answer to this yet.
FWIW, the doc refers to TCP MD5, which has been deprecated and replaced
by TCP-AO. TCP-AO has an experimental extension to support NAT traversal.
Well, several people seem to suggest that making the use of TSval
_mandatory_ with TCP Stealth would solve this and other concerns; so if
we put that into the draft, would you be happy?
You still have the ISN validity to deal with. TSval helps differentiate
wrap - i.e., first use of a sequence number space vs. future use. Your
ISN calculation could easily generate an ISN that's valid for the TSval
used.
Additionally, responding with a TCP RST isn't the best response if
you're trying to hide from port knocking. Silence is best in that case.
That depends on what the system does for a closed port.
No, it depends on what the system does for a port for which no process
is listening. CLOSED is a TCP state. RST says something is listening on
the connection but doesn't want to talk to you given the SYN parameters
you gave.
ICMP destination unreachable/port unreachable seems more what you're
aiming for if you want to prevent someone from trying again.
Joe
The draft says
the system should react in the same way as it usually does, and usually
MY servers respond with TCP RST if the port is closed. If you usually
drop, you should drop. If this is about hiding, the key thing is to not
change the behavior for the stealth-open port in relation to the
behavior of a closed port.
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
