Subject: [tcpm] security draft input request

From: Mark Allman <[email-masked]>
Date: Fri, 30 Apr 2004 09:16:59 -0400

Hi folks!

We'd first like to thank everyone for the rousing discussion on
Randall's security draft.  As a next step, we'd like to hear opinions on
the path forward -- from a very high level (i.e., about the topic, in
general, not the specifics of the i-d).

In particular, we'd like to ask folks to pick one of the options
that best summarizes your opinion, providing any additional
justification as you feel is necessary.

Option #1:

    Do nothing.  There is no problem that needs any sort of IETF
    attention at all.

Option #2:

    Document the problem and the existing techniques that can be used to
    mitigate the vulnerability.  I.e., spell out the attack and that one
    could use IPsec or the MD5 option to reduce (or eliminate) the
    vulnerability.

Option #3:

    Document the problem, the existing mitigations, as well as exploring
    additional mitigations.  Note that this "exploration" leaves open
    the possibility that we will find no mitigations that have
    consensus.  If that is the case, then this option basically becomes
    option #2 (possibly with some additional thoughts from this group on
    why we didn't like anything else in the solution space).

Option #N:

    We *think* the above options pretty much cover the space at a high
    level.  However, if you feel there is some slice of the space not
    covered, please make up a new option.  (But, please do this
    sparingly.)

Thanks!

Mark & Ted

---

From: [email-masked]
Date: Fri, 30 Apr 2004 11:42:04 -0400

Hello,

I have been following this WG since this draft was submitted (to the
public).
We are implementing a particular long-lived TCP application - iSCSI.

If I may, I vote for option #2.

My reasons are presented in the context of implementing iSCSI in a
firmware device, but I  think they would be true of other applications.

For iSCSI the security considerations are covered in the rfc (rfc3720)
and further in a separate rfc (rfc3723).  Please review for yourself but
In short, IPSec is recommended.

I think that minor TCP updates for security will give a false sense
of security (no pun intended) and will need constant revision as attackers
undoubtedly will outsmart the fixes.  I'm sure that the entire internet
cannot
update its TCP stack for every new threat.  In particular, I do not want to
have to implement IPSec as required, then also change the TCP
stack for every new threat that can happen with IPSec disabled.

I also wonder if some of these issues, if they need to be acted on, are
better placed in the security area of the ietf.  At least I do not see any
mention of security in the TCPM work group description or goals.

I appreciate any comments and do not wish to devalue any of the
work that has been done.

Regards,

Aaron Clarke
[email-masked]

                      Mark Allman                                                                                                  
                      <[email-masked]        To:       [email-masked]                                                             
                      >                        cc:                                                                                 
                      Sent by:                 Subject:  [tcpm] security draft input request                                       
                      [email-masked]                                                                                            
                      rg                                                                                                           

                      04/30/2004 09:16                                                                                             
                      AM                                                                                                           
                      Please respond to                                                                                            
                      mallman                                                                                                      

Hi folks!

Option #1:

Option #2:

Option #3:

Option #N:

Thanks!

Mark & Ted

(See attached file: att8yd6p.dat)