Re: [manet] MANET Terminology Update

Abdussalam Baryun <abdussalambaryun@gmail.com> Mon, 23 July 2012 06:59 UTC

Return-Path: <abdussalambaryun@gmail.com>
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25FCA21F84A0 for <manet@ietfa.amsl.com>; Sun, 22 Jul 2012 23:59:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.166
X-Spam-Level:
X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=-1.167, BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9eN7f8NOjj4k for <manet@ietfa.amsl.com>; Sun, 22 Jul 2012 23:59:00 -0700 (PDT)
Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B176E21F84BD for <manet@ietf.org>; Sun, 22 Jul 2012 23:58:59 -0700 (PDT)
Received: by vcbfo14 with SMTP id fo14so4767546vcb.31 for <manet@ietf.org>; Sun, 22 Jul 2012 23:58:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=z1A73uZ/emLaJLzIXX9ZSvWYtdis/WYx2363dgUwmYo=; b=vplo5o94QIB2yTYCCdlf/zCn/KsaGNGRF8dXdguddBU0/+Wb4IQuj7P3Ta+kdWMNAv G16MftX+CKLKwV/gaLsi/eyqgdXs2gYZpPYhL5MeAdxaD1G6UwFwz9nAah5bPyXsCCwf 4ki/i60x1aBcZVfsd+afPxlZvFf4+MIsUXuqEQYT7PrnP+XGi+/5Tx8gJSvHUhR+42DY xWiRNUIx6qq1SdomCdtdSu/6gbkUK25BDDFp9CQsKaw3FgI/FNsw6L+iy5JSQ4ve8x6S zObKs/iNKnAfJ3J8yjMgejCOzWNRxmNC6JWirwPV8k4ns1j5y0kwJVfRqNTUy0FQhF+s SaOA==
MIME-Version: 1.0
Received: by 10.52.71.79 with SMTP id s15mr9925143vdu.86.1343026739065; Sun, 22 Jul 2012 23:58:59 -0700 (PDT)
Received: by 10.220.141.200 with HTTP; Sun, 22 Jul 2012 23:58:58 -0700 (PDT)
In-Reply-To: <2C1F8976-FE53-4C49-9BA3-930BFB63A8F5@thomasclausen.org>
References: <CADnDZ89NQS+tFVDsBjb_TZ2B-jL-o95Gx2HA5AbpRf2a8CstSg@mail.gmail.com> <B4130C17-45C2-485D-B2E4-3B9E16CA85DD@gmail.com> <CADnDZ88AQf_GLxjqdbB47EsACg+gnxHX9YJW5PZpOJzC32bR+A@mail.gmail.com> <2C1F8976-FE53-4C49-9BA3-930BFB63A8F5@thomasclausen.org>
Date: Mon, 23 Jul 2012 08:58:58 +0200
Message-ID: <CADnDZ888Sh_edm4XmPvvzrgN8WAK+NAWMCZEh7PuG-wJYLbMeQ@mail.gmail.com>
From: Abdussalam Baryun <abdussalambaryun@gmail.com>
To: manet <manet@ietf.org>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Cc: Thomas Heide Clausen <thomas@thomasclausen.org>
Subject: Re: [manet] MANET Terminology Update
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Jul 2012 06:59:02 -0000

Hi

Comment inline below:

On 7/6/12, Thomas Heide Clausen <thomas@thomasclausen.org> wrote:
> I do not see the need for this terminology document in MANET:
>
> 	o	The RFCs published by the WG all do a good job of defining their proper
> 		terminology and conventions in the sections, aptly named to this
> 		effect -- and something which both the WG and the IESG has been very
> 		vigilant in ensuring.

Agree

>
> 	o	Extracting this terminology, to present without the context of the RFC in
>
> 		which they are introduced and used, is both futile and a source
> 		of errors and confusion.

It is not extracting any thing it is locating information in easy
location to be reached efficiently by researchers, or other WG
participants. In another reason, for example the RFC5444 and RFC6130
is providing a MANET standard, while any RFC in this WG is specifying
its own terminology and message format, but the reason was to bring
RFCs to have similar formating functions. The terminology RFCs in many
WGs does the same. RFC2501 is doing a good job to bring understanding
of MANET which the terminology informational RFCs are doing in each
concept/group-charter.

>
> 	o	The domain evolves, new protocols appear and introduce new concepts,
> 		terms. This is captured by carefully defining such in the RFC specifying
> 		that protocol. Any terminology document (aside from all its other issues,
> 		indicated in this list) would likely be obsolete and incomplete before
> the
> 		ink with which it was written was dry.

So when new concepts appear any WG needs to prepare updates I-D to
their information/standards/experiments so that knowledge is
consistent and concepts are updated as will (including terminology
document can be updated). Please note that our documents in MANET are
a source of information to any participant in IETF, so we need to
focus to not only produce new concepts/work but we see into
update/obsolete previous work if possible/necessary. other wise why
did the IETF make an option possibility to *update* and *obsolete* if
they are not needed for WGs.

>
> 	o	All RFCs in MANET uses no more than a small subset of the total MANET
> 		(and Internet) terminology. A collective terminology document would,
> 		therefore, necessarily be adding entropy to any single RFC and to the
> 		WG (and to implementers of the WG protocols).

Please note that the bigest reason of terminology is that when WG
participants discuss things they don't misunderstand. Please note
there are many times in MANET WG there are misunderstood in technical
terms (I have references on the list to many incidence if you ask), so
if experts have this problem we need to solve it by a RFC document,
also we need to give the protocol user a sense of the general/specific
terminology (as we have MANET general format, MANET general
understanding, MANET general direction).

>
> 	o	Certainly, a large number of terms in this document are entirely out of
> scope
> 		(such as those pertaining to non-MANET developed concepts or protocols,
> 		e.g., those developed in other parts of the IETF), are useless for the WG
> 		(such as, but not exclusively, "communication channel" and "communication
>
> 		medium"), are by nature ambiguous (such as, but not exclusively, "Upper
> Layer"
> 		and "Node"), carry a legacy that renders them difficult to use (such as,
> but
> 		not exclusively, "Logical (virtual) Link", "Physical Link", and "Link").
>

I disagree that thoes terms are out of scope of the I-D of the MANETs
context terminology, because those terms you mentioned were used in
one/some MANET RFCs, so they need to be explained to bring all terms
together to make overall knowledge to internet community. Your
argument is right only if we are not specifying network-protocols, so
because we are doing a type of network, then our documents for it
SHOULD be *connected* by some combined meaning/knowledge *words*, so
other (i.e. all internet community) can understand, without any
possibility of misunderstanding (there are many examples I can give if
you want).

I thank you for your comments, and I will prepare a new version for the I-D,

Best Regards

Abdussalam Baryun
=====================
>>> On Jul 3, 2012, at 1:24 PM, Abdussalam Baryun wrote:
>>>
>>>> Dear All
>>>>
>>>> I completed the first version of draft on terminology and submited the
>>>> draft yesterday (with getting some techniq problem), but needed to
>>>> post to know the community feedback and advise. There are other terms
>>>> that was not yet included which will need some advise from you.
>>>> Thanking you,
>>>>
>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>> Abbreviations Used in The submitted Document
>>>>
>>>>  AH   Authentication Header
>>>>  DAD  Duplicate Address Detection
>>>>  DPD  Duplicate Packet Detection
>>>>  DoS  Denial of Service
>>>>  ESP  Encapsulating Security Payload
>>>>  IP   IPv4 or IPv6
>>>>  ICMP Internet Control Message Protocol
>>>>  IIB  Interface Information Base
>>>>  ETX  Estimated Expected number of Transmission
>>>>  FIB  Forwarding Information Base
>>>>  LQI  Link Quality Indicator
>>>>  L2   Data Link Layer (i.e. 2nd layer in ISO model)
>>>>  L3   Internet Layer (i.e. 3rd layer in ISO model)
>>>>  LLN  Low power and Lossy Network
>>>>  MAC  Mediam Access Control
>>>>  MIB  Management Information Base
>>>>  MTU  Maximum Transmission Unit
>>>>  NBMA Non-Broadcast Multi-Access link
>>>>  NHDP Neighborhood Discovery Protocol
>>>>  ND   IP Neighbor Discovery
>>>>  OSPF Open Shortest Path First
>>>>  RIB  Routing Information Base
>>>>  SMF  Simplified Multicast Forwarding
>>>>  TCP  Transmission Control Protocol
>>>>  UDP  User Datagram Protocol
>>>>
>>>> 2.3 Definitions for MANET Terms
>>>>
>>>> 2.3.1 Terms Definition of MANET Communication:
>>>>
>>>> Communications’ Technology or Facility:
>>>>  The means employed by two or more devices/subsystems to transfer
>>>>  and/or receive information between them in one way or two way
>>>>  communication.  MANET communications often uses the wireless
>>>>  transmission medium(s) and MAY use some wired mediums (e.g. free
>>>>  space, air, water, antenna, coaxial cables, etc.)
>>>>
>>>> Communication Medium:
>>>>  The transceiver system (e.g. such as L2 systems, IEEE802.11 systems,
>>>>  satellite system, etc.) that the routing device uses to communicates
>>>>  through the transmission medium(s), by providing connectionless and/or
>>>>  connection services that MAY be established. The system medium
>>>>  includes MAC layer and MAY include the physical Layer.
>>>>
>>>> Communication Channel:
>>>> A subdivision of the physical communication medium (i.e. radio carrier
>>>> signal bandwidth, or the system bandwidth) allowing possibly shared
>>>> independent uses of the medium. Channels may be made available by
>>>> subdividing the medium into; distinct time slots, distinct spectral
>>>> bands, or coding sequence, etc.
>>>>
>>>> MANET Protocol:
>>>> The communication system/subsystem that operates and maintains the
>>>> ad hoc communication technology or facility within MANET. MANET routing
>>>> Protocols often apply distributed algorithms/techniques to disseminate
>>>> or forward routing messages within a MANET routing domain.
>>>>
>>>> Topology:
>>>> An abstract representation of a network (physical or logical), as a
>>>> graph (G) whose topology is defined by a set of routers/bridges (V)
>>>> that
>>>> communicate through set of links (E), where the G = (V, E).
>>>>
>>>> Physical-level Topology:
>>>> A topology of the communication medium networks consists of routing
>>>> devices and physical links. This topology information is updated by
>>>> devices’ technology in the L2 information Base.
>>>>
>>>> Network-level Topology:
>>>> A topology of the communication system networks consists of routers and
>>>> links. This topology information is updated by routers in its RIB.
>>>>
>>>> Multihop MANET:
>>>> A MANET that its node(s) MAY need(s) more than one IP hop to reach the
>>>> destination.
>>>>
>>>> Reactive Routing:
>>>> An on-demand based routing protocol that operates route discover and
>>>> maintainance the route(s), to reach the demanded destination(s).
>>>>
>>>> Proactive Routing:
>>>> A topology RIB based routing protocol that operates routes and
>>>> maintains
>>>> the network topology, to reach its known destination(s). Each router
>>>> maintains routes to all reachable destinations at all times, whether or
>>>> not there is currently any demand to deliver packets to those
>>>> destinations.
>>>>
>>>> Upper Layer:
>>>> a protocol layer above IP layer (e.g. as TCP, UDP, OSPF).
>>>>
>>>> MANET Domain: TBD
>>>>
>>>> MANET Signaling:
>>>> Sending and exchanging some MANET messages/information.
>>>>
>>>> 2.3.2 Terms Definition of MANET Elements
>>>>
>>>> Node:
>>>> A device/subsystem that MUST implement IP and SHOULD participate in
>>>> MANET signaling. It either runs a MANET routing protocol or participate
>>>> in MANET signaling.
>>>>
>>>> Router:
>>>> A MANET node that MUST implement a MANET routing protocol and forwards
>>>> IP packets not explicitly addressed to itself.
>>>>
>>>> Host:
>>>> A node that is not a router. All destinations in MANET that receive
>>>> delivered data are hosts.
>>>>
>>>> Link:
>>>> A link between two node interfaces. This link may be Logical
>>>> (i.e. virtual) link or physical link. Logical links are between two
>>>> logical interfaces and physical links are between two physical
>>>> interfaces. Links are either unidirectional or bidirectional
>>>> (links may be on-link and off-link: see RFC4861).
>>>>
>>>>
>>>> Physical Link:
>>>> a communication facility or medium over which the nodes can
>>>> communicate at the link layer, i.e., the layer immediately below
>>>> IP. Physical interfaces are the nodes’ attachment to physical links.
>>>> Physical Link types are point-to-point, NBMA, multicast capable,
>>>> and shared-media, etc (see link types in ND [RFC4861]).
>>>>
>>>> Logical (virtual) Link:
>>>> a communication facility (at L3, or upper-layer) over which nodes can
>>>> communicate. This logical link is between two MANET interfaces exists
>>>> if either can be heard by the other.
>>>>
>>>> Link MTU:
>>>> the maximum transmission unit (i.e. maximum unit size in octets), that
>>>> can be conveyed in one transmission unit over the link.
>>>>
>>>>
>>>> Node Interface:
>>>> A node's point of attachment to a link. Each node MUST have at least
>>>> one
>>>> interface that SHOULD be assigned an IP address. If there is/are more
>>>> than one interface(s) per node then the additional interface(s) MAY be
>>>> assigned an IP address. If an interface is not assigned to an IP
>>>> address
>>>> it MUST be identified by the MANET routing protocol. An interface MAY
>>>> be
>>>> assigned one or more addresses.
>>>>
>>>> MANET Interface:
>>>> A node interface that participate in; exchange MANET information used
>>>> in
>>>> MANET routing or exchange information in MANET neighbor node discovery
>>>> (e.g as the term used in RFC6130). A MANET interface MUST be assigned
>>>> to
>>>> least one  address to communicate. A router interface MUST be
>>>> assigned a routable address which is the main address for the
>>>> interface.
>>>>
>>>>
>>>> 2.3.3 Terms Definition of MANET Identifications:
>>>>
>>>> An interface MAY be assigned one or more addresses. If the interface is
>>>> a logical interface it MAY be assigned to only logical addresses, but
>>>> if
>>>> it is a physical interface MAY be assigned with physical address
>>>> (e.g. MAC address) and/or logical address(es) (e.g. IP addresses,
>>>> MANET addresses).
>>>>
>>>>
>>>> MANET Address
>>>> A MANET-subnet, node, or interface address. Node and interface
>>>> addresses
>>>> are either IP addresses or RFC5444 addresses. All subnet addresses are
>>>> unicast IP addresses.
>>>>
>>>> Address Block and TLV: as specified in RFC5444
>>>>
>>>> Routable address:
>>>> A subnet address which can be a destination address. A router MUST be
>>>> able to distinguish a routable address from a non-routable address.
>>>> Broadcast, and multicast addresses, limited in scope to less than the
>>>> entire MANET, MUST NOT be considered as routable addresses. Anycast
>>>> addresses MAY be considered as routable addresses.
>>>>
>>>> Main address
>>>> A routable address (MANET address) that is assigned to one router's
>>>> MANET interface.
>>>>
>>>> Originator address:
>>>> A node address of the node that originated a MANET message (this
>>>> message
>>>> MUST include the originator address). It MAY be a routable or an
>>>> unroutable address.
>>>>
>>>> subnet prefix
>>>> A bit string that consists of some number of initial bits of an IP
>>>> address.
>>>>
>>>> Interface identifier
>>>> the remaining low-order bits in the node's IP address after the subnet
>>>> prefix. A number used to identify a node's interface on a link.
>>>>
>>>> 2.3.4 Terms Definition of MANET exchange information formats:
>>>>
>>>> Packet:
>>>> A MANET packet of a header plus payload. These packets are either
>>>> IP packets or RFC5444 packets. RFC5444 packet MUST be encapsulated
>>>> in IP packet. Packets are generated by nodes to be sent to
>>>> destination(s) through MANET or through the Internet. RFC5444 packets
>>>> information MAY not be used only by MANET routers.
>>>>
>>>> Message:
>>>> A MANET data message or routing control message. Routing control
>>>> messages are either MANET routing protocol messages or/and RFC5444
>>>> messages.
>>>>
>>>> Type Length Value coding (TLV):
>>>> A generic way to represent MANET information (as in [RFC5444] and
>>>> [RFC5497]).
>>>>
>>>> Frame:
>>>> A L2 protocol TLV with a header and payload. In some technologies the
>>>> L2
>>>> operates a MANET routing protocol as a local area networking system.
>>>> Frames MAY encapsulate MANET packets to be tunneled through a
>>>> telecommunication network.
>>>>
>>>> Route Request Message (RREQ)
>>>> A message is used to discover a valid route to a particular
>>>> destination address, called the RREQ Target Node. When a router
>>>> processes a RREQ it learns routing information on how to Originator
>>>> Node.
>>>>
>>>> Route Reply Message (RREP)
>>>> A message is used to disseminate routing information about
>>>> the RREP Target Node to the RREQ Originator Node and the intermediate
>>>> routers.
>>>>
>>>> Route Error Message (RERR)
>>>> A message is used to disseminate the information that a route is
>>>> not available for one or more particular addresses. A RERR message is
>>>> used to indicate that a router does not have a forwarding route
>>>> to one or more particular addresses.
>>>>
>>>> 2.3.5 Terms Definition Related to MANET Protocol Operation:
>>>>
>>>> Hop-by-hop Routing: (TBD)
>>>> A dynamic routing that routes to destination by routing table.
>>>>
>>>> Source Routing: (TBD)
>>>> A dynamic routing that its route path is provided in the IP packet.
>>>>
>>>> Route Discovery: TBD
>>>>
>>>> Route Maintenance: TBD
>>>>
>>>> Neighbor discovery: (TBD)
>>>> A node discovers neighbors only if the node receives from it's
>>>> neighbors.
>>>>
>>>>
>>>> Multipoint relay (MPR): (TBD)
>>>> A router X1 is an MPR for a router Y1, if router Y1 has indicated
>>>> its selection of router X1 as an MPR in a recent HELLO message.
>>>> Router X1 may be a flooding MPR for Y1 if it is indicated to
>>>> participate in the flooding process of messages received from
>>>> router Y1, or it may be a routing MPR for Y1, if it is indicated to
>>>> declare link-state information for the link from X1 to Y1. It may
>>>> also be both at the same time.
>>>>
>>>> MPR selector:
>>>> A router, Y, is a flooding/routing MPR selector of router X if
>>>> router Y has selected router X as a flooding/routing MPR.
>>>>
>>>> Router Parameters:
>>>> boolean or numerical values, specified for each router, and not
>>>> specific to an interface. A router MAY change router parameter
>>>> values at any time, subject to some MANET constraints.
>>>>
>>>> MANET Routing Metric:
>>>> A MANET routing cost that is governed by specific rules and properties
>>>> defined by the MANET routing protocol which captures specific link or
>>>> node characteristics. Examples of basic metrics are hop-count, ETX,
>>>> LQI,
>>>> etc.
>>>>
>>>> Distance Vector Metric
>>>> A metric class related to rules of the MANET interface and MANET path
>>>> distance. The metric can be calculated by the distance vector routing
>>>> algorithm class used by the MANET routing protocol. A metric of the
>>>> distance a message or piece of information has traversed. The minimum
>>>> value of distance is the number of IP hops traversed.
>>>>
>>>> Link State Metric
>>>> A metric type related to the MANET network-topology status and logical
>>>> links' states. This metric is calculated by the link state routing
>>>> algorithm class used by the MANET routing protocol. A metric type maybe
>>>> EXT, LQL, etc.
>>>>
>>>> Link Metric: TBD
>>>>
>>>> Neighbor Metric: TBD
>>>>
>>>> Path accumulated:
>>>> The RREQ message accumulates intermediate routers that are in path to
>>>> destination(s).
>>>>
>>>> Protocol Sequence Number:
>>>> A Sequence Number related to a MANET protocol that maintained by each
>>>> protocol subsystem process. This sequence number is used by other
>>>> subsystems to identify the temporal order of protocol information
>>>> generated.
>>>>
>>>> Router Sequence Number:
>>>> A router sequence number is maintained by each router process. The
>>>> sequence number is used by other routers to identify the temporal
>>>> order of routing information generated and ensure loop-free routes.
>>>>
>>>> MANET Information Base:
>>>> A collection of information (in Table or Cache structure) maintained
>>>> by MANET protocols and which is to be made available to MANET routing
>>>> protocols. An Information Base may be associated with a MANET router
>>>> or with MANET interface (e.g. route request table, IIB, RIB, FIB, MIB).
>>>>
>>>> RIB Entry:
>>>> The RIB entry is a conceptual data structure. Implementations may use
>>>> any internal representation that conforms to the semantics of a route
>>>> as specified in the router specification.
>>>>
>>>> 3. IP Considerations and Terminology
>>>>
>>>>  All MANET nodes MUST implement IP and all MANET routers MUST
>>>>  run/implement  at least one MANET routing protocol. The
>>>>  terminologies described in this document can be used for
>>>>  IPv4-MANET and IPv6-MANET. The IPv4 addresses MAY be used in IPv6
>>>>  packets but IPv6 addresses MUST not be in IPv4 packets.
>>>>
>>>>  IP address:
>>>>  IPv4 addresses or IPv6 addresses.
>>>>
>>>>  IP Packet:
>>>>  The packet header plus payload as specified in [RFC791] and [RFC2460]
>>>>  for IPv4 and IPv6 respectively. It can encapsulate RFC5444 packets as
>>>>  specified by RFC5498.
>>>>
>>>>  Mobile IP considerations:
>>>>  Mobile IP terms are provided in [RFC6275], and this technology
>>>>  assists nodes while connected through the Internet domain(s). MANET
>>>>  is an infrastructure-less network that is able to communicate with
>>>>  the Internet (i.e. an IP infrastructure network).
>>>>
>>>> 4. Security Consideration and Terminology
>>>>
>>>>  It is RECOMMENDED that MANET routing protocols consider security
>>>>  issues because the MANET's transmission medium is wireless which make
>>>>  it vulnerable to attacks [ANJUM][RFC4593]. In some situations the
>>>>  routing information while traversing the MANET MAY be used by an
>>>>  intruder node, to obtain MANET data traffic or/and attack the MANET
>>>>  [HERBERG]. Forwarding protocols that use DPD techniques MAY be
>>>>  vulnerable to DoS attacks such as [RFC6621]. MANETs MAY be secured
>>>>  by using IPsec, AH, DAD, and ESP techniques, and other. However,
>>>>  it is RECOMMENDED that MANET detects attackers and possible threats.
>>>>
>>>>  The following are some terminology related to MANET threats and
>>>>  security.
>>>>
>>>> Attacker: A node, present in the network and which intentionally seeks
>>>> to compromise information based in MANET router(s). The Attacker MAY be
>>>> a compromised MANET router if obtained MANET identity or routing
>>>> information.
>>>>
>>>> Compromised MANET Router: An attacker router, present in MANET and
>>>> which generates syntactically correct routing control messages. Control
>>>> messages emitted by compromised router(s) may contain additional
>>>> information, or omit information, as compared to a control message
>>>> generated by a non-compromised router located in the same MANET
>>>> topological position.
>>>>
>>>> Legitimate MANET Router: A MANET router, which is not a Compromised
>>>> MANET Router.
>>>>
>>>> Jamming Attack:
>>>> The attacker transmits massive amounts of interfering radio traffic,
>>>> which will prevent legitimate traffic (e.g., routing and data traffic)
>>>> on all or part of the MANET. Indirect jamming attacks MAY occur by
>>>> influencing Legitimate MANET Router to transmit unnecessary
>>>> information.
>>>>
>>>> Eavesdropping:
>>>> Obtaining a copy by the attacker of the transmitted MANET routing
>>>> information or the transmitted data information from its neighbor's
>>>> transmitted radio packet. Attacker’s processes MANY be used by attacker
>>>> to mislead routing. Eavesdropping does not pose a direct threat to the
>>>> MANET or to its routing.
>>>>
>>>> Identity Spoofing:
>>>> Attacker sends routing messages, pretending to have the MANET identity
>>>> of another node.
>>>>
>>>> Link Spoofing:
>>>> Compromised MANET router sends routing messages to neighbor node(s)
>>>> providing incorrect set of link information.
>>>>
>>>> Replay Attack:
>>>> A Compromised router in one MANET region records control traffic
>>>> information and replays the recorded information in a different MANET
>>>> region (this type of attack is also called the Wormhole attack).
>>>>
>>>> Broadcast Storm:
>>>> Compromised MANET router may attack the MANET by attempting to change
>>>> the MANET flooding algorithm(s) to increase routing overheads or/and to
>>>> increase the route discovery delay. Broadcast storm degrades the data
>>>> traffic delivery and MANET performance.
>>>>
>>>> Falsification in MANET:
>>>> The compromised MANET router sends false routing information into
>>>> MANET.
>>>> False routing information received in MANET, MAY create unrealistic
>>>> information bases.
>>>>
>>>> ICMP Attacks:
>>>> The generation of ICMPv6 error messages may be used by compromised
>>>> MANET
>>>> router to attempt DoS attacks by sending an error-causing source
>>>> routing
>>>> header in back-to-back datagrams. As the ICMP messages are passed to
>>>> the
>>>> upper-layer processes, it is possible to perform attacks on the upper
>>>> layer protocols (e.g., UDP, TCP). Protocols at the upper layers are
>>>> RECOMMENDED to perform some form of validation to ICMP messages (using
>>>> the information contained in the payload of the ICMP message) before
>>>> acting upon them.
>>>>
>>>> Source Routing Attacks: TBD
>>>>
>>>> Acknowledgments:
>>>>
>>>> This work has used/modified terms of the following documents: RFC2462,
>>>> RFC2501, RFC3561, RFC3626, RFC3753, RFC4728, RFC4861, RFC5444,
>>>> RFC6130,  RFC6621, [AODVv2], [OLSRv2], and [HERBERG],
>>>> Gratefully acknowledge to the IETF community and all contributions.
>>>>
>>>> Reference:
>>>>  [HERBERG] Herberg, U., Yi, J., Clausen, T.,"Security Threats for
>>>>            NHDP", Work in progress, March, 2012.
>>>>  [ANJUM]   Anjum, F. and Mouchtaris, P. "Security for Wireless Ad Hoc
>>>>            Networks", John Wiley & Sons, March 2007.
>>>>            ISBN: 978-0-471-75688-0.
>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>
>>>> I hope to get some advise from the Internet community to make the
>>>> definitions more suitable/accurate, because I MAY misunderstood.
>>>> Thanking you,
>>>>
>>>> Best Regards
>>>>
>>>> Abdussalam Baryun
>>>> University of Glamorgan, UK
>>>> =====================