Subject: Re: [manet] #3: Use msg-hop-count in RFC 5444 header to limit # of hops

From: Thomas Heide Clausen <[email-masked]>
Date: Thu, 1 Nov 2012 13:18:26 +0100

That would be a direct violation of the definition of <msg-hop-limit> and <msg-hop-count> in RFC5444, and would render any generic demultiplexing/dispatching/forwarding framework inapplicable.

This proposal is, therefore, not acceptable under any circumstances.

Thomas

Sent from my iPad

On 30 oct. 2012, at 19:07, "manet issue tracker" <[email-masked]> wrote:

> #3: Use msg-hop-count in RFC 5444 header to limit # of hops
> 
> The current AODVv2 specification uses msg-hop-limit to control the
> dissemination of routing messages.  It is proposed instead to use msg-hop-
> count to have a direct hop count for disseminated routing messages, and to
> use a protocol constant to limit the number of hops (e.g., MAX_HOP_COUNT
> == 64).  Even 64 is too much for practically any foreseeable ad hoc
> network.  For networks that need to have finer-grained control (e.g.,
> controlling dissemination to be less than the manifest constant), msg-hop-
> limit could be used for just those messages needing it.  The specification
> can (independently) still specify TTL=255 according to RFC 5082.
> 
> -- 
> --------------------------------+----------------------------------
> Reporter:  charliep@…          |      Owner:  Charlie Perkins
>     Type:  enhancement         |     Status:  new
> Priority:  major               |  Milestone:
> Component:  dymo                |    Version:
> Severity:  Active WG Document  |   Keywords:  hop count, hop limit
> --------------------------------+----------------------------------
> 
> Ticket URL: <http://trac.tools.ietf.org/wg/manet/trac/ticket/3>
> manet <http://tools.ietf.org/manet/>
> 
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 1 Nov 2012 13:50:33 +0000

I must be missing something here. I think I have an idea what it is, but let's confirm.

Let's consider an RREQ message, which is flooded. The issue is, does it mutate on its travels? If not, I don't see why we can't use the 5444 hop limit. If it does, then that is not technically an issue for 5444, but does have two bad effects:
- There is a general processing/forwarding engine described in OLSRv2. In an ideal world this is another thing that should be in a separate draft. It is designed for wider use (hence its inclusion of message type). There are reasons I would find that a good model for what I'm going to call son-of-AODV, whatever that ends up being based on and called.
- Unmutated (other than hop count/limit) messages work well with message signatures described in 6622 for end to end verification. Mutating messages are a bigger headache. They need either new signatures each hop, in which case let's just not bother signing messages, but let's sign packets - a valid choice, but loses a tool - or some sort of difference collecting and aggregating signature that I know nothing about, and may not even exist.

I'm guessing Thomas is against this case. But more details needed. (The IP TTL being a separate issue is I think common ground.)

-- 
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
[email-masked] | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Heide Clausen
Sent: 01 November 2012 12:18
To: [email-masked]
Cc: [email-masked]
Subject: Re: [manet] #3: Use msg-hop-count in RFC 5444 header to limit # of hops

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

Thomas

Sent from my iPad

********************************************************************
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: "Charles E. Perkins" <[email-masked]>
Date: Thu, 01 Nov 2012 10:43:51 -0700

Hello Chris,

RFC 5444 has this:

    o  <msg-hop-count> field, if present, contains the number of hops on
       which the packet has traveled across the MANET.  The <msg-hop-
       count> is set to 0 by the message originator and is used to
       prevent messages from endlessly circulating in a MANET. When
       forwarding a message, a MANET router should increase <msg-hop-
       count> by 1 and should discard the message when <msg-hop-count>
       reaches 255.

 From this, I conclude that the purpose of the field is to count the
number of hops a message has traversed.

Am I missing something?

-- 
Regards,
Charlie P.

---

From: Henning Rogge <[email-masked]>
Date: Thu, 1 Nov 2012 18:45:58 +0100

> number of hops a message has traversed.

If DYMO changes the content of a message, its not the same message
anymore. At least thats how I understand this field.

You could not put a signature on it "end to end" for example.

Henning Rogge
-- 
Steven Hawkings about cosmic inflation: "An increase of billions of
billions of percent in a tiny fraction of a second. Of course, that
was before the present government."

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 01 Nov 2012 11:04:13 -0700

Hello Henning,

RFC 5444 also says this:

    o  For forwarded messages where the message is unchanged by
       forwarding MANET routers, end-to-end authentication and integrity
       MAY be implemented, between MANET routers with an existing
       security association, by including a suitable Message TLV
       containing a cryptographic signature in the message.  Since <msg-
       hop-count> and <msg-hop-limit> are the only fields that should be
       modified when such a message is forwarded in this manner, this
       signature can be calculated based on the entire message, including
       the Message Header, with the <msg-hop-count> and <msg-hop-limit>
       fields set to 0, if present.

I think this means that the msg-hop-count can be incremented while
the other content of the message remains the same.

Regards,
Charlie P.

-- 
Regards,
Charlie P.

---

From: Henning Rogge <[email-masked]>
Date: Thu, 1 Nov 2012 19:05:56 +0100

> the other content of the message remains the same.

Yes... similar to the IP TTL/Hopcount field.

But nothing else. I think the issue was that DYMO is changing the
content of the messages hop-by-hop (the metric value towards to
originator).

Henning Rogge

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 1 Nov 2012 19:17:33 +0000

I agree with the proposal, it seems with advantages, but there maybe
disadvantages (i.e. violation to rfc5444) that need to be fixed. I don't
think it is flexible to use only the hop-limit for rfc5444 messages for
better dissimination, using other fields will give advantages. It may be
considered to modify RFC5444 in future to accomodate reactive
protocols advantages.

AB

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 1 Nov 2012 19:29:15 +0000

Hi Chris

A RREQ as rfc5444 message controlling its dissimination by using hop-count
with hop-limit. OLSRv2 messages SHOULD be handled differently than AODVv2
messages, even if they are both rfc5444 messages, because the protocol that
uses RFC5444 format is the only one that can specify its messages types and
handlings.

I do agree to use of signatures for rfc5444 packets only in AODVv2,

AB

On Thu, Nov 1, 2012 at 1:50 PM, Dearlove, Christopher (UK) <
[email-masked]> wrote:

> Let's consider an RREQ message, which is flooded. The issue is, does it
> mutate on its travels? If not, I don't see why we can't use the 5444 hop
> limit. If it does, then that is not technically an issue for 5444, but does
> have two bad effects:
> - There is a general processing/forwarding engine described in OLSRv2. In
> an ideal world this is another thing that should be in a separate draft. It
> is designed for wider use (hence its inclusion of message type). There are
> reasons I would find that a good model for what I'm going to call
> son-of-AODV, whatever that ends up being based on and called.
> - Unmutated (other than hop count/limit) messages work well with message
> signatures described in 6622 for end to end verification. Mutating messages
> are a bigger headache. They need either new signatures each hop, in which
> case let's just not bother signing messages, but let's sign packets - a
> valid choice, but loses a tool - or some sort of difference collecting and
> aggregating signature that I know nothing about, and may not even exist.
>
> I'm guessing Thomas is against this case. But more details needed. (The IP
> TTL being a separate issue is I think common ground.)
>
> --
> Christopher Dearlove