Subject: [BLISS] Comments on Call Completion

From: Eric Burger <[email-masked]>
Date: Tue, 24 Jul 2007 15:01:19 -0500

The automatic addition of a caller to a queue by virtue of having called
once is a huge DDoS opportunity.  This is worse than just the normal SPIT
DDoS opportunity, where lots of UAC's can attack a UAS by calling lots of
time.  That is because the effort on the UAC is similar to the effort on the
UAS.  However, with this proposal, the UAS has to temporarily keep state for
every call it gets.  Worse yet, once there is a subscription, the UAS has to
keep that state for the length of the subscription.

First suggestion: there has to be some relatively short default subscription
state and recommendations to implementers to have the UAS enforce the short
subscription time.

Temporarily turning off notifications while remaining on the queue has a ton
of issues, too.  That means that one has no mechanism for canceling the
queue request.  While it looks elegant to say that if the UAC does not need
to make the call attempt, it can just ignore the "it is OK to call now"
message.  However, that is wasteful of UAS resources.  Even if the UAC
cancels its subscription, the UAS still has to carry the state and go
through the motions of calculating (1) it is time to send a notification and
(2) to suppress that notification.

Likewise, if the UAC unsubscribes, then the call attempt trigger occurs, and
the UAC later resubscribes, because the user is ready to call, what happens?
One option is to either put the caller back into queue or put them at the
top of the queue.  Either way, the UAS needs to keep state forever.  That is
not a scalable option.

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

_______________________________________________
BLISS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bliss