Re: New WG Last Call on the Threats Assessment

Manuel Urueña wrote:

>>Here is the text I propose to add to the threat document in response to your comments.  Any comments on this?
>>    
>>
>
>Seems OK for me, at least for the DoS "bandwidth" attacks.
>
>But as they not explicitly state that PUs may be untrusted, IMHO they do
>not cover a Distributed DoS attack to the MAX-BAD-PE-REPORT counter
>mechanism. I mean, if someone is able to connect to an ENRP server from
>several machines (or the same machine with multiple IPs) it may overflow
>the MAX-BAD-PE-REPORT counter. 
>
>I've being trying to find a simple idea to block this attack, but the
>tricky thing is that it has the same effect than a busy server with a
>interface going down: several unreachable messages from multiple
>machines. Thus increasing the MAX-BAD-PE-REPORT counter slows down the
>attack but also makes less useful the endpoint unreachable messages.
>
>Is this really a threat or I am just too paranoid? :)
>
>Regards,
>--Manuel
>
>
>  
>
>>2.13 Flood of endpoint unreachable messages from the PU to the ENRP
>>server
>>
>>These messages are sent by ASAP to the ENRP server when it is unable to
>>contact a PE.  There is the potential that a PU could flood the ENRP
>>server intentionally or unintentionally with these messages.
>>
>>Effect: DOS attack on the ENRP server
>>
>>Requirement: Need to limit the number of endpoint unreachable messages
>>sent to the ENRP server from the PU.
>>
>>2.14 Flood of endpoint keep alive messages from the ENRP server to a PE
>>
>>These messages would be sent in response to a flood of endpoint
>>unreachable messages from the PUs to the ENRP server.
>>
>>Effect: Unintentional DOS attack on the PE
>>
>>Requirement: ENRP must limit the frequency of keep alive messages to a
>>given PE to prevent overwhelming the PE.
>>
>>-- maureen
>>
>>-----Original Message-----
>>From: ext Manuel Urueña [mailto:[email protected]]
>>Sent: Thursday, September 04, 2003 12:47 PM
>>To: [email protected]
>>Cc: Ong, Lyndon
>>Subject: Re: [Rserpool] New WG Last Call on the Threats Assessment
>>
>>
>>Hi,
>>
>>Reviewing the threats document and the rest of the Rserpool info, I
>>think I have found one question not covered by the threats draft and I
>>don't know if it has been already discussed. The question is: What's the
>>trust relationship between PUs and ENRP servers? 
>>
>>This is answered partially in the Threats draft in the 2.7 Requirement:
>>"ASAP needs to authenticate the ENRP server", but not in the other way.
>>
>>There is one scenario where the ENRP server needs to trust a PU. Section
>>4.7 of ENRP draft explains how a PU tells a ENRP server that a PE is
>>unreachable. When an ENRP server receives a ENDPOINT_UNREACHABLE
>>message, "...MUST inmediately send a point-to-point ENDPOINT_KEEP_ALIVE
>>message to the PE in question." If many PUs send such messages, this may
>>lead to a DoS to the ENRP-PE connection.
>>
>>This doesn't seem to be a very dangerous attack as KEEP_ALIVE messages
>>are small, but maybe could be documented so an ENRP server only sends
>>KEEP_ALIVE messages at certain rate. However, If I have understood
>>correctly, there is a problem related to the MAX-BAD-PE-REPORT counter.
>>
>>An ENRP server SHOULD delete a PE from a pool even if it responds to
>>ENDPOINT_KEEP_ALIVE messages just because several ENDPOINT_UNREACHABLE
>>messages have been received. A rogue PU may just ask for all the PEs of
>>a pool and then send MAX-BAD-PE-REPORT+1 ENDPOINT_UNREACHABLE messages
>>for each PE to knock down the whole pool. Do I miss something?
>>
>>Of course, if all PUs are trusted these attacks will never occur, but
>>IMHO that severely limits the number of PUs able to access to a pool.
>>
>>Thanks,
>>--Manuel
>>
>>    
>>
>>>Hi Folks,
>>>
>>>Maureen and I would like to start WG Last Call on the new version of the threats
>>>assessment (http://ietf.org/internet-drafts/draft-ietf-rserpool-threats-01.txt) that has
>>>now been posted on the server.  This would address comments on the architecture
>>>draft that a security section is needed - the security section would then reference
>>>the threats assessment for detailed discussion of security considerations.
>>>
>>>Last Call will start today and and end on Monday, September 8th (I know it's over 
>>>Labor Day weekend, but it's not a long document).
>>>
>>>Cheers,
>>>
>>>L. Ong
>>>      
>>>
Manuel:

See my last email.. this is NOT an issue.. if ENRP treats reports as 
"hints" on how
to prioritize its normal keep-alive mechanism.

So I don't see a problem at all with the update Q will put in..

R

-- 
Randall R. Stewart
[email protected] 815-342-5222 (cell phone)