> > My understanding of RFC 2460 is that all nodes, meaning
> both hosts and
> > routers, should process Routing Headers.
>
> It is mine as well, but that still doesn't make it sane or
> safe behaviour; which is why I was gauging opinions on 1) how
> you interpret RFC2460 and 2) how you should implement RFC2460
> wrt. routing headers.
After giving this some thought, I think RFC 2460 should be revised to
incorporate some security precautions. I suggest two separate
restrictions on Routing Header processing.
1. When processing a Routing Header, hosts should only forward the
packet to another node via the same interface by which it arrived.
2. When processing a Routing Header, nodes should compare the scope of
the current and new destination addresses and only forward the packet if
the new destination address has scope equal or greater than the old
destination scope.
The first rule will allow the Mobile IP use of Routing Headers, because
in that case the packet is forwarded from a Care-Of address to a Home
address on the same node. It will also allow diagnostic uses like
round-trip traceroute. Forwarding from an address on one interface to an
address on a second interface and then to a different node via the
second interface is not allowed.
The first rule prevents security problems, in the following sense:
Define N1 to be the set of nodes that can attacker A can reach with a
packet if hosts implement the first rule. Define N2 to be the set of
nodes that A can reach if hosts do not honor Routing Headers at all.
It's easy to see that N1 = N2, ie source routing with the first rule
introduces no loss of security.
The second rule assists applications that may be relying on address
scope. For example an application that is using a site-local address
might assume that packets sent to the site-local address originated
within the site, or similarly packets sent to the loopback address
originated within the node. The second rule prevents attackers from
using source routing to violate this kind of assumption.
Rich
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
