New iTrace proposal

It's *not* ready-to-implement solution. It's rather something that should
start a discussion.


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

Mode 1 (default):
- router is sending iTrace packets according to specification (of course
without all this 'crypto' stuff)
- router is not forwarding iTrace packets which were not originated by
itself, because we consider them forged.

Mode 2:
- router is sending iTrace packets according to specification (of course
without all this 'crypto' stuff)
- router is forwarding iTrace packets, to a specified IP address (usually
dedicated PC that will collect and analyze iTrace packets from other
networks)

Mode 3:
- router is sending iTrace packets according to specification (of course
without all this 'crypto' stuff)
- router is forwarding all iTrace packets.

Mode 1 is the default. It requires no configuration, does need
imperceptible router CPU power, and generates imperceptible additional
bandwidth. So, it can be safely ON by default.

Mode 2 is for someone who actually cares about iTrace protocol and, while
sending iTrace messages to other networks, wants to analyze iTrace
messages coming from other networks as well. He needs to deploy a
dedicated PC which will collect and analyze iTrace messages, and then
configure router to forward iTrace messages to that PC. Additional benefit
is that it can be easily noticed when someone is trying to send spoofed
iTrace messages from internal network.

Mode 3 is for big routers that interconnects other networks (like backbone
routers).

There need to be a query/response mechanism, which will assure us that
particular router is running iTrace in mode 1 or 2. If particular router
is running mode 3, or has no iTrace protocol support at all, there not
need to by any response to our query.


The main idea is of course that attacker behind a router that is using
iTrace can't generate spoofed iTrace messages. So, when all routers will
have iTrace protocol implemented, it will not be possible to send any
spoofed iTrace messages to the Internet. Of course it's not a case, so
there should be some kind of mechanism that will assure us that particular
iTrace message is really originated by particular router.
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?


---
Tomasz Grabowski  (0-91)4494234
Akademickie Centrum Informatyki
mailto:[email protected]