[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Comments on multi6dt documents

On 9-nov-04, at 1:36, Pekka Savola wrote:

locators registered in the DNS but assumes that both the reverse tree
and the forward tree are maintained.

==> s/maintained/maintained in a consistent manner/ -- or the like: it's not
sufficient to just put some stuff in the reverses or forward trees, they
must be actively kept in sync. This is an area which is not often the
case..

I think that when it's said that something should be done, it's implied that this should be done correctly.

==> actually, robust implementations have long since started properly
verifying the ICMP messages. For examples, as
draft-gont-tcpm-icmp-attacks-00.txt describes, you can protect against ICMP
attacks against TCP by verifying that the ICMP message includes the correct
port numbers, seq/ack numbers etc., so that only (practically)
on-the-path attacker could have generated them.

We can't presume a multi6 implementation has such intimate knowledge of what TCP has been up to. Also, we need to be generic enough that non-TCP and even non-UDP protocols work reasonably well.

Upon
   changing to a new address pair, transport layer protocol SHOULD be
   notified so that it can perform a slow start.

==> using 'slow start' might be a bit accurate, because there's not much
slow in 'slow start' except the name.

I think triggering slow start is pretty much all you can do to slow down TCP

Did the draft mean a really slow start, or was aggressive probing OK as well?

The properties of the new path are unknown so basically transports should behave as if the session is new after a rehoming even.t

I.e., this does not discuss whether the set-up could be piggybacked upon
earlier messages? There's plenty of space in those TCP conn. establishment
messages, for example..

The trouble is that if you put multihoming stuff between the IP header and the TCP header you may end up being filtered. Also, under most circumstances either the packets you may want to piggyback on are already filling up the MTU, or there aren't any. So the complexity needed for piggybacking is probably not receive a decent return on investment.