[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Syslog-sec] UDP message size issue proposal
Hi,
The RFC2119 keyword usage needs to be tightened up. I suggest:
>From RFC2119:
"MUST This word, or the terms "REQUIRED" or "SHALL", mean that the
definition is an absolute requirement of the specification."
"SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course."
MUST is used to specify compliance requirements. Your text " A
receiver MUST be able to accept messages that are 480 octets (or less)
in length." could be interpreted to mean that I am compliant if I
accept only messages of 4 bytes, since 4 bytes would fit within your
"480 octets (or less)" requirement. "up to and including 480 octets"
is clearer (and consistent with the the same restriction in RFC3417).
SHOULD and RECOMMENDED are equivalent. So I suggest that
" A receiver SHOULD be able to accept messages that
are 65,535 octets (or less) in length. It is RECOMMENDED that
receivers be able to accept messages up to the maximum message
length
of 16,777,216 octets."
be reduced to
" A receiver SHOULD be able to accept messages up to the maximum
message length of 16,777,216 octets."
If they cannot support that size, which would be a valid reason to
ignore that requirement, they should understand the implications.
We don't need the intermediate SHOULD 64k size in the standard, we
only need the minimum size and the maximum size.
If the WG wants to make the 64k the standard maximum, yet allow
implementors to support up to 16,777,216 octets, then the text should
specify a SHOULD for 64k, and a MAY for 16,777,216 bytes.
Can a receiver truncate the message, or just the payload of the
message? If the WG ever s=chooses to add something to the end of the
message, such as for security, the text as written would prevent that.
I would also suggest reordering this text to move from minimum to
maximum:
####
5.1 Message Length
A receiver MUST be able to accept messages up to and including 480
octets in length.
A receiver SHOULD be able to accept messages up to and including
65,535 octets in length.
If a receiver receives a message with a length larger than it
supports, the receiver MAY
discard the message or truncate the payload.
A receiver MAY accept messages up to the maximum message length
of 16,777,216 octets.
The maximum length of any syslog message is 16,777,216 octets. Any
receiver receiving a larger message MUST discard the message. A
diagnostic message SHOULD be logged in this case.
A transport mapping MAY define a maximum length below the one
specified here. Each transport mapping MUST support at least the
minimum size
of 480 octets, and not exceed the maximum of 16,777,216 octets.
####
Why are we specifying a maximum length allowed, and why MUST a larger
message be discarded? It is not a matter of interoperability if I
ACCEPT a message larger than 16,777,216 octets. Since I can truncate
any message to my maxiumum supported size, it isn't even a problem if
somebody SENDS me a message larger than that size. So why even mention
such a limit? What if ten years from now, a new transport is defined
that efficiently moves messages largee than this, and somebody wants
to support messages larger than 16,777,216 octets? Why MUST this be
prevented?
If the WG chooses 64k as the STANDARD maximum, why isn't a diagnostic
message required for messages that exceed the standard maximum? Why is
it REQUIRED only for messages above 16,777,216 octets? Does this
impact on-the-wire interoperability? Wouldn't it make sense to log any
message received greater than that supported by the receiver, so the
operator realizes that a message was received but the message may have
been truncated or discarded?
David Harrington
dbharrington@comcast.net
-----Original Message-----
From: syslog-sec-bounces@www.employees.org
[mailto:syslog-sec-bounces@www.employees.org] On Behalf Of Rainer
Gerhards
Sent: Wednesday, October 13, 2004 5:17 AM
To: Anton Okmianski; syslog-sec@employees.org
Subject: RE: [Syslog-sec] UDP message size issue proposal
Anton,
I agree to your conclusion.
Although I am the one who always voted for larger sizes, the
discussion has shown that this yields to unnecessary complexity. I can
satisfy my needs with a vendor-extension structured data element,
which I think shows the flexibility of the new drafts.
So I support your move. I would tend to even remove the transport
version header. If there is need to, we could always include that in a
later release (e.g. "v1", which would make it clearly distingshable
from the current frame format). I see little need to do so, though.
Regarding -protocol, I think we should still keep an upper limit in
the spec. Even I don't see any reason why a syslog message should go
above 16MB. So for -protocol, I propose the following new text:
####
5.1 Message Length
The maximum length of any syslog message is 16,777,216 octets. Any
receiver receiving a larger message MUST discard the message. A
diagnostic message SHOULD be logged in this case.
A receiver MUST be able to accept messages that are 480 octets (or
less) in length. A receiver SHOULD be able to accept messages that
are 65,535 octets (or less) in length. It is RECOMMENDED that
receivers be able to accept messages up to the maximum message
length
of 16,777,216 octets.
If a receiver receives a message within the maximum length, but
with
a length larger than it handles, the receiver MAY discard or
truncate
it.
A transport mapping MAY define a maximum length below the one
specified here. Each transport mapping MUST support a maximum size
of 480 octets or more.
####
If there is agreement on this, I can post a new version of -protocol.
That version will also include some changes made thanks to Andrew Ross
comments (sent via private mail). I have finished this version. It is
available for immediate posting, but I would like to wait for
agreement on the size issue (at least if that can be reached quickly).
Rainer
> -----Original Message-----
> From: syslog-sec-bounces@www.employees.org
> [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of Anton
> Okmianski
> Sent: Tuesday, October 12, 2004 11:25 PM
> To: syslog-sec@employees.org
> Subject: [Syslog-sec] UDP message size issue proposal
>
> Hi!
>
> Sorry for a long delay on this issue - I was on a 2 week vacation.
I
> have spoken with a number of TCP/UDP/IP experts regarding the sizing
> issue. I am ready to propose the following changes:
>
> 1. Syslog-protocol will state that the max message will be defined
by
> the transport layer.
>
> 2. Syslog-transport-udp will support messages up to maximum UDP
> datagram size of 64K. UDP is a very bad choice for large message
> transmissions, so it does not make sense for us to stretch it by
> adding our own fragmentation without other transmission control
> features such as found in TCP.
>
> 3. Syslog-transport-udp will rely on IP fragmentation and we will
get
> rid of "proprietary" fragmentation which was designed to handle
> messages over 64K and deal with various
> non-compliant network hosts.
>
> 4. Syslog-transport-udp will recommend sending messages within the
> boundaries of prevalent MTU size on a given network to be safe. It
> will recommend Ethernet's 1500 bytes less headers and will draw
reader
> attention to the minimum MTU size hosts on the network are required
to
> support for
> IPv6 (576 bytes) and IPv6 (1280 bytes).
>
> 5. Path MTU discovery may not work robustly and some TCP/IP stacks
may
> not support UDP packets of full 64K size and truncate them. We will
> mention this and bite this bullet.
> We should not restrict the protocol due to incompliant
implementations
> because it is a moving target and penalizes compliant
implementations
> with extra overhead. The above size recommendation would partially
> deal with this, but leave the
> final choice up to the administrator.
>
> 6. We will get rid of most syslog transport headers for UDP as they
> will no longer be needed. The only thing that will be left is the
> transport protocol version prefixed to every syslog message. Should
> we even bother with that?
>
> This is a major change to the syslog-transport-udp. I'd like to get
> positive feedback before I proceed with this update.
> The best part is that if we all agree on the above, the next draft
> will be 1/3 of the size -- easier read for you. :)
>
> Thanks,
> Anton.
>
>
> _______________________________________________
> Syslog-sec mailing list
> Syslog-sec@www.employees.org
> http://www.employees.org/mailman/listinfo/syslog-sec
>
_______________________________________________
Syslog-sec mailing list
Syslog-sec@www.employees.org
http://www.employees.org/mailman/listinfo/syslog-sec
_______________________________________________
Syslog-sec mailing list
Syslog-sec@www.employees.org
http://www.employees.org/mailman/listinfo/syslog-sec