Internet Engineering Task Force Service Location WG
Internet Draft J. Rosenberg, B. Suter
draft-ietf-svrloc-wasrv-00.txt Bell Laboratories
July 1997 H. Schulzrinne
Expires: January 1998 Columbia University
Wide Area Network Service Location
STATUS OF THIS MEMO
This document is an Internet-Draft. Internet-Drafts are working docu-
ments of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute work-
ing documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference mate-
rial or to cite them other than as ``work in progress''.
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Distribution of this document is unlimited.
1 Abstract
This document discusses the problem of service location in wide area
networks. This problem arises when a user wishes to locate some ser-
vice, such as a media bridge, internet telephony gateway, H.323 Gate-
keeper, unicast to multicast bridge, etc, which has some desired
characteristics, but whose location (in terms of IP address, domain,
or geographical location) is completely unknown, and may be anywhere
on the public Internet. We focus on the problem of locating Internet
Telephony Gateways (devices which connect an IP host to a POTS user).
This particular location problem is characteristic of the general
problem; furthermore, location of these devices is particularly dif-
ficult. Generally, the service location mechanisms need to be invoked
for every call setup. This implies that the call setup delays will
include the time to locate the gateway, and these delays should
therefore be kept to a minimum. With large numbers of gateways, the
location mechanisms can potentially become a network, processing, and
storage intensive operation. A solution to the gateway location prob-
lem must therefore be efficient and scalable in use of bandwidth, CPU
Rosenberg et. al. July 24, 1997 [Page 1]
Internet Draft Wide Area Location July 1997
power, and disk storage. Furthermore, relaying internet telephony
calls to the PSTN results in cost for the gateway provider, which
must somehow be passed on to the remote user. This requires security
mechanisms to provide authentication in an international environment.
We propose a solution to the wide area service location problem as an
extension to the existing Service Location Protocol [5]. The solution
relies on a scalable multicast advertisement of services to directory
agents, service specific directory agents called brokers, optional
service advertisement agents called notaries, new search capabili-
ties, and support for billing.
2 Introduction
There has been much attention recently to protocol support for the
location of services on the Internet. This work includes DNS records
for finding services in a particular domain [1][2], and for finding
fax gateways in a particular telephone exchange [3], DHCP for dynamic
discovery of local services upon cold-start [4], URNs for location
independent naming and location of network resources [12][13], and
most importantly, the Service Location Protocol [5] for location of
services in an administrative domain. Unfortunately, none of these
solutions adequately support location of services across wide area
networks, which we believe to be a key aspect of the general service
location problem. This document describes an extension to the service
location protocol for discovery of wide-area services.
There are a number of examples of wide area services. One is media
bridges (also known as Multipoint Control Units, or MCU's), which are
devices used for mixing voice or video together for multipoint con-
ferences. Another might be a media server, which contains movies and
multimedia accessible to the user for playback. Another example are
Internet telephony gateways. These devices allow Internet hosts to
communicate with standard POTS telephone users by translating Inter-
net telephony to traditional telephony. Yet another example is a mul-
ticast to unicast bridge, which would allow unicast-only endpoints to
receive Mbone broadcasts (an admittedly non-scalable and self-
defeating application).
There are two reasons why such services need not be located in the
same administrative domain as the client. The most important reason
is that the service simply may not be provided yet (or may never be
provided) by my domain. Consider a user who subscribes to a small
ISP. This ISP is not likely to support media bridges or telephony
gateways. This should not prohibit the client from using these ser-
vices, no matter how remote the server may be. Secondly, in many
cases it may not even be desirable for the service to be located in a
client's domain. The best example of this is the telephony gateway.
Rosenberg et. al. July 24, 1997 [Page 2]
Internet Draft Wide Area Location July 1997
To reduce costs, as an IP host, I would like to use a gateway which
is closest to the telephone I wish to talk to. Consider an IP host
residing in California who wishes to call a normal telephone in
France; the ideal server may be a gateway in France, almost across
the world from the client.
It should be noted that the use of the word "service" in this docu-
ment includes, but is not restricted to, network services. It may
also include services like Internet access, pizza delivery, airline
reservation, online bookstores, or banks. Any service which can be
accessed electronically, and which has attributes which can be
expressed in some form, can be found via this protocol.
3 Problem Definition
We formally define the wide area service location problem as follows.
A client wishes to find a server that provides a service. There are
no restrictions on the name space, IP address space, geographical
location, or autonomous system where the server may be located. Fur-
thermore, the client has no knowledge of the location of the server.
It has only a definition of specific service attributes or con-
straints (e.g., supported protocols) which are desirable or metrics
to minimize or maximize (e.g., cost, quality, distance).
In the case of wide-area services, we expect some servers to charge
for features they provide. This implies that cost is another
attribute which needs to be supported by servers. Unfortunately, cost
is not always just a simple number. It may depend on the duration of
usage of the service, the specific nature of the service, or even the
time of day during which the service is used. Consider Internet tele-
phony gateways. They will charge the client some amount for the por-
tion of the call carried over the PSTN between the gateway and the
final destination. Unfortunately, telephone cost structures range
from extremely simple (flat rate) to wildly complex (20 cents for the
first minute on weekends, 10 cents for each minute thereafter, but
only to Canada).
Since the distance (in terms of IP hops or delay) between a client
and a possible server may be large, the time required to access the
service may be large. Again, consider the case of an Internet tele-
phony gateway. In some cases, an IP host may wish to call a POTS end-
point from an IP phone, but may not care about the cost of the call.
What may be important is having the lowest end-to-end delays, and as
little loss as possible. This would imply usage of a gateway closest
to the host. Media bridges are another example. To reduce end-to-end
delays, a host may want to use the bridge closest to it (or perhaps
located at the centroid of the users being bridged), and the protocol
should support searches for such servers.
Rosenberg et. al. July 24, 1997 [Page 3]
Internet Draft Wide Area Location July 1997
The protocol should scale so that all Internet hosts could act as
clients, and there could be tens of thousands of servers for each
service. Since the time required to locate a service impacts the
overall delay seen by the user for that service, location times
should remain relatively constant as the number of clients and
servers grow. The control traffic used by the protocol should also
scale well, and not impose an undue burden on the network.
4 Alternate Solutions
A brief mention is in order a few alternative solutions for wide area
service location. One is web search engines, and the other is DNS.
Web search engines use automated programs, called web bots, to search
the web, and index and categorize pages as they go along. If servers
use web pages to describe the services they offer, the web bots would
collect this information and allow a user to query the resulting
database to locate a service. The user could choose between various
search engines (information brokers) based on their user interface,
size of their database, or the power of their query language. This
solution, however, has some serious drawbacks. Most current search
engines are simply based on keyword searches on indexed web pages,
and lack the precision to locate a specific service precisely (anyone
who has done a search which returned over ten thousand matches knows
this problem). Even cooperative approaches (based on indexing meta
information within the html, for example) still require the search
engines to periodically query a large number of servers. The web bots
have no way of knowing when information at a server has changed. This
means that data can remain out of date for long periods of time (this
can be devastating if this data reflects service cost, for example),
or web bots will have to increase the frequency of their queries to
any particular server, increasing network traffic. This solution also
places the burden of service location in the hands of a few, dedi-
cated search engines. Adding more of them can ease the processing
load, but at the expense of even more webbot traffic. Lastly, web-
based searching is designed for human interaction, and not for auto-
mated processes. For these reasons, we feel that web search engines
are not viable as a long term solution to the problem.
Another alternative is to use DNS. Consider the case of telephony
gateways. Each calling area (the 415 area code in the US, for exam-
ple) can map to a particular domain name. This domain name then
points to all of the gateways which can provide service for this
calling area. If a client wishes to call a certain area, it con-
structs the domain name, looks it up, and then gets a list of poten-
tial servers. This approach has many drawbacks. First, since all
gateways connected to the PSTN can potentially call every PSTN end-
point, every gateway can provide service to every single calling
Rosenberg et. al. July 24, 1997 [Page 4]
Internet Draft Wide Area Location July 1997
area. This means that the DNS entries would list every gateway for
each calling area. If the list of gateways for each calling area is
to be restricted (which it must), who gets to decide which gateways
are allowed to service various calling areas? The DNS solution does
not allow one to find a gateway which meets certain criteria (support
for the G.723 speech codec, for example) without querying the server
directly (which does not scale). It also tends to cause a lot of
traffic to pass through the root DNS server. For these reasons, we do
not feel that DNS is a viable long term solution either.
5 Service Location Protocol Limitations
The Service Location Protocol already meets many of the criteria
above. However, it was designed for use only within a single adminis-
trative domain. It suffers from a number of problems when one
attempts to apply it to a general wide area network with thousands of
servers and millions of clients.
The current architecture is centered around the concept of a direc-
tory agent, or DA. This device is a server which collects information
about services provided by various service agents (SA's) across the
network. The SA's register the services they provide directly with
the DA. Clients (also known as user agents, or UA's) wishing to
locate a service send a query to the DA, which then searches its
database for matches. The DA then returns the list of servers to the
client. Clients and SA's must know the IP address of the DA. This can
be learned in one of several ways: through static configuration,
through DHCP, through multicast advertisements from the DA, or
through increasing-scope multicast searches performed by the client
or SA.
We have identified the following difficulties in scaling the current
service location architecture to wide area networks:
1. Registrations of services from SA's to DA's are asynchronous, and
the soft-state refresh interval is fixed (the recommended value is
around three hours). This means that if thousands of servers attempt
to register, the DA may be swamped with bursts of messages. As the
number of servers grows, this problem worsens.
2. SA's must know the location of all DA's. In a small administrative
domain, this is easy. But in a wide area Internet, this is virtually
impossible. Having fixed tables of DA's does not scale well, and is
not dynamic enough. Using the multicast searching technique will
cause an overload on the network, since the scope of such searches is
neccesarily unbounded. Having DA's advertise their presence works
better, but still causes traffic. With fixed soft-state refresh
intervals, the bandwidth used grows linearly with the number of DA's
Rosenberg et. al. July 24, 1997 [Page 5]
Internet Draft Wide Area Location July 1997
present in the network.
3. As the number of servers and services grow, the disk space
required for a DA to store information about all of them is exces-
sive. DA's must somehow be able to provide service location for only
a subset of services.
4. In a wide area network, authenticating services at either the DA
or UA is much more important than in an administrative domain. We
expect, therefore, that all service advertisements will contain URL
and attribute authentication blocks. However, it may not be possible,
in all cases, for the DA or SA to authenticate every service. This
may be for any number of reasons: lack of availability of public keys
for all services, regulatory reasons, etc. Some additional support
for a hierarchy of authentication is required.
5. The current attribute query language has no support for choosing a
service based on minimizing or maximizing some function of an
attribute. This is a requirement for allowing service location based
on cost minimization. Furthermore, the simple attribute matching
rules are not sufficient for describing the possible costs of a phone
call.
6. The current mechanisms provide no way to find out the distance
between a server and a client, even with perhaps marginal precision.
This is required to choose servers based on their proximity to the
client.
6 Proposed Solution
We propose a set of backwards compatible extensions to the Service
Location Protocol which resolve all of the above difficulties. We
describe the basic mechanisms only, much of the detail remains to be
worked out.
6.1 Multicast Registration
First, in addition to SA registrations being unicast, we allow for
multicast registrations. A set of 1024 contiguous multicast addresses
are defined, with each service mapping to one of these addresses via
a string hash. (Note that these addresses are different from the 1024
currently used in the service location protocol for clients to find
SA's directly). Any DA interested in providing location services for
a service listens to its multicast address. In addition, any server
wishing to advertise a service also listens to its address. By lis-
tening to the address, a server wishing to advertise on it can keep
track of the number of other servers also advertising. Let's say a
server hears N other servers. We define a parameter
Rosenberg et. al. July 24, 1997 [Page 6]
Internet Draft Wide Area Location July 1997
CONFIG_INTERVAL_12 which is the average interval of 1 kbyte packets
to be transmitted, summed across all servers, into the multicast
group. Each server wishing to send an advertisement of size K will
periodically send the advertisement with a period T equal to:
T = R(1/2) max(CONFIG_INTERVAL_13 * F(age), N * CONFIG_INTERVAL_12 * K / 1024)
F(age) is a function which starts at some fractional power of two,
-CONFIG_INTERVAL_14, whenever an advertisement is different from the
previous. For each subsequent advertisement which is not different
from the previous, F(age) doubles, until it hits 1, at which point it
stops. We also define R(1/2) as a random variable uniformly dis-
tributed between 1/2 and 3/2. For example, say that
CONFIG_INTERVAL_12 is 64 ms. This means that the total rate of pack-
ets sent into the group will be 128 kb/s when group sizes are large.
If there are 1000 servers, each sending 1 kByte packets, each one
will get to advertise once a minute. When group sizes are smaller,
the packet rate remains at 1 every CONFIG_INTERVAL_13 (perhaps one
per hour) during steady state. However, when an advertisement
changes, the rate can temporarily increase (but not above 128 kb/s)
to hasten the broadcast of this announcement.
As a further enhancement to improve scalability, timer reconsidera-
tion should be used [11]. This algorithm requires end-systems to
recheck the validity of their event timers before sending a packet.
The validity is based on whether the perceived multicast group size
has changed since the timer was set. If the perceived group size has
grown, packet transmission is delayed in accordance with the most
recent group size estimate. This approach will help reduce packet
transmissions from servers which boot up, join their multicast group,
and initially see only one server: themselves.
This mechanism allows for the number of servers to grow without caus-
ing an increase in the bandwidth used on the multicast address. A
similar mechanism is used in RTP [9] to provide scalability, and has
been proposed as a general scaling mechanism for soft-state protocols
[10]. The advantage of this approach here is to solve two of the
above limitations. Now, SA's do not need to know the actual addresses
of DA's. This eliminates the need for wide-area multicast searches
and/or DA advertisements. It also makes the system dynamic. As soon
as a new DA is turned on, it can immediately learn about new ser-
vices, and this process is transparent to the SA's providing the ser-
vice. It also solves the problems of excessive load on DA's. The rate
is now finely controlled, independent of the number of SA's.
Rosenberg et. al. July 24, 1997 [Page 7]
Internet Draft Wide Area Location July 1997
It should be noted that this advertisement mechanism is used in other
protocols. For example, SAP [8] is used to advertise multicast ses-
sions on the Mbone. With this protocol, however, a client must wait a
substantial amount of time to collect announcements about all of the
current sessions. This is because the bandwidth allocated for the
protocol is constant. So, as the number of broadcasters (servers in
our case) increases, the amount of time required to fill the database
grows as well. For this reason, this advertisement mechanism alone is
not sufficient for wide area server location. It would also place an
undo storage and processing burden on clients.
SA's that are not multicast capable or which do not want to subscribe
to the service advertisement multicast group for reasons of bandwidth
or complexity may use a proxy SA or notary to diffuse their service
advertisements (sec 6.5).
6.2 Service Specific DAs: Brokers
We define a new type of DA, called a broker. A broker combines fea-
tures of a DA and an SA. Like a DA, it accepts service requests and
service type requests, and answers with service replies and service
type replies. The main difference is that it provides location ser-
vice for only a subset of services. This is required in order to
scale the disk storage and processing requirements for DA's. It is
also desirable since different services may have different require-
ments for matching client requests. For example, the Internet tele-
phony gateway service may often require searches for servers which
provide the cheapest cost for calling France. Database searches can
be optimized for this kind of query, but only if the DA knows that it
will receive mostly or only these type of service requests.
Unlike a DA, however, a broker will not respond to directory agent
discovery requests, nor will it send directory agent advertisements.
Instead, it will send service advertisements, like an SA. If a broker
offers service location for service X, then it will advertise itself
as offering service X-broker. For example, a broker offering printer
broker service may use a URL:
service:printer-broker://mymachine.mydomain.com:800
Brokers themselves can have various attributes which define the bro-
ker service they provide. For example, this might be a typical
attribute specification for a Internet telephony gateway broker:
(NUMBER_GATEWAYS = 1000), (VERIFICATION_LEVEL = STRONG)
This would define this telephony gateway broker as having a database
of around 1000 gateways. The verification level attribute indicates
Rosenberg et. al. July 24, 1997 [Page 8]
Internet Draft Wide Area Location July 1997
that this broker provides strong assurances of the correctness of the
gateway attributes it stores.
The ways in which brokers register with DA's can be varied. Some bro-
kers may wish to multicast their service advertisements. Other bro-
kers may be used just for clients in an administrative domain, and
therefore will perhaps use currently defined techniques to locate the
DA's in their domain, and register with them. Or, service advertise-
ments can be sent by some non-standard, out of band technique. Con-
sider a small ISP who has a DA for its customers, but no brokers. The
ISP can essentially lease broker service from a nearby, larger ISP.
The small ISP can just manually enter the service advertisements from
the big ISP brokers. Or, the small ISP can tell the big ISP the IP
address of its DA, so that the big ISP can have its brokers directly
register across the domain boundaries.
Brokers can be additionally programmed to implement policy local to
the administrator of the broker. This policy may restrict the set of
servers whose advertisements are kept by the particular broker. For
example, a major ISP is running a broker service for telephony gate-
ways for its customers. The ISP may decide that the broker should
reject all internet telephony gateway service advertisements from
servers run by a competing ISP. As another example, a broker may have
limited disk space, and may drop advertisements for servers which it
believes are unlikely to be used by any of its clients, based on past
history logs of service requests. It should be possible for any sort
of policy to be implemented. However, brokers should indicate the
policy attributes in the service advertisement from their broker.
The use of brokers for a particular service also adds more scalabil-
ity. Requests requiring attribute minimization can be considerably
more CPU intensive than simple lookups. As the queries for a particu-
lar service increase, and begin to exceed the processing capabilities
of a broker, additional brokers can be added to distribute the load.
This load distribution can be implemented easily in the DA, since
brokers are registered through them. The entire process becomes
transparent to the clients, and to the servers.
The main limitation to scalability for the brokers is the processing
burden to search a large number of records. If the number of servers
for a particular service begins to exceed several tens of thousands,
the storage requirements for them, and the time for even a single
search of the database for a match, can become excessive. In this
scenario, brokers always have the option of implementing policy to
restrict the size of the database. As faster machines and bigger
disks become available, these policies can be lifted. Furthermore,
such restrictions open up the possibility of market competition for
broker service. If a broker provider is willing to buy a big enough
Rosenberg et. al. July 24, 1997 [Page 9]
Internet Draft Wide Area Location July 1997
disk and fast enough machine to store and search every server, it can
attract more customers to its broker service.
This leads to the final distinction between DA's and brokers. Since a
broker service may not be local to my autonomous system, it is very
possible that there may be a charge for the service. In that case,
additional fields in the Service Query messages may be required to
allow for client-broker authentication and charging.
6.3 Adding the DISTANCE attribute
Another requirement is for clients to know, at least roughly, how
distant a server is. It is desirable for a client to include some
kind of distance metric in a service request to a broker.
To support this, we propose that all servers place a timestamp in
their service adverisements. When the advertisement arrives at a bro-
ker, the broker can compare the timestamp against the current time,
and then compute an estimate of the one way delays. In scenarios were
services are located across wide area networks, packet delays are
likely to be dominated by propagation delays. This implies that
timestamp estimates should remain relatively constant, even as traf-
fic loads vary. We call this one-way delay the DISTANCE attribute.
The approach has obvious drawbacks. It requires clock synchroniza-
tion, but the accuracy need not be perfect (a few milliseconds dif-
ference is fine). It only makes sense when packet delays are due
mainly to propagation delays. The figure gives the one-way delay from
a server to the broker. This may not be the same as the one-way delay
from a client to the server, especially if the client is not close to
the broker. Despite these drawbacks, it seems to be the only reason-
able solution which is both practical and scales.
The major advantage is that it requires no additional network traf-
fic, and therefore scales extremely well.
An alternative solution would be for servers to include in all ser-
vice advertisements an attribute called INITIAL_TTL. This attribute
indicates the value of the TTL field used in the IP packet containing
the advertisement. When a broker hears this advertisement on the mul-
ticast address, it notes the TTL in the IP packet when it arrived,
and the value of the INITIAL_TTL attribute. From this, a broker can
ascertain the number of hops from the server to itself. The problem
is that the Unix and Windows sockets interface do not allow an appli-
cation to read the TTL of a received packet. This makes this solution
impractical.
6.4 Adding support for cost minimization
Rosenberg et. al. July 24, 1997 [Page 10]
Internet Draft Wide Area Location July 1997
To support searches for the cheapest service, two new operators, max
and min, should be added to the allowable set of operators on
attributes. Service requests must be limited to one min or max opera-
tor per expression, in order to be well defined. In order for the min
or max operator to be applied, the broker must know the destination
telephone number, and an estimate of the call duration. We propose
that this information be specified by the client in the same manner
that attribute constraints are specified. For example, the following
might represent a request for an Internet telephony gateway to com-
plete a call to the Hotel Arabella in Munich:
internet-gateway//( &(CALL_DESTINATION == 49 89 92 32 44 40)
(CALL_DURATION == SHORT)
(DISTANCE < 10)
(SPEECH_CODER == G.729)
(min COST))
In this query, the client is specifying that a gateway is needed
which supports G.729, and whose distance from the client is less than
10 hops. These are attribute constraints. The distance metric is not
a true attribute, however; it is computed by the broker for each
client separately. The remaining data specify to the broker the
desired destination and estimated call duration, and then specifies
that cost is to be minimized.
In the case of Internet telephony gateways, describing the cost func-
tion is a nontrivial process. Our proposal is to use CIDR [6] like
aggregation, but applied to telephone numbers. The cost is specified
as a list of prefix, cost structure pairs. The prefix indicates the
range of telephone numbers, and the cost structure describes the cost
for reaching that range of numbers. The cost structure can be repre-
sented by some simple syntax which is capable of expressing concepts
such as flat rates, sums, days, and times. For example, the following
might be used to describe the cost as seen by a gateway in Califor-
nia:
1 415 822, ($0.1)
1 415, (($0.1) PLUS ($0.03 per MINUTE))
1, (($0.1) PLUS ($0.1 per MINUTE))
49, ($0.03 per MINUTE)
0, ($0.2 per MINUTE)
Rosenberg et. al. July 24, 1997 [Page 11]
Internet Draft Wide Area Location July 1997
The length of the prefix is given implicitly by the number of digits
before the comma. This gateway seems to be located in the 415 area
code, in the 822 exchange, to which it provides the cheapest service.
The gateway is also having a special on calls to Germany - just 3
cents per minute.
Wide area service location is meant to operate over the world wide
public Internet. The problem of how to represent cost (and other
attribute values) in an international context is difficult. One solu-
tion might be to fix cost and attribute representation to an arbi-
trary currency and language (e.g. dollar and English). An alternate
solution is to advertise cost in the local currency, and then have
the broker perform currency translation periodically.
6.5 Notaries
The final addition is a new device which we call a notary. Its pur-
pose is to lessen the burden of authentication which is placed on
DA's and brokers or to support non multicast capable SA's. Instead of
registering directly with all the brokers by multicasting its adver-
tisement, an SA will instead register in some way with a notary. It
is the job of this notary to provide authentication for the SA's
which it represents. Once authenticated, the notary acts as a proxy
for those SA's, multicasting the advertisements for them. The form of
the service advertisements is nearly identical to that of an SA. The
exception is that the authentication block is used to authenticate
the notary, and is the same authentication block for all SA's being
advertised from this notary. This lessens the burden of authentica-
tion to that of a single notary, instead of many SA's.
Due to legal problems regarding cryptographic technologies a unified
strong authentication mechanism may not be available world-wide very
soon (or ever). The use of notaries allows the SA's to authenticate
themselves to the notary by any local or proprietary scheme.
In general, for services that involve billing, authentication of the
server may not be enough. The user may want some assurance about the
trustworthiness of the remote service operator. Notary services could
be provided by authorities of sufficient influence and reputation to
be trusted by users. Such authorities may, for example, police misbe-
having service provides they represent, using non-electronic means
(such as auditing financial records, etc.). This kind of model
already exists; credit card companies will absorb the costs of fraud-
ulent vendors, and revoke their capabilities to use the credit card
to charge customers.
It is not our objective to specify the nature of the verification
procedure performed by the notary owner. Instead, all that is needed
Rosenberg et. al. July 24, 1997 [Page 12]
Internet Draft Wide Area Location July 1997
is a way to classify the level of assurance that a user can expect
from the notaries' authentication, and place this information as an
attribute describing the notary service itself.
The end result is a transitive chain of trust, similar to the mecha-
nisms used in PGP [7].
7 Conclusion
We have described the problem of location of services in the wide
area Internet, and noted the drawbacks of the Service Location Proto-
col for such uses. We then proposed several backwards compatible
extensions for resolving these drawbacks: multicasting of registra-
tions, service specific DA's called brokers, distance metrics, cost
structures for billing, and hierarchical authentication services via
notaries.
8 Security Considerations
The problem of service location involves potential danger of denial
of service or fraud.
Anybody can potentially advertise many bogus service records and
swamp the databases of the brokers to uselessness. Authentication
limits the damage a single individual can do as brokers would become
suspicious if a unknown entity suddenly starts advertising thousands
of servers with optimal characteristics. Even with authentication a
large number of individuals could still produce the same effect by
coordinating their efforts. Should this become a problem brokers
would have to require certification by a "known" notary before they
consider a service advertisement.
For services that involve billing, like internet telephony gateways,
the possibility of deliberate misinformation by a service operator to
attract and "trap" customers becomes likely. It is easy to imagine
that some off-shore gateway operator might advertise very cheap rates
and then charge exorbitant rates to the users credit card. It is for
this reason, among others, that we propose the notary server, as dis-
cussed above.
It is also possible for an SA to misbehave by ignoring the scaling
rules for multicasting advertisements. Although it is simple to
detect this kind of behavior and ignore the frequent messages, the
excessive traffic may cause valid advertisements from other users to
be lost. However, this problem is a generic one for multicast, and we
do not attempt to treat it at this level.
9 Bibliography
Rosenberg et. al. July 24, 1997 [Page 13]
Internet Draft Wide Area Location July 1997
[1] A Gulbrandsen, P Vixie, A DNS RR for specifying the location of
services (DNS SRV), IETF Request for Comments 2052, October 1996
[2] R. Moats, M. Hamilton, P. Leach, Finding Stuff, IETF Internet
Draft draft-ietf-srvloc-discovery-02.txt, Work in Progress
[3] C. Malamud, M. Rose, Principles of Operation for the TPC.INT
Subdomain: General Principles and Policy, IETF Request for Comments
1530, October 1993
[4] R. Droms, Dynamic Host Configuration Protocol, IETF Request for
Comments 2131, March 1997
[5] J. Veizades, E. Guttman, C. Perkins, S. Kaplan, Service Location
Protocol, IETF Request for Comments 2165, June 1997
[6] V. Fuller, T. Li, J. Yu, K. Varadhan, Classless Interdomain
Routing (CIDR): an Address Assignment and Aggregation Strategy, IETF
Request for Comments 1338, September 1993
[7] The International PGP Homepage can be found at:
http://www.ifi.uio.no/pgp
[8] M. Handley, SAP - Session Announcement Protocol, IETF Internet
Draft, draft-ietf-mmusic-sap-00.txt, November 1996. Work In Progress
[9] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, RTP: A
Transport Protocol for Real Time Applications, IETF Request for Com-
ments 1889, January 1996
[10] P. Sharma, D. Estrin, S. Floyd, V. Jacobson, Scalable Timers
for Soft State Protocols, in Proceedings of IEEE Infocom, Kobe,
Japan, 1997.
[11] J. Rosenberg, H. Schulzrinne, Timer Reconsideration for
Enhanced RTP Scalability, submitted for publication in the Proceed-
ings of IEEE Infocom 1998
[12] R. Moats, URN Syntax, IETF Request for Comments 2141, May 1977
[13] R. Daniel, M. Mealling, Resolution of Uniform Resource Identi-
fiers using the Domain Name System, IETF Request for Comments 2168,
June 1997
10 Authors Addresses
Jonathan Rosenberg
Lucent Technologies, Bell Laboratories
Rosenberg et. al. July 24, 1997 [Page 14]
Internet Draft Wide Area Location July 1997
101 Crawfords Corner Rd.
Holmdel, NJ 07733
Rm. 4D-534B
email: jdrosen@bell-labs.com
Henning Schulzrinne
Columbia University
M/S 0401
1214 Amsterdam Ave.
New York, NY 10027-7003
email: schulzrinne@cs.columbia.edu
Bernhard Suter
Lucent Technologies, Bell Laboratories
101 Crawfords Corner Rd.
Holmdel, NJ 07733
Rm. 4G-531
email: suter@bell-labs.com
Rosenberg et. al. July 24, 1997 [Page 15]
