Re: Comments on multi6dt documents

[Pekka Savola <pekkas@netcore.fi>]

On Tue, 9 Nov 2004, Iljitsch van Beijnum wrote:
> 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.

The implication may be done, but one can still correctly argue that 
one can maintain forward and reverse tree in a manner that those don't 
match, as long as there are some records in either :).

Actually, operaionally, I'd guess this is a relatively big challenge.

> > ==> 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.

So, I guess this depends on where this failure detection code resides 
with regard to the ICMP message reception and parsing.

> > 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

That's OK; put that justification to the draft alongside of the 
mention of slow start.

> > 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.

Unfortunately, a very real possibility.  The tradeoff needs to be 
written down, of course

> 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.

Unless you piggyback on the TCP connection establishment messages 
which are known to be small enough to accommodate this.  That's the 
only realistic case for piggybacking benefits AFAICS.

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings