RE: FCIP: Short Frame Security Solution Proposal

[Robert Snively <rsnively@Brocade.COM>]

My response below.

> -----Original Message-----
> From: Black_David@emc.com [mailto:Black_David@emc.com]
> Sent: Thursday, January 10, 2002 1:56 PM
> To: rsnively@brocade.com; ips@ece.cmu.edu
> Subject: RE: FCIP: Short Frame Security Solution Proposal
> 
> 
> 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.

David,  

That is why the nonce got the special treatment of this
text (and related text in another section).  However, I
do not believe the particular scenario is interesting,
since anyone who has the combination of resources and
unauthorized access necessary to do that evil scenario 
can do some dozens of other related scenarios at least 
as evil.  Some of them, especially those involving
denial of service by flooding, can even be done on the first
connection of a link.

By providing the example, we may leave the mistaken 
impression that resolving the security issues of the 
particular scenario will successfully prevent all 
attacks.

I think the straightforward warning that evil scenarios are
possible in this particular environment should be
sufficient to call security attention to that area.
The simple solution (using IPSec) is offered to guarantee
security for environments that can be secured using
internet security functions.

Of course there are lots of security problems outside
the scope of IP, FCIP, and FC, but those are well understood,
even though intractable.

Bob