Subject: [BEEPwg] SEQ frames and MIME entity headers

From: james woodyatt <[email-masked]>
Date: Wed, 5 Jun 2002 18:45:17 -0700

everyone--

Another minor thing that might be helpful to carry around until the IETF 
decides to revise RFC 3080 and/or RFC 3081:

I think BEEP peers should not send SEQ frames to acknowledge processing 
of incomplete MIME entity headers.  It would be better, to my mind, if 
BEEP peers were required to buffer the entire MIME entity header of a 
message before sending a SEQ frame to acknowledge it.

As I read RFC 3080 and 3081, BEEP peers are *permitted* to do this, but 
I can't think of a good reason why an application should expect that its 
BEEP core framework be able to present it with an incomplete entity 
header.  If your application *really* wants to receive a 
Content-Description field that can potentially be larger than the RFC 
3081 window for your channel, then it seems to me it can enlarge the 
window.

One of the reasons I bring this up: if I *do* send SEQ frames 
acknowledging incomplete MIME entity headers, then I have a problem when 
a malicious peer sends an initial greeting message with a 
Content-Description field of infinite length.  Plus, it complicates the 
programming interface for application profiles to have to support 
pathologically long MIME entity headers, and I'd rather just place the 
onus on the application to make sure all its headers fit through the 
transport mapping channel window.

Anyway, this seems like another one of those interoperability "corner 
case" issues that we should be tracking at this stage of the game.  
Would anyone care to add a comment to this?

--
j h woodyatt <[email-masked]>

_______________________________________________
BEEPwg mailing list
[email-masked]
http://lists.beepcore.org/mailman/listinfo/beepwg

---

From: Jered Floyd <[email-masked]>
Date: 06 Jun 2002 08:57:56 -0400

james woodyatt <[email-masked]> writes:
> 
> I think BEEP peers should not send SEQ frames to acknowledge
> processing of incomplete MIME entity headers.  It would be better, to
> my mind, if BEEP peers were required to buffer the entire MIME entity
> header of a message before sending a SEQ frame to acknowledge it.

[...]

> Would anyone care to add a comment to this?

I think this is a poor idea.  As far as I'm concerned, the data format
of a BEEP message should be beyond the abstraction barrier of the
things that the transport code need have knowledge of.  

I also agree that the scenario you describe, in which there are more
headers than the channel window buffer can hold, is a mess, and adds
unnecessary complexity.  You suggest that the sending peer could 
increase the channel window size if it wishes to send a long set
of headers, but BEEP does not currently define a mechanism by which
a sending peer can request an increase in the channel window size.

> acknowledging incomplete MIME entity headers, then I have a problem
> when a malicious peer sends an initial greeting message with a
> Content-Description field of infinite length.

How is this worse than an XML body of infinite length, say filled
with whitespace or comments?  

> Plus, it complicates the programming interface for application
> profiles to have to support pathologically long MIME entity headers,

You applications will often have to support pathologically long
entities, be they MIME headers or not.

--Jered

---

From: james woodyatt <[email-masked]>
Date: Thu, 6 Jun 2002 11:23:37 -0700

> a sending peer can request an increase in the channel window size.

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?

> with whitespace or comments?

All BEEP messages have entity headers.  If an application wants to 
process entity bodies incrementally and still prevent peers from being 
able to send content of unbounded length, its profile can require the 
presence of Content-Length header fields in its message entities.

When an application receives a MSG entity without a required 
Content-Length field, it can immediately produce an ERR entity in 
response.  When receiving any other kind of entity without a required 
Content-Length field, the application can instruct the framework to 
discard the body.

The harder problem is letting applications process entity *headers* 
incrementally, because that forces the application programming interface 
for profiles to support applications having to deal with headers of 
potentially unbounded length.

I think that unnecessarily complicates an already very complicated 
programming interface, and I can't think of any good reasons why 
applications would need to process entity headers incrementally.  Can 
anyone?

> entities, be they MIME headers or not.

As I said, applications get some control over the size of messages with 
the Content-Length entity header field.  The core profiles can all be 
written in such a way that their messages are completely buffered in the 
channel window and processed atomically.  I'm pretty sure that's one of 
the reasons why RFC 3081 says the initial window size of a channel is 
4096 octets.

---

From: Jered Floyd <[email-masked]>
Date: 17 Jun 2002 13:00:12 -0400

> 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.  This
seems poor.  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.

--Jered

---

From: james woodyatt <[email-masked]>
Date: 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:]
> 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'

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.