On Tue, 24 Oct 2000, Chris Lonvick wrote:
Hi Everyone,
>
> T [TR] R At this point, we have no way of doing anything
> useful with the relayed message. There would be the
> assumption that the received message would be
> transported to the collector without errors, but then
> it would be dropped onto the disk/paper/display in
> the same manner as the Traditional messages are
> currently dumped. I would suggest that this may not
> be useful.
> R R R Right now, the defined element "entry" is a syslog
> message. If it is a traditional type, then we may
> be relaying things securely but there will be no
> post-storage authentication or integrity check. If
> it is an Authenticated message type, then those
> values will be transmitted within the BEEP channels
> and stored for later validation.
> 1. Should some wording go into the Authenticated and Reliable IDs that
> explicitly states what is to be done with messages received? Perhaps
> the Authenticated relay must wrap the Traditional message into an
> Authenticated format using its own credential (T-[TA]-A)? Perhaps the
> Reliable relay must do the same (T-[TAR]-R)?
Explicitly state what is to be done with received messages is, IMHO,
convenient only if message integrity is granted to the node that receive
the message and the message source is authenticated.
`Reliable' nodes not necessarily protect message integrity since message
integrity is only a reccomended practice.
This do not prevent an attacker from maliciously alter also the ID where
`what to be done' has been stated. Scenarios prone to this kind of problem
are, for example, R-R-R or T-[TR]-R.
In fact TCP, used by BEEP framework, do not prevent packet forging per se.
Other mechanisms could be used for reliable delivery (eg. redundancy).
If we know that a message has not been altered in transit and the source
is authenticated we can trust `what to be done' information.
Otherwise some nodes/relays should be configured to use ACLs where
policies for senders and relays event messages are stated.
alfonso
