headers
james woodyatt | 1 Jun 2002 01:17

transformative content-transfer-encoding in core profiles

everyone--

What should a BEEP peer do when it receives an initial greeting message 
in a transformative content transfer encoding?

For example:

	RPY 0 0 . 0 nnn
	Content-Type: application/beep+xml; charset="iso-8859-1"
	Content-Transfer-Encoding: quoted-printable

	<greeting/>
	END

RFC 3080 seems to be silent on the subject.

If the IETF ever revises the BEEP core specification, is it possible we 
might see an outright ban on the use of the Content-Transfer-Encoding 
entity header in all of the core profiles?  At least a strong 
recommendation against?

--
j h woodyatt <jhw <at> wetware.com>
Permalink | Reply | 1 comment |
headers
Marshall Rose | 2 Jun 2002 02:54
Picon
Picon

Re: transformative content-transfer-encoding in core profiles

> everyone--
> 
> What should a BEEP peer do when it receives an initial greeting message 
> in a transformative content transfer encoding?
> 
> For example:
> 
> 	RPY 0 0 . 0 nnn
> 	Content-Type: application/beep+xml; charset="iso-8859-1"
> 	Content-Transfer-Encoding: quoted-printable
> 
> 	<greeting/>
> 	END
> 
> RFC 3080 seems to be silent on the subject.
> 
> If the IETF ever revises the BEEP core specification, is it possible we 
> might see an outright ban on the use of the Content-Transfer-Encoding 
> entity header in all of the core profiles?  At least a strong 
> recommendation against?

hmmm... i don't think that seeing a CTE on channel zero is any different than seeing a CTE on any other
channel. it's just wrong. each channel is supposed to be 8-bit clean. can anyone come up with a reason as to
why a CTE is needed?

if not, then i think this falls under the category of "being liberal in what you accept"...if an
implementation treated it as a fatal error, i wouldn't complain about that...

/mtr
(Continue reading)

Permalink | Reply | 0 comments |
headers
james woodyatt | 6 Jun 2002 03:45

SEQ frames and MIME entity headers

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?
(Continue reading)

Permalink | Reply | 4 comments |
headers
Jered Floyd | 6 Jun 2002 14:57
Favicon

Re: SEQ frames and MIME entity headers

james woodyatt <jhw <at> wetware.com> 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.

[...]

> 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?

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.

> 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.

How is this worse than an XML body of infinite length, say filled
(Continue reading)

Permalink | Reply | 3 comments |
headers
james woodyatt | 6 Jun 2002 20:23

Re: SEQ frames and MIME entity headers

On Thursday, June 6, 2002, at 05:57 AM, Jered Floyd wrote:
> james woodyatt <jhw <at> wetware.com> 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.
>
> 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.

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?

>> 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.
>
> How is this worse than an XML body of infinite length, say filled
> 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
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jered Floyd | 17 Jun 2002 19:00
Favicon

Re: SEQ frames and MIME entity headers


> 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.  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
Permalink | Reply | 1 comment |
headers
Ryan Ripken | 25 Jun 2002 00:59

caching and compression profiles?


Has anyone thought about writing a zlib profile to do gzip compression? 
 What about a profile to do caching?  Is there any reason profiles like 
this couldn't be created?

It seems like a compression profile would be straightforward and useful 
enough that someone may have already done this.

In my case I would like to send a large amount of xml messages (IDMEF) 
from a client to a server.  Using gzip I can usually get around 30x 
compression.  I'd imagine that XMill or some other approach could do 
better.  For security reasons I'd like to use the tls profile (actually 
the idxp profile with tls).  Besides network bandwidth there are 
performance and security reasons why compression is attractive.

  I could turn on compression in openssl in both the client and the 
server machines but that is implementation specific and not general 
 purpose.  I could also compress/decompress the messages in the 
applications - but this ties clients to servers and kinda defeats the 
purpose of using an open format like IDMEF.  I think a compression 
profile would be the best solution and allow peers to negotiate a 
compression profile when it is available on the client and the server.

I did a quick search and found a refernce to a suggestion for a 
compression profile in the mailing list archive, whatever happened to 
that idea?
If a compression profile could be written it wouldn't work very well 
with small messages, that is where a caching profile might be useful - 
cache messages and compress a bunch of them at once.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Marshall Rose | 26 Jun 2002 08:12
Picon
Picon

Re: caching and compression profiles?

[ eric rescolra added to thread... ]

eric - what's the story on TLS use of compression? is it automatic, if available? or is there some other
"magic" involved.

ryan - i think that caching and compression are probably two different things.

caching is probably profile-specific in the sense that whatever does the caching has to understand the
semantics of the profile in use on the channel.

compression is more general. i suppose you could do it either as a tuning profile (for the whole session) or
on a per-channel basis. i can see advantages to each, but i'd prefer that the result look like this:

1. if you tune for privacy, then session-wide compression should just happen automatically, as a part of
the security layer.

2. if you don't tune for privacy, then you may decide to tune for compression. it should be fairly easy to
define a family of profiles to do this, e.g., http://.../zlib, http://.../my-whacky-compression, etc.

if someone feels strongly that compression ought to be done on a per-channel basis, then we'll finally get a
chance to use BEEP's feature negotiation mechanism, because there'll have to be a way of letting the two
sides negotiate the use of compression before they start adding a "Content-..." header to the messages
they exchange over BEEP...

/mtr

> Has anyone thought about writing a zlib profile to do gzip compression? 
>  What about a profile to do caching?  Is there any reason profiles like 
> this couldn't be created?
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marshall Rose | 26 Jun 2002 17:07
Picon
Picon

Re: caching and compression profiles?

> > eric - what's the story on TLS use of compression? is it automatic,
> > if available? or is there some other "magic" involved.
> Not good.
> 
> TLS has "support" for compression and automatic algorithm
> negotiation. However, no magic numbers are defined so it doesn't
> actually exist. Essentially what happened was that there were IPR
> concerns about all the algorithms so there was a reluctance to
> standardize.
> 
> A couple of people have implemented compression on an experimental
> scale but there's nothing standard. IIRC, OpenSSL has (disconnected)
> support for RLE and zlib.

eric - thanks, that's very good data. what that indicates to me is that if there's interest in a tuning
profile for beep that does compression, then it should be used regardless of whether or not the session has
already been tuned for privacy... (but, obviously, tuning for compression should occur after tuning for privacy!)

thanks!

/mtr
Permalink | Reply | 0 comments |
headers
james woodyatt | 26 Jun 2002 19:32

Re: SEQ frames and MIME entity headers

[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'
(Continue reading)

Permalink | Reply | 0 comments |

Gmane