At 11:28 AM 1/8/01 -0800, Darren New wrote:
>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?
If the original interface were to die, then the sender shouldn't be able
to carry on the same session with the receiver. The sender would then
have to start a new session with the receiver with a new IP address.
((There are some funky resiliency techniques that could continue the
session on a different interface with the same address but I don't think
that we need to address those scenarios.)) It _may_ also change its FQDN
(if it had knowledge that it had multiple). I would think that would only
be a cosmetic change. The receiver would see that things had been coming
from
10.1.1.1 abcdef.example.org
but were now coming from
172.16.6.6 abcdef2.example.org
If it is stored, then someone (or the automated parser) will need to have
some knowledge of the FQDN and the possible IP addresses associated with
it. Unless someone has a real example of what may break, I'll go along
with what Darren suggested.
>> 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.
I'll agree with Darren's comment. We really need to keep syslog as something
_easy_ to deploy. From our charter, the benefit that BEEG will give to
syslog is reliable delivery. Even a basic deployment of BEEP will satisfy
this need and it will be moderately easy to deploy. Having the additional
features of TLS with SASL is great and they may be used if they are
required by the security policy of the people deploying it. I don't, however,
want to mandate a difficult deployment just because we think that "more
security must be 'better'". Let's go with the thought of simplifying things
so we can get 'better' acceptance. :-)
Thanks,
Chris
