Subject: [manet] NHDP forwarding rules and hoplimit

From: "Teco Boot" <[email-masked]>
Date: Mon, 12 Nov 2007 11:52:44 +0100

Hi,

I checked NHDP on forwarding rules. I think the text is not in line with
PacketBB.
NHDP assumes forwarders understand what messages are and PacketBB defines
the contrary.
NHDP:
   o  HELLO messages MUST NOT be forwarded.
   o  HELLO messages MAY be included in multi-message packets as
      specified in [1].
PacketBB:
   o  A message header format, which may allow a node to make
      praocessing and forwarding decisions based on the node's present
      state and the message header, without inspecting and parsing the
      message body.  Message header information permits single- and
      multi-hop message diffusion.

A solution would be mandating using NHDP messages with hoplimit set to 1.
This option is used in the example in appendix B.

Cheers, Teco

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 12 Nov 2007 10:59:22 -0000

Yes, if an NHDP HELLO message has a header it
should have a hop limit of one, as the example.
There is a little tidying up needed in this
area (and a few others) but revising NHDP
isn't the critcal priority right this minute.
We hope to do it very soon however.

-----Original Message-----
From: Teco Boot [mailto:[email-masked]] 
Sent: 12 November 2007 10:53
To: 'manet'
Subject: [manet] NHDP forwarding rules and hoplimit

               *** WARNING ***

This mail has originated outside your organization,
either from an external partner or the Global Internet. 
     Keep this in mind if you answer this message. 

Hi,

NHDP assumes forwarders understand what messages are and PacketBB
defines

A solution would be mandating using NHDP messages with hoplimit set to
1.
This option is used in the example in appendix B.

Cheers, Teco

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 13 Nov 2007 09:54:36 +0100

Thanks.
I am still worried about the packetBB claim on split in message processing &
forwarding and inspecting & parsing. For example, I don't like leakage of
OLSR information towards DYMO-only routers and forwarded further. Or when an
AreaID TLV is created, TC message leakage into other areas. Or forwarding
messages with incorrect CRC TLV or false authentication TLV. I can imagine
many other evil effects.
Teco.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 13 Nov 2007 09:48:37 -0000

Any actual forwarding would be done by OLSRv2 and/or
DYMO. packetbb doesn't control forwarding (how could
it? - OLSRv2 uses MPR forwarding which packetbb knows
nothing about, as just one example). packetbb just
has the hop count/limit that should be incremented/
decremented (but not by packetbb - there is no packetbb
protocol, just a parser - but by the appropriate
protocol).

Typically if there's an OLSRv2 node, it may or may
not forward a TC message. If there's a neighbouring
DYMO-only node its existence won't encourage OLSRv2
to forward the message (it won't be an MPR) but the
OLSRv2 node may forward it for other reasons. The
DYMO node may then receive the packet with the TC
message in (it's broadcast) but then it's up to DYMO
to do whatever it thinks is appropriate to an unknown
message - which I understand is intended to be discard
it (perfectly allowed, regardless of hop limit). No
problems.

-----Original Message-----
From: Teco Boot [mailto:[email-masked]] 
Sent: 13 November 2007 08:55
To: Dearlove, Christopher (UK); 'manet'
Subject: RE: [manet] NHDP forwarding rules and hoplimit

               *** WARNING ***

Thanks.
I am still worried about the packetBB claim on split in message
processing &
forwarding and inspecting & parsing. For example, I don't like leakage
of
OLSR information towards DYMO-only routers and forwarded further. Or
when an
AreaID TLV is created, TC message leakage into other areas. Or
forwarding
messages with incorrect CRC TLV or false authentication TLV. I can
imagine
many other evil effects.
Teco.