In your previous mail you wrote:
> Routing header won't scale to real policy routing, I think (nice way to
> test and debugging of course).
>
> => I disagree (about the scaling problem, no about the fact source routing
> 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".
=> try any correspondent node for mobile IPv6 (routing optimization
is just doing that :-).
As it is now, the application has to set routing header. That is not
scalable.
=> I agree but this is easier to add in kernel than IPsec for instance.
> 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).
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
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..
=> a billing system is not a necessary condition (but it is a sufficient one)
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.
=> 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.
> > 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)?
>
> 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.
The change makes sense though.
=> we agree (:-).
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.
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!
> 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.
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'.
> 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).
>
> => 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.
> => 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.
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.
> SHOULD in 2), at least, is debatable.
>
> => no because the rule I want is MUST NOT (:-).
You mean MUST NOT be disabled by default?
=> yes.
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]
--------------------------------------------------------------------
