Subject: Re: [manet] Forwarding AODV messages over a tunnel

From: Ulrich Herberg <[email-masked]>
Date: Wed, 5 Jun 2013 10:23:35 -0700

Thomas,

(replying to [email-masked], which I think is the better place to ask
this question rather than [email-masked])

What kind of tunnel do you want to use? IP-in-IP tunnel or L2 tunnel
or something else (IP-over-foo)?
In either way, reactive MANET protocols (as well as the proactive
ones) forward messages hop-by-hop, using a link-local multicast
address. If you use an IP-in-IP tunnel or L2 tunnel, the control
message would not be modified, and to the MANET protocol it would look
like a single hop (hop-count++, IP src address = tunnel start point).

Side-note: a wormhole is itself just a normal link; I don't see a
difference between a "legitimate" link/tunnel and a wormhole, unless
the wormhole does something "bad" with the actual data (dropping
packets, eavesdropping, advertising wrong link metrics etc).

Best regards
Ulrich

On Wed, Jun 5, 2013 at 4:39 AM, Thomas Meier <[email-masked]> wrote:
>
> Hello,
>
> I want to forward AODV messages over a tunnel (don't worry, it's not for a wormhole attack).
> In the RFC3561 I can't find information about how to deal with the packet at the tunnel endpoint. Should I increment the hopcount of a RREQ by one or by the number of hops the tunnel has? Furthermore I'm wondering about which address to use for the previous node at the tunnel endpoint. Should this be the entrance of the tunnel or the "real" previous node?
> If the tunnel entrance is used as previous node and the hopcount is only incremented by one, the tunnel would be prefered compared to a connection without a tunnel (like in wormhole attacks).
> Is there some information on how to deal with a tunnel?
>
> Thanks,
>
> Thomas

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 6 Jun 2013 12:11:19 +0100

I do think this is an interesting question. I think what Thomas is talking about
is running AODV (or any other MANET routing protocol) over a "virtual
adjacency".

Such techniques do, of course, exist in other routing environments and they
cause interesting issues (such as tromboning) if the cost of the virtual link is
not set carefully with consideration of the underlying hop costs, or if careful
(policy-based?) decisions are not made about what traffic can be forwarded on
the tunnel versus the native network.

Ulrich's questions seem quite relevant in that context: what, how, why? :-) It
seems hard to give a simple and definitive answer to a very open question.

Thomas, a normal way to proceed at this point would be to write up the use-case
and motivations for what you are considering and put them in a short
Internet-Draft. The working group can then consider them properly. We might end
up with a little advisory RFC.

Thanks,
Adrian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Ulrich Herberg
> Sent: 05 June 2013 18:24
> To: Thomas Meier
> Cc: [email-masked]
> Subject: Re: [manet] Forwarding AODV messages over a tunnel
> 
> Thomas,
> 
> > In the RFC3561 I can't find information about how to deal with the packet at
the
> tunnel endpoint. Should I increment the hopcount of a RREQ by one or by the
> number of hops the tunnel has? Furthermore I'm wondering about which
> address to use for the previous node at the tunnel endpoint. Should this be
the
> entrance of the tunnel or the "real" previous node?
> > If the tunnel entrance is used as previous node and the hopcount is only
> incremented by one, the tunnel would be prefered compared to a connection
> without a tunnel (like in wormhole attacks).
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 11 Jun 2013 17:40:34 -0700

Hello Thomas,

AODV and other Manet protocols do not impose any restriction on
choice of tunnel mechanism to my knowledge, so basically I agree
with Ulrich.  However, some tunneling mechanisms impose their
own restrictions, and one could imagine defining a tunnel protocol
with unusual conditions.  Depending on the choice, it is likely that
error conditions will be handled differently, or fragmentation, or
perhaps QoS restrictions would come into play.

If someone wanted to go to the trouble of using tunnels to
circumvent hopcount restrictions, I don't think there would be
anything to prevent that.  But, on the other hand, a malicious
router could just set the TTL to be any arbitrary value, so this
might be an unproductive use for a tunnel.

Regards,
Charlie P.

-- 
Regards,
Charlie P.