Subject: Routing Header Considered Harmful

From: Pekka Savola <[email-masked]>
Date: Sat, 1 Sep 2001 17:15:19 +0300 (EEST)

Hello all,

When discussing Linux IPv6 implementation, David Stevens
<[email-masked]> brought up a problem with routing header w/
Hosts.

RFC2460 (The IPv6 Spec) assumes that all _nodes_ (note not routers)
forward source routed packets.

Routing header works so that the next hop is always written to destination
address field and the rest of the path to routing header fields.

Problem with this is that:
 1) it's impossible to authenticate using AH or the like as the header is
rewritten all the time
 2) it allows you to use _any_ IPv6 node to reflect your traffic (, even
to locations that wouldn't normally be routable)

For example:                                or even:

host1 --- rtr1 - INET - rtr2 --- host2       - rtr2 --- host2
                         |     /                |
                        rtr3 -/               host3
                         |
                       host3
                                            or even (same link):

                                             - rtr2 -+- host2
                                                     |
                                                     +- host3

rtr2 performs strict ingress filtering on tcp destination port 80.  host2
is a web server.  (IMO, we _cannot_ assume every device in the path must
be knowledgeable of all the possible extension headers, and implications
of parsing them).

Now host1 could write a packet to dst host2, dport 80, with routing header
to: 'rtr3, host3' (or even just 'host3', there need not necessarily be
rtr3).  (To avoid this, you would have to perform strict ingress filtering
in _all_ of your links, be they internal or not).

Now you can pass traffic unmolested to internal hosts.  Or even John Doe
in the Internet!

Needless to say this will result in very, very much ugliness sooner or
later!

There is no reason to believe IPv6 Routing Header is any better from
security point of view than IPv4 source routing.  And IPv4 source routing
is disabled, luckily, very often.

This won't help:

--8<--
Security Considerations

   The security features of IPv6 are described in the Security
   Architecture for the Internet Protocol [RFC-2401].
--8<--

At this point one could say a classic "WTF? Over."  With this important
core protocols, we definitely _must not_ hide _all_ the security
considerations under the carpet by ambiguous reference to the ipsec
security pixie dust.

More discussion on approaches to tackle this is needed, but IMO:

Forwarding datagrams with Routing Header SHOULD be configurable.

On Hosts, Routing Header MUST be ignored by default.
On Routers, Routing Header SHOULD be ignored by default.
 (I'd only recommend allowing routing header on in backbone routers)

Does disabling routing header break anything significant?  If it does, the
security of that must be analyzed as well.

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

--------------------------------------------------------------------
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: Sebastien Roy <[email-masked]>
Date: Sat, 01 Sep 2001 11:06:41 -0400

>  1) it's impossible to authenticate using AH or the like as the header is

AH has provisions for mutable but predictable data such as the
contents of routing headers.  See rfc2402 Appendix 2.

-Sebastien

---

From: Francis Dupont <[email-masked]>
Date: Sat, 01 Sep 2001 18:28:39 +0200

In your previous mail you wrote:

=> this is not true, hosts are not supposed to forward source routed
packets to other nodes. Many implementations have a flag which enforces
this behavior by default because disabling source route breaks things
and enabling forwarding breaks security).

=> this is not true (and AH authenticates routing headers, rewritting
doesn't matter because it is predictable).

=> this is not true if RFC 2460 section 8.4 is correctly implemented.

   For example:                                or even:

                                                - rtr2 -+- host2
                                                        |
                                                        +- host3

   
   
=> host2 should drop the packet on the floor.

   There is no reason to believe IPv6 Routing Header is any better from
   security point of view than IPv4 source routing.

=> I disagree, read RFC 2460 section 8.4 (or better, ask your implementors
to apply it :-).

   And IPv4 source routing is disabled, luckily, very often.
   
=> I am against this opinion that suggests to remove all devices which
can give a security issue if misimplemented. This is not really better
than the opposite (cf. active "attachement" discussions).

   This won't help:
   
   --8<--
   Security Considerations

   
=> I disagree (again). The security features of IPv6 are simply IPsec.

   
=> I agree, in fact I believe all generic node (i.e. host and router)
implementations have some flags to control this.

=> I disagree because of:

   Does disabling routing header break anything significant?

=> YES, IT DOES!

   If it does, the security of that must be analyzed as well.
   
=> it was and it will be but the security argument should be applied
against two address pseudo-firewalls, not against source routing.
And if you need something to have nightmares this night, just look at
the home address option (same property than a one address source route,
but on the source address in place of the destination) or tunnelling,
esp. ngtrans devices which can hide both the real source and destionation
addresses without trails...

Regards

[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Sat, 1 Sep 2001 19:53:26 +0300 (EEST)

> and enabling forwarding breaks security).

Please read RFC2460 4.4.  Nowhere does it say that hosts should not
forward source-routed packets.  E.g.:

   If, after processing a Routing header of a received packet, an
   intermediate node determines that the packet is to be forwarded onto
   a link whose link MTU is less than the size of the packet, the node
   must discard the packet and send an ICMP Packet Too Big message to
   the packet's Source Address.
   [...]

note 'node' not 'router'; also forward 'forward'.

> doesn't matter because it is predictable).

Ok granted, this can be done, but intermediate nodes should at least check
for the existance of AH.

> => host2 should drop the packet on the floor.

No. AFAICS, RFC 2460 8.4 applies only to the end-node, here host3,
replying to the packet:

   When an upper-layer protocol sends one or more packets in response to
   a received packet that included a Routing header, the response
   [...]

Response in my book means the final endpoint, not a router or host
forwarding the packet to the next hop.

Please also note:

   When an upper-layer protocol sends one or more packets in response to
   a received packet that included a Routing header, the response
   packet(s) must not include a Routing header that was automatically
   derived by "reversing" the received Routing [...]

forwarders don't reverse the order for their "responses" (which aren't
responses as meant here) (unless they send out some ICMP6 messages, but
that's a different story), which implies that response is one sent by the
final destination.

Thus here, if there is no AH, the packet could go:

packet: host1 -> rtr1 -> ... -> rtr2 -> host2 -> rtr3 -> host3 (with
routing header)
response packet: host3 -> rtr3 -> rtr2 -> ... -> rtr1 -> host1 (without
routing header)

The defenses have been penetrated in this scenario; the return traffic can
flow in asymmetric fashion.

> => I disagree, read RFC 2460 section 8.4 (or better, ask your implementors

Please read it again keeping in mind what 'response' means.

> => I disagree (again). The security features of IPv6 are simply IPsec.

One can not say there aren't security considerations to the routing header
use.  IPSec can help with them, but unless they're identified, it's just
some "magic" that may give a warm fuzzy feeling.

>    Does disabling routing header break anything significant?

Please elaborate.  Something related to Mobile IPv6?  They should be using
AH anyway.

> addresses without trails...

Most ngtrans methods can be used for some kind of DoS attacks; with some,
you can even disguise yourself pretty well.  These are being worked.

This, on the other hand, gives the malicious party an active and really
configurable to option to really work around even best defenses.

I haven't taken a look at home address option too deeply, but wasn't it
just that Mobile IPv6 was put to freeze due to improper security
considerations?  <shrug>

---

From: Francis Dupont <[email-masked]>
Date: Sat, 01 Sep 2001 20:19:58 +0200

Please read RFC2460 4.4.  Nowhere does it say that hosts should not
   forward source-routed packets.

=> 4.4 just describes how to process a source route header, it doesn't
specify if/why a node should process it. This is implementation dependent
and of course a clever implementer won't blindly forward source routed
packets. Of course the host requirement document should fix that
(as RFC 1122 section 3.3.5). A statement like mine is likely to be in it...
(note that RFC 1122 is applied to IPv6 too for many details, this doesn't
really replace a real spec but it helps (:-), in your case RFC 1122 should
be enough, not a surprise...)

   
=> I can't see the benefit because intermediate nodes won't be able to
verify the AH (authenticated source routing is known to be unfeasible
with IPsec, just check IPsec mailing list archives).

   
=> 8.4 is for the final destination. Your issue is with an intermediate
destination which is a host. If it doesn't forward packets there is no
problem, isn't it?
   
   >    Does disabling routing header break anything significant?
   
   Please elaborate.

=> any device which needs to set the path followed by a packet:
 - mobile IPv6 routing optimization (a case of source route without
   forwarding)
 - some multihoming solutions
 - policy routing
etc.

   Something related to Mobile IPv6? They should be using AH anyway.

=> no, mobile IPv6 doesn't mandate AH for every packets!

=> this is more serious issue than source routing, and the fix is
not easy.

   considerations?

=> no, for improper solution to security considerations (even I personally
believe more work is needed for the home address option).

Regards

PS: is my proposed fix for the future host requirement document enough
for you? (for other implementors) is it acceptable? is it already what
you do (or would like to do)?
--------------------------------------------------------------------
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: Pekka Savola <[email-masked]>
Date: Sat, 1 Sep 2001 22:05:56 +0300 (EEST)

> be enough, not a surprise...)

All too true.  Why would anyone want to comply with the standards anyway?
;-)

> with IPsec, just check IPsec mailing list archives).

It cannot be verified, but at least it would ensure the sender is serious
about getting the source-routed packet through.  This would avert
implementations that don't require AH to be used for source-routed
packets, not too bright crackers, etc.

But now I agree that this would probably just add unnecessary, imperfect
overhead (at least with the current AH usage guidelines).

> destination which is a host. If it doesn't forward packets there is no

Most, and worst problems are avoided, see below.

>  - some multihoming solutions

One could argue whether IPv6 header is the right place for routing
decisions, rather than the routing system itself.  At least when there
aren't secure guidelines on which routers can safely be used as "beacons".

Routing header won't scale to real policy routing, I think (nice way to
test and debugging of course).

All in all, most of these seem to be scenarios where you know beforehand
which routers (or at least, which group of routers) you're going to use as
source-routing hops, right?  So negotiating beforehand that source-routing
will be accepted would be acceptable?

> => this is more serious issue than source routing, and the fix is

DoS is always possible.  It's boring, nasty or really nasty. Really nasty
issues with ngtrans methods are being plugged, I hope, but some nasties
will remain.

In the end, they're only DoS attacks, though.  In most cases they cannot
be used to map your internal network, go around firewalls, bounce exploit
traffic off real routers.

Both are important, but source-routing without any controls (esp. if
hosts can forward) is a disaster waiting to happen.

> believe more work is needed for the home address option).

Sigh.. I really hoped I wouldn't need to muck with Mobile IPv6, but
perhaps I'll have to look at it... :-/

> you do (or would like to do)?

Linux and AFAICS, KAME at least let hosts act as "reflectors". I'm sure
that's what all would like to do.

Is it enough in the long term?  Probably not.  As a short term, perhaps
yes.

Issue with the fix is that you can still do nasties, even though _way_
less (as router addresses don't usually have many services which have to
be enabled in site ingress packet filters):

host1 --- rtr1 --- rtr2 --- rtr3  --
                      \              Big internal topology
                       \
                        \-- rtr4  --

Here, you could bounce off with e.g. ICMP echo requests, ICMP PMTU, or
whatever from every site's internal router (even ending to those with e.g.
site-local addresses), and map the network by ICMP unreachables you get
back.

In the long term, I think, this should be all of the below:

 0) Rewriting the header based on routing header SHOULD be configurable
(MAY be per-interface).
 1) if the behaviour is configurable, on hosts it MUST default to
disallow.
 2) if the behaviour is configurable, on routers it SHOULD default to
disallow.
 3) if the behaviour is not configurable, on all nodes it MUST default to
disallow.

SHOULD in 2), at least, is debatable. ( 3) would make about all the
existing implementations non-compliant, big deal :-)

---

From: Francis Dupont <[email-masked]>
Date: Sun, 02 Sep 2001 17:01:23 +0200

=> source routing is more efficient and has less security problem than
free tunnelling. I am afraid that to replace source routing by tunnels
won't improve the security...

=> I disagree (about the scaling problem, no about the fact source routing
is very nice for testing and/or debugging).

=> yes but don't forget that immediate addresses can be subnet-router
anycasts (RFC 2373 2.6.1) so the "or at least, which group of routers"
can be the common case.
Note: source routing with subnet-router anycasts is the best way to
implement the requirement that an user should be able to choose transit ISPs.
I've read this requirement is a legal one in USA (a rule from
the telephony world).

=> you already know my opinion about forwarding by hosts...
IMHO the real cause of disasters is the confusion between ACLs with two
addresses and a real firewall, but this is a general security issue,
source routing is just a piece of it.

   
=> please send bug reports!

   Is it enough in the long term?  Probably not.

=> the long term solution is to use an up-to-date firewall with IPv6 support
(unfortunately the only commercial firewall with IPv6 support I know,
which has support for source-routing and home address option too,
is not yet available... grrr!)

=> source routing doesn't fool ingress filtering (but home address
option does). I can't see your issue.

   site-local addresses),

=> packets with scoped source addresses should not go outside their zone.

   and map the network by ICMP unreachables you get back.

=> this is a firewall problem. And I believe you agree that filter out
ICMPs because they are a potential security problem is not what to do?

=> RFC 1122 3.3.5 and RFC 1812 5.3.13.4

=> this is too strong, what you want is disabling forwarding (my proposal) or
disabling non-local forwarding (RFC 1122)

=> read RFC 1812 5.3.13.4 which has an explicit MUST NOT disallow
(with DISCUSSION and EDITORS+COMMENTS)

=> the current status is MAY for configurable, MUST be disallowed by default
for hosts and MUST be allowed by default for routers.

   SHOULD in 2), at least, is debatable.

=> no because the rule I want is MUST NOT (:-).

   ( 3) would make about all the existing implementations
   non-compliant, big deal :-)
   
=> my implementation has the flag you want (currently it is a not-process
intermediate source routes and its default is process them but I can change
it for what I'd like (i.e. my proposal :-) in some seconds)...

Regards

---

From: Marc Blanchet <[email-masked]>
Date: Sat, 01 Sep 2001 18:49:36 -0400

>Does disabling routing header break anything significant?

used by mobileIP for route optimization (important feature for mobileIPv6).

draft-ietf-mobileip-ipv6-14.txt:

8.9. Sending Packets to a Mobile Node

    Before sending any packet, the sending node SHOULD examine its
    Binding Cache for an entry for the destination address to which the
    packet is being sent.  If the sending node has a Binding Cache entry
    for this address, the sending node SHOULD use a Routing header to
    route the packet to this mobile node (the destination node) by way
    of the care-of address in the binding recorded in that Binding Cache
    entry.  For example, assuming use of a Type 0 Routing header [6], if

>  If it does, the

Marc.

---

From: Pekka Savola <[email-masked]>
Date: Mon, 3 Sep 2001 10:52:09 +0300 (EEST)

> won't improve the security...

I don't think we should compare source routing to free tunneling.  Free
tunneling is not enabled by default; it has to be administratively
enabled.  In IPv6-only networks, free tunneling is not used really.

> is very nice for testing and/or debugging).

I've yet to see an implementation where you could set a system-level flag
"packets matching these criteria should have routing header, going
through hops1,...,N, added to the packets".

As it is now, the application has to set routing header.  That is not
scalable.

> I've read this requirement is a legal one in USA (a rule from

As an aside, I'd like to know if this is really the case.  If this was
true, it should implicitly indicate that there is some direct billing
system (perhaps per-packet, per-byte) in the transit system.  I'm not sure
if that's what we want..

Moreover I don't see why user should be able to select transit systems
unless he's being billed directly by the transit.  The user should be able
to choose his ISP, and via that, the transits, though.

> => please send bug reports!

You want to make them non-compliant with RFC2460?

The change makes sense though.

> is not yet available... grrr!)

I'm not sure if it's the packet filter's (ie: it may not need to be a
"firewall" as such at all -- e.g. your LAN router) job to know of all the
possible wackiness in all the possible extension headers.

If this was assumed, I think the behaviour in firewalls would be a toggle
to drop all incoming packets with routing header.  A simple and elegent
approach, but perhaps not one one would like.

> option does). I can't see your issue.

(sorry if I used 'ingress filtering' improperly; I meant incoming access
list, not necessarily only source-address checks)

Sure it does:

host1 sends a packet with 'src=host1, dst=rtr3, rthdr=hostX' to
site-internal router, with final destination some box inside the foreign
site.

Now the site's firewall checks that rtr3 is allowed to receive the packet,
for any reason (e.g. ICMP echo).

Packet goes to site internal router rtr3, where it's bounced off to some
site internal box, _to which, if the packet had gone directly_, wouldn't
have been allowed in the firewall.

A breach.

> => packets with scoped source addresses should not go outside their zone.

Good point, but the rest stands.

> ICMPs because they are a potential security problem is not what to do?

Sure, we don't want to filter out at least all of them. IMO some (e.g.
echo request) is acceptable under some circumstances.  But this goes
beyond ICMP too; basically it's at least at much as you have to allow
access to in your routers from the outside.  For the security-conscious,
this might only be ICMP.

> => RFC 1122 3.3.5 and RFC 1812 5.3.13.4

I don't think these apply to IPv6.. unless you want them to. :-)

> disabling non-local forwarding (RFC 1122)

non-local forwarding changes nothing; hosts could still be used as
reflectors.

> (with DISCUSSION and EDITORS+COMMENTS)

We can improve the security by default from IPv4...

Not many are using source-routing with IPv4 anyway, as most network admins
disable it.

> for hosts and MUST be allowed by default for routers.

I don't see how IPv4 Host/Router requirements set status for IPv6, so _by
the spec_ the status is more like 'MAY for configurable, MUST be allowed
by default on all nodes'.

> => no because the rule I want is MUST NOT (:-).

You mean MUST NOT be disabled by default?

---

From: Ignatios Souvatzis <[email-masked]>
Date: Mon, 3 Sep 2001 12:02:35 +0200

> note 'node' not 'router'; also forward 'forward'.

note "intermediate". Mere hosts are by definition never intermediate.

	-is

---

From: [email-masked]
Date: Mon, 03 Sep 2001 19:14:26 +0900

>address field and the rest of the path to routing header fields.

	I briefly remember that:
	- I (or jinmei) asked this question to Steve Deering and
	- he responded that it is intentionally specified as "node".
	I don't remember the reasons.  Steve, are you there?

itojun

---

From: Francis Dupont <[email-masked]>
Date: Mon, 03 Sep 2001 17:09:41 +0200

=> try any correspondent node for mobile IPv6 (routing optimization
is just doing that :-).

=> I agree but this is easier to add in kernel than IPsec for instance.

   > I've read this requirement is a legal one in USA (a rule from
   
   As an aside, I'd like to know if this is really the case.

=> does someone in the list know the answer?

   If this was
   
=> a billing system is not a necessary condition (but it is a sufficient one)

=> to have the choice of the transit ISP, not only the first one, is nice.
I'd like to get this feature in the kernel controlled by a policy, today
I have to hack my Cisco config to do the same thing, this is not scalable.

   
=> to add a flag which controls the forwarding of source routed packets
won't make them non-compliant, just a bit more secure. I am afraid you
see requirements in RFC 2460 which are not in it.

=> we agree (:-).

=> yes, it is the job of a real firewall.

=> too simple: Mobile IPv6 people won't be happy!

   
=> sorry, RFC 2827 gave a very accurate meaning for the "ingress filtering"
term.

   Sure it does:
   
=> so your argument is that source routing fools simple incoming traffic
filtering. I agree, this is why I used 'firewall' in place of
'packet filters'.

   
=> they apply until there are the equivalent for IPv6.

   
=> old arguments about IPv4 are still valid for IPv6.
   
   I don't see how IPv4 Host/Router requirements set status for IPv6,

=> IPv6 is not so different.

   so _by the spec_ the status is more like 'MAY for configurable,
   MUST be allowed by default on all nodes'.

=> no, there are not such MAY/MUST in RFC 2460.

   
=> yes.

Regards

---

From: Pekka Savola <[email-masked]>
Date: Wed, 5 Sep 2001 17:08:00 +0300 (EEST)

> I have to hack my Cisco config to do the same thing, this is not scalable.

You could negotiate with your upstream to have routing header forwarding
enabled; I'd bet 99.99% of users don't care about this feature, and 99% of
ISP's neither.

> see requirements in RFC 2460 which are not in it.

A flag will not, but how the flag would be set for hosts by default would
:-)

> => yes, it is the job of a real firewall.

Could you elaborate on what you would consider to be a good sanity check
of routing headers in a real firewall?  Defining this might not be simple,
and thus unlikely to happen at all.

> => too simple: Mobile IPv6 people won't be happy!

If solutions aren't simple enough, people are tempted to _just do it
anyway_.  "Mobile IPv6?  We don't need no MIPv6!".

> => sorry, RFC 2827 gave a very accurate meaning for the "ingress filtering"

Confused it with terms like 'site ingress', 'site egress' etc. I suppose.

> => they apply until there are the equivalent for IPv6.

Unfortunately, there is no such thing as "Source Route Option" for IPv6.
:-)

> => old arguments about IPv4 are still valid for IPv6.

And I thought IPv6 was also supposed to be more secure than IPv4.

.. Unless you have a good suggestion on how to perform routing header
sanity checks in a real firewall, I think we should close this thread.

---

From: Francis Dupont <[email-masked]>
Date: Wed, 05 Sep 2001 18:00:10 +0200

enabled.

=> I should not... Source routing is supposed to be enabled by default on
routers, including my upstream ISP routers. The current situation for
IPv4 is from laziness and FUD, I expect to get something better for IPv6.

   
=> where in RFC 2460 you have read that. I am still looking for this kind
of statements and I can't find it.

   Could you elaborate on what you would consider to be a good sanity check
   of routing headers in a real firewall?

=> see after.
   
   "Mobile IPv6?  We don't need no MIPv6!"

=> I can't parse this.

=> first you have three possible position for a firewall:
 - filtering outbound traffic from your site
 - filtering inbound traffic to your site
 - inside the backbone
For many reasons (speed, lack of good policy, ...), no firewall should be
in the last position. About outbound traffic, I can't see a good reason to
check source routes, so the issue is with inbound traffic.
First you can reject source routed packets with a type != 0, and
accept all with segment left == 0. Other source routed packets enter
in one of three cases:
 - will bounce inside the site: apply a local policy (default is to reject
   packets but if you ask a peer to source route via a specified router (*)
   you may accept only packets via this router for instance).
 - will bounce outside the site: reject them if they are not special cases
   (testing tools for instance). Rate limit them!
 - for mobile node: apply a local policy, for instance detect mobile nodes
   (home address option, binding updates (signaling), explicit negociation
    via AAA (my favorite because it works for home address options too))
   and recognize this case. This scheme has already been implemented
   so I can find more details...
(*) this can happen with site multihoming: an upstream ISP is no more
available, you ask correspondents to add a source route via a router
using an address in an other ISP prefix.

Regards

---

From: Pekka Savola <[email-masked]>
Date: Wed, 5 Sep 2001 20:33:24 +0300 (EEST)

> IPv4 is from laziness and FUD, I expect to get something better for IPv6.

As far as I see, the issues are basically the same.  No one has bothered
to implement the firewall checks for verifying "legal" source-routes from
Source Route options either.

> of statements and I can't find it.

the spec talks about node.  Hosts and routers are both nodes.

>    "Mobile IPv6?  We don't need no MIPv6!"

Cutting out the redneck:  "Mobile IPv6?  We don't need MIPv6!"

Also see below.

> check source routes, so the issue is with inbound traffic.

Please also see above; why nobody bothered to do any checking for IPv4
source routes?  I don't see people would be significantly more
enthusiastic about that with IPv6, _unless_ there are some new killer
applications using it _securely_.

>    (testing tools for instance). Rate limit them!

Basically these cover all significant applications (except MIPv6) where
the packet would still be source-routed anywhere, yes?  (If not, please
elaborate on how multihoming relations could be made abstract enough for a
firewall).

(one exception: if there is AH, return route will be source routed; this
will be ok, as the reflected path will be outside your own jurisdiction
anyway, and authenticated).

>    so I can find more details...

Only problem with this is that I fail to see how you _really_ could
identify mobile nodes?  Requiring state in the firewall for this is
probably unacceptable.

In general, short of the MN problem above these sound rather good.

Only, I would want to have something like this implemented in every router
(which would make the behaviour rather close to "disable by default",
except by mobile ipv6, if the problems can be identified).

---

From: Francis Dupont <[email-masked]>
Date: Thu, 06 Sep 2001 18:09:13 +0200

=> the problem is not node or host, it is with a requirement you can find
and I can't find.

   source routes?

=> because options are not used for IPv4 so they don't matter (why to add
a whole set of rules for 0.001% of the traffic?)

   I don't see people would be significantly more enthusiastic about
   that with IPv6,

=> the situation should be different for IPv6 because the broken in practice
option mechanism has been replaced by the superior extension header
mechanism.

   _unless_ there are some new killer applications using it _securely_.

=> multihoming, mobile IPv6, ...

   Basically these cover all significant applications (except MIPv6) where
   the packet would still be source-routed anywhere, yes?

=> yes (I've described three cases, the last one is MIPv6, so do you
expect another answer? :-)

   (If not, please elaborate on how multihoming relations could be
   made abstract enough for a firewall).
   
=> multihoming stuff will be in the first case (source route for incoming
traffic, home address option for outgoing traffic, both as optimizations
for tunnels).

   identify mobile nodes?

=> I've suggested three different ways.

   Requiring state in the firewall for this is probably unacceptable.
   
=> yes, you need a statefull firewall but a stateless firewall is *not*
a real one, at least you may not say it is a good one (:-).

=> I was involved in a project about secure mobility for IPv6,
one part (not mine :-) was about mobile aware firewalls so
my colleagues had to solve all security issues with MIPv6
(the real problem is with home address options which fool ingress
filtering but MN detection is good for source route filtering too).

=> no, the job of a router is to route <dot>

=> it is disabled if not justified, exactly what we can expect from
a firewall, isn't it?

=> mobile IPv6 is an interesting case because it uses the home address
option which IMHO is more a security problem than source routing.
And mobile IPv6 uses it even without routing optimization, the equivalent
of not using home address option is the reverse tunneling, a kind of
route anti-optimization.

Regards

PS: I am surprised nobody else takes part in the discussion.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 7 Sep 2001 10:48:12 +0300 (EEST)

> => the problem is not node or host, it is with a requirement you can find

Not nearly all cases of the IPv6 specification use "must" clauses, even
though they are clearly required.

A bit tongue-in-cheek now..:

For example, by your analogy, if an implementation might choose to
(ridiculous!) omit Payload Length field altogether(!) or replace it with
something else, it would still be compliant?  There is _nothing_ AFAICS in
the spec that says Payload Length is a _required_ field, or it _must_ be
processed in a certain way.

Back to Routing Header.. there are a few cases which hint at it being
required:

---
   IPv6 nodes must accept and attempt to process extension headers in
   any order and occurring any number of times in the same packet, [...]
---

So IPv6 hosts must accept and (attempt to) process Routing Headers,
regardless of order (order issue not important here)

"Attempt to" is IMO there because:
 1) the implementation must know _how_ to process header, ie. know of
the header type; and
 2) the header fields must be as specified, ie. parseable

---
---

Routing Headers are to be processed, as above, and it's specified how you
must (discard) react on certain failure conditions.  So, if the routing
header is syntactically correct, it appears that hosts must at least send
packet too big messages.

Note that 'intermediate node' is not a (big) contradiction here, as it's
intermediate only in routing header forwarding sense.

> a whole set of rules for 0.001% of the traffic?)

But why they aren't used?  There are mobile ipv4, multihoming, traceroute
etc. solutions very possible for IPv4 too!

One could argue that at least at this point, Routing Headers constitute a
very small percentage of IPv6 traffic also.

> => multihoming, mobile IPv6, ...

Did you forget the last part?  :-) Mobile IPv6 will at least need it.

> => I've suggested three different ways.

Do you have more specific ideas how these could work?

- Home address option: check if it exists (could be added by anyone, isn't
enough)
- Binding updates (requires state)
- Explicit negotiation (requires state to be exported from AAA to
firewall)

> a real one, at least you may not say it is a good one (:-).

Stateful firewall usually creates a SPOF, which may not be acceptable for
multihoming solutions at least.

> => no, the job of a router is to route <dot>

There are different kinds of routers.  I agree with you when "core"
routers are concerned, but "access routers" e.g. of a small-midsize
company (not necessaily even classical "router hardware router") must be
able to perform these checks.

I don't like the idea that everyone should get a big, expensive stateful
firewall if all you want is basic security and stateless access-lists.

---

From: Francis Dupont <[email-masked]>
Date: Sun, 09 Sep 2001 14:25:45 +0200

=> no, nothing without a MUST is clearly required. If I apply your
argument to RFC 791 IPv4 source route processing an forwarding is
mandatory for IPv4 hosts. RFC 2460 defines the processing rule,
it says *nothing* about any requirement for a node to forward a
source routed packet. As I said, RFC 2460 is not a IPv6 node
requirement document.

   

=> I disagree, if you see an outgoing packet from C without home address H
you can decide to accept incoming packet to C with a source route to H.

=> I can't see a problem with state!

=> same.

   
=> I am afraid that you have to accept a single-point-of-failure
if you'd like to get a high level of security. Note that for AAA
the state is not in the firewall, it is in the AAA system.

   
=> I believe a router is a bad firewall (and a firewall a bad router).

   firewall

=> you are not required to pay a lot of money to get a good software (:-).

   if all you want is basic security and stateless access-lists.
   
=> you can't both ask for good security and propose in order to archieve
it basic security and known to be not enough tools.

Regards