On Tue, 11 Dec 2001, Erik Nordmark wrote: > > However, I don't see this "distinguishability" as a MUST as long as: > > > > 1) MIPv6 MUST NOT require all processing of routing headers be enabled in > > MN's > > Just MNs? Or hosts in general?
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. > It isn't obvious to me from reading RFC 2460 whether a host can drop packets > with routing headers instead of resubmitting them for transmissing to the > next hop. AFAICS, the behaviour when routing header processing is disabled is left undefined. Perhaps an IPv4 analogy would apply. > > 2) MIPv6 MUST require a special case for routing header processing that > > is sufficiently secure. > > > > 3)IPv6 SHOULD/MUST state (given 1,2) that nodes SHOULD NOT/MUST NOT > > enable routing header processing on hosts by default > > > > ( one could argue that currently, RFC2460 requires they must be processed > > [due to MIPv6] -- not all share my interpretation on this ) > > 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. 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. > > That is, if we can say quickly enough "routing headers cannot harm your > > hosts!" they might not be taken as a security threat, and > > distinguishability would not be required. > > > But really, IMO the tougher issue is how HAO will/should be handled. > > Do you see issues with only accepting packets with HAOpt when the receipient > has a matching binding cache entry? > That seems to be the simplest approach to me. > > Of course there are some details e.g. on how the MN discovers that the CN has > garbage collected the BCE but I think an ICMP error can handle that (but > I haven't thought enough about that). I don't see security issues with that. I was worried about the same thing too -- as Michael Thomas also pointed out. This could lead to rather unpredictable behaviour. Getting this robust enough (packets discarded until ICMP is received to notify about this might not be enough) may be challenging. -- 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] --------------------------------------------------------------------
