Re: [tcpm] Q&C regarding tcpsecure-09 recommendations

[Joe Touch <[e-mail]>]

Hi, all,

This is, IMO, a signal to review the recommendations in Section 1.1. I 
was always concerned that these mitigations would be misinterpreted as 
applying to hosts in general, which they do not.

The document, IMO, is insufficient in indicating therein that:

	- with source port randomization, the mitigations are not needed
	(port randomization provides a 2^15 strength amplification),
	even presuming source IP addresses are known

	- if source IP addresses are not known, the mitigations are not
	needed

	- the mitigations may increase the time needed to respond to
	a legitimate RST, incurring extra RTTs or retransmissions
	vs. an unmodified system

	- the mitigations are not a substitute for network or
	transport authentication, either of which obviate the need
	for the mitigations (yes, this is noted in the security
	considerations, but it's buried w.r.t. applicability)

	- the mitigations protect only off-path attacks; on-path
	attacks, such as ISPs shutting connections down deliberately,
	are not prevented by this mitigation (yes, also noted
	in security considerations, but again worth noting in
	applicability, and worth adding the ISP example, IMO)

It seems like these ought to be added, in light of the note below.

Joe

Andre Oppermann wrote:
> I'm reworking/refactoring/rewriting the FreeBSD TCP input path (in a separate
> perforce tree at the moment) and in that process I'm evaluating all assumptions
> and test them against a close reading of all relevant RFCs.
> 
> While reading and applying draft-ietf-tcpm-tcpsecure-09.txt I've come across a
> couple of inconsistencies and issues that require further clarification:
> 
> Section 3.2 Mitigation of Blind RST
> 
>   [Real world observation]
>   Some implementations send the RST not on rcv_nxt but on rcv_nxt-1 or
>   rcv_nxt+rcv_win.  Thus we accept three small windows of rcv_nxt(+-1),
>   last_ack_sent(+-1) and rcv_nxt+rcv_win(+-1).
> 
>   Of course the challenge ACK should have the same effect at the expense
>   of another round trip.  While these three (two in case of rcv_nxt == last_ack_sent)
>   do increase the chances of a succesful attack (only every third seq# has to
>   be probed plus the average hit rate is increased due to having two/three
>   different places that match) real world behavior and interop should be
>   considered and discussed.
> 
>   http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_input.c#rev1.316
>   http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_input.c#rev1.259
> 
> 
> Section 4.2 Mitigation of Blind SYN
> 
>   [Possible inconsistency in text]
>   The test in 4.2 eq. 1) is a little different.  In RFC793 it is:
> 
>    RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND
> 
>   in tcpsecure it is described as one byte larger beyond the real window:
> 
>    RCV.NXT <= SEG.SEQ <= RCV.NXT+RCV.WND.
> 
>   This seems to be incorrectly transcribed.
> 
> 
> Section 5.2 Mitigation of Blind data injection attack
> 
>   [Clarification]
>   Data that doesn't satisfy the new check in first paragraph MUST be discarded
>   silently. Before RFC793 used to require an ACK to be sent back. This change
>   is not sufficiently explained and lacks an obvious rationale.
> 
>   The second related issue is where this check should be placed relative to
>   RFC793 ordering?  Before the fifth check, last sentence (page 72) "If the ACK
>   acks something not yet sent (SEG.ACK > SND.NXT) then send an ACK, drop the
>   segment, and return." or right after it?  This has implications on the response
>   as tcpsecure requires to silently discard the segment.  If it weren't for the
>   silent discard the new tcpsecure check could simply replace/extend the fifth
>   check from RFC793.
> 
> 
> Feedback appreciated.
> 

_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm