if some platforms receive a SRC routed datagram, implement the option, and don't use the recorded route as the return path, they're breaking the RFC.
quoting RFC-1122, section 3.2.1.8 (c)
(c) Source Route Options
A host MUST support originating a source route and MUST
be able to act as the final destination of a source
route.
If host receives a datagram containing a completed
source route (i.e., the pointer points beyond the last
field), the datagram has reached its final destination;
the option as received (the recorded route) MUST be
passed up to the transport layer (or to ICMP message
processing). This recorded route will be reversed and
used to form a return source route for reply datagrams
(see discussion of IP Options in Section 4). When a
return source route is built, it MUST be correctly
formed even if the recorded route included the source
host (see case (B) in the discussion below).
An IP header containing more than one Source Route
option MUST NOT be sent; the effect on routing of
multiple Source Route options is implementation-
specific.
Section 3.3.5 presents the rules for a host acting as
an intermediate hop in a source route, i.e., forwarding
Internet Engineering Task Force [Page 36]
--------------------------------------------------------------------------------
RFC1122 INTERNET LAYER October 1989
a source-routed datagram.
DISCUSSION:
If a source-routed datagram is fragmented, each
fragment will contain a copy of the source route.
Since the processing of IP options (including a
source route) must precede reassembly, the
original datagram will not be reassembled until
the final destination is reached.
Suppose a source routed datagram is to be routed
from host S to host D via gateways G1, G2, ... Gn.
There was an ambiguity in the specification over
whether the source route option in a datagram sent
out by S should be (A) or (B):
(A): {>>G2, G3, ... Gn, D} <--- CORRECT
(B): {S, >>G2, G3, ... Gn, D} <---- WRONG
(where >> represents the pointer). If (A) is
sent, the datagram received at D will contain the
option: {G1, G2, ... Gn >>}, with S and D as the
IP source and destination addresses. If (B) were
sent, the datagram received at D would again
contain S and D as the same IP source and
destination addresses, but the option would be:
{S, G1, ...Gn >>}; i.e., the originating host
would be the first hop in the route.
At 16:11 6/7/2001 +0200, Marius Huse Jacobsen wrote:
>> > That is, it should replace the source addr with a spoofed one, and add the
>> > real one as a source route.
>>
>> That implies that you're trying to spoof your source address, and get the
>> victim machine to source-route back [to|through] the real attacker IP.
>> It doesn't work that way. Only the originator of a packet gets to specify
>> that source routing is on. I know of no way to force a victim to use
>> source routing.
>
>I believe at least some platforms place source routing opposite to the one
>used in the original packet. Which means they will more or less reverse the
>path taken by the original (attacker) packet.
This archive was generated by hypermail 2b30 : Sun Jun 10 2001 - 11:46:58 PDT