On Sun, 2 Sep 2001, Francis Dupont wrote:
> In your previous mail you wrote:
> 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...
I don't think we should compare source routing to free tunneling. Free
tunneling is not enabled by default; it has to be administratively
enabled. In IPv6-only networks, free tunneling is not used really.
> 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".
As it is now, the application has to set routing header. That is not
scalable.
> 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. 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..
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.
> > 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?
The change makes sense though.
> 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!)
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.
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.
> 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)
Sure it does:
host1 sends a packet with 'src=host1, dst=rtr3, rthdr=hostX' to
site-internal router, with final destination some box inside the foreign
site.
Now the site's firewall checks that rtr3 is allowed to receive the packet,
for any reason (e.g. ICMP echo).
Packet goes to site internal router rtr3, where it's bounced off to some
site internal box, _to which, if the packet had gone directly_, wouldn't
have been allowed in the firewall.
A breach.
> 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.
Good point, but the rest stands.
> 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?
Sure, we don't want to filter out at least all of them. IMO some (e.g.
echo request) is acceptable under some circumstances. But this goes
beyond ICMP too; basically it's at least at much as you have to allow
access to in your routers from the outside. For the security-conscious,
this might only be ICMP.
> 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. :-)
> 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)
non-local forwarding changes nothing; hosts could still be used as
reflectors.
> 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)
We can improve the security by default from IPv4...
Not many are using source-routing with IPv4 anyway, as most network admins
disable it.
> 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.
I don't see how IPv4 Host/Router requirements set status for IPv6, so _by
the spec_ the status is more like 'MAY for configurable, MUST be allowed
by default on all nodes'.
> SHOULD in 2), at least, is debatable.
>
> => no because the rule I want is MUST NOT (:-).
You mean MUST NOT be disabled by default?
--
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]
--------------------------------------------------------------------
