> > I want to create a new ip_option for use in some DOS protection experiments
.
> > I have a whole 40 bytes (+/-) to share... Now although I don't see anythin
g
> > explicitly prohibiting the use of unused IP Header option space, I know tha
t
> > it really was designed for use by the sending parties, and not routers in
> > between.. Has anyone seen any RFC that explicitly says I MUST NOT?
>
>Not to my knowledge. Routers already change the time to live field,
>so I see no reason why they can't do smart things with special IP
>options either (besides efficiency concerns :-).
FWIW, the LSRR, SSRR, Record Route, and Internet Timestamp
options all require routers to change the contents of their IP option
as the packets bearing the option passed through. Of course, the
source routine ones are out of favor now...
I've forgotten how the Stream ID option was implemented, but I
won't be surprised if a router inserted it on the fly (but it was
probably inserted by end systems). On the other hand, there was also
a competing philosophy that said that the IP checksum must be
recomputed incrementally at routers to catch hardware problems in the
routers, and an incremental recomputation when changing the size of
the header would be more work.
The one thing I would worry about is unleashing mutant IP
packets upon the world at large. I hope the proposed experiments have
a very good firewall. It would be very nice to attempt to acquire an
officially blessed IP option number for such experiments before
unleashing these packets upon an unprepared world.
Craig Milo Rogers
|