From: vjs@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.
>> >> 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.
>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.
> 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.
>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.
>> 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.
Vernon Schryver vjs@rhyolite.com
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
