Re: New WG Last Call on the Threats Assessment

Manuel:

Comments below...

Manuel Urueña wrote:

>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? 
>  
>
There should be none needed... just as DNS does not really need
to trust the requestor or care.. The PE must establish the trust
relationship with the PU when they setup their communication.

>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 is actually an oversight.. we had discussed changing this ... 
Qiaobing.. we need
to get that change in. In one of the meetings (Atlanta I think) we were 
going
to change this so that the ENRP server used this as a "hint" and no 
more. The
only true way to deregister is if the ENRP server itself can't reach the 
PE. This
then avoids the scenario you describe..

>
>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.
>  
>
Again.. as a hint then this whole issue goes away.. and that will get
changed in the next rev of the ENRP document...

>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?
>  
>
Again.. as I said.. just a HINT nothing more.. and I think we should leave
the algorithm  that is used by the ENRP server unspecified. Some may
want to keep a counter of "UNIQUE" hints given by varing endpoints.
Say by keeping the last hint location and discouting multiple hints.. some
may use it in there own way to "prioitize" how often to send a 
Endpoint-keep-alive.

In any case... I think the point is moot... considering it is just a 
docutment oversite
that we missed.. thanks for pointing it out..




>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.
>  
>

I don't think we need ANY trust relationship between PU and ENRP server.
If a PE registers it is asking for its information to be given out. If a 
PU-PE needs
a trust relationship then the interaction between the two can be
what drives things.. and thats app specific...

R

>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
>>    
>>
>
>  
>


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