Subject: RE: [Rfid] Re: XML vs. Text vs. Binary

From: "Scott Barvick" <[email-masked]>
Date: Fri, 22 Jul 2005 06:56:14 -0400

Stephane,
 
>From the security perspective, the protocol processing is layered on top of standard security mechanisms as discussed in Section 4.2 of the draft.  Therefore, the implementation can safely access fields in payload as efficiently as possible.
 
Scott

________________________________

From: [email-masked] on behalf of Stephane Bortzmeyer
Sent: Fri 7/22/2005 4:19 AM
To: David Husak
Cc: [email-masked]
Subject: [Rfid] Re: XML vs. Text vs. Binary

On Thu, Jul 21, 2005 at 07:56:22PM -0400,
 David Husak <[email-masked]> wrote
 a message of 213 lines which said:

> In a compact, fixed binary encoding, it's easy for an implementation
> to access protocol fields directly via indexed load and store,
> i.e. an implementation need only access the bytes it needs, and it
> knows where those bytes are.

#define WARNING "newbie"

I've read quite often this statement in IETF discussions. I am not an
implementer but I wonder if this idea of blindly retrieving bits
coming from the newtork is really what the implementers do. Because it
seems there is a security issue here: since the bits come from a
possibly untrusted source (either because it is malicious or because
it is buggy), you surely validate them in some way, first, and
therefore you have to parse the incoming data, no?

_______________________________________________
Rfid mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rfid

_______________________________________________
Rfid mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rfid

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 22 Jul 2005 13:33:49 +0200

On Fri, Jul 22, 2005 at 06:56:14AM -0400, Scott Barvick wrote:
> Stephane,
>  
> From the security perspective, the protocol processing is layered on 
> top of standard security mechanisms as discussed in Section 4.2 of 
> the draft.  Therefore, the implementation can safely access fields 
> in payload as efficiently as possible.

I will leave it to implementors to decide whether they want to be 
robust against broken implementations or not. However, I like to point 
out two things:

a) As long as security processing is done in software, this will weight
   more than any encoding/decoding required, whether that is a binary
   format or not does not matter.

b) Our SNMP experience is that encoding/decoding is not at all an
   issue when it comes to the amount of CPU cycles burned. Most of 
   the time is spend accessing the instrumentation and in the security 
   processing (if enabled). So if you want to optimize CPU usage, 
   make sure you look at the whole system and spend the efforts
   where you can maximize the benefit.

Human readability is a major enabling factor. In theory, all you need 
is a decent library to handle binary encodings well but in the real 
world it seems to help if people can do things without relying on 
such a library. Human readable encodings (and I include XML here) 
simply enable more people to get into the "game" and this is 
ultimately driving the success of a technology.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 22 Jul 2005 13:42:39 +0200

On Fri, Jul 22, 2005 at 06:56:14AM -0400,
 Scott Barvick <[email-masked]> wrote 
 a message of 121 lines which said:

> the protocol processing is layered on top of standard security
> mechanisms as discussed in Section 4.2 of the draft.

Section 4.2 is nice but it just says that TLS MUST be present, not
that it MUST be used, no?

> Therefore, the implementation can safely access fields in payload as
> efficiently as possible.

It seems to me quite contradictory to say (David Husak's message) "We
will use fixed-length encoding because it is faster" and "security is
not an issue, since we use TLS". Surely, TLS processing is much more
costly than XML processing and therefore the cost of XML is
negligible?

---

From: Scott Barvick <[email-masked]>
Date: Fri, 22 Jul 2005 07:49:52 -0400

You are correct to note that TLS is not required to be used.  However,
if you are concerned about security, which was the basis for your first
question, then you can use it.   There are environments where the
security concerns that you raise are not an issue.  For those and the
base case, I argue for efficient, mimimal requirements on the
implementations.

Scott

---

From: Scott Barvick <[email-masked]>
Date: Fri, 22 Jul 2005 08:08:03 -0400

It is probably important to point out on this thread as well that
security and human readability are mutually exclusive, and security
needs will trump human readability (including binary decodes through
open source, free tools such as Ethereal) any day.   So designing for
human readability in what is inherently machine-to-machine operation
does not seem like a requirement, especially if RFID deployments grow
the way we all believe they will.

Scott

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 22 Jul 2005 10:00:53 -0400

The other inherent contradiction that I see in these discussions is:

(1) We need to use a binary encoding because the latency of decoding 
XML would interfere with SLRRP's real-time requirements,

AND

(2) Our secure transport will the TLS over TCP/IP.

What is wrong with this picture?

This is why I keep getting back to the question of what the real-time 
requirements actually are.  It seems very unlikely to me that TLS 
over TCP/IP would meet the goals of a "real-time control protocol", 
but that parsing XML on top of that would push us over the edge...

I can't make a coherent argument on that front, though, because I see 
absolutely no real-time requirements.  What are the real-time 
requirements for a controller that says, effectively "Here are your 
inventory settings, run this until I say stop.  I'll be back later to 
pick up the data."?

Margaret