On Tue, 11 Dec 2001, Erik Nordmark wrote: > > MN's are the only IPv6 hosts that need it right now, AFAIR. > > > > All hosts would also be good, but I'm not sure if there's any _need_ to > > burden IPv6 implementations that don't support MIPv6 at this point. > > But if there is a security issue with mobile hosts forwarding packets > with RH (that contain them as a destination) why doesn't that > concern extend to hosts that don't implement MIPv6?
It does concern them, but I guess I didn't say it clearly: We can tell everyone to disable routing headers in hosts *IF* this particular case is special-handled *where it's used*. Currently, only MN's use it. Therefore implementing this in MN's and switching the default would be the minimal procedure. Hope this clarifies? > > > There is other use of routing headers such as being able to remotely > > > do a traceroute from the other end by source routing the packets > > > through that host. > > > > I'm not sure if that is all that useful, but you're right. There might be > > an exception (as is noted in RFC1122 IIRC) about "local routing headers". > > The check would be made stricter by e.g. requiring to-be-swapped address > > must equal the source address. > > But that wouldn't allow 3rd party traceroute (such as the NOC doing a > traceroute from A to B by source routing packets to B through A). > I have no idea if this is used operationally... Yes it wouldn't, but this kind of traceroute should be done with routers anyway (and this discussion wouldn't apply), or if really careful, the forwarding could be toggled on. > > If one is able to spoof the source address, this could be used for > > anonymous reflection by spoofing source address to be that of the final > > victim. Therefore I don't think this kind of use should be encouraged. > > But it is a bit different than reflection ... in subtle ways. > My brain can't tell if these differences are significant... Yeah, too many reflection attacks :-). Difficult to say whether it's critically different.. but that's one more potential nastie anyway.. > A possible addition would be allowing the CN to sending "binding nack" > when deleting the BCE. > Then the ICMP error would occur e.g. when such a message is lost > or the CN crashes and reboots (i.e. doesn't have the ability to send > a nack). Perhaps those that analyzed the IPSEC behaviour (if it's similar enough) can elaborate on the subject. But I think this is better done in a separate thread, in mobile-ip@ only. -- 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] --------------------------------------------------------------------
