From: spam@bde-arc.ampr.org   
      
   "Vernon Schryver"  wrote in message   
   news:glgoi5$2cbs$1@calcite.rhyolite.com...   
   > In article ,   
   > D. Stussy  wrote:   
   > >> on a project where I need to determine the number of hops a connection   
   > >> takes between 2 machines, essentially to eliminate if someone sticks a   
   > >> router between the 2 machines.   
   > >>   
   > >> 1.  Is this pretty easy to do in a small bit of code?   
   >   
   > In general and to really solve that problem, no.   
   >   
   > If the goal is for one machine to try to ensure that a second machine   
   > is connected to the same IP network as the first machine, then the   
   > least bad tactic may be to ask the operating system for the host   
   > addresses and netmasks of relevant network interfaces and then check   
   > that the IP address of the second machine is on one of the connected   
   > networks.   
   > That tactic is vulnerable to proxy-ARP, bridges, and other complications.   
   >   
   > Perhaps the quickest kludge would be to tell your operating system   
   > to use a TTL of 1 (or whatever) on all of the packets you send.   
   > That won't be perfect, but it will work in many cases.   
      
   Connected to the same network is a special case of the question.  However,   
   this approach doesn't scale acrosss networks (or non-bridged network   
   segments).   
      
   > >> 2.  Does anyone have an example of this?   
   > >   
   > >See "traceroute".  Its algorithm does the job.   
   >   
   > Traceroute gives only an approximate number of routers between the   
   > source and destination, and then only in one direction and only for   
   > a sample of the available paths at the instant the measurement is   
   > made.  Traceroute does not necessarily see all routers, not even   
   > for the loose definition of "router" as "box that forwards packets   
   > and decrements the IP TTL field."   
      
   Only in one direction?  Only if implemented on one side.  Should both ends   
   implement a hop-by-hop search for the other host, both paths (i.e. both   
   directions) get revealed.   
      
   Routers do decrement the TTL field.  Switches don't.  However, he was only   
   concerned about routers, so a change in end-TTL will indicate a change in   
   path which may as well be the same as the insertion or deletion of a   
   router - and that's what he's after.   
      
   The traceroute algorithm is what he needs to determine a change in "from   
   host A to B".  A change in incoming (remaining) TTL can detect a change in   
   route from B to A - but is not conclusive as to the insertion or deletion   
   that causes equally distant alternative routes.  Multiple routes of the   
   same distance will be a special case that needs to be handled.   
      
   > Another difficulty with the notion of using the traceroute idea is that   
   > it requires sending packets, waiting for responses, and doing something   
   > reasonable when there are no responses.  Because of the nature of the   
   > packets, the sending and waiting tend to require elevated privileges   
   > on UNIX-like operating systems, which is why /usr/sbin/traceroute (or   
   > wherever) is likely to be set-UID.   
      
   True, but it records the route(s) taken, which is what is needed to   
   determine if routing has been altered.   
      
   > Of course, the algorithm in `traceroute` is related to setting the TTL.   
   >   
   > Before doing anything, it is best to consider the problem being   
   > solved.  If the real problem has anything to do with "security,"   
   > then it is practically certain that the number of routers in the   
   > path is irrelevant.  Real solutions to confidentiality, authentication,   
   > authorization, non-repudiation, no-replay, etc. problems do not   
   > care about the number of intervening routers.   
      
   Agreed.  Physical access is just as important.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)