->-----Original Message-----
->From: Steven M. Bellovin [mailto:[EMAIL PROTECTED]]
->Sent: Monday, May 29, 2000 1:56 PM
->To: Dawson, Peter D
->Cc: [EMAIL PROTECTED]
->Subject: Re: Storage over Ethernet/IP
->
->
->In message
-><[EMAIL PROTECTED]>,
->"Dawson, Peter D" writes:
->>
->>
->>->-----Original Message-----
->>->From: Harald Tveit Alvestrand [mailto:[EMAIL PROTECTED]]
->>->Sent: Friday, May 26, 2000 6:27 PM
->>->To: [EMAIL PROTECTED]
->>->Cc: [EMAIL PROTECTED]
->>->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
