Internet DRAFT - draft-iwao-roll-dadr
draft-iwao-roll-dadr
Networking Working Group T. Iwao, Ed.
Internet Draft FUJITSU LIMITED
Intended status: <e.g., Informational> July 2, 2009
Expires: January 2010
Distributed Autonomous Depth-first Routing Protocol in LLN
draft-iwao-roll-dadr-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, except to publish it
as an RFC and to translate it into languages other than English.
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.
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 January 2, 2009.
Iwao, et al. Expires January 2, 2010 [Page 1]
Internet-Draft DADR Protocol July 2009
Copyright Notice
Copyright (c) 2009 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
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This document is a proposal of the distributed autonomous depth-first
routing (DADR) protocol which is quite different from conventional
algorithms such as AODV and OLSR. It proposes a traversable algorithm
which can determine a direct path between the global source and the
global destination in a low power and lossy network (LLN). We propose
the DADR algorithm whose characteristics work well in LLNs with more
than 10^4 nodes. This algorithm selects a direct path between the
global source and the global destination based on a routing-cost-
function which identifies path-candidates with good communication
quality between each pair of nodes on the path. This protocol does
not need to configure the equipment such as setting IP addresses, and
thisresults in saving cost and time in deploying, establishing and
operating a large scale network.
Iwao, et al. Expires January 2, 2010 [Page 2]
Internet-Draft DADR Protocol July 2009
Table of Contents
1. Introduction...................................................4
2. Terminology....................................................6
3. Overview.......................................................6
4. Operating Principle............................................7
5. Node Operation.................................................7
5.1. Time Synchronization Message..............................8
5.2. Hello Message............................................10
5.3. Data and Data ACK Message................................11
6. Message Formats...............................................12
6.1. Ad Hoc Header Format.....................................12
6.2. Time Synchronization Message Format......................13
6.3. Hello Message Format.....................................14
6.4. Hello Message Header Format..............................15
6.5. Hello Header Format......................................15
6.6. Data Frame Format........................................16
6.7. Data Header Format.......................................17
6.8. Data ACK Format..........................................17
6.9. Data ACK Header Format...................................17
7. Table Formats.................................................19
7.1. Routing Table format.....................................19
7.2. Data Management Table format.............................20
7.3. Link Table format........................................20
8. Security Considerations.......................................21
9. IANA Considerations...........................................21
10. Conclusions..................................................21
11. References...................................................21
11.1. Normative References....................................21
11.2. Informative References..................................22
12. Acknowledgments..............................................22
Appendix A. First Appendix.......................................23
A.1. First Header level.......................................23
Iwao, et al. Expires January 2, 2010 [Page 3]
Internet-Draft DADR Protocol July 2009
1. Introduction
A low power and lossy network (LLN) has a characteristic in which
links between nodes are unstable due to interference, limited power
and frequent equipment failures. Because of this characteristic, it
is difficult to keep established paths between nodes in an LLN. In
addition, the number of nodes in an LLN is very large. RFC5548([ROLL-
Req-RFC]) mandates that the LLN must handle on the order of 10^4
nodes. Hence, a protocol which creates an LLN needs to overcome both
unstable links among nodes and the huge number of nodes in a power
efficient manner.
Conventional protocols such as Ad hoc On-Demand Distance Vector
(AODV) and Optimized Link State Routing Protocol (OLSR) are based on
breadth first search and are not efficient enough to support LLNs.
These protocols need to use a flooding mechanism to send messages to
a large area of the network for searching for a path. This presents a
scalability issue when dealing with a large number of nodes.
Additionally, once a path is found, it is continuously used to
maintain the paths. However, the probability that the found path will
persist for a long period of time is low because of the lossy
characteristics of LLN. If nodes lose the path, then they flood the
"lossy" network with additional path request messages. These messages
influence other nodes, and then more and more flooding messages are
generated by other nodes. This potentially overloads the network and
causes the network to crash due to the huge amount of path request
messages. Therefore, the Breadth first search mechanism is unfit for
LLNs.
To become overloaded with a specific node from the point of view of
power consumption is not a good efficiency in terms of a variation of
a life time of each node and the network. One of the methods to
achieve the "low power" network is a load distribution technique by
adding a term of the load distribution and the power consumption into
a path cost evaluation function.
A protocol that is suited for LLNs should also support redundant
paths, does not rely on flooding messages, and also flexibly handles
unstable links among nodes.
The Distributed Autonomous Depth-first Routing (DADR) enables nodes
to efficiently form an LLN. TheDADR protocol, based on depth first
search, guarantees reachability, handles failure of nodes, adapts to
environmental changes, and is suited to a large scale network. This
protocol uses a decentralized depth-first search algorithm for a
large scale network and enables nodes to adjust their routes
depending on the knowledge of the local area of each node whenever it
Iwao, et al. Expires January 2, 2010 [Page 4]
Internet-Draft DADR Protocol July 2009
forwards messages to others. This protocol does not place a heavy
burden on the network when nodes create routes, and also makes nodes
keep communication with each other under real time changes in the
environment. This protocol does not need to use flooding for a path
search and maintains redundant paths and flexibility with respect to
an environmental change (e.g., link status or topology change)..
Therefore, the DADR protocol is well suited for LLNs.
Iwao, et al. Expires January 2, 2010 [Page 5]
Internet-Draft DADR Protocol July 2009
2. Terminology
node: a core equipment which organizes Ad hoc network
neighboring node(s): a node(s) which can receive a message in one hop
Ad Hoc header: Frame information encapsulating each message
Global DST: Final End Destination node of the message
Global SRC: Original Source node of the message
Local DST: Next neighboring node of the message on the path toward a
global DST
Local SRC: Current node that is transmitting the message along the
path toward the Global DST
3. Overview
A distributed autonomous traversable routing algorithm based on a
depth first search is a learning strategy that can create routes by
transmitting data without using an explicit route request message. In
the depth first search, a node transfers incoming data from an
upstream node into a downstream node. By the use of the depth first
search, all nodes can be found as long as each node is connected on
the same network even if the network topology is complex. The depth
first search method does not require a route request message to
create a route, and this method is able to create a route through a
data transmission if a node detects a neighbor node. Therefore, it
can adapt to real time changes in an environment; it can select an
appropriate link by switching to another candidate node (Local DST)
immediately when a transmission fails due to an unstable link. One
drawback of the depth first search method is that it may take a long
time to find a Global DST depending on the network condition and
topology. In the worst case, relaying the data message to all
possible neighboring nodes is required to find the destination node.
This causes significant delays and an increase of number of packets
in the network. In order to overcome this problem, Hello messages are
used to indicate the appropriate path. It is important for each node
to select an appropriate node which has an efficient route to a
Global DST. The distributed traversable routing algorithm based on a
depth first search has a function that gives a direction to a Global
DST in advance. One of a way to select a neighbor node which has
Iwao, et al. Expires January 2, 2010 [Page 6]
Internet-Draft DADR Protocol July 2009
higher reach-ability to a Global DST makes use of a Hello message.
Each node sends a Hello message at a regular interval (for example,
on the order of once every several minutes) to its neighbors. Every
Hello message includes self information and information on other
nodes in the same network, and each path cost evaluation value. Each
node can reduce the search time by exchanging a Hello message that
has highest evaluated value going to each Global DST. Furthermore,
this Hello message is able to create an appropriate route by using a
suitable cost function for each application.
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
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 [1].
4. Operating Principle
A distributed autonomous traversable routing algorithm is composed of
three procedures: time synchronization, route discovery and data
delivery. A time synchronization message is a message to share a
specific time in network to achieve time synchronization in the
network. Hello messages are exchanged among neighbors and have three
meanings; 1) To notify the neighboring nodes in the same network of a
nodes' information, 2) To evaluate the link cost metric for the
neighbors, and 3) To exchange the current encryption key. The
notification of a nodes' information indicates what kind of node this
is and how much each node has for an evaluation value. Each node
evaluates a link cost by exchanging both radio field strength (e.g.,
RSSI) and periodical variance (of RSSI?) through the Hello message.
This link cost is one of parameters of the overall cost function.
Each node has its own encryption key and encrypts data by using this
encryption key. The Data message has two kinds of messages: with an
ACK and without an ACK. Each node must return an ACK message to the
Local SRC which sends a data message including an ACK requirement.
5. Node Operation
All messages exchanged between nodes have an Ad Hoc header(See 6.1. ).
When a node receives a message from another node, it processes the
message according to the frame type in its Ad Hoc header.
Iwao, et al. Expires January 2, 2010 [Page 7]
Internet-Draft DADR Protocol July 2009
5.1. Time Synchronization Message
First of all, a node which joins a network must synchronize a
present time which other nodes consisting of the network already
have. Because Hello Messages are encrypted by using both the time
and a cryptographic seed (see Error! Reference source not found.), a
node which doesn't have the both can not attend the network.
In Ad Hoc networks, forwarding the present time from node to node is
not a successful method to share a specific time among nodes. Figure
1 shows an example of failure to adjust the time of node i only with
a present time. In this example, node i misunderstands 11:20 is the
newest even though it is older than the time from node e.
To solve this problem, each node sends a Time Synchronization Message
consisting of a pair of times, present time and synchronized time,
periodically (e.g. once per hour). Figure 2 shows a successful
example. A node checks synchronized time before adjusting a present
time.
Time Synchronization Message processing is shown as follows.
Upon receipt of a synchronization message, a node will compare the
Synchronized time of its own clock with the synchronized time in the
message. If the synchronized time in the received message is
older(past)than the clock maintained at this node, discard the
message. If the synchronized time in the received message is newer,
adjust both the present time and the synchronized time in the node
to those in the Synchronization Message. As shown in Figure 2, node
i can adjust to the newer time successfully.
Present time: time when a node sends the message
Synchronized time: time when synchronized by a master clock
Iwao, et al. Expires January 2, 2010 [Page 8]
Internet-Draft DADR Protocol July 2009
+------+
|node a|(ntp or gateway)
+------+
10:00/ \ 11:00
+------+ +------+
|node b| |node e|
+------+ +------+
10:20 | | 11:02
+------+ +------+
|node c| |node i| -----> 11:20
+------+ +------+
10:40 | /
+------+ / 11:20
|node d|----/
+------+
Figure 1 Synchronizing time only with a present time (not successful)
+------+
|node a|(ntp or gateway)
10:00 +------+ 11:00
10:10 / \ 11:01
+------+ +------+
|node b| |node e|
10:00 +------+ +------+ 11:00
10:20 | | 11:02
+------+ +------+ 11:00
|node c| |node i| ----> 11:02
10:00 +------+ +------+
10:40 | / 10:00
+------+ / 11:20
|node d|----/
+------+ upper line: synchronization time
lower line: present time
Figure 2 Synchronizing time with synchronization time and a present
time (successful)
Iwao, et al. Expires January 2, 2010 [Page 9]
Internet-Draft DADR Protocol July 2009
5.2. Hello Message
o Each node sends a Hello Message to neighboring nodes periodically
(e.g. at an interval of one minute).
Link Table:
1. Register several parameters connected with Local SRC Address in
the Hello Messages.
2. Initialize TTL (e.g. 6 hours) for this table entry.
Routing Table:
3. Register Global DST Address as it is, if it reaches in one hop.
4. Register Global DST Address as Local DST Address if it reaches
over one hop.
5. Calculate Evaluated Value with the evaluation function.
Iwao, et al. Expires January 2, 2010 [Page 10]
Internet-Draft DADR Protocol July 2009
5.3. Data and Data ACK Message
This section describes the process of sending a Data message and
handling of Data ACK message, if applicable.
1. Look up the FID of the message in the Data Management table.
2. If the entry is not found, find out a candidate next hop which has
the best evaluated value among neighboring nodes in the Routing
table for the global destination.
3. If the entry is found, update the Routing table, because this
means retransmission has occurred.
4. Data messages may be sent with ACK response request. If ACK
response is not required go to step 6 to end.
5. Wait for ACK when sending a message which requires ACK response.
6. End of procedure
Iwao, et al. Expires January 2, 2010 [Page 11]
Internet-Draft DADR Protocol July 2009
6. Message Formats
6.1. Ad Hoc Header Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Local DST Address (6) +-------------------------------+
| | |
+-------------------------------+ Local SRC Address (6) |
| |
+---------------+-------------------------------+---------------+
| Frame Type(1) | Frame Length (2) |
+---------------+-------------------------------+
Local DST Address: MAC Address
Local DST Address: MAC Address
Frame Type:
LSB 1-4 Bit Message Identifier
number message type
------------------------------
1 Hello Message
2 Data Message
3 Data ACK Message
4 Time Synchronization Message
5 Hello Request Message
6 Hello Response Message
Bit 6 Gateway information (1: From Gateway, 0: otherwise)
Bit 7 Data ACK information (1: ACK request, 0: otherwise)
Frame Length: Payload Length after Ad Hoc Header
Iwao, et al. Expires January 2, 2010 [Page 12]
Internet-Draft DADR Protocol July 2009
6.2. Time Synchronization Message Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~
~ Ad Hoc Header(15) +---------------+
| | Hop Count (1) |
+---------------+-------------------------------+---------------+
| Frame Type (1)| Reserve (2) | |
+---------------+-------------------------------+ +
| |
+ NTP Time (8) +---------------+
| | |
+-----------------------------------------------+ +
| |
+ Sent Time (8) +---------------+
| |
+-----------------------------------------------+
NTP Time:
Sent Time:
Iwao, et al. Expires January 2, 2010 [Page 13]
Internet-Draft DADR Protocol July 2009
6.3. Hello Message Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~
~ Ad Hoc Header(15) +---------------+
| | |
+-----------------------------------------------+ +
| |
~ Hello Message Header (28) +---------------+
| | |
+-----------------------------------------------+ ~
| Hello Header 1(16) |
~ +-----------------------------------------------+
| |
+---------------+ :
: +---------------+
| |
+-----------------------------------------------+ ~
| Hello Header n(16) |
~ +-----------------------------------------------+
| | |
+---------------+ Signature (8) +
| |
+ +-----------------------------------------------+
| |
+---------------+
Signature is an 8-byte hash value of the contents of the Hello message??
Iwao, et al. Expires January 2, 2010 [Page 14]
Internet-Draft DADR Protocol July 2009
Hello Message Header Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Service Type(1)|Frame Page (1) | number of Hello Headers (2) |
+---------------+---------------+-------------------------------+
| |
~ Access Key (16) ~
| |
+---------------------------------------------------------------+
Service Type:
number meaning
-----------------------
1 Hello All
2 Hello Update
Frame Page: sequential number of Hello Message
6.4. Hello Header Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Global DST Address (6) +---------------+---------------+
| |Node/Hop Count | Reserve (1) |
+-------------------------------+---------------+---------------+
| Link Quality (4) |
+---------------------------------------------------------------+
| Return Path Quality (4) |
+---------------------------------------------------------------+
Where Node/Hop Count is ?, Link Quality is ? and Return Path Quality
is ?.
Iwao, et al. Expires January 2, 2010 [Page 15]
Internet-Draft DADR Protocol July 2009
Data Frame Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~
~ Ad Hoc Header(15) +---------------+
| | |
+---------------+-------------------------------+ ~
| Data Header (20) |
~ +-----------------------------------------------+
| | |
+---------------+ Payload ~
| |
~ ~
| |
+---------------------------------------------------------------+
| |
~ Signature (16) ~
| |
+---------------------------------------------------------------+
Iwao, et al. Expires January 2, 2010 [Page 16]
Internet-Draft DADR Protocol July 2009
6.5. Data Header Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Global DST Address (6) +-------------------------------+
| | |
+-------------------------------+ Global SRC Address (6) +
| |
+-------------------------------+---------------+---------------+
| Frame ID (2) | HTL (1) | Send Count(1) |
+---------------+---------------+---------------+---------------+
| Data Type (1) |Retry Count(1) |
+---------------+---------------+
Frame ID:
HTL: ?
Data Type:?
Retry Count:?
Signature is a 16-byte hash of the data message???
6.6. Data ACK Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~
~ Ad Hoc Header(15) +---------------+
| | |
+---------------+-------------------------------+ ~
| Data ACK Header (28) |
~ +-----------------------------------------------+
| |
+---------------+
6.7. Data ACK Header Format
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
Iwao, et al. Expires January 2, 2010 [Page 17]
Internet-Draft DADR Protocol July 2009
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame ID (2) | |
+---------------+---------------+ Global SRC Address (6) +
| |
+---------------------------------------------------------------+
where
Frame ID is a 2-byte ID of the frame that is unique.
Iwao, et al. Expires January 2, 2010 [Page 18]
Internet-Draft DADR Protocol July 2009
7. Table Formats
7.1. Routing Table format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Global DST Address (6) +-------------------------------+
| | |
+-------------------------------+ Local DST Address 1(6) +
| |
+---------------+---------------+-------------------------------+
|Link Weight(1) | Hop Count(1) | Path Quality (4) ~
+---------------+---------------+-------------------------------+
~ | Evaluated Value (4) ~
+-------------------------------+-------------------------------+
~ + RSSI (4) ~
+-------------------------------+-------------------------------+
~ | |
+-------------------------------+ Local DST Address 2(6) +
| |
+---------------+---------------+-------------------------------+
|Link Weight(1) | Hop Count(1) | Path Quality (4) ~
+---------------+---------------+-------------------------------+
~ | Evaluated Value (4) ~
+-------------------------------+-------------------------------+
~ + RSSI (4) ~
+-------------------------------+-------------------------------+
~ | |
+-------------------------------+ Local DST Address 3(6) +
| |
+---------------+---------------+-------------------------------+
|Link Weight(1) | Hop Count(1) | Path Quality (4) ~
+---------------+---------------+-------------------------------+
~ | Evaluated Value (4) ~
+-------------------------------+-------------------------------+
~ + RSSI (4) ~
+-------------------------------+-------------------------------+
~ +
+-------------------------------+
Iwao, et al. Expires January 2, 2010 [Page 19]
Internet-Draft DADR Protocol July 2009
7.2. Data Management Table format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL (1) | TTW (1) | FLAG (1) |Retry Count (1)|
+---------------+---------------+---------------+---------------+
| |
~ Data Header (28) ~
| |
+---------------------------------------------------------------+
| |
+ Local SRC Address (6) +-------------------------------+
| | |
+-------------------------------+ Local DST Address 1 (6) +
| |
+---------------------------------------------------------------+
| |
+ Local DST Address 2 (6) +------------------------------+
| | |
+--------------------------------+ Local DST Address 3 (6) +
| |
+---------------------------------------------------------------+
TTL: Time to live
TTW: Time to wait for Data ACK
Retry Count: Count of sending Data ACK request
7.3. Link Table format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Local DST Address (6) +---------------+---------------+
| | Path Quality | TTL (1) |
+---------------+---------------+---------------+---------------+
| Transmitting | Receiving |
| Quality (1) | Quality (1) |
+---------------+---------------+
Iwao, et al. Expires January 2, 2010 [Page 20]
Internet-Draft DADR Protocol July 2009
8. Security Considerations
In a DADR network, it is possible to provide security among nodes
without any central controls.
To this end, two kinds of keys, a common key and an access key are
required shown in Error! Reference source not found.. The common key
is the same for all nodes. However it is generated in each node by
using a system-specific algorithm with a cryptographic seed (e.g.
stored and executed in a tamper-resistant device) and a present time
(T2). It changes at relatively longer intervals (e.g. 12 hours). The
access key is different for each node. It is also periodically
generated in each node, for example every 10 minutes. The nodes
exchange their access keys via Hello Messages encrypted by the common
key. The nodes add a hash value of the message as a signature at the
end of the message.
The nodes are resistant to the following attacks:
o Packet snooping is difficult because messages among nodes are
encrypted by different access keys for each node and the nodes change
their own keys within a short time(e.g. 10 minutes).
o Disguise and falsification of messages can be detected by checking a
signature in a message.
o Denial of Service(DoS)and replay attacks are rejected by checking FID
and its received time.
9. IANA Considerations
<Add any IANA considerations>
10. Conclusions
<Add any conclusions>
11. References
11.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
Iwao, et al. Expires January 2, 2010 [Page 21]
Internet-Draft DADR Protocol July 2009
[2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, Internet Mail Consortium and
Demon Internet Ltd., November 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234, Internet Mail
Consortium and Demon Internet Ltd., November 1997.
[RFC5548] M. Dohler, Ed., T. Watteyne, Ed., T. Winter, Ed., D.
Barthel, Ed., "Routing Requirements for Urban Low-Power and
Lossy Networks", RFC5548, May 2009.
11.2. Informative References
[3] Faber, T., Touch, J. and W. Yue, "The TIME-WAIT state in TCP
and Its Effect on Busy Servers", Proc. Infocom 1999 pp. 1573-
1583.
[Fab1999] Faber, T., Touch, J. and W. Yue, "The TIME-WAIT state in
TCP and Its Effect on Busy Servers", Proc. Infocom 1999 pp.
1573-1583.
12. Acknowledgments
<Add any acknowledgements>
This document was prepared using 2-Word-v2.0.template.dot.
Iwao, et al. Expires January 2, 2010 [Page 22]
Internet-Draft DADR Protocol July 2009
Appendix A.
First Appendix
A.1. First Header level
Text
Copyright (c) 2009 IETF Trust and the persons identified as authors
of the code. All rights reserved.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
This code was derived from IETF RFC [insert RFC number]. Please
reproduce this note if possible.
Iwao, et al. Expires January 2, 2010 [Page 23]
Internet-Draft DADR Protocol July 2009
Authors' Addresses
Questions about this memo can be directed to:
Tadashige Iwao, Kentaro Ikemoto, Kenji Yamada, Yuji Takahashi,
Shunsuke Koga, Yuta Nakaya, and Sung Lee
FUJITSU LIMITED
Shiodome City Center, 5-2, Higashi-shimbashi 1-chome, Minato-ku,
Tokyo 105-7123,Japan
Phone. +81-3-6252-2283
Email: smartnetpro-iwao_std@ml.css.fujitsu.com
Iwao, et al. Expires January 2, 2010 [Page 24]
