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.