Hi Pekka,
On Mon, 2003-01-27 at 17:40, Pekka Savola wrote:
> On Mon, 27 Jan 2003, Brian Haberman wrote:
> > >>>My own, very raw idea for anycast + TCP: a new ICMP message, including the
> > >>>seq number (or equivalent protocol-specific information) of the
> > >>>just-received TCP SYN, indicating the unicast address which should be used
> > >>>instead of the included anycast address.
> > >>
> > >>My original thought was to signal back the mapping using ICMP. The
> > >>mapping authentication capability of the RR procedure gives a better
> > >>level of security than a plain ICMP message.
> > >
> > >
> > > 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.
> >
> > 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).
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.
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.
MikaL
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
