[BEEPwg] SEQ frames and MIME entity headers

james woodyatt jhw@wetware.com
Wed, 26 Jun 2002 10:32:04 -0700


[apologies for waiting so long to get back to this.  we were having a 
friendly discussion stemming from my deeply paranoid fear that 
unauthenticated peers might attack a beep listener by sending 
pathologically long entity headers in an attempt to deplete the space 
resources used by its MIME parser.]

On Monday, June 17, 2002, at 10:00 AM, Jered Floyd wrote:
> [I wrote:]
>> That's true, but it doesn't have to.  Applications that depend on that
>> feature can define mechanisms in their profiles for doing that.  The
>> core profiles don't have any such mechanism, but then-- they don't
>> need to send pathologically long entity headers, do they?
>
> Applications can only define mechanisms in their profiles only if
> their profiles are tied to only operate over a TCP transport. [...]

[if we recall, the mechanisms we are talking about would allow a 
mechanism to request an increase in the size of its channel window.]

I disagree.  Every BEEP connection is a point-to-point full-duplex flow 
over a network with finite resources.  Managing the share of that flow 
consumed by each channel is the job of the transport mapping.  While the 
TCP mapping uses SEQ frames for this purpose, since the transport 
provider itself doesn't provide a mechanism, *every* transport mapping 
will have some mechanism for this.

Applications need not be "tied" to the TCP transport mapping if they 
want to implement mechanisms for requesting a larger share of the flow.

> [...] The core profiles don't need to send 'pathologically'
> long entity headers, but they *could*, and changing the standard
> in such a way where the 'proper' behaviour can only be defined as
> 'deadlock' is inappropriate.  It's reasonable to disallow certain
> operations, but only if failure can be indicated meaningfully.

It's true.  The proposed standard is silent about what a BEEP listener 
may do in the face of an attack on its MIME parser space resource by an 
unauthenticated peer.

I should rephrase my original proposition: I think RFC 3081 should be 
amended (someday, over the rainbow) to say: "A peer MAY process the 
entity header fields in a message atomically; therefore, to avoid 
deadlock, a peer SHOULD NOT send a frame containing any part of the 
entity header of a message until the channel window is large enough to 
send the complete entity header (including its terminating CRLF)."

I'll worry about other transport mappings when they emerge from whatever 
dungeon in which they are currently withering.


--
j h woodyatt <jhw@wetware.com>