Rainer: I agree with your assessment. I also don't see any benefit in restricting the source port. Firewalls can be configured with target port filtering. So, why restrict something if it has no benefit to the standard.
Instead of omitting discussion of source port like the current draft does, I think it is a good point to explicitly mention that source port is undefined, so there is no ambiguity for those familiar with RFC 3164. If somebody thinks differently, please let me know. Thanks, Anton. > -----Original Message----- > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > Sent: Thursday, February 19, 2004 6:53 AM > To: Anton Okmianski; [EMAIL PROTECTED] > Subject: RE: syslog-transport-udp ID 00 - source port requirement > > > Hi Anton, > > thanks for the fine ID :) > > I am commenting on the source port issue. In RFC 3164, port > 514/UDP is recommended as source port. This recommendation is > based on seen behaviour. However, maintaining source port 514 > severely limits implementation options for new implementations. > > Let's first see how a "classical" syslogd works: > > It opens a single UDP socket (at port 514) and uses this > socket both the receive AND send data. As the listener - by > definition - listens to 514, the sender also uses the same > port because the socket is bound to it. I think this was > actually a side-effect of the choosen application structure > (single socket) than a deliberately introduce feature. It is > seen on (many) existing syslogd's simply because that is > their program design. There are also modular implementations > which do not support this because they technically can/will > not (more on this below). > > Using port 514 as the source, requires an application design > where a single socket is shared between the sending and > receiving parts of the application. In those *nix syslogd's > that I have looked at, this is not a problem, because they > are more or less monolythical. > > If we now think about new implementations, some may want to > go for a modular model, one where the sender is only loosly > coupled with the receiver. This e.g. is important for > multi-threading and burst queueing. A simple, elegant and > efficient way is to use one socket for the receiver and (at > least one) for the sender(s). > > However, you can not bind a single socket to the same port/IP > address on a systemwide basis. So if we require port 514 to > be the source, we limit an implementation to use a > single-socket design. Of course, this is doable, but it leads > to more and more complex code (locking / thread sync), slower > code (locking) and probably less reliable (locking / thread > sync) code. And it brings us ... nothing. At least I don't > see any value in requiring a client to send FROM a specific > port. After all, many operators will re-configure port > assignments, anyhow. > > In short, I propose that we completely drop any requirement > for a specific source port. > > Rainer >
