> host1 --- rtr1 - INET - rtr2 -+- host2 (other scenarios also exist)
> |
> +- host3
>
> Assume that host2 is a web server.
>
> Assume that rtr2 blocks all traffic to port 80, except for host2.
>
> host3 is running an internal/testing web server.
>
> Now host1 can write:
>
> src = host1
> dst = host2
> tcp dport = 80
> routing header = host3
>
> Whoops.. traffic straight to host3 port 80 that was blocked.
This is a good example of a potential problem with source routing, but
it is a weak counter-example to my claim that allowing hosts to process
source routes subject to the "same interface" rule does not introduce
additional security problems beyond what you get if routers process
source routes.
For example, modify the example as follows:
host1 --- rtr1 - INET - rtr2 -+- rtr3 -+- host2
| +- host4, etc
|
+- host3
Where rtr2 has a firewall policy that only allows port 80 towards the
subnet of host2 & host4. Then host1 can construct a source route to
reach host3 where the intermediate address is assigned to rtr3's
interface towards host2.
So my point is that whether or not hosts honor source routes, a firewall
with destination-based policies should be cognizant of Routing Headers.
It's really an orthogonal issue.
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]
--------------------------------------------------------------------
