Re: [tcpm] tcpsecure recommendations

Folks-

We do not need more unending debate on this subject.  We need to make a
collective decision about how strongly to recommend these mitigations.
I want to encourage folks to please poke their head up and voice their
opinion on this question (my original request is below for reference).
And, I would also like to ask folks to hold off on re-debating the
issues again.  Certainly, if you feel you have a *new* opinion to offer
or the AS has brought something *new and different* to the fore of your
thinking, by all means please raise the issue.

Thanks,
allman

Folks-

It'd be good to get some opinions on the new tcpsecure version and get
it finished.  The sticking point on this document is how strongly to
recommend TCP stacks implement / use the three mitigations in the draft
(to spoofed RSTs, SYNs and data segments).  We had a discussion about
this in Chicago and also on the list.  Since it seemed that we were not
converging because there was not WG-wide agreement on the scope of the
document we asked the authors to generate an applicability statement.
They did that, per a previous email from Anantha.  The AS reads:

    The mitigations presented in this document talks about some known
    in-window attacks and the solutions to the same. The mitigations
    suggested in this draft SHOULD (RECOMMENDED) be implemented in
    devices where the TCP connections are most vulnerable to the attacks
    described in this document.  Some examples of such TCP connections
    are the ones that tend to be long-lived where the connection end
    points can be determined, in cases where no auxiliary anti-spoofing
    protection mechanisms like TCP MD5 can be deployed. TCP secure MAY
    (OPTIONAL) be implemented in other cases.

We can recommend each of mitigations with a MAY, SHOULD or MUST.  In
Chicago we winnowed the proposals to three three:

    (1) RST spoofing mitigation: MAY
        SYN spoofing mitigation: MAY
        data injection mitigation: MAY

    (2) RST spoofing mitigation: SHOULD
        SYN spoofing mitigation: SHOULD
        data injection mitigation: SHOULD

    (3) RST spoofing mitigation: SHOULD
        SYN spoofing mitigation: SHOULD
        data injection mitigation: MAY

Nobody has advocated for other permutations of recommendations
(although, clearly if people like some different combination they should
advocate away!).  

Can folks please weigh in on their feeling about how strongly we should
recommend these mitigations given the AS above?  It'd be great to get
this document moving and we're sort of stuck here.

Thanks,
allman