INTERNET-DRAFT S. Sakane
Intended Status: Informational Cisco Systems
Expires: November 24, 2011 M. Ishiyama
Toshiba Corp.
May 23, 2011
Kerberos Options for DHCPv6
draft-sakane-dhc-dhcpv6-kdc-option-11.txt
Abstract
This document defines new four options of Dynamic Host Configuration
Protocol for IPv6 (DHCPv6) to carry a set of configuration
information related to the Kerberos protocol [RFC4120].
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft expires in November 24, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Sakane & Ishiyama [Page 1]
Internet-Draft May 2011
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Sakane & Ishiyama [Page 2]
Internet-Draft May 2011
Table of Contents
1. Introduction ................................................. 4
2. Conventions used in this document ............................ 5
3. Kerberos Options ............................................. 5
3.1. Kerberos Principal Name Option .......................... 5
3.2. Kerberos Realm Name Option .............................. 6
3.3. Kerberos Default Realm Name Option ...................... 7
3.4. Kerberos KDC Option ..................................... 7
4. Client Operation ............................................. 8
4.1. A recommendation of KDC discovery for a client .......... 9
5. Server Operation ............................................. 11
6. Appearance of this option .................................... 11
7. IANA Considerations .......................................... 11
8. Security Considerations ...................................... 12
9. Acknowledgments .............................................. 12
10. References ................................................... 13
10.1. Normative References ................................... 13
10.2. Informative References ................................. 14
Appendix A. Why DNS is not acceptable in some environment ........ 14
Authors' Addresses ............................................... 18
Sakane & Ishiyama [Page 3]
Internet-Draft May 2011
1. Introduction
The Kerberos Version 5 [RFC4120] is an authentication system which is
based on the trusted third-party authentication protocol. Each
organization wishing to use the Kerberos protocol establishes its own
"realm", and each client is assigned to the realm. At least one Key
Distribution Center (KDC) is required for the Kerberos operation of
the realm.
When a client wants to start communication with a server (that means
another client of the KDC), and to be authenticated to the server,
the client needs to take a credential from the KDC. In this process,
the client presents both an identifier itself, and a realm name to
which the client itself belongs. After the client gets a credential
from the KDC, the client presents it to the peer. The peer can
authenticate the access from the client with the credential. Hence,
the client needs to know at least one IP address of KDC from which
the client can get a credential before the client begins the
communication with the peer.
Here is a use case that a client has to know a realm name. A public
workstation for an unspecified several number of students in a
college does not have any initial configuration for Kerberos. If
there is a mechanism providing a realm name and a set of IP addresses
of the KDC, a student only puts a user identifier and a pass phrase
into the workstation, and can user the Kerberos authentication
system.
To provide a set of IP addresses of the KDC, the Kerberos V5
specification [RFC4120] defines a KDC discovery by utilizing DNS SRV
records [RFC2782]. In the meantime, the system which does not employ
DNS, but does use DHCP, exists like the industrial system. Some
industrial systems don't use DNS because they have already had their
own name spaces and their own name resolution systems, including the
pre-configured mapping table into the device, rather than FQDN and
DNS. And these systems dare not to employ DNS for only the name
resolution because adding a new server brings to decrease the
reliability of the system, and to increase the management cost of the
system. (The detail is described in the APPENDIX), For such
environment, another mechanism is required to provide a set of IP
addresses of the KDC. Providing a set of IPv4 addresses of the KDC
to the devices deployed into the PacketCable Architecture [PCARCH],
the KDC Server Address sub-option for the DHCPv4 CableLabs Client
Configuration option is defined in RFC 3634 [RFC3634]. However, a
mechanism which does not depend on any architecture is required for
providing a realm name and a set of IPv6 addresses.
The Kerberos option for DHCPv6 defined by this document allows to
Sakane & Ishiyama [Page 4]
Internet-Draft May 2011
provide a realm name and/or a list of IP addresses of the KDC. The
Kerberos option does not replace and deny of the previous methods,
and this option does not interfere with those methods.
2. Conventions used in this document
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 RFC 2119 [RFC2119].
It is assumed that the readers are familiar with the terms and
concepts described in the DHCPv6 [RFC3315].
Since a server would mean a DHCP server or a server in the Kerberos
service, when there is no declaration in particular, the server means
a server against a client of the Kerberos service in this document.
3. Kerberos Options
The Kerberos options provide a set of configuration parameters which
a clients and a servers of Kerberos will use. This document defines
the options listed below.
Kerberos Principal Name Option
Kerberos Realm Name Option
Kerberos Default Realm Name Option
Kerberos KDC Option
This section describes the format of each option, and the usage of
each field.
These options can appear multiple times in a DHCPv6 message.
3.1. Kerberos Principal Name Option
This option provides a principal name of the Kerberos system. It is
intended that a DHCPv6 server determines a specific set of the
configuration parameters of the Kerberos system for either a client
or a server specified by the principal-name field.
The format of the Kerberos Principal Name option is:
Sakane & Ishiyama [Page 5]
Internet-Draft May 2011
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_KRB_PRINCIPAL_NAME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: principal-name :
: (variable length) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o option-code (16-bit): OPTION_KRB_PRINCIPAL_NAME (TBD by IANA)
o option-len (16-bit): length of the principal-name field.
o principal-name (variable): a client principal name. The encoding
of the principal-name field MUST be conformed to "PrincipalName"
defined in section 5.2.2 of RFC 4120 [RFC4120].
3.2. Kerberos Realm Name Option
This option provides a realm name of the Kerberos system. It is
intended for a DHCPv6 client use, which indicates what kind of KDC
address that the client needs. A DHCPv6 server determines a set of
the configuration parameters of a KDC in a Kerberos realm specified
by the realm-name field in this option.
The format of the Kerberos Realm Name option is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_KRB_REALM_NAME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: realm-name :
: (variable length) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o option-code (16-bit): OPTION_KRB_REALM_NAME (TBD by IANA)
o option-len (16-bit): the length of the realm-name field in octets.
Sakane & Ishiyama [Page 6]
Internet-Draft May 2011
o realm-name (variable): a realm-name. The encoding of the realm-
name field MUST be conformed to "Realm" which is defined in
section 5.2.2 of RFC 4120 [RFC4120].
3.3. Kerberos Default Realm Name Option
This option provides a default realm name of the Kerberos system.
Contrary to the Kerberos Realm Name Option, it is intended for a
DHCPv6 server use, which notifies the default realm name to both
clients and servers in the Kerberos system.
The option-code of this option is OPTION_KRB_DEFAULT_REALM_NAME. The
format and the usage of each field are similar to the Kerberos Realm
Name Option.
3.4. Kerberos KDC Option
This option provides a set of configuration parameters of a KDC. It
is intended that a DHCPv6 server provides a set of the configuration
parameters of a KDC in a Kerberos realm.
The format of the Kerberos KDC Option is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_KRB_KDC | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority | Weight |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Type| Reserved | Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| KDC IPv6 address |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: realm-name :
: (variable length) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o option-code (16-bit): OPTION_KRB_KDC (TBD by IANA)
Sakane & Ishiyama [Page 7]
Internet-Draft May 2011
o option-len (16-bit): 24-octet + the length of the realm-name field
in octets.
o Priority (16-bit): see the description of Weight field.
o Weight (16-bit): both Priority and Weight are for a server
selection mechanism. These parameters indicate a hint for a kind
of server selection mechanism of a client. An implementer MUST
follow the DNS SRV specification [RFC2782] for this usage.
o Transport Type (8-bit): The Transport Type specifies the transport
of the Kerberos communication. The Kerberos specification
[RFC4120] defines to use both UDP and TCP for communication
between clients and servers. The exchanges over TCP is described
in [RFC5021]. The exchanges over TLS is described in [RFC6251].
The transport type is defined in below.
Value Transport Type
---- --------------
0 Reserved
1 UDP
2 TCP
3 TLS
4-254 Unassigned
255 Reserved
o Reserved (8-bit): initialized to zero for transmission, and
ignored on reception.
o Port Number (16-bit): a port number listened to by the KDC.
o KDC address (128-bit): an IPv6 address of the KDC.
4. Client Operation
This section describes the client behavior when the client requires a
set of the configuration parameters of the Kerberos system, and when
the client receives messages from the DHCPv6 server. The processing
of both the Information-request message and the Option Request Option
MUST be conformed to [RFC3315]. An implementor MUST refer to the
Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6
[RFC3736].
When the client requires a set of the configuration parameters of a
Kerberos system in the phase of its bootstrapping, the client SHOULD
Sakane & Ishiyama [Page 8]
Internet-Draft May 2011
put the client principal name itself into the Kerberos Principal Name
Option. The client expects to receive the Default Realm Name Option
and/or the KDC option of the client and/or the additional one or more
KDC options required by the client's operation.
When the client requires a specific information of a certain realm,
the client MUST specify the realm name into the Kerberos Realm Name
Option. When the client requires a specific information related to a
certain server of the Kerberos system, the client MUST put the
principal name of the server into the Kerberos Principal Name Option.
More than one KDC Options MAY be presented in a DHCPv6 message of the
Reply Message from the server. In this case, the client MUST contact
to the addresses in the order of the value of the priority field in
each Kerberos KDC Option. The value of the weight field might be
considered simultaneously. For this usage, an implementer could
refer to the DNS SRV specification [RFC2782].
The client MAY include any other options with data values as hints to
the server as it is described in section 18.1.5 of RFC 3315
[RFC3315].
4.1. A recommendation of KDC discovery for a client
When a client has a capability of both the DNS method defined by
section 7.2.3.2 of [RFC4120] and the DHCP method defined by this
document, which methods the client adopts depends on the policy of
the environment. The administrator of the realm MUST define the
method to the client before the client is installed into the
environment.
When there is no criteria in the environment, and the client could
get the Kerberos information from both the DNS server and the DHCP
server, then the information from DNS is recommended. The following
is a recommendation of the behavior of the client in such environment
where there is no criteria.
Sakane & Ishiyama [Page 9]
Internet-Draft May 2011
No Ans. or
+------------+ DNS Info. +-----------+ No Ans.
Start --> | Ask DHCP(1)| ----------> | Ask DNS(3)| ------> Abort(4)
+------------+ +-----------+
/ \ \
Only KRB / \ DNS and \ KRB Info.
Info. / \ KRB Info. \
/ \ \
| | |
| V |
V No Ans. +-----------+ KRB Info. V
Adopt Info. <-------- | Ask DNS(6)| ---------> Adopt Info.
from DHCP +-----------+ from DNS
(2), (7) (5), (8)
Abbreviations:
Ans.: Answer
Info.: Information
KRB: Kerberos
1) At the first, the client asks both DNS and KRB information to the
DHCP server.
2) If the client gets only a response with KRB information from the
DHCP server, the client adopts the information from the DHCP
server.
3) As the result of (1), if the client gets either no answer or only
a response with DNS information from the DHCP server, the client
then asks KRB information to the DNS server.
4) If the client gets no answer from the DNS server, then the client
will abort.
5) If the client gets KRB information from the DNS server, then the
client adopts the information from the DNS server.
6) As the result of (1), if the client gets both DNS and KRB
information from the DHCP server, then the client asks KRB
information to the DNS server.
7) If the client gets no answer from the DNS server, the client
adopts the KRB information from the DHCP server.
8) As the result of (6), if the client gets KRB information from the
DNS server, the client adopts the information instead of another
from the DHCP server.
Sakane & Ishiyama [Page 10]
Internet-Draft May 2011
5. Server Operation
After the DHCPv6 server receives a message which is contained an
Option Request Option, what information the server will provide
depends on the policy of the server in the end. If there is no
criteria on the server, the following operation is recommended.
The server SHOULD send a Reply Message back to the client when the
option number of the Kerberos option is specified in the Option
Request option by the client.
When the message from a client did not include any information which
can be used to determine the configuration parameter for a specific
client, the server SHOULD reply at least the Default Realm Name
Option.
6. Appearance of this option
The Kerberos option MUST NOT appear in any other than the following
messages: Solicit, Advertise, Request, Renew, Rebind, Information-
request and Reply. The option MAY also appear in the DHCP-relay-
message field of both Relay-forward or Relay-reply message. If this
option appears in messages other than those specified above, the
receiver MUST ignore it.
The number of the Kerberos option MAY appear in the Option Request
Option in the DHCPv6 message types Solicit, Request, Renew, Rebind,
Information-request and Reconfigure. The number MAY also appear in
the DHCP-relay-message field of both Relay-forward or Relay-reply
message.
The sub-option of the Kerberos option MUST appear only in the
Kerberos option.
7. IANA Considerations
When this document is published, the IANA is requested to assign four
option codes from the "DHCPv6 Options Codes" registry for the
following.
OPTION_KRB_PRINCIPAL_NAME
OPTION_KRB_REALM_NAME
OPTION_KRB_DEFAULT_REALM_NAME
OPTION_KRB_KDC
IANA is required to maintain a new number space of Kerberos Message
Sakane & Ishiyama [Page 11]
Internet-Draft May 2011
Transport Type, located in the Kerberos Parameters Registry. The
initial types are described in section 3.4.
IANA assigns future type with a "IETF Consensus" policy as described
in BCP 26. Future proposed type is to be referenced symbolically in
the Internet-Drafts that describe it, and shall be assigned numeric
code by IANA when approved for publication as an RFC.
8. Security Considerations
The security considerations in RFC 3315 fully apply.
The message of DHCPv6 could be altered undesirably. If an adversary
modifies the response from a DHCPv6 server or inserts its own
response, a client could be led to contact a rogue KDC or a server
which does not know the client access. Both cases are categorized
into a kind of the denial of service attack. However, such incorrect
KDC does not know the shared key between the client and a valid KDC.
The incorrect KDC is not be able to proceed any further state of the
client. Even when the client receives a response from such KDC, the
client can know the fact that it has received an inappropriate
message after it verifies the response with the shared key.
The considerable situation is that the support of an unconfigured
workstation used by multiple users, which obtains its KDC information
and default realm via DHCP. In such a scenario, the workstation may
not have a host or other service key, and thus be unable to validate
TGT's issued to users for the purposes of authorizing login. If this
is the case, an altered DHCP response could result in the workstation
talking to a rogue KDC which it will be unable to distinguish from a
real KDC, and allowing access by unauthorized users.
In order to minimize potential vulnerabilities, a client SHOULD
require to use the DHCPv6 authentication defined in section 21 of RFC
3315, or any other authentication mechanism.
Sometimes, the Kerberos information is manually configured into the
client before the DHCPv6 process starts. Generally, the manual
configuration to the device should be preferred to the configuration
by the DHCP server. Overriding the manual configuration should be
considered in anytime.
9. Acknowledgments
The authors are very grateful to Nobuo Okabe and Shigeya Suzuki.
They contributed the summary explaining why DNS is not appropriate to
Sakane & Ishiyama [Page 12]
Internet-Draft May 2011
some industry networks, which is put as the appendix of this
document. Ted Lemon gave us many suggestions to improve the
specification in terms of the DHCP manner. Ken'ichi Kamada and
Yukiyo Akisada contributed for the initial work of making this
document. The authors also thank Jeffrey Hutzelman, Kazunori
Miyazawa, Kensuke Hosoya, Nicolas Williams, Nobumichi Ozoe, and Sam
Hartman. They gave us valuable comments and suggestions for this
document.
10. References
10.1. Normative References
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[RFC2782]
A. Gulbrandsen, P. Vixie, L. Esibov, "A DNS RR for specifying the
location of services (DNS SRV)", RFC 2782, February 2000.
[RFC3315]
R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins, M. Carney.
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315,
July 2003.
[RFC3736]
R. Droms, "Stateless Dynamic Host Configuration Protocol (DHCP)
Service for IPv6", RFC 3736, April 2004.
[RFC4120]
Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos
Network Authentication Service (V5)", RFC 4120, July 2005.
[RFC5021]
Josefsson, S., "Extended Kerberos Version 5 Key Distribution
Center (KDC) Exchanges over TCP", RFC 5021, August 2007.
[RFC6251]
Josefsson, S., "Using Kerberos Version 5 over the Transport Layer
Security (TLS) Protocol", RFC 6251, May 2011.
Sakane & Ishiyama [Page 13]
Internet-Draft May 2011
10.2. Informative References
[PCARCH]
"PacketCable 1.0 Architecture Framework Technical Report", PKT-TR-
ARCH-V01-991201, http://www.packetcable.com/downloads/specs/pkt-
tr-arch-v01-991201.pdf
[RFC3634]
K. Luehrs, R. Woundy, J. Bevilacqua, N. Davoust, "Key Distribution
Center (KDC) Server Address Sub-option for the Dynamic Host
Configuration Protocol (DHCP) CableLabs Client Configuration (CCC)
Option", RFC 3634, December 2003.
Appendix A. Why DNS is not acceptable in some environment
Sakane & Ishiyama [Page 14]
Internet-Draft May 2011
1. Summary
- This appendix describes reasons why DHCP-based KDC discovery
is more suitable than DNS-based KDC discovery described
in RFC4120 (= the RFC4120-way) for the industrial systems.
- The main reason is that some industrial systems don't use DNS
because they have already had their own name spaces and
naming systems rather than FQDN and DNS.
- Less servers benefits the industrial systems:
1) Less messages simplifying the systems.
2) Less servers contributing reliability,
and reducing management cost.
- We understand that RFC4120 does not require DHCP for KDC
discovery. However, we will have to solve DNS discovery
when considering the RFC4120-way.
And it is natural way to use DHCP for the purpose.
- DHCP-based KDC discovery is more efficient under those
systems (=expecting not to use DNS).
2. Background (what's industrial systems?)
Industrial systems are a kind of sensor systems.
The systems have a large number of devices, i.e. sensors and
actuators, usually called field devices
by which the systems control plants, factories, buildings, etc.
The field devices have the following features:
1) Their resources, e.g. processing capability, memory size,
footprint, power consumption and user i/f, are limited
even though they are physically large.
2) The field device is controlled as an I/O by a administrative
device, usually called controller, with a legacy communication
technology.
3) Security of the field devices have not been cared
because they are regarded as being on I/O buses, not networks.
3. High-level goal and some requirements
3.1. IP and security can enhance the industrial systems.
Our goal is to introduce latest IP-based network technology
into field devices for enhancing the entire system.
1) Network architecture (=IP technology) can enhance
the systems including the field devices.
Sakane & Ishiyama [Page 15]
Internet-Draft May 2011
2) The field devices will require security if network architecture
is introduced. The field devices will not be I/O devices
anymore.
3.2. Auto-configuration benefits the industrial systems.
Auto-configuration will also be important for large systems
like the industrial systems if introducing new technology or
capability:
1) Reducing engineering cost when installing/configuring
large number of field devices over spread area.
The following are existing large systems.
The size of a plant, the size of an industrial system and
the number of field devices are growing.
- An example of a single large process automation system:
About 20000 field devices over 2km*2km area
References:
- http://www.process-worldwide.com/fachartikel/pw_facha
rtikel_2699276.html
- An example of a distributed process automation systems:
About 30000 field devices for 26 distributed sites
over 30km*30km area.
References:
- http://www.mikrocentrum.nl/FilesPage/3462/Presentatie
%20C3-1.pdf
- http://www.nam.nl/home/Framework?siteId=nam-en&FC2=/n
am-en/html/iwgen/algemeen/zzz_lhn.html&FC3=/nam-en/ht
ml/iwgen/algemeen/over_de_nam.html
- An example of a single large building automation system:
170000 control points of 16500 field devices in
729,000 sq. meters (7.8 million sq. ft.) building complex.
References:
- http://www.echelon.com/company/press/2003/echelon_mor
i.htm
2) Reducing the chance of human error.
3) Making disaster-recovery easier.
3.3. Security mechanism suited to resource-limited devices are
necessary.
Sakane & Ishiyama [Page 16]
Internet-Draft May 2011
Kerberos-based security can be suited resource-limited devices,
i.e. the field devices, because of not requiring
public key cryptography (of course, when not using PKINIT).
4. Some industrial systems don't use DNS.
For field devices, there have been multiple technologies (see
Section 6) which don't use DNS because of having already had
their own name spaces and naming systems even though introducing
IP (partially at this moment).
For example, "tag" is the common logical identifier for the
process
automation systems and Device ID is the common logical identifier
for the building automation systems.
(You may think those names are not so abstracted, though....)
5. KDC discovery with DHCP is more suitable than the one with DNS.
If Kerberos is introduced into the field devices,
auto-configuration will be achieved with the following steps:
1) Learning DNS address(es) by DHCP
2) Learning KDC address(es) by DNS based on RFC4120-way.
However, DNS will be used by kerberos-related part only.
Most application will not use DNS as described above.
If DHCP can advertise KDC-related information instead of DNS,
there are the following advantages.
1) It can reduce messages handled by the field devices.
Consequently, it can reduce footprint of the field devices.
2) It can reduce the number of servers.
Consequently, it contribute to management cost of the systems.
6. References
There have been multiple technologies for field devices.
Examples:
- FOUNDATION Fieldbus (http://www.fieldbus.org/)
- PROFIBUS (http://www.profibus.com/)
- BACnet (http://www.bacnet.org/)
- LonWorks (http://www.echelon.co.jp/products/lonworks.html)
- Modbus (http://www.modbus.org/)
You can learn about communication technology of field devices
with wikipedia:
- http://en.wikipedia.org/wiki/Fieldbus
- http://en.wikipedia.org/wiki/BACnet
- http://en.wikipedia.org/wiki/LonWorks
Sakane & Ishiyama [Page 17]
Internet-Draft May 2011
Authors' Addresses
Shoichi Sakane
Cisco Systems
2-1-1 Nishi-Shinjuku, Shinjuku-ku,
Tokyo 163-0409 Japan
E-mail: ssakane@cisco.com
Masahiro Ishiyama
Toshiba Corporation
1, komukai-toshiba-cho, Saiwai-ku,
Kawasaki 212-8582 Japan
E-mail: masahiro@isl.rdc.toshiba.co.jp
Sakane & Ishiyama [Page 18]