Erik, (sorry omitting you from to-field) > > My point was that even though firewall would not know, if we have > > enforcement of the "host-check" rule [cf. Pekka's mail for its decoding], > > in all nodes _receiving_ the routing header, this would be a distributed way > > of enforcing the conditions we discuss. > > Yes, if you make all hosts and routers inside the firewall have that check > you'd be fine. > > Two issues: > 1. the firewall might not want to trust all the internal hosts and routers > to be correctly configured with such a rule.
True. However, to use general source routing, you may need such configuration anyway. > 2. I think this would prevent using routing headers for their general use > for traffic that is local to the domain inside the firewall. If the forwarding source routers do have the host-check rule disabling as an option, they'd need to do further checking for legal destinations to enforce locality you mention. Otherwise packets won't always stay local to the domain. But as said, the distributed approach is one option. > So it seems like if these should be the default rule for all hosts and routers > we've effectively redefined the type 0 routing header to be only useful > for MIPv6. And if it isn't the default then issue #1 is definitely present. > > Sounds like if there are strong arguments for this level of security > it would be politer to define a new header than cripple the general usability > of the routing header. Given the distributed scheme I sketched, it would give all possibilities to do source routing, routing forwarders would just need to locally allow for source routing and have appropriate restrictions not to source-route anywhere. I'd not call this crippling but insertion of distributed protection that would allow a more controlled source routing. Analogous would be to allow web access to a server inside, you must locally ensure the server does not crash and let root shells run in it. This would also possibly be doable in a firewall, but currently the control is usually done watching all your reachable web server have current patches not to crash. Source routing would be a similar "service" in the distributed model. > > In the distributed approach I was describing, we would need the > > "host rule" to be something to enable or disable in forwarding source > > routers, too. In case source routing would be disabled for the domain, > > they too would disable this. > > We're in agreement on this one. > > > > As Pekka's draft points out this could lack of distinction could > > > be addressed by defining a new type of routing header which is > > > limited to "forwarding" on the same node. > > > > True. This is another way, which is a "cheaper" way than a totally > > new extension header to have the control localized to the firewall. > > For what notion of "cost" do you come to that conclusion? > To me the cost/benefit tradeoff between a new routing header type > and e.g. Deering/Zill tunneling headers isn't obvious. First, the security analysis in mobileip has identified the discussed issues in routing header. They'd be needing attention anyway. MIPv6 would give the opportunity both to have the issues for routing header fixed and to define the forwarding needed by MIPv6 securely, both with the same fix. Also, current implementations already know semantics of routing header, among other thing, already being able to skip an even unknown rthdr type, should this alternative be adapted, and as no new extension headers are needed, less change to base IPv6 implementations. > > So to get more clarity, is the localization (to the firewall) of > > controlling the use of routing header something that you find necessary? > > I honestly don't know. > Pekka brought up the issue - perhaps he can comment? > > The background for this was that allowing generic use of routing headers > is dangerous and is something that firewalls might block. > But I don't fully understand the severity of allowing general use of routing > headers - it does allow a DoS attacker to hide a bit since it could be > present at any previous hop in the routing header. > > > If so, would the use of "type 1" routing header in MIPv6 draft address > > the issue? > > Yes, but is this conceptually simpler than Deering/Zill tunneling? > Easier to implement? Slightly due to the already-known-semantics mentioned above. Also, if this tunneling is not quickly mandated into the standard to all nodes, there will be a big headache adapting it to legacy. > They seem to be about equivalent in these respects as far as I understand > today. This on my opinion requires a closer look. In format, yes, in all the implementation rules discussed here for the current RH/HAO, whether the same rules can be applied to the tunneling and keep the idea of genericity, I am not so sure. Other uses may have constraints conflicting with MIPv6. And finally, a silly question: if they do not have any difference, why can't RH/HAO as well be considered the generic approach usable also elsewhere? > Erik BR, -Jari -------------------------------------------------------------------- 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] --------------------------------------------------------------------
