Subject: RE: [manet] Dymo route discovery

From: "Weber, Michael J. \(US SSA\)" <[email-masked]>
Date: Mon, 23 Apr 2007 14:37:29 -0400

I think it may be helpful to consider the role of the IP stack and the
role of a DYMO process on a node.

As a routing protocol, I think it is DYMO's responsibility to discover
and maintain routes to reachable networks and reachable nodes. DYMO
provides routes that (should) be usable by IP to reach the described
destinations.

As a datagram delivery service, I think it is IP's responsibility to
move datagrams from host to host on a best-effort basis until the
destination host is reached.

It is quite possible that an IP packet addressed to a particular host
address on a network serviced by a router running DYMO is undeliverable
because the host assigned that address is turned off (or otherwise
unavailable) and not because of any routing errors on DYMO's part. In
that case, an ICMP destination unreachable delivered to the originator
of the packet is quite appropriate. We realize, of course, that the
packet never would have reached that final step if not for routes
provided, perhaps fully or in part, by DYMO.

In the reactive routing protocol case there is always the delicate
interface between the IP stack and the routing protocol. The routing
protocol needs a chance to dynamically discover routes, but does not
necessarily want to take over all the responsibilities of the IP stack,
the forwarding engine, and the firewall. These are topics for other
discussions, I believe.

In this particular case I think it is appropriate for DYMO to specify
the messaging required to insure its full and correct operation and for
the IP stack to consume or ignore and generate or withhold ICMP messages
per the site administrator's wishes.
 
Additional comments below.

> -----Original Message-----
> From: Alexandru Petrescu [mailto:[email-masked]] 
> Sent: Monday, April 23, 2007 7:54 AM
> To: Ian Chakeres
> Cc: Alexandru Petrescu; manet
> Subject: Re: [manet] Dymo route discovery
> 
> Ian Chakeres wrote:
> [...]
> >>> I don't see any reason why they couldn't work together, but as I 
> >>> mention I wouldn't suggest it.
> >> 
> >> So one has to _disable_ ICMP DstUnreachable generation code, right?
> >>  That's built-in into the stack.
> > 
> > This is an implementation issue. I myself cannot say how/when ICMP 
> > destination unreachable messages are generated.
> 
> I can say when they're generated: when a packet travelling to 
> a destination hits a router having no route to that 
> destination, and no default route.  Any router will generate 
> such an ICMP DstUnreachable. 
> Do you agree?

Two comments here:

If the router is responsible for the target network for the packet in
question, it may (if so configured) generate an ICMP destination
unreachable if it cannot successfully transmit the packet to the target
host even if a default route is available. This makes sense, because the
default route is only for networks which we do not otherwise know how to
reach, and directly connected networks are always known.

Also, the generation and consumption of ICMP messages can be
site-specific. The common IP stacks I've seen (windows, linux, macos)
can be instructed to disable or ignore receipt of various ICMP messages,
either explicitly or with the aid of firewall filters. Many sites
consider ICMP redirect in particular a security risk and ignore it. It
does not seem beneficial to me to tie DYMO to ICMP's fate in any
particular network deployment.

Best,
Mike

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 23 Apr 2007 22:28:06 +0200

Weber, Michael J. (US SSA) wrote:
> I think it may be helpful to consider the role of the IP stack and 
> the role of a DYMO process on a node.
> 
> As a routing protocol, I think it is DYMO's responsibility to 
> discover and maintain routes to reachable networks and reachable 
> nodes. DYMO provides routes that (should) be usable by IP to reach 
> the described destinations.
> 
>  address on a network serviced by a router running DYMO is 
> undeliverable because the host assigned that address is turned off 
> (or otherwise unavailable) and not because of any routing errors on 
> DYMO's part. In that case, an ICMP destination unreachable delivered
>  to the originator of the packet is quite appropriate. We realize, of
>  course, that the packet never would have reached that final step if
>  not for routes provided, perhaps fully or in part, by DYMO.

I think it makes sense.  It does illustrate however a picture where
end2end communication happens from a host to another host, through
routers that maintain routes with DYMO process and send ICMP
DstUnreachable sometimes.

This is very much inline with how a NEMO moving network is being seen,
hosts not supporting any form of mobility run applications and
intermediary routers support Mobile IPv6 mobility.

I will post separately later of where I see this similarity going.

> necessarily want to take over all the responsibilities of the IP 
> stack, the forwarding engine, and the firewall. These are topics for
>  other discussions, I believe.
> 
>  the messaging required to insure its full and correct operation and
>  for the IP stack to consume or ignore and generate or withhold ICMP
>  messages per the site administrator's wishes.
> 
>> -----Original Message----- From: Alexandru Petrescu 
>> [mailto:[email-masked]] Sent: Monday, April 23, 2007
>>  7:54 AM To: Ian Chakeres Cc: Alexandru Petrescu; manet Subject:
>> Re: [manet] Dymo route discovery
>> 
>> Ian Chakeres wrote: [...]
>>>>> I don't see any reason why they couldn't work together, but 
>>>>> as I mention I wouldn't suggest it.
>>>> So one has to _disable_ ICMP DstUnreachable generation code, 
>>>> right? That's built-in into the stack.
>>> This is an implementation issue. I myself cannot say how/when 
>>> ICMP destination unreachable messages are generated.
>> I can say when they're generated: when a packet travelling to a 
>> destination hits a router having no route to that destination, and
>>  no default route.  Any router will generate such an ICMP 
>> DstUnreachable. Do you agree?
> 
> Two comments here:
> 
> unreachable if it cannot successfully transmit the packet to the 
> target host even if a default route is available. This makes sense, 
> because the default route is only for networks which we do not 
> otherwise know how to reach, and directly connected networks are 
> always known.
> 
>  can be instructed to disable or ignore receipt of various ICMP 
> messages, either explicitly or with the aid of firewall filters. Many
>  sites consider ICMP redirect in particular a security risk and 
> ignore it.

Security risks of Redirect and DDoS ICMP Echo Req/Rep are probably
completely irrelevant threats in a MANET network which is presumably
administered by a same unique administrator/team.  The Redirect and ICMP
Echo Req/Rep DDoS are threats that can _only_ happen in the Internet at
large, where no central administration controls everything.

Not sure there's a threat analysis document for MANET...

> It does not seem beneficial to me to tie DYMO to ICMP's fate in any 

Presented this way, it may make sense.  It depends very much about what
the particular deployment looks like.  I completely agree that
particular deployments have very specific needs, to which some protocols
can fully satisfy.  It may very well be that some particular deployments
are so static that routes are established once, for a long time, and
then change very very little.  Such a deployment will not see any
Redirect and any DstUnreachable for maybe a long time.

Alex

> Best, Mike

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________