[BEEPwg] SEQ frames and MIME entity headers
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
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 <email@example.com>