On Mon, 3 Sep 2001, Francis Dupont 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'd bet 99.99% of users don't care about this feature, and 99% of
ISP's neither.
> >
> > Linux and AFAICS, KAME at least let hosts act as "reflectors". I'm sure
> > that's what all would like to do.
> >
> > => please send bug reports!
>
> You want to make them non-compliant with RFC2460?
>
> => 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
:-)
> 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.
>
> => 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.
> 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.
>
> => 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!".
> > 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):
> >
> > => source routing doesn't fool ingress filtering (but home address
> > 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)
>
> => sorry, RFC 2827 gave a very accurate meaning for the "ingress filtering"
> term.
Confused it with terms like 'site ingress', 'site egress' etc. I suppose.
> > => 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. :-)
>
> => they apply until there are the equivalent for IPv6.
Unfortunately, there is no such thing as "Source Route Option" for IPv6.
:-)
> > => read RFC 1812 5.3.13.4 which has an explicit MUST NOT disallow
> > (with DISCUSSION and EDITORS+COMMENTS)
>
> We can improve the security by default from IPv4...
>
> => 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.
--
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 PROTECTED]
--------------------------------------------------------------------
