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

["Anantha Ramaiah (ananth)" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Joe Touch
> Sent: Monday, June 02, 2008 5:41 PM
> To: [e-mail]
> Subject: Re: [tcpm] Q&C regarding tcpsecure-09 recommendations
> 
> Hi, all,

Others can comment, but wanted to offer my perspective as one of the
document's authors. Pl find inline responses..

> 
> This is, IMO, a signal to review the recommendations in 
> Section 1.1. I was always concerned that these mitigations 

tcpsecure-09 has been reviewed and that includes the AS. There have been
some general comments received which will be incorporated in the next
revision.

> would be misinterpreted as applying to hosts in general, 
> which they do not.

Actually this is TCP document and hence these mitigations apply to any
system that thinks it needs those. Also the definition between hosts and
routers have diminished long ago. The AS is in place for the very reason
you wanted it to be, i.e, these mitigations are generally useful for
long lived sessions (SHOULD) than short lived (MAY) sessions. A TCP
stack which caters to multitude of applications (short and long lived)
may want to take the super set approach, IMO. It is purely an
implementation decision.


> 
> 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

Source port randomization is one way of adding robustness and does not
every situation. Also you can't assume everyone is doing src port
randomization. Even then having these mitigations would make the attacks
described in the document harder to accomplish.

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

I think this is very obvious in the document. Right from the intro which
talks about the attack vectors, and what is needed to accomplish the
attack. 


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

Yes, this is obvious too due to the challenge ACK being sent.

> 
> 	- 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)

Oh, the way I read the draft the above fact is mentioned all over the
draft.. I can point out all the places if you want, but we have been
thru this before and I have incorporated the feedback received from you
but I am surprised that you are bringing this one up now.

> 
> 	- 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)

Well, I would think that we generally don't want to repeat the same text
all over the document again and again, but if the work group believes in
this redundancy as you semm to do, I am more than willing to add it. 

-Anantha
> 
> 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_inpu
> t.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