178
Internet of Things (IoT)
context, where product flows constitute valuable business intelligence. The combination of
an EPC company identifier and item reference is usually enough to determine the exact kind
of object to which it belongs. This information can be used to identify assets of an individual
or an organization. If someone happens to wear a rare item or a rare combination of belongings, one could track that person even without knowing the actual serial numbers. In addition to this supply side, there are also many entities that have a certain or at least potential
demand for EPC traces, which will be illustrated in the following section.
9.3 Object Naming Service
For ONS, a hierarchical, tree-like architecture has been proposed by EPCglobal. The ONS
protocol is identical to the protocol used by the Domain Name System (DNS). The ONS
root is the central root of this tree. Further delegation works as in DNS, and information
providers itself will deploy authoritative ONS servers—for their EPC ranges—that point
to their actual EPCIS. This architecture and protocol choice will have a deep impact on the
reliability, security, and privacy of the involved stakeholders and their business processes,
especially for information clients, as will be discussed after the technical inheritance of
DNS has been described in the next section.
9.3.1 ONS Foundation: DNS
From a technical point of view, ONS is a subsystem of the DNS, and are codified in many
requests-for-comments (RFCs). The main design idea of ONS is to first encode the EPC into
a syntactically correct domain name, then to use the existing DNS infrastructure to query
for additional information. This procedure makes use of the Naming Authority Pointer
(NAPTR) DNS record, which is also used with other Internet applications, for example the
Session Initiation Protocol (SIP) for Voice-over-IP (VoIP) to map phone numbers into corresponding URIs.
For a discussion of the DNS security heritage to ONS later in this chapter, in the following sections a short summary of the inner workings of DNS is given, discussing names,
architecture, and protocol.
9.3.1.1 DNS Names and Architecture
The basic function of the DNS is that of an Internet name service: the resolution of humanmemorable, alpha-numerical hostnames into the corresponding purely numerical IP
addresses used for datagram routing. At an early stage of the Internet, the Advanced
Research Projects Agency Network (ARPANET), name resolution was performed by referring to a flat text file that stored mappings between the hostnames and the IP addresses
(hosts file). Obviously, maintaining and synchronizing copies of the hosts file on all computers connected to ARPANET were extremely inefficient. To address this issue, the name
resolution protocol was updated to introduce a central distribution of the master hosts
file via an online service maintained by the Network Information Center. This architecture worked successfully for about a decade. However, the rapid growth of the Internet
rendered this centralized approach impractical. The increasing number of changes introduced to the hosts file and its growing size required hosts to regularly download large
Internet of Things (IoT)
context, where product flows constitute valuable business intelligence. The combination of
an EPC company identifier and item reference is usually enough to determine the exact kind
of object to which it belongs. This information can be used to identify assets of an individual
or an organization. If someone happens to wear a rare item or a rare combination of belongings, one could track that person even without knowing the actual serial numbers. In addition to this supply side, there are also many entities that have a certain or at least potential
demand for EPC traces, which will be illustrated in the following section.
9.3 Object Naming Service
For ONS, a hierarchical, tree-like architecture has been proposed by EPCglobal. The ONS
protocol is identical to the protocol used by the Domain Name System (DNS). The ONS
root is the central root of this tree. Further delegation works as in DNS, and information
providers itself will deploy authoritative ONS servers—for their EPC ranges—that point
to their actual EPCIS. This architecture and protocol choice will have a deep impact on the
reliability, security, and privacy of the involved stakeholders and their business processes,
especially for information clients, as will be discussed after the technical inheritance of
DNS has been described in the next section.
9.3.1 ONS Foundation: DNS
From a technical point of view, ONS is a subsystem of the DNS, and are codified in many
requests-for-comments (RFCs). The main design idea of ONS is to first encode the EPC into
a syntactically correct domain name, then to use the existing DNS infrastructure to query
for additional information. This procedure makes use of the Naming Authority Pointer
(NAPTR) DNS record, which is also used with other Internet applications, for example the
Session Initiation Protocol (SIP) for Voice-over-IP (VoIP) to map phone numbers into corresponding URIs.
For a discussion of the DNS security heritage to ONS later in this chapter, in the following sections a short summary of the inner workings of DNS is given, discussing names,
architecture, and protocol.
9.3.1.1 DNS Names and Architecture
The basic function of the DNS is that of an Internet name service: the resolution of humanmemorable, alpha-numerical hostnames into the corresponding purely numerical IP
addresses used for datagram routing. At an early stage of the Internet, the Advanced
Research Projects Agency Network (ARPANET), name resolution was performed by referring to a flat text file that stored mappings between the hostnames and the IP addresses
(hosts file). Obviously, maintaining and synchronizing copies of the hosts file on all computers connected to ARPANET were extremely inefficient. To address this issue, the name
resolution protocol was updated to introduce a central distribution of the master hosts
file via an online service maintained by the Network Information Center. This architecture worked successfully for about a decade. However, the rapid growth of the Internet
rendered this centralized approach impractical. The increasing number of changes introduced to the hosts file and its growing size required hosts to regularly download large