->-----Original Message-----
->From: Steven M. Bellovin [mailto:smb(_at_)research(_dot_)att(_dot_)com]
->Sent: Monday, May 29, 2000 1:56 PM
->To: Dawson, Peter D
->Cc: ietf(_at_)ietf(_dot_)org
->Subject: Re: Storage over Ethernet/IP
->
->
->In message
-><C7091526C06AD211A7450004AC384A350C35D21E(_at_)mwabs035(_dot_)emeryworld(_dot_)com>,
->"Dawson, Peter D" writes:
->>
->>
->>->-----Original Message-----
->>->From: Harald Tveit Alvestrand [mailto:Harald(_at_)Alvestrand(_dot_)no]
->>->Sent: Friday, May 26, 2000 6:27 PM
->>->To: Brian(_dot_)Rubarts(_at_)BORN(_dot_)COM
->>->Cc: ietf(_at_)ietf(_dot_)org
->>->Subject: RE: Storage over Ethernet/IP
->>
->>->The point being made, remade and made again here is:
->>->- Any protocol that offers no means of countering such
->>->security threats is
->>->broken, and should not be considered for standardization.
->>
->>->It is perfectly possible that after conducting a threat
->and modality
->>->analysis, one ends up with saying that hardware-accelerated
->>->IPsec using
->>->host identities is adequate for the scenarios involving
->>->otherwise-unprotected Internet links, and that a mode with no
->>->protection is
->>->adequate when the media is physically secured.
->>->
->>->But the analysis MUST BE DONE.
->>->
->>
->>is vulnerability and threat analysis part of the
->>standardization process ??
->>
->Yes, in order to come up with a reasonable security considerations
->section. (Clearly, much of it is site-specific. But the protocol
->developers can't ignore it.)
->
->
-> --Steve Bellovin
->
OK...but nowhere in rfc2401/2402 do the STD doc's specify
finding's of the security /threat analysis, so how does
one state that the std doc, is within the reasonable limits
to counter "such threats and security" ??
/pd