Hello Jari,
Thank you very much for this clarification. Jari Arkko wrote: >> I looked at a lot of stuff, but that's the only one I saw, >> even though it can be dressed up in different ways. >> What else is there? > > I think you are right Charlie, that is the only downside. > (There's a bunch of other downsides related to fixing > with AAA the hole HAO leaves in ingress filtering, but > that's another issue.) AAA for IPv6 is, indeed, quite another problem domain, and one for which we've hardly started considering the issues. > The primary danger of unconstrained HAO is having even a small > number of attackers spoof HAOs and use a large > number of CNs as reflectors to attack a specific > target even if your network has ingress filtering. > Basically, it voids ingress filtering. Here, I disagree, although I clearly understand why you would say that. 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. > 2-way i-trace would still detect the source of these attacks, at least > in some cases. However, my concern is that i-trace isn't ready, > isn't deployed and frankly I don't really believe it being deployed > anytime soon. A hypothetical "Care of Address Option" for MIPv6 > would have the same detection power. The trouble with both of > these as opposed to ingress filtering is that they act after the attack > is done or over, while ingress filtering prevents attacks. But the larger problem is that we are being fantastically careful about avoiding a possible future problem that is: 1) solvable in a backwards compatible way 2) not so horrible, 3) delaying by years the specification, and consequently 4) causing other design dislocations in, e.g., 3G. --------------------------------- 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. 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. 2) The ingress filtering router can strictly limit the number of HAOs transmitted from any particular subnet prefix per unit time (*). These are the first things that come to mind, and I believe they are quite simple to implement. (1) certainly is. 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. Regards, Charlie P. -------------------------------------------------------------------- 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] --------------------------------------------------------------------
