Re: [secdir] review of draft-ietf-tcpm-tcpsecure-11.txt

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

Sandra,
    I am in the process of integrating all the last call comments
received. I need some clarfications on some of your comments. Pl look
for ANA> 

> -----Original Message-----
> From: Sandra Murphy [mailto:[e-mail]] 
> Sent: Wednesday, May 06, 2009 11:32 AM
> To: Mitesh Dalal (mdalal)
> Cc: [e-mail]; [e-mail]; 
> [e-mail]; 
> [e-mail]; Anantha Ramaiah (ananth)
> Subject: RE: review of draft-ietf-tcpm-tcpsecure-11.txt
> 
> On Tue, 28 Apr 2009 11:31:01 -0700, Mitesh Dalal wrote:
> 
> Comments below in-line.
> 
> >Hi Sandra,
> >
> >Thank you for taking time to review the draft. Please see inline.
> >
> >
> >---------- Forwarded message ----------
> >Date: Thu, 23 Apr 2009 14:19:11 -0400 (Eastern Daylight Time)
> >From: Sandra Murphy <[e-mail]>
> >To: [e-mail], [e-mail],
> >[e-mail],
> >     [e-mail]
> 
> ><snip>
> 
> 
> >This document is intended to update rfc793.  That means that 
> it should 
> >be very explicit about what text it is replacing and what 
> the new text 
> >is.
> >
> >Mitesh: The mitigation section of the discussed attack does 
> highlight 
> >the processing "rules" that are being modified. If you have explicit 
> >suggestions to make it better, we welcome it.
> 
> Essentially, I'm thinking that you need to indicate
> 
> OLD:
> 
>      793 text
>      793 text
>      793 text
> 
> NEW:
> 
>      draft text
>      draft text
>      draft text

ANA> I guess each mitigation says something like : For rg:-

 [RFC0793] currently requires handling of a segment with the RST bit
   when in a synchronized state to be processed as follows:

   1) If the RST bit is set and the sequence number is outside the  ....
   ......

 Instead, this document requires that implementations SHOULD implement
   the following steps in place of those specified in [RFC0793] (as
   listed above).

   ......
   ......


So, is very clear as which is the OLD RFC text and the NEW one proposed
by this document. May be there are places out there would benefit some
correction. But the place where the crux is described seems to be ok.

<snip>

> >
> >
> >The dicussions of interactions between TCP peers are always 
> difficult 
> >to phrase, as most terms are relative to viewpoint.  The 
> text in some 
> >places is tough to read - who is the sender, who the receiver, etc.  
> >The text also uses a lot of different terms to represent the same 
> >entity - remote peer, remote end sender, remote TCP endpoint, etc.
> >
> >Mitesh: We may consider simplifying these terms to remote 
> peer if that 
> >helps. Point noted.

Ok, I have retained the Sender/Receiver terminology as per RFC 793. I am
using remote peer in all other places where "receiver" isn't very
intriguing.

> 
> OK.  Note that I recognize the difficulty of choosing an 
> apporpriate term from among the common ones, which are 
> relative to the point of view.

Sure :-)

> 
> 
> >The term "initial sequence number" has a special meaning in TCP and 
> >should be avoided.
> >
> >Mitesh: Can you please elaborate the context?
> 
> Context in your draft:
> 
>     2) A sequence number that will be used in the RST.  This sequence
>        number will be a starting point for a series of 
> guesses to attempt
>        to present a RST segment to a connection endpoint that would be
>        acceptable to it.  Any random value may be used to guess the
>        initial sequence number.
>        ^^^^^^^^^^^^^^^^^^^^^^^
> 
> Context in RFC793:
> 
>      [Lots of places in 793 refer to initial sequence number 
> or to ISN.
>       And, of course, lots of literature.]
> 
> I think the draft means "the first guess", "the starting 
> point", not the TCP "initial sequence number".

Good point. I have used the term "starting sequence number."

> 
> >
> >The text says that this mitigation SHOULD be used "in devices" which 
> >typically host apps that are most vulnerable and MIGHT be used 
> >elsewhere. Is there a suggestion that this would be under 
> application 
> >control? Chosen by the OS vendor (or device vendor)?  For 
> those who are 
> >using Quagga routers (routing apps on top of intel boxes 
> running some 
> >*ix), would this be a socket option?
> >What's the vision here?
> >
> >Mitesh: This implementation detail is outside the scope of 
> the document.
> >Although, implementors may
> >make it a compile time option, application dependent control (as you 
> >hint with socket option) or may make it mandatory for the stack.
> 
> The draft discusses issues of interoperability between a TCP 
> stack that implements the new algorithm and one that does 
> not.  But I'm wondering about issues of interoperabality 
> between applications and TCP stacks.  An vulnerable app that 
> wants the new algorithm on an OS that has decided to leave 
> the decision in the TCP stack, etc.
> 
> For those systems where TCP stack and application are 
> integrally implemented, i.e., "devices" like routers running 
> BGP, the interoperability will be taken care of.  But there 
> are cases where an app that is vulnerable is running on a 
> platform where the OS is a general purpose OS.  In that case, 
> you aren't considering just one integrally implemented "device".

This is again an implementation advice and it is upto the
implemantations to chose whatever form they want, I second what Mitesh
has alluded to.

> 
> I'm just having trouble deciding what this all means in light 
> of the recommendation of section 1.1:
> 
>     SHOULD be implemented in devices that regularly need to 
> maintain TCP
>     connections of the kind most vulnerable to the attacks 
> described in
>     this document.  Examples of such TCP connections are the ones that
>     tend to be long-lived and where the connection end points can be
>     determined, in cases where no auxiliary anti-spoofing protection
>     mechanisms like TCP MD5 [RFC2385] can be deployed.  These 
> mitigations
>     MAY be implemented in other cases.
> 
> I'm having difficulty figuring out how this will work.  Maybe 
> this is just the age-old inter-layer feature negotiation 
> problem, and people will deal.

Well, this is a good point. The AS was added when some members felt that
this mitigation is useful only in some situations, however there were
others who felt that these are general purpose and it may benefit some
situations and in other situations it is harmless. Some felt that since
this document has IPT, may be having an AS would help. This document has
been floating around for 5 years and there is lot of dicsussions that
have taken place in the past, so I am not sure it is a good idea to
modify the AS. I am open if you have some specfic suggestions.

> 
> >
> >I don't understand some parts of
> >
> >    All TCP stacks MAY implement the following mitigation.  
> TCP stacks
> >    which implement this mitigation MUST add an additional 
> input check 
> >to
> >    any incoming segment.  The ACK value is considered 
> acceptable only 
> >if
> >    it is in the range of ((SND.UNA - MAX.SND.WND) <= SEG.ACK <=
> >    SND.NXT).  All incoming segments whose ACK value doesn't 
> satisfy the
> >    above condition MUST be discarded and an ACK sent back.  
> It needs to
> >    be noted that RFC 793 on page 72 (fifth check) says: "If 
> the ACK is 
> >a
> >    duplicate (SEG.ACK < SND.UNA), it can be ignored.  If the ACK
> >    acknowledges something not yet sent (SEG.ACK > SND.NXT) 
> then send an
> >    ACK, drop the segment, and return."  This mitigation 
> makes the ACK
> >    check more stringent since any ACK < SND.UNA wouldn't be 
> accepted,
> >    instead only ACKs which are in the range ((SND.UNA - 
> MAX.SND.WND) <=
> >    SEG.ACK <= SND.NXT) gets through.
> >
> >Seems that SEG.ACK could fall between the SND.UNA and SND.UNA - 
> >MAX.SND.WND, in which case the new code accepts segments that the 
> >existing text says "it is ignored".  I would read the 793 text as the
> >*ACK* is ignored, which means the new text would accept (and act on) 
> >ACKs that are presently ignored.  But looking at existing 

Nope. We added more text to clarify this situation. The current RFC 793
will *accept* any ACK that satisfies the following in-equality :
((SND.UNA-(2^31-1)) <= SEG.ACK <= SND.NXT).

The term "ignored" means that "ignore the ACK value and continue
processing the TCP segment", if sequence no. etc., is Ok, the TCP
segment would be accepted.
"ignored" doesn't mean the segment is dropped :-) Only when the SEG.ACK
> SND.NXT it gets dropped. Now all the new text is saying is to add a
stringent boundary on the acceptability of ACK's.
I re-read the whole "data mitigation" section and I am unable to come
out with text which is more explanatory than the current existing one.


> TCP code, it 
> >looks like people have interpreted "it is ignored" as the 
> *segment* is 
> >ignored, i.e., dropped.  In that case, this new text is accepting 

No, see above.

> >segments that in existing implementations would be dropped.
> >Is that the intent?  (Note: I could be easily wrong about 
> the tcp_input
> >code.)

> if MAX.SND.WND > 0, then SND.UNA-MAX.SND.WND < SND.UNA, so if 
> SEG.ACK < SND.UNA,it is possible that (SND.UNA - MAX.SND.WND) 
> <= SEG.ACK and SEG.ACK < SND.UNA.  So the statement
>                  since any ACK < SND.UNA wouldn't be accepted 
> disagrees with
>                   ACKs which are in the range ((SND.UNA - 
> MAX.SND.WND) <=
>      SEG.ACK <= SND.NXT) gets through.
> for the SEG.ACK range SND.UNA - MAX.SND.WND <= SEG.ACK < SND.UNA

Pl see above, I guess confusion is about the RFC 793 terminology on the
term "ignored".

> 
> The second comment was about the difference in behavior 
> between existing implementations and the new recommended 
> algorithm.  I'm interested in what turns up about that.

The recommended algorithm wouldn't accept ACK's which are < (SND.UNA -
MAX.SND.WND)

> 
> 
> >
> >
> >There are some language errors (missed words, punctuation, all that 
> >sort of boring stuff) that I could point out, or you could 
> rely on the 
> >RFC editor to find.
> >
> >Mitesh: Do send us stuff annotated and we can "refine" the 
> document as 
> >we move to the finish line.
> 
> Working on that.
Well, any help in amy grammatcial/language stuff is appreciated. There
might have some which have in-advertently missed out.
Did I miss any email ?
 
Actually it has been out of the last call and the document is in the
state where we need to get the next revision out ASAP. Hence a quick
response is appreciated.

Thanks for your detailed review.

-Anantha