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

[Sandra Murphy <[e-mail]>]

(sorry about the resend - thought an empty subject (sorry) might not get 
through).

-_Sandy


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

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

I know that I am so late with this review as to be make this pro-forma only.

I have no serious security considerations with this document.  It presents a 
mitigation technique against a well-known vulnerability in TCP processing of 
RST segments, and the increased concern over that the impact of exploits of 
that vulnerability on Internet infrastructure.

I do have document concerns, which I will mention in general and offer to 
specify more explicitly if deemed valid.

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

The term "initial sequence number" has a special meaning in TCP and should be 
avoided.

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?

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

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.


--Sandy