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

David Waite mass at akuma.org
Wed Jan 30 21:17:59 UTC 2002


Mike Lin wrote:

>As I see it, the issues you are pointing out are more verbose forms of
>the ones listed in the JEP as it is.
>
>>1. I cannot think of a way to protect against misframing (number not 
>>representing the full packet, representing more than one packet) other 
>>than by trusting the remote party to indicate framing correctly. This 
>>would seem to indicate that you must have a degree of trust of the 
>>remote party to trust their framing, so client to server and server to 
>>server connections are out of bounds - this could only be used within a 
>>particular server architecture.
>>
>
>Firstly, there is already this sort of trust in place to send
>well-formed XML.
>
>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.

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

>>2. If namespaces were properly handled by Jabber, this would mean that 
>>there was other data outside of a packet which was required for correct 
>>handling of the packet, being the namespaces and prefixes declared on 
>>the root element. This sort of framing and full use of namespaces seem 
>>to be mutually exclusive - you would either need to rewrite packets to 
>>contain all namespaces they need as defined by the document representing 
>>the connection between the packets, or ignore namespaces declared at the 
>>root.
>>
>
>Namespaces are handled correctly by Jabber.
>
>From an XML parsing perspective, the framing data is not required for
>correct handling of the packet; it's just extraneous data. So I think
>the namespace issue for the text nodes is generally moot. The framing
>data is just sugar for the transport layer. So, as stated in the JEP,
>there is a valid concern that the transport metadata is being sort of
>mixed with its payload content - but this seems necessary for the sake
>of backwards compatibility.
>
I'm just indicating that for data to be routed correctly in a 
namespace-correct server, each packet may need to be rewritten on each 
hop. For example:
I am a client, and send something similar to the following:

<x:stream xmlns:x='http://etherx.jabber.org/streams' 
xmlns:client='jabber:client' 
xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/' to='jabber.org'>
  ...
  <client:message to='user at otherserver.com'>
      <soap:Envelope 
soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
          <soap:Body>
               ...
          </soap:Body>
      </soap:Envelope>
   </client:message>

Now, imagine this is sent over a S2S connection which initialized using 
the following root element:
<stream:stream xmlns='jabber:server' to='otherserver.com' from='jabber.org'>

The above element would need to be rewritten in order to be sent over 
the connection and be interpreted as correctly on the other side, to 
something like this:
<client:message to='user at otherserver.com' from='foo at jabber.org' 
xmlns:client='jabber:client' 
xmlns:soap='http://schemas.xmlsoap.org/soap/envelope'>
    <soap:Envelope 
soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
        <soap:Body>
            ...
        </soap:Body>
   </soap:Envelope>
</client:message>

It just so happens that right now this is not neccessary, since 
namespace usage is extremely limited in the current client protocol, and 
incorrect in the current component and server protocols.  It is 
understood that namespaces are read as normal attributes, that prefixes 
are considered part of the local name of an element, and that if things 
are not phrased exactly correct, all bets are off.

If you bring correct namespace support into the picture, a packet is no 
longer independant of itself, but instead relies on the document root to 
get all of the neccessary context information. one incoming document on 
a client does not  map to one outgoing document on another, so the XML 
element may need to be modified at any step between clients, servers, 
and components.

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.
- to send a document between endpoints, framed by something like BEEP.

-David Waite

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20020130/457d0899/attachment.html>


More information about the Standards mailing list