Subject: [xmpp] #57: recommended number of retries for resource binding

From: "xmpp issue tracker" <[email-masked]>
Date: Tue, 22 Jun 2010 01:41:39 -0000

#57: recommended number of retries for resource binding
--------------------------------+-------------------------------------------
 Reporter:  stpeter@…           |       Owner:  stpeter@…         
     Type:  defect              |      Status:  new               
 Priority:  minor               |   Milestone:                    
Component:  3920bis             |     Version:                    
 Severity:  In WG Last Call     |    Keywords:                    
--------------------------------+-------------------------------------------
 Section 7.6.3 (Retries) states:

 > If an error occurs when a client submits a resourcepart, the server
 > SHOULD allow a configurable but reasonable number of retries (at
 > least 2 and no more than 5); this enables the client to tolerate
 > incorrectly-provided resourceparts (e.g., bad data formats or
 > duplicate text strings) without being forced to reconnect.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/xmpp/trac/ticket/57>
xmpp <http://tools.ietf.org/xmpp/>

---

From: "xmpp issue tracker" <[email-masked]>
Date: Tue, 22 Jun 2010 01:42:10 -0000

Comment(by stpeter@…):

 Dave Cridland commented: "I'm not sure why we mandate no more than 5
 retries."

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/xmpp/trac/ticket/57#comment:1>
xmpp <http://tools.ietf.org/xmpp/>

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 24 Jun 2010 22:54:18 -0600

> #57: recommended number of retries for resource binding

We're not mandating, we're recommending (it's a SHOULD).

Do you have an alternate recommendation? I'm not sure why we would
recommend allowing an unbounded number of resource binding attempts
(just as we don't recommend allowing an unbounded number of
authentication attempts).

Pending text, I'm going to mark this as "wontfix".

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "xmpp issue tracker" <[email-masked]>
Date: Fri, 25 Jun 2010 04:54:34 -0000

#57: recommended number of retries for resource binding
--------------------------------+-------------------------------------------
 Reporter:  stpeter@…           |        Owner:  stpeter@…         
     Type:  defect              |       Status:  closed            
 Priority:  minor               |    Milestone:                    
Component:  3920bis             |      Version:                    
 Severity:  In WG Last Call     |   Resolution:  wontfix           
 Keywords:                      |  
--------------------------------+-------------------------------------------
Changes (by stpeter@…):

  * status:  new => closed
  * resolution:  => wontfix

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/xmpp/trac/ticket/57#comment:2>
xmpp <http://tools.ietf.org/xmpp/>

---

From: Dave Cridland <[email-masked]>
Date: Fri, 25 Jun 2010 11:28:04 +0100

> > #57: recommended number of retries for resource binding

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

What attack is this addressing? What interoperability issue may be  
affected by a server offering more than 5 resource binding attempts?  
What are the implications of allowing a 6th attempt at resource  
binding?

I could understanding requiring at least 5 attempts, incidentally.

Dave.

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 27 Jun 2010 15:44:31 -0600

On 6/25/10 4:28 AM, Dave Cridland wrote:
> What attack is this addressing? 

I suppose that clients could max out server resources by endlessly
binding unbindable resources. Plus, it just seems bad to allow clients
to hang around forever in limbo.

> What interoperability issue may be
> What are the implications of allowing a 6th attempt at resource binding?
> 

I've changed it to "at least 5 and no more than 10".

Peter

-- 
Peter Saint-Andre
https://stpeter.im/