Subject: RE: (usagi-users 00767) Re: source routing honored by hosts?

From: "Richard Draves" <[email-masked]>
Date: Thu, 13 Sep 2001 13:47:54 -0700

>    After giving this some thought, I think RFC 2460 should be 
> revised to
>    incorporate some security precautions.
> 
> => I agree but this should not be in RFC 2460 (which is a 
> draft standard i.e. not so easy to change BTW).

I don't care much how it ends being standardized.

>    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.
>    
> => this rule is the RFC 1122 local forwarding rule. I 
> proposed something a bit more strict (forbid forwarding)... I 
> don't know if you really open a security hole (I don't 
> believe this is the case), my proposal has the advantage (?) 
> that the host definition (never
> forward) is still valid for source routes. Any opinion/good argument?

I just looked at RFC 1122 section 3.3.5 and indeed my proposal is
basically its "local source-routing". The only difference is that for
IPv6 I think we need to allow source routing between interfaces within
the host, for Mobile IP.

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-masked]
--------------------------------------------------------------------

---

From: "Richard Draves" <[email-masked]>
Date: Thu, 13 Sep 2001 13:09:50 -0700

> >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.
> 
> 	for mobile-ip6, i don't think there's a requirement to put
> 	care-of address and home address onto the same 
> interface.  forwarding
> 	from care-of to home address may not be considered an "output"
> 	in some stacks.  therefore, i guess rule (1) should be augmented
> 	to cover other implementation choices.  "another node" 
> in the text
> 	looks confusing for me.

I agree, there is no requirement to assign the care-of address and home
address to the same interface and many implementations will in fact
assign them to different interfaces. The rule does not prevent
forwarding that is internal to the node - the "same interface" clause
applies when forwarding the packet to another node.

Rich

---

From: "Richard Draves" <[email-masked]>
Date: Thu, 13 Sep 2001 13:55:06 -0700

>  > 1. When processing a Routing Header, hosts should only 
> forward the  > packet to another node via the same interface 
> by which it arrived.
> 
>    Is this to prevent bypass of firewall access control?
>    If so, why couldn't you just reclassify the packet
>    after you pop the routing header against the firewall
>    rules again? I'd be a little worried about the implications
>    routing loops if you don't follow least cost routing.

The idea is to prevent a multi-homed host from becoming an unintended
conduit for packets between two networks.

I'm not sure I understand your comment about least-cost routing, but
there are already situations where some implementations restrict an
outgoing packet to the same interface as incoming packet. For example
when sending ICMP errors.

>  > 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.
> 
>    Again, this seems to be trying to enforce something
>    from within the routing system which is usually
>    enforced by access control lists at border gateways.
>    IP-IP encapsultation would yield the same result, and
>    it seems to me that you just want to set up a rule
>    at your site border router that just preclude site
>    local addresses from entering the site *regardless*
>    of how they get there. I'm a little worried that to
>    put in half-measures in ipv6's treatment of site/link
>    locals might lull people into a potentially false sense
>    of security if there are other cases which are missed.

It's true there are many pieces that have to be covered to enforce
containment of scope addresses. For example, having routers check the
scope of source addresses. I do not view scoped address containment as
something which is usually enforced by access control lists.

Rich

---

From: "Richard Draves" <[email-masked]>
Date: Thu, 13 Sep 2001 09:53:58 -0700

> 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