[snip]
Let me give an example. An ftp implementation is per spec in all respects
except that whenever you send "get foo" it returns the contents of the
file
bar. It seems to me that there is nothing that the peer ftp
implementation
can do within the scope of ftp to rectify or even detect this. Only the
application of other features (such as file encryption and file tagging)
can
help and this is outside the scope of ftp.
So with RSVP-TE. An application can do lots of things to verify that its
LSP
is correctly connected and passing the right data unmollested, but that
is
the job of the application not of the protocol.
Ahh, but in the RSVP restart case, it's more like an FTP
implementation does a "put foo" and then later a "get foo" and expects
the remote implementation to return the same "foo" that it put there
originally. You're trusting the remote implementation to give you the
same file that you uploaded earlier but you're not doing any kind of
verification that that's indeed the case.
All I'm suggesting is that the originator of the data have some way to
self-verify that the foo it got is the same foo it put. This could be
done by a simple "self-signature" or MAC, something where I have some
long term secret key (e.g. an AES key) and then upload the MAC with
the original data; then when I get it I can re-verify the MAC and see
that yes, this IS the data I uploaded.
-derek
--
Derek Atkins 617-623-3745
derek@ihtfp.com www.ihtfp.com
Computer and Internet Security Consultant