RE: New WG Last Call on the Threats Assessment

I agree with your assessment that the MAX-BAD-PE-REPORT counter should be dropped and the ENRP should be updated accordingly.  I guess I didn't make that clear in my last message.

In regard to your second question about a flood of endpoint unreachable messages, I would like to defer to Qiaobing or other list members who have more experience or experience with a live implementation.  

Could you all chime in with your thoughts on this?

-- maureen


-----Original Message-----
From: ext Manuel Urueña [mailto:[email protected]]
Sent: Monday, September 29, 2003 4:35 AM
To: Stillman Maureen (NVO-NIC/Ithaca)
Cc: [email protected]; [email protected]
Subject: RE: [Rserpool] New WG Last Call on the Threats Assessment


> It seems to me that the only way to solve this is to have the PU send a
> message to the ENRP server and have the ENRP server check it out.  If they
> agree that the PE is down, then it should be removed; there is no problem
> with this case.

Agree

> The second case in which the PU thinks the PE is down, but the ENRP server
> can reach it, well, I think the ENRP server has to keep the entry for two
> reasons:
> 
> 1) the message from the PU might be malicious
> 2) just because one PU can't reach the PE doesn't mean that other PUs can't
> reach it.

Totally agree

Thus, is the MAX-BAD-PE-REPORT counter used? or it should be dropped?

> In my opinion it doesn't matter if the PU is authenticated or not.  So
> again, I would change the actions of the ENRP server rather than the actions
> of the PU.

I also think ENRP should be changed, as you say the ASAP layer of an
attacker PU can be hacked.

But IMHO the "good" PUs should be also changed to protect the ENRP
server from flooding when a PE goes down. But I'm not sure what's the
better method though.

Let's say a popular web server (1000 simultaneous clients) goes down.
Therefore the ENRP server will have 1000 new connections in the next few
seconds. This can be limited with an random choice (1%), then only 10
PUs will send an ENDPOINT_UNREACHABLE message. 

The problem is that this random limit cannot be a fixed value. It should
be proportional to the number of PUs. In other case there is a high
probability than a PE going down with only 10 clients will be unaware
until its registration expires.

Comments?

> By the way, it is not the application layer that is sending this message,
> but the ASAP protocol.  I do understand that the ASAP layer could be hacked
> to change the code.  

Absolutely right, I'm afraid

> Comments?
> 
> -- maureen
> 
> -----Original Message-----
> From: ext Manuel Urueña [mailto:[email protected]]
> Sent: Friday, September 19, 2003 1:14 PM
> To: Stillman Maureen (NVO-NIC/Ithaca)
> Cc: [email protected]; [email protected]
> Subject: RE: [Rserpool] New WG Last Call on the Threats Assessment
> 
> There are two cases to consider:  
> 
> Case 1: The PU and ENRP server agree that the PE is down, then it should be removed from the database. 
> There is no problem with this case.
> 
> Case 2: The PU thinks the PE is down, but the ENRP server can reach it.  
> I think the ENRP server has to keep the PE entry for two reasons:
> 
> 1) the message from the PU might be malicious
> 2) just because one PU can't reach the PE doesn't mean that other PUs can't
> reach it.
> 
> In my opinion it doesn't matter if the PU is authenticated or not.  So
> again, I would change the actions of the ENRP server rather than the actions
> of the PU.  I would delete the part about Max-bad-PE-Report counter in the ENRP draft and 
> replace it with my case 2 above.
> 
> By the way, it is not the application layer that is sending this message,
> but the ASAP protocol.  However, I do understand that the ASAP layer could be hacked
> to change the code.  
> 
> Comments?
> 
> -- maureen
> 
> > 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 Uruen~a - Universidad Carlos III de Madrid
GPG FP: 9BE9 9FFF ACFF 2887 80E6 50FE FABC A79F 5535 5A75