Subject: [manet] NHDP Issues- TTL/HopLimit - GTSM RFC 5082

From: "Ian Chakeres" <[email-masked]>
Date: Wed, 6 Feb 2008 12:58:25 +0530

This idea behind using techniques expressed in GTSM (RFC 5082) is to
discard NHDP packets if they have a passed through an intermediate
router. That is, TTL/HopLimit has been decremented from the largest
possible value. By doing this properly, GTSM stops devices off the
local interfaces from being able to pass information to NHDP without
local help.

I believe the modifications are minimal and this security benefit is clear.

Please examine the RFC if you have questions.

Ian Chakeres
_______________________________________________
manet mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/manet

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 6 Feb 2008 09:50:00 -0000

What's the advantage of this over setting the TTL to 1?
(I skimmed the RFC, but haven't read it in detail.) That
seems the natural approach to this, and one we have
implemented.

-- 
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

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: Ian Chakeres [mailto:[email-masked]] 
Sent: 06 February 2008 07:28
To: manet; Thomas Heide Clausen (work); Justin Dean (work); Dearlove,
Christopher (UK)
Subject: NHDP Issues- TTL/HopLimit - GTSM RFC 5082

               *** 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. 

I believe the modifications are minimal and this security benefit is
clear.

Ian Chakeres

********************************************************************
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: "Ian Chakeres" <[email-masked]>
Date: Wed, 6 Feb 2008 17:03:37 +0530

GTSM is about identifying messages that might have been generated off
the local link. If the TTL is 1 this fact does not give you any
assurance that the packet had not been forwarded by a router.

Ian

Note: I did not see any text in NHDP about setting the TTL/HopLimit.
Can you please add that to the document?

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 6 Feb 2008 11:49:22 -0000

Here we are concerned with preventing messages from being
forwarded over a wireless link when they've already been
over a wireless link. Assuming TTL is decremented over a
wireless link, TTL = 1 would accomplish that.

I'm not trying to say GTSM is wrong, just that it's not
the only option. At the NHDP level, what's important
is that HELLO messages aren't forwarded. I'd be happy
just saying that. I could live with GTSM as an example
of how to accomplish that. I'm not sure it's appropriate
to mandate GTSM as the mechanism to achieve that.

(Of course we also have TTL at the packetbb level, and
again I would expect that to be 1, or omitted.)

-----Original Message-----
From: Ian Chakeres [mailto:[email-masked]] 
Sent: 06 February 2008 11:34
To: Dearlove, Christopher (UK)
Cc: manet; Thomas Heide Clausen (work); Justin Dean (work)
Subject: Re: NHDP Issues- TTL/HopLimit - GTSM RFC 5082

Ian

---

From: "Ian Chakeres" <[email-masked]>
Date: Wed, 6 Feb 2008 17:27:48 +0530

GTSM is more about reception of packets than transmission of packets.

A node off the local link could send a packet and it could have TTL=1
(or something else) when received. GTSM attempts to stop this type of
behavior.

Please look at the RFC briefly.
Ian Chakeres