Académique Documents
Professionnel Documents
Culture Documents
security
From: fitz@wang.com (Tom Fitzgerald)
Subject: Re: Source Routing
Organization: Wang Labs, Billerica MA, USA
Date: Wed, 6 Sep 1995 19:17:34 GMT
Message-ID: <DEI09C.BAq@wang.com>
References: <810407791snz@hacknet.demon.co.uk>
Sender: news@wang.com
Nntp-Posting-Host: fnord.wang.com
Lines: 39
Status: RO
When the packet gets to the final destination, the record can tell you a
little more about which interface the packet came into for each router in
the path. It's not terribly valuable (since you've already told the packet
which routers to go through), but it can give you a little more information
about which of several redundant paths was used.....
> When someone ICMP Bombs you how are they to bomb your host as
> I always thought that it was the source that reported wether a
> host is unreachable? But an ICMP bomber can make a destination
> unreachable.. how?
--
Tom Fitzgerald 1-508-967-5278 Wang Labs, Billerica MA, USA fitz@wang.com
Newsgroups: comp.security.unix,comp.protocols.tcp-ip,alt.security
From: vjs@calcite.rhyolite.com (Vernon Schryver)
Subject: Re: Source Routing
Message-ID: <DEIG66.FrL@calcite.rhyolite.com>
Organization: Rhyolite Software
Date: Thu, 7 Sep 1995 01:01:17 GMT
References: <810407791snz@hacknet.demon.co.uk> <DEI09C.BAq@wang.com>
Status: RO
Not so if you have not used source routing or have only used loose
source routing. In those cases, as with `ping -R`, record-route is
very useful. `ping -R` can give information otherwise not available
about the return path. `traceroute -g` can also tell you about the
return path, but only when the IP source route option works.
Only if the system grabs the IP options it receives and uses them
on its own transmissions. Some systems do that, but others do not.
"Lots of protocols" sounds wrong. We have only TCP and UDP to worry about.
Perhaps "protocols" referred to application layer protocols. If so,
the major applications can be compiled to ignore received IP options,
if the operating system does normally turn them around.
Also, you could easily modify inetd or equivalent to dump the received
IP options.
No. It's setuid root so it can change the TTL field in the IP header. This
requires opening a raw socket, which requires root.
>strict and loose source routing are, as you say, in the options field. If i
>remember correctly, you have the routing code, the length, and a pointer to
>the start of the routing data.
--
| Nate Lawson Elite Networking Admin Merced, CA Area's first Internet |
| nate@elite.net (209) 357-4900 Provider.. finger info@elite.net |
-----------------------------------------------------------------------------
Ciao
Jochen
--
Jochen Kaiser Jochen.Kaiser@rrze.uni-erlangen.de
Betreuung Terminal-Server dialinadm@rrze.uni-erlangen.de
Regionales Rechenzentrum Universitaet Erlangen-Nuernberg
>> The record route option is to record the route a packet is taking, it is
>> used by (i think) the traceroute program, which is probably why traceroute
>> is suid root.
Jochen> No ! The Record Route Option is used by most ping implementations when
Jochen> you supply the "-R" Option. Because the record route option offers
Jochen> only place for 9 IP-Adresses in the IP-Header the traceroute cannot
Jochen> make use of it. Traceroute uses ICMP messages with a varying TTL (time
Jochen> to live) - field. The traceroute Program works as follows: When you
Jochen> want the route to a host several hops away, the traceroute sends out
Jochen> an ICMP-Message with a TTL of 1 to that host. The first router on the
Jochen> way gets this message and sees the tiny little TTL. It's an internet
Jochen> standard that TTL of 1 must not be forwarded. Thats why the router
Jochen> throws away the packet and sends back an ICMP - time-exceeded message.
Jochen> The traceroute program gets the ICMP-time-exceeded message and sends
Jochen> out a next ICMP - Messages to the host with a TTL of 2 which passes
Jochen> the first router and is decremented by it by one and passsed to the
Jochen> next hop. This hop sees an TTL of 1 and sends back another
Jochen> ICMP-time-exceeded message .... and so on. The traceroute program
Jochen> collect these messages and gives the user one (!) possibly route to
Jochen> that host.
Mostly right. Traceroute actually sends out UDP datagrams to find a route,
however, and not ICMP messages. The destination UDP port is set to an
unlikely value so the final destination host won't process the packet, but
will instead send back an ICMP port unreachable message. When it gets a port
unreachable, it knows it has reached the destination host.
UDP datagrams are sent out rather than, say, ICMP echo request messages
because an ICMP port unreachable message sends back 8 bytes of the data from
the IP datagram that caused the ICMP error. In this case, those 8 bytes are
the UDP header. Van Jacobson uses a hack: the source UDP port in the messages
traceroute sends out is actually used by his code as an identifier, to allow
more than one use to run traceroute at the same time. Another hack in the
same vein: he increments the destination port with each message to keep track
of what hop he's on. (These are obviously on the order of "very clever"
rather than "awful" hacks).
traceroute makes some of the cleverest use of various ICMP messages I can
imagine. Understand what's going on with traceroute, and you'll be a lot
closer to knowing what's really happening when you send information across the
Internet (or on any tcp/ip network), which is doubtless why Rich Stevens
devotes all of chapter 8 of TCP/IP Ill. Vol 1 to it.