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

From: Sandra Murphy <[email-masked]>
Date: Wed, 6 May 2009 14:32:08 -0400 (Eastern Daylight Time)

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 <[email-masked]>
>To: [email-masked], [email-masked],
>[email-masked],
>     [email-masked]

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

Your mitigation techniques summarize the various pieces of 793 text
scattered over the fsm description.  Figuring out which pieces of the fsm
text are the ones summarized and which should be changed could be ambiguous
in interpretation.  As the typical tcp code tries hard to follow the fsm 
description, being precise about the changes would be good.  And very
tedious, I'm sure.

>
>
>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.  Note that I recognize the difficulty of choosing an apporpriate
term from among the common ones, which are relative to the point of view.

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

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

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.

>
>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 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
>segments that in existing implementations would be dropped. 
>Is that the intent?  (Note: I could be easily wrong about the tcp_input
>code.)
>
>Mitesh: I will have to dig and find out, my recollection is hazy but I
>think this was raised earlier
>and may have been discussed.

Note that I have mixed two comments here.  The first comment is about
the algebra:

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

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.

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

>Thanks for your time and input!
>Mitesh

---

From: Lars Eggert <[email-masked]>
Date: Thu, 7 May 2009 10:19:05 +0300

Hi,

note that it is not at all clear whether this document will end up  
indicating that it is updating 793. In the document writeup (in the  
tracker) the chairs describe the discussion the WG had around this  
issue and are asking for the IESG to discuss what is appropriate here.

Lars

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Mon, 25 May 2009 01:06:48 -0700

I think there is a differentiation between what the draft actually does
versus what we want to indicate.

The draft DOES update RFC 793, but whether we want to put that upfront
or not is left to the collective wisdom of IETF.

Sandra's comments are valid and need to be taken care of whether or not
we put the keyword "updates " in front of the RFC (draft)

Thanks,
-Anantha

> -----Original Message-----
> From: Lars Eggert [mailto:[email-masked]] 
> Sent: Thursday, May 07, 2009 12:19 AM
> To: Sandra Murphy
> Cc: Mitesh Dalal (mdalal); [email-masked]; 
> [email-masked]; Anantha Ramaiah 
> (ananth); [email-masked]; [email-masked]
> Subject: Re: review of draft-ietf-tcpm-tcpsecure-11.txt
> 
> Hi,
> 
> note that it is not at all clear whether this document will 
> end up indicating that it is updating 793. In the document 
> writeup (in the
> tracker) the chairs describe the discussion the WG had around 
> this issue and are asking for the IESG to discuss what is 
> appropriate here.
> 
> Lars
> 
> >> 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.
> >>
> >> the processing "rules" that are being modified. If you 
> have explicit 
> >> suggestions to make it better, we welcome it.
> >
> > scattered over the fsm description.  Figuring out which 
> pieces of the 
> > fsm text are the ones summarized and which should be 
> changed could be 
> > ambiguous in interpretation.  As the typical tcp code tries hard to 
> > follow the fsm description, being precise about the changes 
> would be 
> > good.  And very tedious, I'm sure.
> >
> >>
> >>
> >> 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.
> >
> > I think the draft means "the first guess", "the starting 
> point", not 
> > the TCP "initial sequence number".
> >
> >>
> >> control? Chosen by the OS vendor (or device vendor)?  For 
> those who  
> >> are
> > wondering about issues of interoperabality between 
> applications and  
> > TCP
> >    SHOULD be implemented in devices that regularly need to 
> maintain  
> > TCP
> >>   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
> >>   acknowledges something not yet sent (SEG.ACK > SND.NXT) 
> then send  
> >> an
> >>   instead only ACKs which are in the range ((SND.UNA - 
> MAX.SND.WND)  
> >> <=
> >> ACKs that are presently ignored.  But looking at existing 
> TCP code,  
> >> it
> >> looks like people have interpreted "it is ignored" as the 
> *segment*  
> >> is
> >> There are some language errors (missed words, punctuation, 
> all that  
> >> sort
> >> Mitesh: Do send us stuff annotated and we can "refine" the 
> document  
> >> as

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Sun, 31 May 2009 15:36:55 -0700

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> 

> From: Sandra Murphy [mailto:[email-masked]] 
> Sent: Wednesday, May 06, 2009 11:32 AM
> To: Mitesh Dalal (mdalal)
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; 
> [email-masked]; Anantha Ramaiah (ananth)
> Subject: RE: review of draft-ietf-tcpm-tcpsecure-11.txt
> 
> >the processing "rules" that are being modified. If you have explicit 

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 
> >places is tough to read - who is the sender, who the receiver, etc.  

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

> point", not the TCP "initial sequence number".

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

> those who are 
> >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:
> 
> maintain TCP
> 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.

> satisfy the
> It needs to
> then send an
> MAX.SND.WND) <=

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 
> *segment* is 

No, see above.

> SEG.ACK < SND.UNA,it is possible that (SND.UNA - MAX.SND.WND) 
> <= SEG.ACK and SEG.ACK < SND.UNA.  So the statement

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.
> >
> document as 
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