draft-ietf-manet-olsrv2-15.txt   draft-ietf-manet-olsrv2-16.txt 
Mobile Ad hoc Networking (MANET) T. Clausen Mobile Ad hoc Networking (MANET) T. Clausen
Internet-Draft LIX, Ecole Polytechnique Internet-Draft LIX, Ecole Polytechnique
Intended status: Standards Track C. Dearlove Intended status: Standards Track C. Dearlove
Expires: November 16, 2012 BAE Systems ATC Expires: April 5, 2013 BAE Systems ATC
P. Jacquet P. Jacquet
Alcatel-Lucent Bell Labs Alcatel-Lucent Bell Labs
U. Herberg U. Herberg
Fujitsu Laboratories of America Fujitsu Laboratories of America
May 15, 2012 October 2, 2012
The Optimized Link State Routing Protocol version 2 The Optimized Link State Routing Protocol version 2
draft-ietf-manet-olsrv2-15 draft-ietf-manet-olsrv2-16
Abstract Abstract
This specification describes version 2 of the Optimized Link State This specification describes version 2 of the Optimized Link State
Routing (OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs). Routing (OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 16, 2012. This Internet-Draft will expire on April 5, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 34 skipping to change at page 4, line 34
20.1. Local History Time Parameters . . . . . . . . . . . . . . 79 20.1. Local History Time Parameters . . . . . . . . . . . . . . 79
20.2. Message Interval Parameters . . . . . . . . . . . . . . . 79 20.2. Message Interval Parameters . . . . . . . . . . . . . . . 79
20.3. Advertised Information Validity Time Parameters . . . . . 79 20.3. Advertised Information Validity Time Parameters . . . . . 79
20.4. Received Message Validity Time Parameters . . . . . . . . 79 20.4. Received Message Validity Time Parameters . . . . . . . . 79
20.5. Jitter Time Parameters . . . . . . . . . . . . . . . . . 80 20.5. Jitter Time Parameters . . . . . . . . . . . . . . . . . 80
20.6. Hop Limit Parameter . . . . . . . . . . . . . . . . . . . 80 20.6. Hop Limit Parameter . . . . . . . . . . . . . . . . . . . 80
20.7. Willingness Parameter . . . . . . . . . . . . . . . . . . 80 20.7. Willingness Parameter . . . . . . . . . . . . . . . . . . 80
21. Sequence Numbers . . . . . . . . . . . . . . . . . . . . . . 80 21. Sequence Numbers . . . . . . . . . . . . . . . . . . . . . . 80
22. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 81 22. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 81
23. Security Considerations . . . . . . . . . . . . . . . . . . . 81 23. Security Considerations . . . . . . . . . . . . . . . . . . . 81
23.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . 81 23.1. Security Architecture . . . . . . . . . . . . . . . . . . 82
23.2. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 82 23.2. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 82
23.3. Interaction with External Routing Domains . . . . . . . . 83 23.3. Confidentiality . . . . . . . . . . . . . . . . . . . . . 84
24. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 84 23.4. Interaction with External Routing Domains . . . . . . . . 84
24.1. Expert Review: Evaluation Guidelines . . . . . . . . . . 84 24. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 85
24.2. Message Types . . . . . . . . . . . . . . . . . . . . . . 84 24.1. Expert Review: Evaluation Guidelines . . . . . . . . . . 85
24.3. Message-Type-Specific TLV Type Registries . . . . . . . . 84 24.2. Message Types . . . . . . . . . . . . . . . . . . . . . . 85
24.4. Message TLV Types . . . . . . . . . . . . . . . . . . . . 85 24.3. Message-Type-Specific TLV Type Registries . . . . . . . . 85
24.5. Address Block TLV Types . . . . . . . . . . . . . . . . . 86 24.4. Message TLV Types . . . . . . . . . . . . . . . . . . . . 86
24.6. NBR_ADDR_TYPE and MPR Values . . . . . . . . . . . . . . 89 24.5. Address Block TLV Types . . . . . . . . . . . . . . . . . 88
25. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 89 24.6. NBR_ADDR_TYPE and MPR Values . . . . . . . . . . . . . . 90
26. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 90 25. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 91
27. References . . . . . . . . . . . . . . . . . . . . . . . . . 90 26. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 91
27.1. Normative References . . . . . . . . . . . . . . . . . . 90 27. References . . . . . . . . . . . . . . . . . . . . . . . . . 92
27.2. Informative References . . . . . . . . . . . . . . . . . 91 27.1. Normative References . . . . . . . . . . . . . . . . . . 92
Appendix A. Example Algorithm for Calculating MPRs . . . . . . . 91 27.2. Informative References . . . . . . . . . . . . . . . . . 92
A.1. Additional Notation . . . . . . . . . . . . . . . . . . . 92 Appendix A. Example Algorithm for Calculating MPRs . . . . . . . 93
A.2. MPR Selection Algorithm . . . . . . . . . . . . . . . . . 92 A.1. Additional Notation . . . . . . . . . . . . . . . . . . . 93
A.2. MPR Selection Algorithm . . . . . . . . . . . . . . . . . 93
Appendix B. Example Algorithm for Calculating the Routing Set . 93 Appendix B. Example Algorithm for Calculating the Routing Set . 94
B.1. Local Interfaces and Neighbors . . . . . . . . . . . . . 93 B.1. Local Interfaces and Neighbors . . . . . . . . . . . . . 94
B.2. Add Neighbor Routers . . . . . . . . . . . . . . . . . . 94 B.2. Add Neighbor Routers . . . . . . . . . . . . . . . . . . 95
B.3. Add Remote Routers . . . . . . . . . . . . . . . . . . . 94 B.3. Add Remote Routers . . . . . . . . . . . . . . . . . . . 96
B.4. Add Neighbor Addresses . . . . . . . . . . . . . . . . . 96 B.4. Add Neighbor Addresses . . . . . . . . . . . . . . . . . 97
B.5. Add Remote Routable Addresses . . . . . . . . . . . . . . 96 B.5. Add Remote Routable Addresses . . . . . . . . . . . . . . 98
B.6. Add Attached Networks . . . . . . . . . . . . . . . . . . 97 B.6. Add Attached Networks . . . . . . . . . . . . . . . . . . 98
B.7. Add 2-Hop Neighbors . . . . . . . . . . . . . . . . . . . 98 B.7. Add 2-Hop Neighbors . . . . . . . . . . . . . . . . . . . 99
Appendix C. TC Message Example . . . . . . . . . . . . . . . . . 98 Appendix C. TC Message Example . . . . . . . . . . . . . . . . . 100
Appendix D. Constraints . . . . . . . . . . . . . . . . . . . . 101 Appendix D. Constraints . . . . . . . . . . . . . . . . . . . . 102
Appendix E. Flow and Congestion Control . . . . . . . . . . . . 105 Appendix E. Flow and Congestion Control . . . . . . . . . . . . 107
1. Introduction 1. Introduction
The Optimized Link State Routing protocol version 2 (OLSRv2) is the The Optimized Link State Routing protocol version 2 (OLSRv2) is the
successor to OLSR (version 1) as published in [RFC3626]. Compared to successor to OLSR (version 1) as published in [RFC3626]. Compared to
[RFC3626], OLSRv2 retains the same basic mechanisms and algorithms, [RFC3626], OLSRv2 retains the same basic mechanisms and algorithms,
enhanced by the ability to use a link metric other than hop count in enhanced by the ability to use a link metric other than hop count in
the selection of shortest routes. OLSRv2 also uses a more flexible the selection of shortest routes. OLSRv2 also uses a more flexible
and efficient signaling framework, and includes some simplification and efficient signaling framework, and includes some simplification
of the messages being exchanged. of the messages being exchanged.
skipping to change at page 7, line 24 skipping to change at page 7, line 24
OLSRv2 makes no assumptions about the underlying link layer. OLSRv2, OLSRv2 makes no assumptions about the underlying link layer. OLSRv2,
through its use of [RFC6130], may use link layer information and through its use of [RFC6130], may use link layer information and
notifications when available and applicable. In addition, OLSRv2 notifications when available and applicable. In addition, OLSRv2
uses link metrics that may be derived from link layer or any other uses link metrics that may be derived from link layer or any other
information. OLSRv2 does not specify the physical meaning of link information. OLSRv2 does not specify the physical meaning of link
metrics, but specifies a means by which new types of link metrics may metrics, but specifies a means by which new types of link metrics may
be specified in the future, but used by OLSRv2 without modification. be specified in the future, but used by OLSRv2 without modification.
OLSRv2, as OLSR [RFC3626], inherits its concept of forwarding and OLSRv2, as OLSR [RFC3626], inherits its concept of forwarding and
relaying from HIPERLAN (a MAC layer protocol) which is standardized relaying from HIPERLAN (a MAC layer protocol) which is standardized
by ETSI [HIPERLAN], [HIPERLAN2]. by ETSI [HIPERLAN], [HIPERLAN2]. This document does not obsolete
[RFC3626] which is left in place for further experimentation.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
All terms introduced in [RFC5444], including "packet", "Packet All terms introduced in [RFC5444], including "packet", "Packet
Header", "message", "Message Header", "Message Body", "Message Type", Header", "message", "Message Header", "Message Body", "Message Type",
skipping to change at page 8, line 20 skipping to change at page 8, line 20
protocol MUST have at least one OLSRv2 interface. protocol MUST have at least one OLSRv2 interface.
Routable address: Routable address:
A network address which may be used as the destination of a data A network address which may be used as the destination of a data
packet. A router MUST be able to distinguish a routable address packet. A router MUST be able to distinguish a routable address
from a non-routable address by direct inspection of the network from a non-routable address by direct inspection of the network
address, based on global scope address allocations by IANA and/or address, based on global scope address allocations by IANA and/or
administrative configuration. Broadcast and multicast addresses, administrative configuration. Broadcast and multicast addresses,
and addresses which are limited in scope to less than the entire and addresses which are limited in scope to less than the entire
MANET, MUST NOT be considered as routable addresses. Anycast MANET, MUST NOT be considered as routable addresses. Anycast
addresses MAY be considered as routable addresses. addresses may be considered as routable addresses.
Originator address: Originator address:
An address which is unique (within the MANET) to a router. A An address which is unique (within the MANET) to a router. A
router MUST select an originator address; it MAY choose one of its router MUST select an originator address; it MAY choose one of its
interface addresses as its originator address; it MAY select interface addresses as its originator address; it MAY select
either a routable or non-routable address. A broadcast, multicast either a routable or non-routable address. A broadcast, multicast
or anycast address MUST NOT be chosen as an originator address. or anycast address MUST NOT be chosen as an originator address.
If the router selects a routable address then this MUST be one If the router selects a routable address then this MUST be one
which the router will accept as destination. An originator which the router will accept as destination. An originator
address MUST NOT have a prefix length, except for when included in address MUST NOT have a prefix length, except for when included in
skipping to change at page 28, line 23 skipping to change at page 28, line 23
In some cases a link metric value may be unknown. This is indicated In some cases a link metric value may be unknown. This is indicated
in this specification by the symbolic value UNKNOWN_METRIC. An in this specification by the symbolic value UNKNOWN_METRIC. An
implementation may use any representation of UNKNOWN_METRIC as it is implementation may use any representation of UNKNOWN_METRIC as it is
never included in messages, or used in any computation. (Possible never included in messages, or used in any computation. (Possible
representations are zero, or any value greater than the maximum representations are zero, or any value greater than the maximum
representable metric value.) representable metric value.)
6.2. Link Metric Compressed Form 6.2. Link Metric Compressed Form
The 12-bit compressed form of a link metric uses a modified form of a The 12-bit compressed form of a link metric uses a modified form of a
representation with an 8-bit mantissa (denoted b) and a 4-bit representation with an 8-bit mantissa (denoted a) and a 4-bit
exponent (denoted a). Note that if represented as the 12 bit value exponent (denoted b). Note that if represented as the 12 bit value
256a+b then the ordering of those 12 bit values is identical to the 256b+a then the ordering of those 12 bit values is identical to the
ordering of the represented values. ordering of the represented values.
The value so represented is (257+b)2^a - 256, where ^ denotes The value so represented is (257+a)2^b - 256, where ^ denotes
exponentiation. This has a minimum value (when a = 0 and b = 0) of exponentiation. This has a minimum value (when a = 0 and b = 0) of
MINIMUM_METRIC = 1 and a maximum value (when a = 15 and b = 255) of MINIMUM_METRIC = 1 and a maximum value (when a = 255 and b = 15) of
MAXIMUM_METRIC = 2^24 - 256. MAXIMUM_METRIC = 2^24 - 256.
An algorithm for computing a and b for the smallest representable An algorithm for computing a and b for the smallest representable
value not less than a link metric value v such that MINIMUM_METRIC <= value not less than a link metric value v such that MINIMUM_METRIC <=
v <= MAXIMUM_METRIC is: v <= MAXIMUM_METRIC is:
1. Find the smallest integer a such that v + 256 <= 2^(a + 9). 1. Find the smallest integer b such that v + 256 <= 2^(b + 9).
2. Set b := (v - 256(2^a - 1)) / (2^a) - 1, rounded up to the 2. Set a := (v - 256(2^b - 1)) / (2^b) - 1, rounded up to the
nearest integer. nearest integer.
7. Local Information Base 7. Local Information Base
The Local Information Base, as defined for each router in [RFC6130], The Local Information Base, as defined for each router in [RFC6130],
is extended by this protocol by: is extended by this protocol by:
o Recording the router's originator address. The originator address o Recording the router's originator address. The originator address
MUST be unique to this router. It MUST NOT be used by any other MUST be unique to this router. It MUST NOT be used by any other
router as an originator address. It MAY be included in any router as an originator address. It MAY be included in any
skipping to change at page 81, line 44 skipping to change at page 81, line 44
appropriate TLVs, or of network addresses associated with new appropriate TLVs, or of network addresses associated with new
TLVs, access to such information after appropriate updates have TLVs, access to such information after appropriate updates have
been recorded in the Information Bases in this protocol. been recorded in the Information Bases in this protocol.
o Through requesting that a message be generated at a specific time. o Through requesting that a message be generated at a specific time.
In that case, message generation MUST still respect the In that case, message generation MUST still respect the
constraints in [RFC6130] and Section 5.4.3. constraints in [RFC6130] and Section 5.4.3.
23. Security Considerations 23. Security Considerations
Currently, this protocol does not specify any special security As a proactive routing protocol, this protocol is a potential target
measures. As a proactive routing protocol, this protocol is a for various attacks. This section presents the envisioned security
potential target for various attacks. Various possible architecture for OLSRv2, and gives guidelines on how to provide
vulnerabilities are discussed in this section. integrity, confidentiality, and integration into external routing
domains.
23.1. Confidentiality 23.1. Security Architecture
This protocol periodically MPR floods topological information to all OLSRv2 integrates into the architecture specified in Appendix A of
routers in the network. Hence, if used in an unprotected network, [RFC5444], in [RFC5498], and in Section 16 of [RFC6130], the latter
such as an unprotected wireless network, the network topology is by using and extending its messages and Information Bases.
revealed to anyone who listens to the control messages.
In situations where the confidentiality of the network topology is of As part of this architecture, OLSRv2, and NHDP, recognize that there
importance, regular cryptographic techniques, such as exchange of may be external reasons for rejecting messages that would be
OLSRv2 control traffic messages encrypted by PGP [RFC4880] or considered "badly formed" or "insecure", e.g., if a digital signature
encrypted by some shared secret key, can be applied to ensure that included in a message by an external mechanism cannot be verified.
control traffic can be read and interpreted by only those authorized This architecture allows options as to whether and how to implement
to do so. security features, reflecting the situation that MANET routing
protocol deployment domains have varying security requirements,
ranging from "practically unbreakable" to "virtually none". This
approach allows MANET routing protocol specifications to remain
generic, with extensions to them, and/or extensions to the
multiplexing and demultiplexing process described in Appendix A of
[RFC5444], providing security mechanisms appropriate to a given
deployment domain.
The following sections provide guidelines how to provide integrity,
confidentiality, and integration with external routing domains in
such extensions.
23.2. Integrity 23.2. Integrity
Each router is injecting topological information into the network Each router injects topological information into the network by
through transmitting HELLO messages and, for some routers, TC transmitting HELLO messages and, for some routers, also TC messages.
messages. If some routers for some reason, malice or malfunction, If some routers for some reason, malice or malfunction, inject
inject invalid control traffic, network integrity may be compromised. invalid control traffic, network integrity may be compromised.
Therefore, message authentication is RECOMMENDED. Therefore, message, or packet, authentication is recommended.
Different such situations may occur, for instance: Different such situations may occur, for example:
1. A router generates TC messages, advertising links to non-neighbor 1. A router generates TC messages, advertising links to non-neighbor
routers; routers;
2. A router generates TC messages, pretending to be another router; 2. A router generates TC messages, pretending to be another router;
3. A router generates HELLO messages, advertising non-neighbor 3. A router generates HELLO messages, advertising non-neighbor
routers; routers;
4. A router generates HELLO messages, pretending to be another 4. A router generates HELLO messages, pretending to be another
skipping to change at page 82, line 48 skipping to change at page 83, line 15
7. A router does not select multipoint relays correctly; 7. A router does not select multipoint relays correctly;
8. A router forwards broadcast control messages unaltered, but does 8. A router forwards broadcast control messages unaltered, but does
not forward unicast data traffic; not forward unicast data traffic;
9. A router "replays" previously recorded control traffic from 9. A router "replays" previously recorded control traffic from
another router. another router.
Authentication of the originator router for control messages (for Authentication of the originator router for control messages (for
situations 2, 4 and 5) and on the individual links announced in the situations 2, 4 and 5), and of the individual links announced in the
control messages (for situations 1 and 3) may be used as a control messages (for situations 1 and 3), may be used as a
countermeasure. However to prevent routers from repeating old (and countermeasure. However to prevent routers from repeating old (and
correctly authenticated) information (situation 9) temporal correctly authenticated) information (situation 9) temporal
information is required, allowing a router to positively identify information (a timestamp) is required, allowing a router to
such delayed messages. positively identify such replayed messages.
In general, digital signatures and other required security In general, digital signatures and other required security
information MAY be transmitted as a separate Message Type, or information may be transmitted within the HELLO and TC messages, or
signatures and security information MAY be transmitted within the within a packet header, using the TLV mechanism. Either option
HELLO and TC messages, using the TLV mechanism. Either option permits "secured" and "unsecured" routers to coexist in the same
permits that "secured" and "unsecured" routers can coexist in the network, if desired.
same network, if desired.
Specifically, the authenticity of entire control packets can be
established through employing IPsec authentication headers, whereas
authenticity of individual links (situations 1 and 3) require
additional security information to be distributed.
An important consideration is that all control messages (HELLO An important consideration is that all control messages (HELLO
messages and TC messages) are transmitted to all routers in the 1-hop messages and TC messages) are transmitted to all routers in the 1-hop
neighborhood and some (TC messages) are flooded to all routers in the neighborhood and some control messages (TC messages) are flooded to
network. all routers in the network. This is done in a packet that is
transmitted to all routers in the 1-hop neighborhood, the current set
of which may not be known. Thus, a control message, or packet, used
by this protocol is always contained in a transmission destined for
multiple destinations, and it is important that the authentication
mechanism employed permits any receiving router to validate the
authenticity of a message or packet.
Thus, a control message in this protocol is always a point-to- [RFC6622] specifies a common exchange format for cryptographic
multipoint transmission. It is therefore important that the information in the form of Packet TLVs, Message TLVs, and Address
authentication mechanism employed permits that any receiving router Block TLVs, as specified in [RFC5444]. These may be used (and
can validate the authenticity of a message. As an analogy, given a shared) among MANET routing protocol security extensions. In
block of text, signed by a PGP private key, then anyone with the particular, [RFC6622] specifies the format of TLVs for containing
corresponding public key can verify the authenticity of the text. Integrity Check Values (ICVs), i.e., signatures, for providing
integrity, as well as TLVs for containing temporal information for
preventing replay attacks. [RFC6622] specifies registries for using
different ciphers and formats of temporal information. Failure to
verify an ICV included can be used as a reason to reject an incoming
message or packet as "valid", according to Section 12.1 of [RFC6130],
and according to Section 16.3.1 of this specification, when using the
multiplexing and demultiplexing process described in Appendix A of
23.3. Interaction with External Routing Domains [RFC5444].
This protocol does, through the use of TC messages, provide a basic Any security extension that uses [RFC6622] must specify how to insert
mechanism for injecting external routing information to this IVCs in generated messages, how to verify incoming messages, and to
protocol's domain. Routing information can be extracted from the reject "insecure" messages (i.e., messages without an ICV or with an
protocol's Information Bases, in particular the Routing Set, of this ICV that cannot be verified) when operating in a secure mode.
protocol and, potentially, injected into an external domain, if the Different MANET deployments may, as a result of their purpose for
routing protocol governing that domain permits this. which they are used and the possibility and nature of their
configuration, require different ICV algorithms and timestamps, and
thus a security extension may use any of the different options
provided in [RFC6622].
When operating routers connecting a MANET using this protocol to an 23.3. Confidentiality
external routing domain, care MUST be taken not to allow potentially
insecure and untrustworthy information to be injected from this
domain to external routing domains. Care MUST also be taken to
validate the correctness of information prior to it being injected as
to avoid polluting routing tables with invalid information.
A RECOMMENDED way of extending connectivity from an external routing OLSRv2 periodically MPR floods topological information to all routers
domain to a MANET routed using this protocol is to assign an IP in the network. Hence, if used in an unprotected network, in
prefix (under the authority of the routers/gateways connecting the particular an unprotected wireless network, the network topology is
MANET with the external routing domain) exclusively to that MANET revealed to anyone who successfully listens to the control messages.
area, and to statically configure the gateways to advertise routes This information may serve an attacker to acquire details about the
for that IP sequence to routers in the external routing domain. topology, and therefore to initiate more effective attacks against
routers in the routing domain e.g., by spoofing addresses of routers
in the network and attracting traffic for these addresses. Note that
this is independent of the data traffic, and purely protects the
control traffic, i.e., information about the network topology.
In situations where the confidentiality of the network topology is of
importance, regular cryptographic techniques, such as use of OLSRv2
multicast control packets encrypted using IPsec (e.g., with a shared
secret key), can be applied to ensure that control traffic can be
read and interpreted by only those authorized to do so.
Alternatively, a security extension may specify a mechanism to
provide confidentiality for control messages and/or packets.
However, unless the information about the network topology itself is
confidential, integrity of control messages (as specified in
Section 23.2) is sufficient to admit only trusted routers (i.e.
routers with valid credentials) to the network.
23.4. Interaction with External Routing Domains
This protocol provides a basic mechanism for injecting external
routing information into this protocol's routing domain. Routing
information can also be extracted from this protocol's Information
Bases, in particular the Routing Set, and injected into an external
routing domain, if the routing protocol governing that routing domain
permits this.
When operating routers connecting a routing domain using this
protocol to an external routing domain, care MUST be taken not to
allow potentially insecure and untrustworthy information to be
injected from this routing domain to an external routing domain.
Care MUST also be taken to validate the correctness of information
prior to it being injected, so as to avoid polluting routing tables
with invalid information.
A recommended way of extending connectivity from an external routing
domain to this routing domain, which is routed using this protocol,
is to assign an IP prefix (under the authority of the routers/
gateways connecting this routing domain with the external routing
domain) exclusively to this routing domain, and to configure the
gateways to advertise routes for that IP prefix into the external
routing domain.
24. IANA Considerations 24. IANA Considerations
This specification defines one Message Type, which must be allocated This specification defines one Message Type, which must be allocated
from the "Message Types" repository of [RFC5444], two Message TLV from the "Message Types" repository of [RFC5444], two Message TLV
Types, which must be allocated from the "Message TLV Types" Types, which must be allocated from the "Message TLV Types"
repository of [RFC5444], and four Address Block TLV Types, which must repository of [RFC5444], and four Address Block TLV Types, which must
be allocated from the "Address Block TLV Types" repository of be allocated from the "Address Block TLV Types" repository of
[RFC5444]. [RFC5444].
skipping to change at page 91, line 18 skipping to change at page 92, line 41
27.2. Informative References 27.2. Informative References
[RFC2501] Macker, J. and S. Corson, "Mobile Ad hoc Networking [RFC2501] Macker, J. and S. Corson, "Mobile Ad hoc Networking
(MANET): Routing Protocol Performance Issues and (MANET): Routing Protocol Performance Issues and
Evaluation Considerations", RFC 2501, January 1999. Evaluation Considerations", RFC 2501, January 1999.
[RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State [RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State
Routing Protocol", RFC 3626, October 2003. Routing Protocol", RFC 3626, October 2003.
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, [RFC6622] Herberg, U. and T. Clausen, "Integrity Check Value and
"OpenPGP message format", RFC 4880, November 2007. Timestamp TLV Definitions for Mobile Ad Hoc Networks
(MANETs)", RFC 6622, May 2012.
[HIPERLAN] ETSI, "ETSI STC-RES10 Committee. Radio equipment and [HIPERLAN] ETSI, "ETSI STC-RES10 Committee. Radio equipment and
systems: HIPERLAN type 1, functional specifications ETS systems: HIPERLAN type 1, functional specifications ETS
300-652", June 1996. 300-652", June 1996.
[HIPERLAN2] Jacquet, P., Minet, P., Muhlethaler, P., and N. [HIPERLAN2] Jacquet, P., Minet, P., Muhlethaler, P., and N.
Rivierre, "Increasing reliability in cable free radio Rivierre, "Increasing reliability in cable free radio
LANs: Low level forwarding in HIPERLAN.", 1996. LANs: Low level forwarding in HIPERLAN.", 1996.
[MPR] Qayyum, A., Viennot, L., and A. Laouiti, "Multipoint [MPR] Qayyum, A., Viennot, L., and A. Laouiti, "Multipoint
skipping to change at page 106, line 26 skipping to change at page 108, line 25
BAE Systems ATC BAE Systems ATC
Phone: +44 1245 242194 Phone: +44 1245 242194
EMail: chris.dearlove@baesystems.com EMail: chris.dearlove@baesystems.com
URI: http://www.baesystems.com/ URI: http://www.baesystems.com/
Philippe Jacquet Philippe Jacquet
Alcatel-Lucent Bell Labs Alcatel-Lucent Bell Labs
Phone: +33 6 7337 1880 Phone: +33 6 7337 1880
EMail: philippe.jacquet@alcatel-lucent.fr EMail: philippe.jacquet@alcatel-lucent.com
Ulrich Herberg Ulrich Herberg
Fujitsu Laboratories of America Fujitsu Laboratories of America
1240 E. Arques Ave. 1240 E. Arques Ave.
Sunnyvale, CA, 94085 Sunnyvale, CA, 94085
USA USA
EMail: ulrich@herberg.name EMail: ulrich@herberg.name
URI: http://www.herberg.name/ URI: http://www.herberg.name/
 End of changes. 30 change blocks. 
107 lines changed or deleted 166 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/