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

From: "Richard Draves" <[email-masked]>
Date: Wed, 12 Sep 2001 22:25:21 -0700

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

---

From: [email-masked]
Date: Thu, 13 Sep 2001 15:15:48 +0900

>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.

itojun

---

From: Pekka Savola <[email-masked]>
Date: Thu, 13 Sep 2001 10:28:43 +0300 (EEST)

> packet to another node via the same interface by which it arrived.

[snip rule 2]

> introduces no loss of security.

I don't think this is enough.

I'm not sure what you mean by round-trip traceroute, but I'm assuming it's
probably like normal traceroute (increasing hop count), where you can send
an additional packet to the intermediate router using routing header, to
see what the return path from it is.

If the intent is to send the packet with huge TTL to the destination
directly, possibly with routing header, I don't see much "traceroute" in
it, more like ping.

The diagnostic uses don't seem interesting IMO here, as you can
(assumedly) do round-trip traceroute to the next-hop router of the
destination host.  From there, the latency etc. changes should be minimal,
and the patch symmetric assuming same-interface rule stands.  So, I can't
see much use for the diagnostic argument if it's assumed that routers
enable source-route forwarding by default.

"Local forwarding" _does_ cause a loss of security, depending on the
policies.  There are two kinds:
 1) any host can use used as a traffic reflector
 2) (more important) it can be used to avoid (simple) access-lists

Of 2), I've already given an example, but I'll add it here again:

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.

Not Good.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Francis Dupont <[email-masked]>
Date: Thu, 13 Sep 2001 14:40:58 +0200

In your previous mail you wrote:

   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 suggest two separate restrictions on Routing Header processing.

=> 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 agree (note the destination can't reply because its address has
not enough scope).

Regards

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Thu, 13 Sep 2001 14:44:23 +0200

=> for mobile IPv6 the source routed packet is not forwarded so rule (1)
doesn't apply. Is it more clear now?

Regards

---

From: Michael Thomas <[email-masked]>
Date: Thu, 13 Sep 2001 08:10:14 -0700 (PDT)

> 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.

   (is this a really dumb question for a well known attack?)

 > the new destination address has scope equal or greater than the old

   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.

	Mike

---

From: Vladislav Yasevich <[email-masked]>
Date: Thu, 13 Sep 2001 11:54:41 -0400

>  In your previous mail you wrote:
...
> forward) is still valid for source routes. Any opinion/good argument?

I agree.  I don't think a host should be doing any forwarding unless
explicitly configured to do so.  In the case of Mobile IP, the mobile
is not really doing "forwarding" (however it may be implemented as such)
since both the COA and HA are assigned to the mobile node.

> => I agree (note the destination can't reply because its address has

In this case, the final destination can't reverse and use the source route
so this would need carefull wording.  The node may end up sending a beyond
scope icmp message following this rule.

-vlad

-- 
++++++++++++++++++++++++++++++++++++++++++++++++++++
Vladislav Yasevich		Tel: (603) 884-1079
Compaq Computer Corp.		Fax: (435) 514-6884
110 Spit Brook Rd ZK03-3/T07
Nashua, NH 03062
--------------------------------------------------------------------
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]
--------------------------------------------------------------------