> Here, I disagree, although I clearly understand why you would say > that.
Fair enough. Reading on... > The reason I disagree, is that I can specify an augmented > ingress filtering router that will work with HAOs (and, actually, > have already begun to done so). I do understand that such a thing > is harder to build. Furthermore, I am quite reluctant to get > embroiled in a design discussion about building ingress filtering > routers (notwithstanding (*) below), when what I really want to > do is to move the Mobile IPv6 specification forward. Yes. Your approach is a good one, but I think the concern people have is that they are doubtful whether a sufficiently good solution exists. I simply don't believe in the AAA approach to fix this problem, for instance (even if I'm a big fan of AAA for other purposes and even partially behind the Diameter base spec). So, if you were able to give some clue to the plan how what you intend to achieve, perhaps we could go with this approach then. However, for the moment as has appeared such a hard problem to me that I really need to see a some convincing parts of the solution at least before I'd believe this really can be done. > In an effort to be constructive, here are some further ideas about > how to limit the damage from the packet reflection which can be > caused by malicious use of unrestricted HAOs. Excellent! > 1) The correspondent node can strictly limit the number of > care-of addresses available to any one home address (to, > say, one or two). It _could_ even do so for the number > of care-of addresses assignable to home addresses on a > particular subnet, if we wanted to go to the trouble of > putting the prefix length back into the Binding Update. Unfortunately I don't think this will work. One property of the HAO reflection vulnerability is that the number of nodes offering "reflection service" is roughly the size of the IPv6 Internet. So, any rate limitation / address limitation etc will not help if the attacker chooses another CN the next time. > 2) The ingress filtering router can strictly limit the number > of HAOs transmitted from any particular subnet prefix > per unit time (*). This is better than the previous one. But I'm still not too happy with it. How do we ensure that what seems like a small bandwidth at the Nokia Research Group router isn't going to feel like a catastrophy at my home link? And what if everyone in the Nokia Research Group wanted to use HAOs at the same time, would their traffic capacity be cut down too much? What would the value be? What will it require from the router, is state involved or can you do it in stateless way? Also, if the HAO reflection would be used to hide DDoS attack clients in a number of places, rate limitation at single router might not help. > Plus, I believe that, for the purposes of handling HAOs, > we should begin to distinguish between home addresses that > have security associations established with the correspondent > node, and home addresses that do not. It is the latter > variety that need to have the strict numerical limitations. I'll treat this as the third offered solution. Like I think Pekka mentioned some time ago, there's ways of coming up with SAs that don't necessarily live up to this standard, even if such SAs would be useful for e.g. preventing passive wiretapping. But given that Opportunistic IPsec is not deployed much yet, maybe we could put that consideration aside. Perhaps we should then consider a rule that forbids HAOs if there's no SA involved? That would be a possibility. The downside is that you'd still have to provide for bidir tunneling for cleartext communications. Then I could also ask that if you bothered to do 2xRSA+1xD-H and keep at least a few hundred bytes of state at both ends, why couldn't you use RO at that time too? In conclusion I like these ideas better than the AAA approach. However, I still think we'd need something even better to start considering this alternative for real. 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] --------------------------------------------------------------------
