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.
> 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.
> > 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, perhaps this is not a
problem.
> > 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.
> 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.
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]
--------------------------------------------------------------------
