RE: FCIP: Short Frame Security Solution Proposal

[Black_David@emc.com]

Bob, 

> In poking through the relevant text of our latest author's
> draft (to be published early next week as an IETF draft),
> I found the following text, which I would have imagined would
> have addressed your concerns without any requirement
> to document the particular example you have hypothesized.
> 
>   This one is part of the description of the authentication
>   procedure for creating additional connections.
> 
> 	Warning: The authentication mechanism described here 
> 	and in FC-BB-2 [4] is not designed to thwart 
> 	sophisticated security threats. The IP security 
> 	mechanisms described in section 9 should be enabled 
> 	in environments where security threats are suspected.
> 
> One of the reasons I would be reluctant to document the
> special case you have described is that, given the same
> kind of security threat you have described, there are probably
> a number of other cases with equal exposure if you were to choose
> to operate without turning on the appropriate IPSec
> security features.

Ralph pointed out that text to me a while ago.  Here's some more
text to consider, from the "Submitting Documents to the IESG"
guidelines at http://www.ietf.org/ID-nits.html -

  Does your document have an adequate security considerations section?
  Some have said that the "Security Considerations" section of a document
  essentially helps hackers attack implementations. It may, but the fact
  is that they will do the analysis themselves anyway - not doing a threat
  analysis will not stop them from exploiting weaknesses in your design.
  But by pointing out design choices you have made which have security
  implications, or by documenting "when you implement this, you should
  make these choices that have security implications", you may help people
  build implementations that are more hacker-proof, and you may find
  something you can improve. Frankly, the IESG has so many documents come
  its way which have no thought for security in them it must return for
  the analysis, putting the analysis into the document will be helpful
  in getting it through.

The use of the nonce is a design choice that has security implications,
and I'm asking that those implications be described.  A specific
discussion of other threats to TCP, IP, and protocols that use them
(e.g., address spoofing, TCP connection hijacking, RST attacks) is
not needed beyond something like Ralph's text that notes their existence.
FCIP did not invent TCP or IP, and hence can rely on other documents
to describe security considerations inherent to those protocols.
FCIP did invent the nonce, and hence needs to describe its security
considerations.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
black_david@emc.com         Cell: +1 (978) 394-7754
---------------------------------------------------