Subject: [tcpm] strength of tcpsecure recommendation

From: Mark Allman <[email-masked]>
Date: Tue, 03 Apr 2007 16:10:07 -0400

Folks-

I'd like to try to be a bit systematic about figuring out how to proceed
with the tcpsecure i-d and so I have cooked a poll below.  The essential
questions on the table is the mitigations ought to be labeled as SHOULD
or MAY and whether these labels ought to be conditioned or not.

We have had some good conversation on the topic and lots of points have
been aired (how baked these solutions are, IPR, cost v. benefit, etc.).
So, I am asking that the answers to the following questions be succinct
and not rehash a bunch of previous argument.  If you feel you have a
**new** point then that is clearly fine.

I am trying to get a good read of the WG here and so even if you have
clearly aired opinions before, please take the minute and answer these
questions.

(Note that SHOULD and MAY are clearly not the only choices.  If you want
to vote for MUST or MUST NOT then that is fine, even though they are not
listed as choices below.  If you do, please then do provide some
justification.)

The questions then ...

(1) (a) Do you believe the draft should allow the "blind reset attack
        using the RST bit" mitigation described in section 3 of the
        document as a SHOULD or a MAY?

    (b) Should we apply a condition to the recommendation?  If so,
        please state the condition you'd like to see very succinctly.

(2) (a) Do you believe the draft should allow the "blind reset attack
        using the SYN bit" mitigation described in section 4 of the
        document as a SHOULD or a MAY?

    (b) Should we apply a condition to the recommendation?  If so,
        please state the condition you'd like to see very succinctly.

(3) (a) Do you believe the draft should allow the "blind data injection
        attack" mitigation described in section 5 of the document as a
        SHOULD or a MAY? 

    (b) Should we apply a condition to the recommendation?  If so,
        please state the condition you'd like to see very succinctly.

Thanks in advance for the input!

allman

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: "Mitesh Dalal \(mdalal\)" <[email-masked]>
Date: Mon, 30 Apr 2007 10:38:46 -0700

It would have been great if fresh set of inputs were received on this,
rather than have the same set of people discuss this topic :)
but since there are no replies, lets see if we can get this to 
jumpstart (again!) Please see inline.  

> -----Original Message-----
> From: Mark Allman [mailto:[email-masked]] 
> Sent: Tuesday, April 03, 2007 1:10 PM
> To: [email-masked]
> Subject: [tcpm] strength of tcpsecure recommendation
> 
>  
> Folks-
> 
> I'd like to try to be a bit systematic about figuring out how 
> to proceed with the tcpsecure i-d and so I have cooked a poll 
> below.  The essential questions on the table is the 
> mitigations ought to be labeled as SHOULD or MAY and whether 
> these labels ought to be conditioned or not.
> 
> We have had some good conversation on the topic and lots of 
> points have been aired (how baked these solutions are, IPR, 
> cost v. benefit, etc.).
> So, I am asking that the answers to the following questions 
> be succinct and not rehash a bunch of previous argument.  If 
> you feel you have a
> I am trying to get a good read of the WG here and so even if 
> you have clearly aired opinions before, please take the 
> minute and answer these questions.
> 
> (Note that SHOULD and MAY are clearly not the only choices.  
> If you want to vote for MUST or MUST NOT then that is fine, 
> even though they are not listed as choices below.  If you do, 
> please then do provide some
> justification.)
> 
> The questions then ...
> 

SHOULD. This issue has sufficent risk to require a SHOULD. 

>         please state the condition you'd like to see very succinctly.

unconditional. SHOULD in itself leaves sufficient leeway. However, if
there are precedents of conditionally defining a requirement, than maybe
we can consider an alternate, MUST for routers and MAY for everbody
else.

>         please state the condition you'd like to see very succinctly.
 
SYN has the same repercussions as the RST bit and hence same comments as
in 1 above.

>         please state the condition you'd like to see very succinctly.

This is fairly benign. Would prefer SHOULD but ok to go with either if
that will lead to consensus. 
 
Thanks
Mitesh