In your previous mail you wrote:
> A flag will not, but how the flag would be set for hosts by default would
> :-)
>
> => where in RFC 2460 you have read that. I am still looking for this kind
> of statements and I can't find it.
the spec talks about node. Hosts and routers are both nodes.
=> the problem is not node or host, it is with a requirement you can find
and I can't find.
> .. 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.
>
> => 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.
Please also see above; why nobody bothered to do any checking for IPv4
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, ...
> 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!
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).
> - 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...
Only problem with this is that I fail to see how you _really_ could
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 (:-).
In general, short of the MN problem above these sound rather good.
=> 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).
Only, I would want to have something like this implemented in every router
=> no, the job of a router is to route <dot>
(which would make the behaviour rather close to "disable by default",
=> it is disabled if not justified, exactly what we can expect from
a firewall, isn't it?
except by mobile ipv6, if the problems can be identified).
=> 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
[EMAIL PROTECTED]
PS: I am surprised nobody else takes part in the discussion.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
