Re: [ESDS] ESDS and bootstrapping

[Mark Harrison <[e-mail]>]

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

> 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

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

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

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.

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

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.

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

That seems OK.

>
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/esds


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