Re: Terminate message a security threat?

"Mallikarjun C." <[email protected]> Wed, 05 Jan 2005 09:43:19 -0800
Newsgroups gmane.ietf.rddp
Message-ID <[email protected]>
Thanks Jim for patiently working through all the comments.

The note I wrote to Jim was:

"It may be worth dealing with for two reasons - (1) Terminate has a role 
in DoS attacks, (2) the current description of DDP/RDMAP message 
processing is seemingly comprehensive but is not due to the exclusion of 
Terminate."

Wrt #1 above, it so far appears that the WG believes that Terminate is 
not any worse than other security threats that were discussed.  I can go 
with this, some new text (summarizing the sentiments on this thread) & 
to address #2 might still be appropriate.  However, I will leave it to 
the authors at this point, I expect to be slow in responding to emails 
for the next 2 weeks.

Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668
Roseville CA 95747
cbm [at] rose.hp.com


Michael Krause wrote:
> At 06:12 AM 1/4/2005, Jim Pinkerton wrote:
> 
>> Content-class: urn:content-classes:message
>> Content-Type: multipart/alternative;
>>          boundary="----_=_NextPart_001_01C4F267.6FD91653"
>>
>>  
>> To date the security ID doesn’t discuss the Terminate Message. It was 
>> suggested to me by Mallikarjun as part of his detailed review that 
>> since all other messages are discussed, shouldn’t Terminate be?
>>  
>> In thinking this through, I don’t believe this represents any new 
>> attacks. If the Remote Peer is sending you a Terminate Message, then 
>> that ½ of the Stream is terminated. So he just clobbered himself, but 
>> hasn’t been able to affect any other connections – thus this is not a 
>> security issue. If a third party is able to inject a Terminate Message 
>> into the data stream, then it is a spoofing attack. The spoofing 
>> attack and mitigations are already discussed. So I think at best the 
>> Terminate Message could be added as an example of a spoofing attack, 
>> but honestly there are a ton of things the spoofer could do, so I’m 
>> not sure I’d revise the draft just to add another example.
>>  
>> Does anyone see a hole in my reasoning?
> 
> 
> I do not see this as a security threat - at best, just another example 
> of existing issues that should be examined in any robust design.
> 
> Mike
> 
>>  
>>  
>> Jim
>>  
>>  
>>  
>> _______________________________________________
>> rddp mailing list
>> [email protected]
>> https://www1.ietf.org/mailman/listinfo/rddp
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> rddp mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/rddp