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

From: Sandra Murphy <[email-masked]>
Date: Thu, 23 Apr 2009 14:20:52 -0400 (Eastern Daylight Time)

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

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

---

From: "Mitesh Dalal (mdalal)" <[email-masked]>
Date: Tue, 28 Apr 2009 11:31:01 -0700

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]

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.

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.

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.

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

Mitesh: Can you please elaborate the context? 

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.

    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.

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.

Thanks for your time and input!
Mitesh