Subject: [ESDS] ESDS and bootstrapping

From: Stephen van Egmond <[email-masked]>
Date: Wed, 30 Jan 2008 15:46:17 +0000

To paraphrase the definition of bootstrapping in the ESDS problem
statement, bootstrapping starts with the problem of an entitty that has
only an object identifier (probably an RFID tag) and wants to find out
more about the thing it's attached to.

In the current EPCglobal architecture, the answer involves ONS and
ultimately the DNS root servers.  The answer also opens a number of
information leaks about every participant's manufacturing process,
internal structure, and inventory, to name just a few.

What we would like to do is come up with a solution that doesn't rely
on DNS, and provides better security. Here's some ideas.

The main challenge is discovery: given a object identifier (hereafter oid),
which DS instance can tell me more about it? 

We're thinking maybe an out-of-band communication protocol that has less
stringent security, on a different SOAP endpoint:
http://ds.company.biz/ -- regular DS traffic
http://ds.company.biz/announce -- peer to peer information exchange

The information exchange would understand some straightforward requests.
We presume that the peer is able to formulate a reasonably random peer ID that
would uniquely identify it.  This is open to spoofing, but given the protocol
that's easy to detect and track down.

setPeerProfile(peer_id, profile)
- This announces that peer_id conforms to the given profile.
  The profile might have information about the company or department,
  and what object identifier ranges it answers.  A simple example for
  an airplane manufacturer (AirTrain) is to announce that it understands
  object identifiers:
	aircar.*

  This profile information should at least indicate:
	- object ID patterns that it understands
	- publically routable IP/port combinations for their DS
	  servers, along with order of preference, similar to MX 
	  servers for SMTP
	- ownership information (company, administrators, and phone/email
	  contact info)
	- an expiry timestamp after which the profile should be considered expired.
	- of course it would be extensible
	- how many DS peers it knows about

The peer profile should be updated periodically, certainly well within
the expiry timeframe.

getSupernodes()
 
- Publically-spirited DS operators could offer to act as supernodes
  for peer profiles, which will let them collect peer profiles and act as
  clearinghouses within the network.  This function would return a list
  of other DS's that the requestor should offer its profile to.

getPeerProfiles(spec)

- This would return a list of currently-valid peer profiles that DS
  instance knows about that match the specification. So if you have an
  object ID that is aircar.581.958198705171 you might reasonably inquire
  about aircar.581.* and aircar.*.

Other possibilities

The DS bootstrap problem may eventually converge on the same problem as Internet routing tables?

What about something like XMPP's Service Discovery (draft) extension? This
might provide a way for peers to publish information about the extensions
(the E in ESDS) they offer.
http://www.xmpp.org/protocols/disco/

References

I'm borrowing from the bittorrent specification, which is admirably brief.
http://www.bittorrent.org/protocol.html

XMPP Standards Foundation is a clear and lucid standards body.
http://www.xmpp.org/protocols/

UDDI contributed the idea of a service discovery protocol that uses the same
protocol as the service itself.

----- End forwarded message -----

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

---

From: Mark Harrison <[email-masked]>
Date: Wed, 30 Jan 2008 17:52:31 +0000

Dear Stephen,

Thanks for these thoughts regarding approaches to a bootstrapping  
protocol for ESDS.
I've inserted a few comments inline below:

Best regards,

- Mark Harrison

> http://ds.company.biz/announce -- peer to peer information exchange

Agreed.  This is logically a somewhat different interface from the  
ESDS query interface or the publish/capture interface (event creation  
method)

I was also thinking it's more about a P2P overlay across multiple DS,  
so that one DS can 'announce' to other DS that "there is a 'lost  
child' here - and does anyone (of the other DS) recognize them?"

>  an airplane manufacturer (AirTrain) is to announce that it  

Now - are we both talking about a P2P announcement between Discovery  
Services - or announcing 'down' to the individual company information  
services?  If peerProfiles are not managed mainly by the supernodes,  
we need to make sure that this announcement protocol does not   
construct a mechanism that  results in increased exposure to denial-of- 
service attacks.

>  of other DS's that the requestor should offer its profile to.

I was initially only thinking of getSupernodes(spec)
- but if getPeerProfiles(spec) also allows searching across peer  
profiles from across multiple supernode peers, then that makes sense.

>  about aircar.581.* and aircar.*.

That seems OK.