Re: New iTrace proposal

On Thu, 16 Oct 2003, Tomasz Grabowski wrote:
> I think that it is actually possible to get rid of all this 'crypto' part
> of iTrace protocol. While dramatically simpler to implement, protocol will
> still be able to do its job. 

True..

> The problem is that some of the specification
> needs to be changed. I will try to briefly describe this concept (without
> detailed specification).  I'm wondering what others think about it.
> 
> There will be three modes of iTrace operations.
[...]

I'm not sure if I see the need for a protocol for these three modes.

They could be operational modes, achievable by doing packet filtering on 
the specific ICMP type/code, end of story.

I fail to see how you'd have to complicate this with a protocol, when 
*apparently* at least, an operational procedure would be enough.

The default bevivour would naturally be your mode 3 ("forward all iTraces, 
generate them").

> Instead of all 'cryptio' stuff, we can now use simple 'packet marking'
> with a number similar to sequence numbers in TCP protocol. So, every
> iTrace packet generated by router will need to have such a number. Some (I
> don't know how many) of last generated numbers need to be held by router.
> This number will be of course used in query/response mechanism to assure
> that particular router really generated particular iTrace message.
> 
> So, what others think about that proposal?

I disagree about this.  In practice these query/response protocols 
re-invent security, and usually make a mess out of it.

I think just using the TTL=255 when originating packets should be enough.

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