On 27 Jan 2003, Mika Liljeberg wrote: > > > > I agree with you here .. but ICMP could give you enough strong > > > > authorization with basically zero added messages. > > Not necessarily. If the TCP anycast server were to send the ICMP > back-to-back with the SYN-ACK, any reordering in the network would cause > the TCP client to send back an RST, deleting the TCB at the server. This > would be followed by a SYN retransmission to the anycast address 3 > seconds later. > > If the RST happened to experience a significant delay in the network, > the retransmitted SYN might even overtake the RST, in which case the > newly formed connection would be immediately deleted by the delayed RST. > > This approach would also double the probability of a costly > retransmission in case of packet loss, since losing either the ICMP or > the SYN-ACK would cause a SYN retransmission to the anycast address. > > On the other hand, if the anycast TCP server refrained from sending > SYN-ACK after the ICMP, the TCP client would have to retransmit the SYN > to the new address. > > So, not necessarily zero cost or zero added messages.
Sorry, I left the other parts of the proposal implicit. The idea was the sender sends TCP SYN. The anycast node responds with an ICMP _only_ (not RST, not SYN ACK). When the original sender receives the ICMP message, it resends a new TCP SYN to the unicast address, after verifying the ICMP message's validity from TCP SYN_SENT table (among other things). > > > In order for the client to verify the authentication information in > > > the ICMP message, we would need a key distribution mechanism. > > > > No. ICMP would contain critical parts of the TCP header, including TCP > > sequence number. This, and the state the initiator has about that > > particular connection would be enough. > > This smacks too much like a layer violation to me. If TCP must be > modified to support this, might as well go all the way and do it as a > TCP SYN option that is legal with SYN-ACK only (although that would > slurp up half the available option space). 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. 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. > 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. > 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. MIPv6-like approaches would be one option of course, rather heavy though. -- 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] --------------------------------------------------------------------
