On 28 Jan 2003, Mika Liljeberg wrote: > On Tue, 2003-01-28 at 08:33, Pekka Savola wrote: > > TCP has to be modified anyway, I see no way around that. > > > > Even with RR mechanism, TCP has to be modified to reconnect to the new > > unicast address. This is basically the same. > > Not necessarily. The <anycast,unicast> binding could be stored in the > binding cache as in MIPv6 and TCP could continue using the anycast > address.
That would require anycast be used as source address, or home address option, right? (Plus some modifications in clients etc.) This really should need a bit fleshening up, in a short I-D. > > Actually, there's no need for additional messages at all -- as SYN-ACK > > includes the sequence number sent in SYN as ack number. So there's some > > small proof in this. But then TCP would have to changed to change the > > endpoint address in TCB etc. That's what my proposition tried to avoid. > > Me too. Reconnecting to a unicast address changes the TCB as well. This > is a change in semantics that is visible to applications (unexpected > peername). I'd be hesitant to change API semantics that have remained > the same for the past 20 years. Well, I guess that's true, unless someone invents some nice hack to work around that. I'm not sure how damaging though. > > > Either way, this would still make the TCP "security" weaker, because it > > > would make it possible (by guessing the ISN) to high-jack both > > > directions of a TCP connection, rather than just one. Needless to say, > > > this would be a lot more valuable to the attacker. > > > > Sure.. but consider the big picture. To guess the ISN in the first 3 > > messages would be rather difficult. To know when exactly the source node > > has communicated with an anycast address about equally so (to get into the > > SYN_SENT window for that address). Especially the latter is something > > that off-path attackers should find really difficult. > > I didn't say guessing the ISN or timing the attack would become any > easier. The point is simply that guessing the ISN would now make > applications vulnerable to man-in-the-middle attacks by off-path > attackers. Assuming sufficient ISN randomness, and timing requirements > perhaps this is not a > problem. I agree but I think the total security level is not _all_ that different. > > > However, it would be preferable not to have to have to modify TCP at > > > all. Maintaining the binding at TCP level would simply be a pain. The > > > better option would seem to be to hide the address change from TCP by > > > employing a routing header and something similar to the home address > > > option. Might as well require that all hosts sporting TCP servers at > > > anycast addresses must also support MIPv6. > > > > TCP modifications would be about the same level as with the RR procedure. > > Which is why existing mechanisms (e.g. MIPv6) should be reused rather > than inventing new ones. I'd like to see a roadmap for these. :-) > > MIPv6-like approaches would be one option of course, rather heavy though. > > A light-weight compromise might be to have TCP authenticate the binding, > but use MIPv6 mechanisms for the routing. This would avoid the change in > API semantics as well. > > I have a hard time seeing anycast TCP used in the global network or > beyond selected applications in local networks. That being the case, > requiring that the client hosts to support MIPv6 route optimisation > (with some tweaks) should not be that big a deal. Perhaps not a big deal, assuming every node that should be capable of (anycast) TCP would be able to act as an IPv6 CN.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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] --------------------------------------------------------------------
