Subject: [ESDS] Review of draft-rezafard-esds-problem-statement-01

From: Eric Rescorla <[email-masked]>
Date: Fri, 07 Mar 2008 23:46:47 -0500

$Id: draft-rezafard-esds-problem-statement-01-rev.txt,v 1.1 2008/03/08 04:25:19 ekr Exp $

GENERAL
I think this draft would be a lot clearer with an explanation of the
assumed operational model.  Some sort of boxes and arrow diagram (RFC
4101) would be pretty helpful here.

Reconstructing from the draft, it looks like the assumption is
something like this.

Updating:
1. An object with ID X is delivered to Alice.
3. Alice move it from point A to point B.
4. Alice writes update information to an information provider 
   (say "alice.example.com") to store the current state, along with some potential
   access control rules.
5. Alice update some Discovery Service server to tell it that 
   some information about X is at "alice.example.com"
   information about X, along with some potential access control
   rules.

Querying:
1. I somehow come into possession of ID X.
2. I use some bootstrapping procedure to discover which DS (or
   DSes) has information about X.
3. I query the DS(es), potentilly authenticating to them, and 
   get back whatever information the ACL entitles me to.
   The DS points me to "alice.example.com".
4. I then contact to "alice.example.com", again authenticating,
   and it provides me with the state of X subject to 
   access control.

Do I have this at least approximately right? 

I'm a little confused about the terminology: 
I get (at least I think I do) that ESDS is a referral service,
but in S 1 you imply that it refers to "information providers",
but in S 5.1.1, you imply it's to "resources". Are these the
same thing? For the rest of this review, I'm going to refer to the holder
(and server) of the actual object state as an information
provider. If that's wrong, please try to do the mapping.

So, at a high level, here's some things I don't understand:

1. What's the relationship between Alice and the DS? I.e.,
   how does the DS know who is allowed to publish information
   about object X?
2. What's the trust relationship involved in the bootstrapping
   system? I.e., what gives the DS permission to advertise
   information about object X?
3. Is the bootstrapping service intended to enforce access control
   on who can do the object -> DS mappings?

DETAILED COMMENTS
S 1.3.
   traffic on DNS roots exponentially.  Since data will be routed
   through the Internet, the bootstrapping procedure needs to be
   formulated under the IETF approval process.

More detail here might be useful. Obviously, it's possible to screw
up any kind of resolver, but why would this be especially bad?

S 2.1.
   IETF review process and, in its design, necessitates increased tree-
   walking.  ONS specifies a reverse mapping of the EPCglobal "SGTIN"

Why does it necessitate increased tree-walking.

   chain.  This would require successive updates to the hierarchal ONS
   to indicate incremental supply chain partner referrals, reducing the
   effectiveness of caching.  Alternatively the ONS could provide a

So, this is certainly true, but the fact that this data is dynamic
is what makes caching ineffective. I don't see that this is a DNS-specific
issue or that it's likely to be dramatically better with another design.

   chain partner.  However, even a relatively static entry, which only
   refers to the point of origin within the supply chain, would drive
   the number of public zone entries to extremely large numbers if an
   individual record were created for each serial number.  The number of
   records could exceed the current IPv4 address space by several orders
   of magnitude.  Also since many of the tagged physical objects would
   neither require nor provide network connectivity, utilizing IPv6 for
   such objects would waste this finite address space resource
   unnecessarily.

   One common suggestion to manage this problem is to have multiple
   alternate ONS roots which can be managed for separate and unrelated
   supply chains and/or regions.  However, since there is nothing to
   prevent ONS from operating in the existing Internet root hierarchy,
   even alternate ONS providers can opt to drive traffic to the existing
   Internet root servers, rather than operate their own ONS roots.
   There has already been a pilot ONS implementation under the .aero
   zone (sgtin.id.ons.autoid.aero) where this phenomenon may already be
   observed.

I totally don't understand this issue issue of the large number of
records.  Sure, there's a lot of records because there's a lot of
data, but what does this have to do with the number of IPv4 or IPv6
addresses?  Why can't data for more than one device be hosted on the
same server?  Isn't the usual response here to have a wildcard entry
(or synthetic entries) that points to a single server? I don't
understand why the number of records has anything to do with the
number of servers except for the conventional administrative
convenience and load sharing reasons.

   It was therefore a very wise decision of EPCglobal not to propose
   that ONS 1.0 should store a DNS record for each unique EPC, since the
   number of resulting DNS records could clearly overwhelm the DNS
   infrastructure.

Again, this isn't clear to me. Why is DNS any more susceptible to
being overwhelmed than what you propose?

S 2.2.

   information provided by the object identifier.  Unlike DNS, where
   there is a known set of root servers, ESDS will have numerous roots
   for various supply chains operating globally.  This, in turn,
   complicates the bootstrapping process.

Why is having multiple roots desirable? The arguments from RFC 3245
seem to apply here as well. 

   (such as JXTA [jxta-protocols]) as an alternative to hierarchical
   lookup protocols such as DNS and ONS.  This would keep the ESDS

How does JXTA help? Perhaps you're thinking of storing data in
a DHT or something like it? More detail seems appropriate here.

S 5.1.
   The ESDS protocol should be decoupled from the security layer and not
   have embedded components specific to certain security protocol
   implementations.  This will enable ESDS implementations to respond
   quickly to changes in the ever advancing security layer protocols.

It's not clear to me that this is possible. You seem to be conceiving
of security as a transport layer thing, but in order to have a distributed
system of this type, you may need to use cryptographic access control.

S 5.8.
   To enable the grouping of information belonging to the same object,
   each object needs to be uniquely identifiable as it moves through the
   supply chain and its lifecycle steps.  The protocol cannot safely
   rely on unique object identifiers alone, because an identifier may
   enter the supply chain multiple times.  A sample use case for this is
   returnable bins, where the same bin will go through the supply chain
   many times.  Another use case is airline baggage, where the same
   baggage identifier could appear the following year, due to the fact
   that the identifier is only required to include a Julian date (the
   day of the year) but is not required to include the year.

I think you're conflating two different things here. An object entering
the system multiple times is still a single object. That's very 
different from having multiple objects with the same identifier.
I wonder if the second case is really that important. To take the
airline case as an example you can generate a synthetically unique identifier
by taking the identifier and appending the year. It's not clear to
me that there are important cases where this is not so, and it's
not clear to me that a system can be designed that can handle this
adequately.

S 5.12
   Architecting a bootstrapping policy will involve defining a protocol
   for peer-to-peer communication between Discovery Services (DS).  The
   ultimate goal is to locate the target DS without dependence on
   hierarchical information and services such as ONS or the underlying
   DNS.  To facilitate the peer-to-peer communication it is recommended

Why is this a desirable goal?

   One point to keep in mind with DSs is that finding one target DS does
   not mean that the search is over.  One product identifier could be
   acceptable to many DSs; therefore a search cannot stop once a DS is
   located but needs to propagate to all peers.

This kind of flood search is very expensive. An alternative design
is to have all the DSes for an object ID represented at a single
location in the bootstrap system. 

   [bridge-discovery-services-design].  Considerations must be given to
   protection against data mining to discovery whether a serial number
   exists.

This seems like a problematic requirement. In order to avoid this 
kind of data mining, it seems to me that you'd need to either
make serial numbers hard to guess (which has obvious backward
compatibility issues) or have the system behave identically
for existing and non-existing serial numbers, which potentially
is expensive for the DSs which need to pretend to know about
objects they actually do not know about.

-Ekr

_______________________________________________
ESDS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/esds

---

From: Ali Rezafard <[email-masked]>
Date: Wed, 26 Mar 2008 09:50:12 -0400

Hi Eric,

Thank you very much for your detailed review of ESDS problem  
statement. Your comments and feedback were very constructive and will  
be integrated into the next version of the problem statement.

Responses to your comments are inline below.

Best Regards,
Mark, Ali

> 4101) would be pretty helpful here.
Agreed, diagrams will be included in the next version of problem  
statement.
> Do I have this at least approximately right?
Yes, that's the general idea - except that the object with ID X will  
pass through multiple organizations on its way to you.
Alice may pass it to Bill, who passes it to Claire, who passes it to  
David.

Each of Alice, Bill, Claire and David might record a lot of detailed  
information about the object X while it is in their custody - such as  
all the places it was observed within their organization, what actions  
they performed on it, what measurements they made about it (or its  
surroundings) e.g. temperature.

Each of them writes the detailed record in their own information  
systems, e.g. info.alice.com, info.bill.net, info.claire.info,  
info.david.com
- but is not required to send the detailed info to anyone else - but  
there might be occasions when someone else (e.g. Eric) would like to  
find out the detailed history of object X  (e.g. to check whether it  
has always been stored at the correct temperature) - or someone (e.g.  
Alice) wants to find out who has it now - because they need to do a  
selective product recall of that particular object because it is  
unsafe or defective.

Discovery Services help keep records about the path that an individual  
object follows (in this case Alice - Bill - Claire - David - Eric for  
object X).  However, this path might not be the same for all objects -  
and might even be very different for an almost identical object X'  
that Alice manufactured at the same time.
> provider. If that's wrong, please try to do the mapping.
Sorry for the lack of clarity here.

What we meant to say is:

Organization or company (or even an individual) = 'information  
provider'   (the entity)
Information service provided by that organization / company /  
individual = 'information resource' or 'information service'

>   how does the DS know who is allowed to publish information
Alice co-operates with a number of organizations who handle objects  
like object X.  These might be conventional supply chains that link  
manufacturers to distributors to retailers  - or they might be  
extended product lifecycles including organizations who do repair,  
maintenance and servicing of objects.

Alice chooses a particular DS to publish to - perhaps because of the  
industry sector and/or geographic area in which she operates - or  
perhaps because she is subject to some regulation that requires her to  
notify a particular DS in order to ensure that traceability  
information can be tracked.

There needs to be a way to specify clusters of organizations within a  
DS - and to allow these to self-organize about who can join the  
cluster - and who can publish records for a range of objects, in order  
to protect against large numbers of spurious links.
However, the access control policies for publishing will usually allow  
Bill, Claire, David (but potentially also Brenda, Charlie and Diane)  
to publish records for objects of the same kind as X.

Any of these actors may belong to multiple clusters or supply chains.
>   information about object X?
The DS will not normally advertise any information about an object X -  
other than that it might indicate that it may hold information about it.
Note that this should not be taken as evidence that the ID X does  
exist or has been issued.  In some situations, a DS might hold a  
general pattern that recognizes IDs such as X that match the pattern.

In the bootstrapping system, one DS may ask the other DSes 'Does  
anyone know about object X?'  Any DS can answer 'Yes' - and reveal  
their own DS URL - without sending any other link information back to  
the client.
>   on who can do the object -> DS mappings?
No - a DS (even one that does not participate in the bootstrapping  
protocol) should be able to enforce access control policies.  These  
will primarily be access control policies governing permission to  
'read' link information, and set by each information provider (Alice,  
Bill etc.).  A DS might also enforce some additional access control  
policies, such as those specified by its operator - or by a regulator  
or other industry body.

The bootstrapping service is primarily about using one known DS in  
order to find another DS that may hold information about an object,  
assuming that Discovery Services are aware of the existence of each  
other and that they have a mechanism for relaying a query between each  
other.
> up any kind of resolver, but why would this be especially bad?
It would be especially bad in the case that the ONS traffic is routed  
through the Internet's DNS infrastructure. If the ONS is extended to  
include item level lookups, and given that most lookups would be  
initiated by automated processes, traffic demands can scale to very  
large numbers. As it is mentioned in detailed in the following  
sections, there is a tendency for businesses to route their ONS  
traffic over existing DNS servers without considerations for the  
consequence of such action given the high volume of traffic that will  
be flowing.

Also we need to mention security requirements of supply chains. ONS  
and DNS (as usually implemented) have no client authentication.  This  
is not acceptable for querying for links to serial-level data.  
Unencrypted DNS requests would be visible to any intermediate router -  
so there is a risk of data sniffing and mining by unauthorized  
intermediate parties. DNS cache poisoning could cause major disruption  
and misdirection away from the genuine information resources for an  
object

> Why does it necessitate increased tree-walking.

This needs to be corrected. It is NOT by design that ONS increases  
tree-walking, it is by the unintended extension to include serial  
level (item level) information.
> issue or that it's likely to be dramatically better with another  
ESDS will hold an instance of referral information about an individual  
object X only on ONE service node. Unlike the DNS protocol, which  
utilizes the fact, that "the same data is cached on multiple nodes".  
The ESDS protocol will hold the data on the node which data was  
published to. (of course it is true that in the layers below the  
protocol layer data can be stored and replicated on multiple servers.  
This is an implementation detail and will be invisible to the layers  
that sit on the ESDS protocol layer)

It is true that the same referral information CAN be published to  
multiple ESDS nodes. However in the basic use case referral  
information is only published to one node, and it will always be  
accessible via that single node.

Hence there won't be any caching problems in the draft ESDS  
architecture. This can be done because of unique requirements of the  
Discovery Services. We can expect that large amounts of 'link' records  
may be published to Discovery Services but that only a FEW queries are  
exercised against EACH published record.

> addresses?
There is a business need for tracking of serial level information on  
objects in the supply chain. The ONS as specified does not address  
this need, because it only holds records for product types - rather  
than individual instances of products.

However in real world pilots the ONS approach has been extended to  
include the serial level information. Also there are instances in  
which the ONS service is utilizing Internet's DNS roots instead of the  
specified alternate roots.

The real problem is concerned with track and trace of uniquely  
identifiable objects, most of which cannot be considered as devices,  
since they do not have a network interface.  (A passive RFID tag or a  
barcode or DataMatrix symbol is not a network interface in the  
conventional sense).

IP addresses are mainly used for identifying devices on a local or  
global network.  DNS provides a name lookup service for such devices.

ESDS is trying to solve the problem of tracking and tracing several  
trillions of individual objects per year.

The point is that we are trying to track and trace many more things   
than simply the number of devices that can connect to the internet (or  
which currently use the global DNS)

> Why can't data for more than one device be hosted on the
> same server?
We're not talking about devices - we can be talking about something as  
'dumb' as a carton of milk with a unique barcode ID printed on it.

The data for more than one device CAN BE hosted on the same node. Our  
argument is that we shouldn't waste IP real estate for objects that  
never interface into a network.

Many of the things we will be tracking and tracing are not devices,  
will never have any intrinsic network connectivity - but might  
occasionally be read at locations by readers that do have network  
connectivity.

The address space for these 'dumb' objects is already larger than even  
IPv6, since identifier structures of over 200 bits are already in use.
It's therefore not even possible to map these all onto IPv6 even if we  
wanted to (which we don't).

> Isn't the usual response here to have a wildcard entry
> (or synthetic entries) that points to a single server?

A single service (such as an EPC Information Service) may hold  
detailed information for several objects.
A manufacturer might use a wildcard entry to point to their  
information service - but further down the chain, the use of a  
wildcard entry does not help in the tracking of individual objects -  
other than to indicate all the potential information providers for  
that object type - rather than just the specific information providers  
who actually hold information for an individual object.

ONS effectively does use a form of wildcard entry (where the serial  
number can take any value) to point to a single server (usually the  
manufacturer's information about a particular product type).

However, beyond the manufacturer, we need more specific entries.   
There may be an opportunity to use ranges if a downstream party (such  
as a distributor or retailer) receives several objects of the same  
type and sequential serial numbers.
> I don't

ONS reverse maps the identifier class to a URL which is provided via a  
DNS NAPTR record.
> being overwhelmed than what you propose?

1) Currently ONS does not cause a major burden on DNS because it only  
stores a small number of NAPTR records per product type.
2) However, some companies produce billions of instances per year of a  
particular product type.
3) If we introduced a new DNS NAPTR record for every single object in  
the world - and created an additional DNS NAPTR record every time each  
object moved from one location to another, our concern is that this  
might overwhelm the DNS infrastructure.
4) We cannot escape the fact that there is potentially an extremely  
large number of objects to track - and that there will be increasing  
numbers of regulatory drivers to do this (mainly from public safety  
and anti-counterfeit perspectives).
5) What ESDS is trying to do is to establish an enabling framework for  
such track and trace services that does not cripple the DNS.
In the same way that search engines provide indexing between keywords  
and web pages and avoids having to create new DNS records for every  
single web page, ESDS provides resolution between unique identifiers  
of 'dumb' objects and the information services that hold information  
about them.  Each information service might itself hold detailed  
information about several millions or billions of objects - and it  
would still be necessary to specify the identifier of the object of  
interest in order to retrieve only the relevant information from among  
all the other information that a single information service holds.

> seem to apply here as well.
1) An individual object typically belongs to one industry sector.  An  
aircraft part belongs in the aerospace sector.  A packet of tablets  
belongs in the pharmaceutical sector.  Each sector has its own  
traceability requirements and is regulated by designated regulatory  
agencies.  (e.g. FDA for food and pharmaceuticals in the USA, FAA for  
safety of aircraft in the USA).
Each of these industry sectors could have its own ESDS which need not  
hold any records for objects from a different industry sector.
Globally, there may also be more than one ESDS per industry sector.   
These might be distributed on a geographic basis.
For example, there could be an ESDS focussing on traceability of  
pharmaceuticals in the USA - and operating under whatever regulatory  
guidelines are set by the USA FDA.  There might be a counterpart ESDS  
focussing on traceability of pharmaceuticals in Europe - and operating  
under the regulatory guidelines set by EFPIA.
In summary, there may be multiple ESDS services that are logically  
separable.  This is the closest analogy to multiple roots or multiple  
top-level domains on the internet.  It is one logical way to break the  
scalability problem into manageable chunks.

2) Objects travel between different regions - so there might be a need  
for a record in one ESDS to point to another ESDS in order to maintain  
continuity.  e.g. When an individual packet of tablets X in Europe is  
shipped to the USA, it would be helpful for a ESDS for pharmaceuticals  
in Europe to contain a record for object X that links to the address  
of the ESDS for pharmaceutical tracking in the USA.  Upon arrival in  
the USA, the company that has imported it might publish a record to  
the ESDS for pharmaceutical tracking in the USA to indicate receipt of  
X - and an additional record to point back to the ESDS for  
pharmaceutical tracking in Europe (to maintain a link to its previous  
life history before arrival in the USA.)

3) It is conceivable that two different organizations operating in  
different industry sectors or different regions might happen to create  
the same identifier to refer to completely different objects.   One  
way to avoid confusion is to rely upon globally unique identifiers, in  
which a 'locally created' identifier is fully qualified by a namespace  
indicator, such as a URN prefix.  However, it is difficult to enforce  
globally unique identifier management on things that do not require  
network connectivity.  Therefore, it may be necessary for an ESDS  
itself to 'advertise' some contextual information about its scope  
(such as industry sector(s) and geographic region(s)) - so that if  
there is any ambiguity or a search to a federation of ESDS services  
identifies multiple possible ESDS services, the advertised context  
information might enable disambiguation between them and the  
discarding of irrelevant results.

It should be noted that EPCglobal's Electronic Product Code provides a  
technical framework for globally unique identifiers.  However, there  
are still economic barriers to its widespread adoption across all  
industry sectors.
> a DHT or something like it? More detail seems appropriate here.
This is an area which needs further research. There is a desire for  
facilitating peer-to-peer communications, the exact means of doing so  
is not determined yet. Lisa suggested looking at the P2PSIP work and  
we are currently doing that.
> system of this type, you may need to use cryptographic access control.
Yes, this was referring to the security at the transport layer. Access  
control for ESDS server to client communication as well as ESDS server  
to server (peer-to-peer) needs to be enforceable. We are waiting for  
release of a recent report from BRIDGE Work Package 4 (Security) which  
includes specific recommendations for security techniques and  
technologies that can be used to meet the requirements of end users.   
It focuses specifically on the access control problem for Discovery  
Services and proposes the use of XACML as a framework for handling  
machine-readable access control policies.
> I wonder if the second case is really that important.
Different objects *simultaneously* having the same identifier can be a  
problem
because it is difficult to disentangle their paths.

See previous response about namespace qualifiers.

Another problem is when there are multiple reports of observations of  
the same object identifier
at very different locations at approximately the same time (such that  
the same object could not
have been simultaneously in several locations since it could not have  
travelled so quickly between them.
This may also be an indication of suspicious behaviour in the real- 
world, such as
counterfeit objects or objects carrying cloned ID tags.

There are however a number of objects that legitimately re-enter the  
system multiple times.
There are often referred to as reusable assets or returnable transport  
items.
There is even a designated identifier namespace for such objects - the  
GS1 Global Returnable Asset Identifier (GRAI).
This can be encoded as an EPC on an RFID tag - or as a barcode.

> To take the
I agree that for a returnable object, an access control policy may  
refer to a synthetic identifier
formed from a combination of a unique ID and a time window.

If ESDS is identifier agnostic, then:
1) it should allow any namespace qualifiers (such as URN prefixes,  
TEIs etc.) to be considered as part of the object identifier string.
2) an ESDS should be able to be configured to advertise the scope of  
its service (industry sector, geographic region) - and this  
information should be available on an equal basis to any query client,  
on a similar basis to queries about whether it is responding (ping /  
hello) or which version of a protocol it is running.
3) the combination of an identifier and an access control policy that  
specifies a time window should be sufficient to prevent different  
users of a genuine returnable asset or recirculating object from  
accessing information that they are not entitled to see.
> Why is this a desirable goal?

ONS and DNS rely upon the use of structured identifiers.  While this  
makes perfect sense in URNs that are exchanged between information  
systems, there are concerns about encoding structured identifiers in  
RFID tags that can be read at a distance by anyone with reader  
equipment.  The currently available low-cost EPC tags do not provide  
any protection from unauthorized read access.
This can be a problem if the structured identifier encoded on a tag  
indicates the product type of medication that a person is carrying.   
In some cases, even indicating the manufacturer of a specific  
pharmaceutical effectively reveals what the product type is likely to  
be, since some manufacturers specialize in only 1 or 2 product types.
For further details of such concerns, please see <http://www.darkreading.com/document.asp?doc_id=142127&page_number=4 

In the future, there may be technical ways to restrict unauthorized  
read access to tags - or to effectively use pseudonyms on tags so that  
the identifier encoded on the tag is cryptographically decoupled from  
the identifier of the object.  However, there are already a number of  
regulatory drivers pushing for improved serial-level track and trace,  
such as the e-pedigree legislation in Florida, California and  
elsewhere.  ESDS therefore needs to be designed to work with currently  
available tag technology and tag-encoding practices.

We believe that it is desirable for ESDS to minimize reliance on  
structured identifiers - but to treat identifiers as opaque strings,  
similar to keys in a distributed hash table.
> location in the bootstrap system.
That would require ID patterns because it won't scale to trillions of  
individual IDs.
However, it's not clear how well this works for unstructured IDs.
There may be some kinds of objects where two almost identical objects  
have
IDs that deliberately have no discernible correlation between them.

The majority of queries to an ESDS should be to a well-known ESDS  
(that is appropriate for a particular industry sector and region) and  
the need for using a bootstrap protocol should be minimal - really  
only for dealing with unexpected objects where there is no information  
in the frequently-used / well-known ESDS that a company would normally  
query.

Implementations of ESDS might use different changing models or quota  
limits for bootstrap protocol queries vs regular queries, in order to  
discourage use.
> objects they actually do not know about.
We need to keep in mind is that MOST ESDS nodes will only cater for a  
specific pattern of identifiers, for example "urn:epc:id:ata1:.*" so  
when a peer-to-peer request arrives that matches this pattern, the  
ESDS node just replies back with its URL. All following communications  
will take place between the initiating client (C) and the ESDS node  
(S) with the matching pattern, not between the ESDS peers. At this  
point S will require C to present an un-revoked SSL certificate from  
its trusted certificate authority with an up-to-date CRL. S can add  
provisions against data miners by restricting access to anonymous  
users or those whose SSL certificates are not granted sufficient  
authorization by S or the information providers to S.

Also there could be ESDS nodes that accept any identifiers. These  
nodes can choose to ignore all peer requests with regard to whether  
they accept an identifier or not. Or they could answer yes to ALL peer  
requests and be willing to service all the extra direct queries that  
they will receive.