From: spam@bde-arc.ampr.org   
      
   "Vernon Schryver"  wrote in message   
   news:gli094$10fu$1@calcite.rhyolite.com...   
   > In article ,   
   > D. Stussy  wrote:   
   > >> 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).   
   >   
   > I think "scale" is the wrong word.   
   > Besides, where setting the TTL to 1 or, as I wrote, "or whatever," does   
   > not work to prevent the addition of routers, then neither does the   
   > `traceroute` algorithm.  That is because setting the TTL and then   
   > watching for ICMP error messages is what traceroute does.   
      
   OK, but nothing can prevent the insertion of a router.  Regardless, what   
   the OP wants is a way to detect insertion, not prevent it.   
      
   > >> >> 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.   
   >   
   > No, only parts of some paths would get revealed.  For example, traceroute   
   > cannot see routers that do not send ICMP error messages or whose ICMP   
   > messages are filtered by firewalls.  Firewalls that block all ICMP   
   > time-eeceeded messages are broken, but that is not the only reason ICMP   
   > messages are deleted.  Routers connecting segments using RFC 1918   
   > addresses usually need to use those addresses as sources in their ICMP   
   > messages, which makes those messages appopriately deleted in many   
   > situations.   
      
   I never said that it would be universally applicable.  If the OP has any   
   router or host that kills ICMP, that's his problem.  Regardless, if the   
   end-to-end TTL changes, he can still detect that the path was altered.   
   This won't reveal the insertion of a router that creates an equally long   
   path.   
      
   > >Routers do decrement the TTL field.   
   >   
   > No, routers are merely supposed to to decrement the TTL field.  Moreover,   
   > routers can decrement the TTL field by more than one.   
   > The distinction between "supposed to" and does" is significant for those   
   > who don't produce products down to the Microsoft standard of quality.   
      
   Those who know what they're doing follow the standards.  Micro$oft doesn't.   
      
   > >                                     Switches don't.   
   >   
   > That is wrong for the many routers labeled "switches."  For 20 years   
   > the word "switch" has been marketing blather meaning no more than "a   
   > box that shuffles packets faster," and without specifying whatever   
   > might be slower.   
      
   Mislabelling isn't my problem.  Switches and routers are separate things.   
      
   > >True, but it records the route(s) taken, which is what is needed to   
   > >determine if routing has been altered.   
   >   
   > No, traceroute can *sometimes* "determine that routing has been altered."   
   > Again, those whose solutions to computer problems are not down to the   
   > standards established by Microsoft for the least 30 years care about   
   > the cases their solusions don't solve, even if (as is usually true)   
   > their solutions don't solve call cases.   
      
   Pay attention to context and the exceptions I mentioned.   
      
   > >> 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.   
   >   
   > Considerations that might be covered by "physical access" were a   
   > trivial, irrelevant part of what I meant.   
      
   Why?  If the two hosts are in the same location where there's no external   
   network, the only way a router can then be inserted is by physical access   
   to that network.   
      
   Computer security always includes physical access, not merely electronic.   
   Why run a dictionary attack to find an ID/PW pair when one can call a user   
   and ask (obviously tricking the user into revealing access info), or look   
   at the PW written down on some desk drawer (cf. the movie "Wargames")?   
   Physical access may be overlooked but is never trivial.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)