In your previous mail you wrote:
> => 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.
You could negotiate with your upstream to have routing header forwarding
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.
> => 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.
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.
> => 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?
=> see after.
"Mobile IPv6? We don't need no MIPv6!"
=> I can't parse this.
.. 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.
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
[EMAIL PROTECTED]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
