Chris Lonvick wrote:
> Q: Multihomed hosts - which fqdn, which IP?
> Q: If we insist IP addr interface MUST be used, this might break some
> implementations. Make this a SHOULD?
> A: Will discuss on mailing list.
My take is that for a multihomed host, the FQDN/IP to use is the one
belonging to the interface over which the session is being carried. (This
assumes, of course, that each channel is carried over at most one
interface.) What problems might be caused by making this otherwise?
> COOKED <received> :
>
> Discussion Points
>
> Q: Would it be reasonable to make TLS a MUST and SASL a should?
> A: Perhaps the matrix of options should be simplified; always TLS can
> be discussed on the email list.
I'm not sure of the benefit of making TLS a MUST rather than a SHOULD.
Making relays and collectors required to implement the *capability* of using
TLS would make sense. Making every syslog-reliable communication encrypted
might not.
> Q: How does replay protection work?
> A: (Paraphrasing) It's a challenge/response protocol, using password
> as a shared secret.
Actually, it's all spelled out in the SASL/DIGEST-MD5 RFC. But in quick
summary, each message is tagged with (essentially)
Hash(Hash(password),nonces,counter,content)
and the counter gets incremented. If you see the same nonces with the same
counter, you know it's a replay.
> COOKED <received> really needed? Some data could be one-time for
> a channel, put into the <iam> message.
>
> Comment: this would be a good thing, but we should avoid an explosion
> in the number of channels.
>
> Comment: multiple paths to log are possible.
> A: But those would be on different channels.
>
> Comment: some folks want to store info on the complete trail.
I have a mechanism now whereby each channel can have one or more <path>
elements describing a possible path that messages have covered. The <path>
elements contain the routing information and "sticky flag" types of
information. Each <entry> element can now refer to which <path> it followed.
Collectors can store the received <path> elements and later match them to
<entry> elements as desired. Since you can send new <path> elements over the
established channels at any time, there's no "channel explosion". It was
just a brain-cramp of mine that made me think the <iam> would be a good
place to put this. I'll submit the new draft in a couple of days unless
there is more discussion.
--
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
