[tcpm] Q&C regarding tcpsecure-09 recommendations

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.

-- 
Andre

andre@FreeBSD.org

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm