From: Kirk Graham (kgraham@instructors.net)
Date: Fri Mar 04 2005 - 23:47:57 GMT-3
Thanks for the updated info John. All of those Operating Systems are ones
that I'd never tested. But it seems I'd done that on a Linux box of some
type before and it responded to every probe. Oh well. Maybe an update or
change in the code.
I did find the traceroute.c source code and see where it says Cisco does
that. My copy of the source code is probably pretty dated.
The reference for ICMP Unreachable rate limiting is in RFC 1812 section
4.3.2.8 if anyone is interested. Its vague and likely to give you a
headache. <g>
A friend of mine believes its a Cisco conspiracy since RFC 1812 was written
by Fred Baker of Cisco systems in order to make their code RFC-compliant.
HAHAHA!
I wonder if my friend believes in black helicopters? <G>
Enjoy,
Kirk!
> Actually... NetBSD supports icmp unreachable rate limiting, as does
> FreeBSD, and Foundry and Juniper and Extreme, Sun and HP use the 'source
> quench' response when they rate limit and, quoting from 'man 7 icmp' on
> a Linux boxen..."
>
> Linux limits the rate of ICMP error packets to each destination.
*ICMP_REDIRECT* and *
> ICMP_DEST_UNREACH* are also limited by the destination route of the
incoming packets."
>
> .... not nearly an all-incluseive list, but I think adequate to
> determine your fingerprinting method might not be quite so accurate. ;)
>
> Also if you take a look at RFC2463 you'll see that when the world goes
> to IPv6, nodes are *required* limit ICMP error messages, including
> unreachables.
>
> Best Regards,
>
> john
>
> Kirk Graham wrote:
>
> >It means that the destination device is a Cisco. Pretty much.
> >
> >I've never found another device that does the same behaviour. Microsoft
> >doesn't. Bay/Nortel doesn't. Cabletron/whatever. None of the *nix
varieties
> >I've tested.
> >
> >I can't remember *which* RFC, but there's one that says something like if
> >you receive two successive UDP packets from the same source IP within
some
> >timeframe, that you do not have to reply to the second packet.
> >
> >If you get no response to a traceroute packet, the IOS displays an '*' to
> >indicate a timeout.
> >
> >So Cisco is following the RFC standards. ITs probably an option thing, so
> >everyone else is as well.
> >
> >Someone else may be able to find the specific RFC reference. Or maybe it
> >was in the traceroute spec. I really can't remember.
> >
> >But its a nice fingerprinting technique! <g>
> >
> >--kg
> >
> >
> >
> >
> >>Hi, dear all:
> >>
> >>I found that there are some "*" in the last line of traceroute result,
> >>
> >>
> >can somebody explain it?
> >
> >
> >>Thanks in advance.
> >>dillon
> >>
> >>
> >>r1#traceroute ip
> >>
> >>Target IP address: 197.68.1.1
> >>Source address: 200.200.200.3
> >>Numeric display [n]:
> >>Timeout in seconds [3]:
> >>Probe count [3]: 6
> >>Minimum Time to Live [1]:
> >>Maximum Time to Live [30]:
> >>Port Number [33434]:
> >>Loose, Strict, Record, Timestamp, Verbose[none]:
> >>Type escape sequence to abort.
> >>Tracing the route to 197.68.1.1
> >>
> >> 1 3.3.13.3 20 msec 24 msec 20 msec 20 msec 24 msec 20 msec
> >> 2 3.3.13.3 20 msec 24 msec 20 msec 20 msec 20 msec 20 msec
> >> 3 3.3.36.6 28 msec 36 msec 24 msec 28 msec 32 msec 24 msec
> >> 4 3.3.36.6 24 msec 32 msec 24 msec 24 msec 32 msec 28 msec
> >> 5 3.3.46.4 44 msec 40 msec 40 msec 40 msec 40 msec 40 msec
> >> 6 3.3.46.4 40 msec 40 msec 40 msec 40 msec 40 msec 40 msec
> >> 7 150.100.2.254 40 msec * 40 msec * 40 msec *
> >>r1#
> >>
> >>_______________________________________________________________________
> >>Subscription information may be found at:
> >>http://www.groupstudy.com/list/CCIELab.html
> >>
> >>
> >
> >_______________________________________________________________________
> >Subscription information may be found at:
> >http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sun Apr 03 2005 - 17:56:41 GMT-3