In your previous mail you wrote:
> > Does disabling routing header break anything significant?
> >
> > => YES, IT DOES!
>
> 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.
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".
=> 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...
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).
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?
=> 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).
Both are important, but source-routing without any controls (esp. if
hosts can forward) is a disaster waiting to happen.
=> 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.
> 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!
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!)
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.
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),
=> 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?
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
1) if the behaviour is configurable, on hosts it MUST default to
disallow.
=> this is too strong, what you want is disabling forwarding (my proposal) or
disabling non-local forwarding (RFC 1122)
2) if the behaviour is configurable, on routers it SHOULD default to
disallow.
=> read RFC 1812 5.3.13.4 which has an explicit MUST NOT disallow
(with DISCUSSION and EDITORS+COMMENTS)
3) if the behaviour is not configurable, on all nodes it MUST default to
disallow.
=> 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
[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]
--------------------------------------------------------------------
