[standards-jig] JEP-0017: Naive Packet Framing Protocol

Iain Shigeoka iainshigeoka at yahoo.com
Fri Feb 1 19:05:20 UTC 2002


Hey David and Mike and everyone...

Yup, it's the other pain in the rear coming in to spout off... :)  I bet you
thought I'd missed this one.

On 1/30/02 1:17 PM, "David Waite" <mass at akuma.org> wrote:

> Mike Lin wrote:
> 
>>> 1. I cannot think of a way to protect against misframing (number not
[snip]
>> 
>> Secondly, as stated in the JEP, error-handling semantics in the event of
>> misframing would have to be arbitrarily defined in a future revision of
>> the JEP. However, I think it would be difficult to build any kind of DoS
>> attack around misframing that would be more effective than can be done
>> currently. If the packet is misframed, it wil probably not be a
>> well-formed XML fragment, so parsing should fail at some point (although
>> possibly not until the end of the route).
>> 
> Right - however, the framing implies that the XML is not also being
> checked for well-formedness. Right now, if you send badly-formed XML,
> the stream protocol closes its document to you, indicating that there
> was an error on data it received, and closes the socket so that data
> cannot be sent to it anymore. With the data not being checked for
> well-formedness by the server (and just being routed), the data may not
> get properly interpreted until some point later in the system.
> 
> So, at some point later in the route, this non-well-formed data may hit
> a node which does not support framing, and instead uses a normal XML
> parser. This parser will stop parsing on the error. So, I could frame
> invalid packets and send them over the wire to disrupt any clients or
> components using a compliant XML parser. Because of this, client and
> server connections cannot be trusted to provide well-formed XML, and the
> XML must be fully parsed whether or not framing information is present.

In some ways I agree and others I disagree.  First, there is the trivial DoS
attack of just sending an almost endless stream of whitespace to the
server...  Something beneficially exploited for keep alive but could
obviously be used for evil...

Although your malformed XML concern is valid, I wonder if it would really
pose the kind of problem you imagine.  The main complaint being that a
client would hit the malformed packet rather than the server.  Something
that could theoretically be used to disconnect other clients and services.
However if framing were to be implemented, I would assume that part of the
whole spec would have to address error handling on a frame by frame basis,
not on the entire stream.  In other words, parse errors on a packet in a
frame invalidates the frame but not the stream.

The logical communication "chunk" then becomes the frame not the session.

>>> There is also routing information associated with a user's session,
>>> which replaces the 'from' address with the correct one for the session,
>>> and adds a 'to' address if none was specified (to a user's account.)
>>> 
>> 
>> I don't quite understand this. Can you clarify?
>> 
> Sure! Right now, I am allowed to send a packet resembling this
> <iq type='get'><query xmlns='jabber:iq:roster'/></iq>
> 
> This gets converted to
> <iq type='get' from='foo at server.com/resource' to='foo at server.com'><query
> xmlns='jabber:iq:roster'/></iq>
> 
> any 'from' address sent by a client is ignored, and changed to be the
> full jid associated with the session of that user.
> 
> So, the data within a frame will need to be manipulated when sent from
> clients, which probably negates any benefit from having clients frame
> the data

Agreed.  And I think this is one of the biggest handicaps with the Jabber
framing scheme (using XML).  You must inspect the package in order to get
addressing correct, rather than only needing to look at an "envelope".
Rewriting addresses is also greatly hindered by this aspect of using XML to
frame packets.

[accurate and insightful namespace issues snipped]

> The solution I see for this are to make one document inputted to the
> system actually represent a document received by another endpoint in the
> system. The two ways I can think of doing (as I said previously) are:
> - to send self-contained documents between points, rather than
> first-level child elements of the root. You would then frame each document.

Agreed.  Although this seems ad hoc and begins to beg the question of
transports over existing protocols...

> - to send a document between endpoints, framed by something like BEEP.

Exactly. I'm posting my thoughts in a different thread...

-iain


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com




More information about the Standards mailing list