One document matched: draft-rosen-dns-sos-00.txt
dnsext B. Rosen
Internet-Draft Marconi
Expires: July 1, 2004 January 2004
Emergency Call Information in the Domain Name System
draft-rosen-dns-sos-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working 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
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 1, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
Location of a caller is essential to processing an emergency call.
Location is needed to correctly route the call, and to correctly
dispatch help to the right place. Location can be specified in
geographic (lat/lon/altitude) or civil (country/provin ce/city/
street/floor/room) forms. Determining which Emergency Response
Center (ERC) should receive the call requires comparing the callers
location to a service area boundary description, which may require
location in geo form. Dispatching a call generally requires a civil
location. There is a need for a way to translate a civil to a geo or
vice versa to the resolution of a room. There is also a need to
publish the service area boundary of the ERC and the emergency
responders. Further, there is a need for a database of legal civil
addresses (sometimes called a Master Street Address Guide) that civil
Rosen Expires July 1, 2004 [Page 1]
Internet-Draft Emergency Call Info in the DNS January 2004
locations may be verified against to assure correctness, and
uniformity of naming so that dispatch is accurate. The memo proposes
a new DDDS application and a new POLY RR to assist emergency calls.
Those who believe that this is a misuse of the DNS are invited to
look at the discussion in Section 8 on how it is possible that this
idea is realized in a completely separate database not connected to
the real DNS, but using the same architecture, protocols and data
structures.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . 3
2. Problem . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of the Solution . . . . . . . . . . . . . . . . . . 5
4. POLY RR . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1 IANA Registration for POLY Format . . . . . . . . . . . . . 10
5. The SOS Application Specifications . . . . . . . . . . . . . 10
5.1 Application Unique String . . . . . . . . . . . . . . . . . 10
5.2 First Well Known Rule . . . . . . . . . . . . . . . . . . . 10
5.3 Expected Output . . . . . . . . . . . . . . . . . . . . . . 10
5.4 Valid Databases . . . . . . . . . . . . . . . . . . . . . . 10
5.4.1 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.4.2 Services Parameters . . . . . . . . . . . . . . . . . . . . 11
5.5 What constitutes an 'Sos Resolver'? . . . . . . . . . . . . 12
6. Registration mechanism for sosservices . . . . . . . . . . . 12
6.1 Registration Requirements . . . . . . . . . . . . . . . . . 12
6.1.1 Functionality Requirement . . . . . . . . . . . . . . . . . 13
6.1.2 Naming requirement . . . . . . . . . . . . . . . . . . . . . 13
6.1.3 Security requirement . . . . . . . . . . . . . . . . . . . . 13
6.1.4 Publication Requirements . . . . . . . . . . . . . . . . . . 13
6.2 Registration procedure . . . . . . . . . . . . . . . . . . . 14
6.2.1 IANA Registration . . . . . . . . . . . . . . . . . . . . . 14
6.2.2 Initial Registrations . . . . . . . . . . . . . . . . . . . 14
7. Obscuring Lower Level Information . . . . . . . . . . . . . 16
8. Notes and things to do . . . . . . . . . . . . . . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . 17
References . . . . . . . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . 19
Rosen Expires July 1, 2004 [Page 2]
Internet-Draft Emergency Call Info in the DNS January 2004
1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Problem
Placing an emergency call to get help depends on location = where the
caller is located at the time of the call. Location is needed for
two fundamental reasons:
1. To determine which Public Safety Answering Point (PSAP) also
known as an Emergency Response Center (ERC) to direct the call
to.
2. To direct responders (police, fire, ambulance) to the caller.
Location, within the context of emergency calls, can be expressed in
two different forms, geographic (geo) - lat/lon/altitude and civil -
country/state/city/street/building/floor/room.
Determining the correct ERC is not trivial. ERCs have service
boundaries. If you are inside the service boundary, that ERC should
get your call. Nearest ERC, home ERC or other, simpler mechanisms
will not work. One must either know from some kind of authenticated
database the ERC that serves a given civil Address, or have a geo
location, know the service boundaries, and compare the location of
the caller with all of the ERC service boundaries to determine which
boundary the geo location falls within. There are about 6,000 ERCs
in North America, and perhaps 3X that in the rest of the world (ed
note, anyone have a better number?). As a practical matter, service
boundaries are defined by a combination of civil and geo forms, but
can reasonably be converted to an all-geo representation, which is
the most practical form to use when determining within which boundary
the caller lies.
With the advent of Voice over IP, the Internet presents daunting
problems to emergency calls because users can be anywhere in the
world relative to the elements that are processing the call.
Consider for example, a user sitting in a café in Chicago with a
laptop connected to the Internet via a hotspot, communicating with
her employer's SIP proxy through a VPN tunnel. An accident occurs
and the patron calls for help. What if the employer is in Sierra
Leone, and has a local VoIP service provider? The employer's proxy
server must determine based on the actual location of the user that
the ERC is in Chicago!
In processing a call to an ERC using a protocol such as SIP, a
routing element must determine the location of the caller, and either
Rosen Expires July 1, 2004 [Page 3]
Internet-Draft Emergency Call Info in the DNS January 2004
have access to all the ERC service boundaries, and run an
intersection algorithm determine the ERC, or have a civil address
and a database that contains the ERC that serves that address.
Having determined the correct ERC, the routing element must forward
the call to it (which implies knowing the URI of that ERC). At
present, there is no universal mechanism to learn the service
boundaries of the ERCs. There are commercial databases available for
some areas that have such information. This memo discusses a
mechanism by which an ERC may publish its service boundary in a
publicly available, standardized form.
Once the correct ERC is determined, the call will be forwarded to it.
The ERC will then answer the call, and determine what response is
required. The responders are then dispatched to the location of the
caller. Dispatch is always based on civil location. If the location
is reported by the caller in geographic form, it must be translated
to civil form in the ERC. Furthermore, responders also have service
boundaries, and the service boundaries of the responders do not
necessarily match the service boundary of the ERC.
It is very common for there to be multiple response units dispatched
by one ERC, and it is possible for a responder's service boundary to
cross ERC service boundaries, although this is much less common.
Once again, there is no standardized way to determine the service
boundaries of the responders, although this problem is less important
to solve in a standardized way because only the ERCs need the
information. Nevertheless, if the same mechanism used to publish ERC
service boundaries could be used for responder service boundaries, it
would be very desirable.
Because dispatch is always to a civil location, ERCs must translate
location reported as geo to civil. At present, the way this is done
is to employ a commercial "graphical information system" to capture
street address data, often by manual digitization of aerial
photographs. Location to the range of a street address is possible
using this mechanism, but it is essential for larger buildings to
have much finer grained location information. Accuracy to a room on
a floor in a building is desired, and dispatch to that level is
essential in a large multistory structure. There are no standardized
mechanisms for this, and in fact there are no mechanisms short of a
fire marshal carrying a box of paper floor plans in his car for
interior layout information.
If location is available as a civil, access to a database that
enumerates all known street addresses and indicates the ERC, and
responders, can provide the caller and the ERC with the information
they need without any geo conversions or comparisons. However, this
database (MSAG) must be made available to the routing elements, and
Rosen Expires July 1, 2004 [Page 4]
Internet-Draft Emergency Call Info in the DNS January 2004
mechanisms used to determine the civil address of a device must be
verified against the MSAG, because there are many variations in
naming locations (First Street vs 1st Street, New York Avenue
Northwest, vs New York Avenue). Accurate dispatch requires
uniformity of reporting civil addresses, and thus all addresses must
be verified against the MSAG prior to an emergency. This implies the
MSAG, which is commonly available and in use by ERCs, must be more
publicly available.
Notice that the routing proxy server may require a geo, but the ERC
requires a civil. That implies that regardless of what form the
original location is reported, either the routing proxy server or the
ERC may have to translate Location in calls to the other form.
Translation databases from geo to civil and civil to geo are thus
required for many emergency calls. This memo describes a
standardized mechanism for publishing such databases.
Organizing ERCs and responders is a government function. Governments
determine where boundaries are, how coverage is handled in less
populated areas, etc. In smaller countries, the national government
organizes the entire system. More commonly, while some aspects are
organized and regulated at the national level, much of the
organization is delegated to state/province/district level, and often
further delegation to country and/or city/township level is done.
Any organization of the data here are must mirror this delegation.
There is a specific problem that occurs because ERCs and responders
are government organized. There are areas of the world that are
disputed - more than one country claims the area as part of its
territory. This gives rise to multiple ERCs having a service
boundary including disputed territory. While such areas are few and
relatively small, the problem exists and must be accounted for in the
design of systems and databases.
3. Overview of the Solution
We propose to use the DNS to publish the service boundary, MSAG and
civil-geo-civil translation databases. We think the DNS is
particularly appropriate for this purpose because of its delegation
mechanism, which we will show matches the need very closely.
Starting at the root sos.arpa (sos being the universal symbol for
emergency), we propose that the next level be a two-character iso
country code, e.g. cn.sos.arpa. We propose that an international
agency, probably the ITU be delegated the sos.arpa domain, and that
it delegate cn.sos.arpa to an agency selected by the government of
China. The national agency can, if appropriate, make further
delegations. For example, there might be a domain such as
pittsburgh.allegheny.pa.us.sos.arpa representing the City of
Rosen Expires July 1, 2004 [Page 5]
Internet-Draft Emergency Call Info in the DNS January 2004
Pittsburgh, in the Commonwealth (state) of Pennsylvania, in the
United States. The city would create subdomains in its domain
representing streets, and within those street domains, subdomains for
addresses. For example, we might find an entry at
123.Main.Pittsburgh.Allegheny.pa.us.sos.arpa.
At each of the levels of this hierarchy, we propose that the boundary
of that area be defined with a new RR called "POLY". A POLY would
have a sequence of points represented as lat/lon pairs or lat/lon/
altitude triples. The domain could have more than one POLY because:
o Some boundaries have multiple independent areas (several islands
for example)
o Holes may exist within the boundary
In addition, some of these domains may have NAPTR records
representing the service URIs for the ERC or responders that cover
that boundary. These may exist at any level.
For interior layout information, a city/township may delegate a
street address to a building owner. In turn, the building owner may
delegate subdomains to Suite tenants. The tenant, or building owner,
would enter floor subdomains, and within those, room domains. Each,
as above, would have POLY boundaries.
Of course, any administrative entity in the hierarchy could contract
with a registrar to manage the delegation of its subdomains if it so
chose. It could also create an administrative mechanism to obtain
lower level data, and publish lower levels itself, rather than
delegate.
Interior information could be considered a privacy concern. For that
reason, the domain names of the lower level hierarchies can be
obscured (sequential or random numbers for example), with the actual
name placed inside the entry (CNAME) and the contents encrypted.
We note that the actual meaning of any level in this hierarchy is not
defined, and the number of levels is not significant. What matters
is that the names (unobscured) mean something to the (human)
dispatcher and responder.
The above information, in theory at least, is sufficient to solve the
problem. Given a civil location, the routing proxy looks it up in
the sos.arpa tree, and locates the ERC NAPTR. If there is no ERC
entry, it looks upward in the tree until one is found. Given a geo
location, one starts at the top of the sos.arpa tree, and examines
the entire zone, intersecting the location with the boundaries (of
the countries). Finding the country (or countries if in a disputed
area) boundary(s) within which the location lies, drop down one level
Rosen Expires July 1, 2004 [Page 6]
Internet-Draft Emergency Call Info in the DNS January 2004
and repeat until one reaches the bottom of the hierarchy. That
yields a civil location, and the procedure above can be used for
determining the ERC uri and responders.
Of course, the solution as presented depends on the entire tree being
available. Clearly, while some jurisdictions have at least street
level information in existing Geographic Information Systems, not
every jurisdiction has that level of automation yet. Due to the way
mobile telephone systems report location (which is nearly always in
some form of geo), such GIS systems are becoming more common and will
be ubiquitous eventually. However, to be practical, solutions should
not entirely depend on such extensive databases. Therefore, we
propose that in addition to the civil boundary information, we also
provide service boundary information - that is the POLYs representing
the service boundaries for the ERCs. A routing proxy with a geo
would need only the complete list of ERC service boundaries in order
to do an intersection to determine the correct ERC. That information
is much more readily available and deployable in a short time.
Further, in most cases, ERC boundaries are aligned to political
boundaries. A large city, for example, typically has only one ERC,
whose service boundary matches the city boundary. Thus, street level
information is not needed for a civil location to find the serving
ERC, if the city entry has an ERC NAPTR. In is common for an ERC to
serve more than one township or smaller city, but the mechanism would
work equally well for such a circumstance. There are some
circumstances where ERC boundaries do not align well. Some ERCs only
serve a part of a city, and an adjacent ERC serves the remainder. To
ease deployment, we propose that in those circumstances, a SIP
routing proxy be designated as the ERC NAPTR for the entire city, and
that proxy has the information needed to determine which of the two
ERCs serve the caller location, forwarding the call to the correct
ERC.
Of course, the DNS is not organized to search the breadth of a level,
and the time required to do multiple intersections is costly (the
time between initiating an emergency call and answering it is ideally
under two seconds). For this reason we expect that the civil-to-geo
information represented in the DNS will be cached by the routing
server, which will compute an inverse geo-to-civil database, and make
the operations very fast. In fact, we expect that the DNS would not
be used directly during processing of an emergency call. Rather, the
DNS is the PUBLISHING mechanism, which will be cached and used by the
route server and the ERC. Typically, for example, we would expect a
routing server to know the general location of its clients and cache
that area of the DNS tree, plus the inverse data.
Clearly, the existence of a street address entry indicates a valid
Rosen Expires July 1, 2004 [Page 7]
Internet-Draft Emergency Call Info in the DNS January 2004
civil Location. The jurisdiction responsible for defining valid
addresses within its domain would enter its preferred spelling/
representation of that name. Any entity assigning civil locations
would verify an address by looking it up in the sos.arpa tree. In
this regard, the tree is the MSAG.
4. POLY RR
The packet format of the POLY RR is given below. The DNS type code
for POLY is ??
The first 3 bytes are a header
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NUMBER OF POINTS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| FORMAT | Datum |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The number of points in the polygon is first. FORMAT is a code from
an IANA registry defining the interpretation of the subsequent
location data. Code points defined in this memo are:
Code 0 = 3DAm
All points have 3 coordinates, altitude is expressed in meters.
Code 1 = 3DAf
All points have 3 coordinates, altitude is expressed in floors.
Code 2 = 2D
All points have 2 coordinates.
Code 3 = P3Dam
Like 3Dam, but all points except the first are represented in 2s
complement 16 bit delta fractions of a degree (for Lat/Lon) and 8 bit
2s complement integer, 8 bit fraction delta meters.
Code 4 = P3Daf
Like 3Dam, but all points except the first are represented in 2s
complement 16 bit delta fractions of a degree (for Lat/Lon) and 8 bit
signed floor number.
Code 5 = P2D
Like 2D, but all points except the first are represented in 2s
complemented 16 bit delta fractions of a degree.
Datum is a code for the reference model the points represent. Codes
are the same as in [DHCPLCI].
Rosen Expires July 1, 2004 [Page 8]
Internet-Draft Emergency Call Info in the DNS January 2004
The basic point location format is copied from [DHCPLCI].
Latitude: a 34 bit fixed point value consisting of 9 bits of integer
and 25 bits of fraction. Latitude SHOULD be normalized to within +/-
90 degrees. Positive numbers are north of the equator and negative
numbers are south of the equator.
Longitude: a 34 bit fixed point value consisting of 9 bits of
integer and 25 bits of fraction. Longitude SHOULD be normalized to
within +/- 180 degrees. Positive values are East of the prime
meridian and negative (2s complement) numbers are West of the prime
meridian.
Altitude: A 30 bit value in 2s-complement fixed-point 22-bit integer
part with 8-bit fraction, expressed as meters or floors depending on
the value of FORMAT
The meaning of altitude measured in floors is the same as that
specified in [DHCPLCI].
The values of Latitude, Longitude, and if appropriate, Altitude are
packed sequentially into bytes with no filler. This means that a 2D
point would be 68 bits, and a 3D point would be 98 bits. The next
point follows immediately (bit-wise). The last byte would be zero
filled. For example, a POLY with Format 0 and 100 points would be
1228 bytes long: 3 byte header plus 100*98/8 = 1225 bytes of data.
Multiple POLYs can exist in an entry. The meaning of multiple POLYs
depends on whether one POLY completely encloses another. Multiple
POLYs that are not boundaries within another boundaries are additive
(multiple islands). POLYs that are contained within another POLY are
subtractive (holes). If there are multiple levels of enclosing
POLYs, they define islands within holes. For For example:
+------------------------+
| |
| +------------------+ |
| |//////////////////| |
| |//+---+////+---+//| |
| |//| |////| |//| |
| |//| |////| |//| |
| |//+---+////+---+//| |
| |//////////////////| |
| +------------------+ |
| |
+------------------------+
Rosen Expires July 1, 2004 [Page 9]
Internet-Draft Emergency Call Info in the DNS January 2004
4.1 IANA Registration for POLY Format
IANA shall create a registry for the format of a POLY. The registry
shall initially contain the 3 entries enumerated above. An RFC shall
be required to add a new code in the registry.
5. The SOS Application Specifications
The following text is based on the equivalent text in [RFC2916].
This template defines the SOS DDDS Application according to the rules
and requirements found in [RFC3402]. The DDDS database used by this
Application is found in [RFC3403] which is the document that defines
the NAPTR DNS Resource Record type.
5.1 Application Unique String
The Application Unique String is a civil location expressed as a
series of increasingly specific regions starting at national
(country), with the components separated by periods, and in reverse
order (i.e. country is rightmost). There is no significance to the
meaning of the components as long as the civil location is
interpretable by residents in the specified location, and they are in
increasingly specific.
5.2 First Well Known Rule
The First Well Known Rule for this Application is the identity rule.
The output of this rule is the same as the input. This is because
this Application's databases are organized in such a way that it is
possible to go directly from the name to the smallest granularity of
the namespace directly from the name itself.
5.3 Expected Output
The output of the last DDDS loop is a Uniform Resource Identifier in
its absolute form according to the 'absoluteURI' production in the
Collected ABNF found in [RFC2396]
5.4 Valid Databases
At present only one DDDS Database is specified for this Application.
"Dynamic Delegation Discovery System (DDDS) Part Three: The DNS
Database" [RFC3403] specifies a DDDS Database that uses the NAPTR DNS
resource record to contain the rewrite rules. The Keys for this
database are encoded as domain-names.
The output of the First Well Known Rule for the SOS Application is
Rosen Expires July 1, 2004 [Page 10]
Internet-Draft Emergency Call Info in the DNS January 2004
the input string with the string "sos.arpa" appended.
This domain-name is used to request NAPTR records which may contain
the end result or, if the flags field is blank, produces new keys in
the form of domain-names from the DNS.
The character set used to encode the substitution expression is
UTF-8. The allowed input characters are and the characters allowed to
be in a Key are those that are currently defined for DNS
domain-names.
5.4.1 Flags
This Database contains a field that contains flags that signal when
the DDDS algorithm has finished. At this time only one flag, "U", is
defined. This means that this Rule is the last one and that the
output of the Rule is a URI. See [RFC3403].
If a client encounters a record with an unknown flag, it MUST ignore
it and move to the next Rule. This test takes precedence over any
ordering since flags can control the interpretation placed on fields.
A novel flag might change the interpretation of the regexp and/or
replacement fields such that it is impossible to determine if a
record matched a given target.
If this flag is not present then this rule is non-terminal. If a Rule
is non-terminal then clients MUST use the Key produced by this
Rewrite Rule as the new Key in the DDDS loop (i.e. causing the client
to query for new NAPTR records at the domain-name that is the result
of this Rule).
5.4.2 Services Parameters
Service Parameters for this Application take the following form and
are found in the Service field of the NAPTR record.
service_field = "SOS" 1*(servicespec)
servicespec = "+" sosservice
sosservice = type 0*(subtypespec)
subtypespec = ":" subtype
type = 1*32(ALPHA / DIGIT)
subtype = 1*32(ALPHA / DIGIT)
In other words, a non-optional "SOS" (used to denote SOS only Rewrite
Rules in order to mitigate record collisions) followed by 1 or more
or more sosservices which indicate what class of functionality a
given end point offers. Each sosservice is indicated by an initial
'+' character.
Rosen Expires July 1, 2004 [Page 11]
Internet-Draft Emergency Call Info in the DNS January 2004
No use for subtypes is presently contemplated, but is left defined as
in [RFC2916] for possible future use.
5.4.2.1 SOS Services
sosservice specifications contain the functional specification (i.e.
what it can be used for), the valid protocols, and the URI schemes
that may be returned. Note that there is no implicit mapping between
the textual string "type" or "subtype" in the grammar for the
sosservice and URI schemes or protocols. The mapping, if any, must be
made explicit in the specification for the sosservice itself. A
registration of a specific Type also has to specify the Subtypes
allowed.
The registration mechanism is specified in Section 6.
5.5 What constitutes an 'Sos Resolver'?
The sos algorithm always returns a single rule. Specific applications
may have application-specific knowledge or facilities that allow them
to present multiple results or speed selection, but these should
never change the operation of the algorithm.
6. Registration mechanism for sosservices
As specified in the ABNF found in Section 5.4.2, an 'sosservice' is
made up of 'types' and 'subtypes'. For any given 'type', the
allowable 'subtypes' must be specified in the registration. There is
currently no concept of a registered 'subtype' outside the scope of a
given 'type'. Thus the registration process uses the 'type' as the
main key within the IANA Registry. While the combination of each
type and all of its subtypes constitutes the allowed values for the
'enumservice' field, it is not sufficient to simply document those
values. A complete registration will also include the allowed URI
schemes, a functional specification, security considerations,
intended usage, and any other information needed to allow for
interoperability within the application. In order to be a registered
sos service, the entire specification, including the template,
requires publication of the sosservice registration specification as
an RFC.
6.1 Registration Requirements
Service registration proposals are all expected to conform to various
requirements laid out in the following sections.
Rosen Expires July 1, 2004 [Page 12]
Internet-Draft Emergency Call Info in the DNS January 2004
6.1.1 Functionality Requirement
A registered sosservice must be able to function as a selection
mechanism when choosing one NAPTR resource record from another. That
means that the registration MUST specify what is expected when using
that very NAPTR record, and the URI that is the outcome of the use of
it.
6.1.2 Naming requirement
An sosservice MUST be unique in order to be useful as a selection
criteria. Since an sosservice is made up of a type and a
type-dependent subtype, it is sufficient to require that the 'type'
itself be unique. The 'type' MUST be unique, conform to the ABNF
specified in Section 5.4.2.
The subtype, being dependent on the type, MUST be unique within a
given 'type'. It must conform to the ABNF specified in Section 5.4.2.
The subtype for one type MAY be the same as a subtype for a different
registered type but it is not sufficient to simply reference another
type's subtype. The function of each subtype must be specified in the
context of the type being registered.
6.1.3 Security requirement
An analysis of security issues is required for all registered
sosservices. (This is in accordance with the basic requirements for
all IETF protocols.) In most cases, it is expected that the security
considerations will be the same as those services defined in this
memo, but new services could have different security considerations.
All descriptions of security issues must be as accurate as possibly
regardless of registration tree. In particular, a statement that
there are "no security issues associated with this sosservice" must
not be confused with "the security issues associated with this
sosservice have not been assessed".
There is no requirement that an sosservice must be secure or
completely free from risks. Nevertheless, all known security risks
must be identified in the registration of an sosservice.
The security considerations section of all registrations is subject
to continuing evaluation and modification.
6.1.4 Publication Requirements
Proposals for sosservice registrations MUST be published as an RFC,
or as a BCP.
Rosen Expires July 1, 2004 [Page 13]
Internet-Draft Emergency Call Info in the DNS January 2004
6.2 Registration procedure
6.2.1 IANA Registration
IANA will register the sosservice and make the sosservice
registration available to the community in addition to the RFC/BCP
publication.
6.2.1.1 Location of sosservice Registrations
sosservice registrations will be published in the IANA repository and
made available via anonymous FTP at the following URI: "ftp://
ftp.iana.org/assignments/sos-services/".
6.2.1.2 Change Control
Change control of sosservice stay with the IETF via the RFC
publication process. sosservice registrations may not be deleted;
sosservice which are no longer believed appropriate for use can be
declared OBSOLETE by publication of a new RFC and a change to their
"intended use" field; such sosservices will be clearly marked
OBSOLETE in the lists published by IANA.
Registration Template
sosservice Type:
sosservice Subtype(s):
URI Scheme(s):
Functional Specification:
Security considerations:
Intended usage: (One of COMMON, LIMITED USE or OBSOLETE)
Author:
Any other information that the author deems interesting:
Note: In the case where a particular field has no value, that field
is left completely blank, especially in the case where a given type
has no subtypes.
6.2.2 Initial Registrations
The following services are defined in this memo
Type sos+erc
Subtypes: none
URI Schemes: sip: [RFC3261] and tel: [RFC2806]
Functional Specification: Provides a contact uri for the public
service access point that serves the civil address corresponding
to this DDDS entry.
Rosen Expires July 1, 2004 [Page 14]
Internet-Draft Emergency Call Info in the DNS January 2004
Security considerations: see Section 9
Intended usage: COMMON
Author: Brian Rosen
Other Information: None
Type_sos+fire
Subtypes: none
URI Schemes: sip: [RFC3261] and tel: [RFC2806]
Functional Specification: Provides a contact uri for the fire
department/brigade that serves the civil address corresponding to
this DDDS entry.
Security considerations: see Section 9
Intended usage: COMMON
Author: Brian Rosen
Other Information: In many jurisdictions, emergency calls should
be routed to an ERC rather than a specific service such as a
direct call to the fire department/brigade.
Type_sos+rescue
Subtypes: none
URI Schemes: sip: [RFC3261] and tel: [RFC2806]
Functional Specification: Provides a contact uri for the rescue/
ambulance service that serves the civil address corresponding to
this DDDS entry. Security considerations: see Section 9
Intended usage: COMMON
Author: Brian Rosen
Other Information: In many jurisdictions, emergency calls should
be routed to an ERC rather than a specific service such as a
direct call to the rescue/ambulance service.
Type_sos+marine
Subtypes: none
URI Schemes: sip: [RFC3261] and tel: [RFC2806]
Functional Specification: Provides a contact uri for the maritime
rescue service that serves the civil address corresponding to this
DDDS entry.
Security considerations: see Section 9
Intended usage: COMMON
Author: Brian Rosen
Other Information: The concept of a "civil address" for a marine
emergency is somewhat strange. Entries should be made in the DDDS
for territory within a jurisdiction that is served by a maritime
emergency response service. For example, one could have an entry
such as 5.atlantic.us for the Coast Guard District 5 in the
Atlantic region of the United States.
Type_sos+police
Rosen Expires July 1, 2004 [Page 15]
Internet-Draft Emergency Call Info in the DNS January 2004
Subtypes: none
URI Schemes: sip: [RFC3261] and tel: [RFC2806]
Functional Specification: Provides a contact uri for the police
department that serves the civil address corresponding to this
DDDS entry.
Security considerations: see Section 9
Intended usage: COMMON
Author: Brian Rosen
Other Information: In many jurisdictions, emergency calls should
be routed to an ERC rather than a specific service such as a
direct call to the police.
Type_sos+mountain
Subtypes: none
URI Schemes: sip: [RFC3261] and tel: [RFC2806]
Functional Specification: Provides a contact uri for the public
service access point that serves the civil address corresponding
to this DDDS entry.
Security considerations: see Section 9
Intended usage: COMMON
Author: Brian Rosen
Other Information: None
7. Obscuring Lower Level Information
Most of the information in the sos.arpa domain is public, but
information interior to a building may not be. In these cases, the
domain names may be obscured by substituting a string (perhaps a
random or sequentially assigned number) for the parts of the domain
name to be obscured, and placing the actual name in the entry using
CNAME. The contents of the entry would be encrypted by:
Placing the certificate of the entity obscuring the data in a CERT
RR
Encrypting the data to be obscured (CNAME and POLY) using RSA-1024
with the Private Key of the entity obscuring the data, and the
Public key of the ERC serving the area obscured.
Placing the resulting data in a ENCRYPT RR
8. Notes and things to do
It's clearly possible to make this database be entirely independent
of the DNS. We would use the same namespace (sos.arpa) subtree to
avoid conflicts, but have entirely separate root servers, etc. One
reason not to do this is that the civil to geo and geo to civil data
is useful for other applications, but this proposal is really limited
to supporting emergency calls. The author would strongly prefer not
to have to develop a new root server infrastructure, modified code
for accessing, etc.
Rosen Expires July 1, 2004 [Page 16]
Internet-Draft Emergency Call Info in the DNS January 2004
I've waffled back and forth on whether the contact URI should be a
NAPTR, thus making this a DDDS application like ENUM, or making it an
SRV. The problem with an SRV is that you can't easily encode a SIP
URI. There is some precedence for using the first component of the
name as the access protocol. We would have to use the second one for
the userpart, so sip:alice@example.com becomes sip.alice.example.com
in the SRV. The wording would be considerably simpler if we did.
The case for DDDS is that it just works, like ENUM just works, as
long as the REGEXP is straight replacement. You don't really "call"
the civil location, but you do call the ERC corresponding to the
civil location, so it works
At times, I have advocated actually having the reverse tree (geo to
civil). I note that you can mechanically create geo to civil from
the civil to geo this proposes. There is no really good way that has
occurred to me to construct the name hierarchy. The SRI geo proposal
isn't appropriate.
I haven't put in the section that defines how you know the entry is
an ERC (or fire or police). I have to pick or define an appropriate
RR.
The ENCRYPT thing needs work. I could put the CNAME inside the
ENCRYPT. Need to define what the exact format of ENCRYPT is. At
times, I have considered Extending DNSSEC to include privacy, but I
don't want to encrypt the whole thing, just the POLY and CNAME.
Need text on size of entries. These are going to be big.
Need text on i18n names.
9. Security Considerations
Up to street address level, the information in the proposed DNS tree
is public. Where the data is not public, the entry SHOULD be
encrypted.
If the data in the DNS is forged, or a man in the middle attack is
mounted, emergency calls could be directed to the wrong place,
causing harm to a caller. DNSSEC [RFC2535] SHOULD be used for
clients accessing the data. It is more important, however, that the
data be used, than it be assured that it is genuine, and in general,
the emergency response community would prefer that failure be that
the data is provided, but denoted as possibly inaccurate. Thus if
DNSSEC mechanisms fail, the request should be allowed to proceed,
with a failure indicator returned.
References
Rosen Expires July 1, 2004 [Page 17]
Internet-Draft Emergency Call Info in the DNS January 2004
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999.
[RFC2806] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806,
April 2000.
[RFC2916] Faltstrom, P., "E.164 number and DNS", RFC 2916, September
2000.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M. and E. Schooler,
"SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3402] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Two: The Algorithm", RFC 3402, October 2002.
[RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Three: The Domain Name System (DNS) Database", RFC
3403, October 2002.
Author's Address
Brian Rosen
Marconi
2000 Marconi Drive
Warrendale, PA 15086
US
Phone: +1 724 742 6826
EMail: brian.rosen@marconi.com
Rosen Expires July 1, 2004 [Page 18]
Internet-Draft Emergency Call Info in the DNS January 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Rosen Expires July 1, 2004 [Page 19]
Internet-Draft Emergency Call Info in the DNS January 2004
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Rosen Expires July 1, 2004 [Page 20]
| PAFTECH AB 2003-2026 | 2026-04-20 15:23:03 |