Subject: [Syslog] WGLC: udp-07

From: "David Harrington" <[email-masked]>
Date: Mon, 28 Aug 2006 14:40:07 -0400

Hi,

I have reviewed
http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-udp-07
.txt for WGLC.

The xml2rfc will be submitted with the final draft, so this should be
a "clean" xml2rfc source file.
The xml2rfc-validator tools at
http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/valid.cgi shows the
following warnings or errors, which should be fixed in the source
file. Note that my copy of the XML source apparently does not match
that used to generate the official draft.

---- start validation output ---
Validation results for D:\My
Documents\IETF\syslog\draft-ietf-syslog-transport-udp-07.xml
Processing...

Validating document...
280: element front: validity error : Element front content does not
follow the DTD, expecting (title , author+ , date , area* , workgroup*
, keyword* , abstract? , note*), got (title author )
 279: <reference anchor='RFC-protocol'>
 280: <front>
 281: <title>The syslog Protocol</title>
...validation failed
Performing additional checks...
50: fyi: anchor intro not referenced
  49: <middle>
  50: <section anchor="intro" title="Introduction">
  51: 	<t>
68: fyi: anchor terms not referenced
  67: 
  68: <section anchor="terms" title="Conventions Used in This
Document">
  69: 
76: fyi: anchor Transport not referenced
  75: 
  76: <section anchor="Transport" title="Transport Protocol">
  77: 
78: fyi: anchor Datagram not referenced
  77: 
  78: <section anchor="Datagram" title="One Message Per Datagram">
  79: <t>
84: fyi: anchor MessageSize not referenced
  83: 
  84: <section anchor="MessageSize" title="Message Size">
  85: 
104: fyi: anchor TargetPort not referenced
 103: 
 104: <section anchor="TargetPort" title="Source and Target Ports">
 105: <t>
110: fyi: anchor SourceIPAddress not referenced
 109: 
 110: <section anchor="SourceIPAddress" title="Source IP Address">
 111: <t>
116: fyi: anchor UDPIPStructure not referenced
 115: 
 116: <section anchor="UDPIPStructure" title="UDP/IP Structure">
 117: <t>
122: fyi: anchor UDPChecksums not referenced
 121: 
 122: <section anchor="UDPChecksums" title="UDP Checksums">
 123: <t>
137: fyi: anchor reliability not referenced
 136: 
 137: <section anchor="reliability" title="Reliability
Considerations">
 138: 
143: fyi: anchor loss not referenced
 142: 
 143: <section anchor="loss" title="Lost Datagrams">
 144: <t>
152: fyi: anchor corruption not referenced
 151: 
 152: <section anchor="corruption" title="Message Corruption">
 153: <t>
162: fyi: anchor overload not referenced
 161: 
 162: <section anchor="overload" title="Congestion Control">
 163: <t>
168: fyi: anchor sequence not referenced
 167: 
 168: <section anchor="sequence" title="Sequenced Delivery">
 169: <t>
177: fyi: anchor security not referenced
 176: 
 177: <section anchor="security" title="Security Considerations">
 178: <t>
182: fyi: anchor SenderAuthentication not referenced
 181: 
 182: <section anchor="SenderAuthentication" title="Sender
Authentication">
 183: <t>
188: fyi: anchor SecForg not referenced
 187: 
 188: <section anchor="SecForg" title="Message Forgery">
 189: <t>
200: fyi: anchor SecObs not referenced
 199: 
 200: <section anchor="SecObs" title="Message Observation">
 201: <t>
206: fyi: anchor SecReplay not referenced
 205: 
 206: <section anchor="SecReplay" title="Replaying">
 207: <t>
212: fyi: anchor SecRelDel not referenced
 211: 
 212: <section anchor="SecRelDel" title="Unreliable Delivery">
 213: <t>
218: fyi: anchor SecPri not referenced
 217: 
 218: <section anchor="SecPri" title="Message Prioritization and
Differentiation">
 219: <t>
224: fyi: anchor SecDen not referenced
 223: 
 224: <section anchor="SecDen" title="Denial of Service">
 225: <t>
231: fyi: anchor iana not referenced
 230: 
 231: <section anchor="iana" title="IANA Considerations">
 232: 	<t>
237: fyi: anchor rfc-editor not referenced
 236: 
 237: <section anchor="rfc-editor" title="Notice to RFC Editor">
 238: 	<t>
244: fyi: anchor acks not referenced
 243: 
 244: <section anchor="acks" title="Acknowledgements">
 245: 	<t>
310: warning: anchor RFC1122 not referenced
 309: 
 310: <reference anchor='RFC1122'>
 311: <front>
...done 
---- end xml2rfc validation output ---

Idnits (using http://tools.ietf.org/tools/idnits/idnits.pyht)
Boilerplates and formatting checks look good.

---- spelling ----
(using MS-Word on the xml2rfc-generated html file)

The implementer/implementor debate rages on. 
Usage is inconsistenct within this document.
It would be nice if we were consistent across our documents. 
My research shows implementer as the preferred spelling.

The term "misconfigured" is used. This is apparently not a real
English word, and that means that implementers and readers who rely on
translation tools will probably have problems with this term. Can we
use "inappropriately configured" instead?

The draft acknowledges Mickael Graham; is this the correct spelling?

--- grammar ---

"The informational RFC 3164 [7] originally described the syslog" -
eliminate "originally"

The documentt talks about "RFC3164 described" - doesn't it still
describe? Shouldn't this be "describes"?

"The RFC-protocol specifies a layered architecture that provided for"
- /provided/provides/

"This standards track RFC describes" should be "This document
describes"; the IESG could always decide to publish this as a
non-standards-track RFC, and it could be moved to "Historic" at a
later date, so we should not specify standards-track in the body of
the document; that status is external to the document.

I don't feel very comfortable with use of the word protocol in
"Network administrators and architects should be aware of the
significant reliability and security issues of this protocol, which
stem from the use of UDP."  I think this document describes a
transport mapping - how syslog should "interface to" the UDP protocol.
We are not defining a syslog-udp message format. Part of the problem
is that when the text says "this protocol", I need to think about
whether "this protocol" means syslog (which is definitely a protocol),
or the syslog-udp transport mapping. So "This protocol supports
transmission of syslog messages up to 65535 octets in size"  is
ambiguous as to wehere the limit is defined, but "This transport
mapping supports transmission of syslog messages up to 65535 octets in
size" is not. In sexction 5.3, "This transport protocol" apparently
refers to UDP. It woul dbe less ambiguous if each usage of "this ...
Protocol" was replaced by "the UDP protocol" or "the syslog/udp
transport mapping".

"a well-known port 514" s/b "the well-known port 514"

--- RFC2119 terminology ---

Some of the keywrods are used in both lowercase and uppercase; I
believe the preferred approach is to use uppercase consistently. Some
authors use lowercase when th eterm is not used as an rfc2119 keyword,
but uppercase when referring to an rfc2119 keyword. I recommend always
using uppercase and avoiding the keywords when they are not meant to
be used as an rfc2119 keyword to avoid ambiguity.

The word "can" is used where MAY might be more appropriate.

The document says that "this transport protocol" is required for
interoperability. However, two transport protocols are referred to,
and they are not necessarily interoperable. For a system that only
supports IPv4, then the UDP/IPv4 protocol should be required for
interoperability. For a system that only supports IPv6, then UDP/IPv6
should be supported for interoperability in an IPv6 environment. For a
system that supports both IPv4 and IPv6, what is required - UDP/IPv4,
UDP/IPv6, or both, for interoperability? If both, then by default,
should operators have syslog messages sent over both (i.e. duplicate
the messages) so they can be transmitted over IPv4 and IPv6 networks?
In SNMPv3, we chose UDP/IPv4 as the required even if both IPv4 and
IPv6 are available, and for IPv6-only devices, we require UDP/IPv6.

--- general review ---

"This limit stems from the maximum supported UDP payload of 65535
octets specified in the RFC 768 [1]." - I couldn't find such a limit
specified in rfc768. In fact, rfc768 **assumes** this will run over
the IP protocol. IP might define some limits that would lead to this
syslog limit. If UDP had a limit, then saying UDP supported "payloads"
of 65535 would probably be incorrect, since part of the 65535 limit
would be used up by header fields, thus lessening the "payload" limit.

"It is RECOMMENDED that application developers restrict message sizes"
- shouldn't this be "It is RECOMMENDED that syslog senders restrict
message sizes"? The receivers are also applications and we don't
really want the receivers to restrict message sizes.

I am a bit concerned that we are violating layer separation when we
get too specific about the structure and checksums of the transport
protocol; lower-layer details like checksums should not necessarily be
made accessible to the syslog protocol, which operates at a higher
layer. We should trust the                                underlying
transport to do its job correctly, and operators to configure their
devices correctly, so requiring syslog receivers to examine the UDP
checksums seems wrong. In section 4.1, we go even further - "This
protocol specifies use of UDP    checksums to enable corruption
detection in addition to checksums used in IP and Layer 2 protocols."
We have no business looking at layer 3 and layer 2 checksums. If a
checksum is neede to validate the syslog mesdsage, then we should have
a syslog checksum.

Doesn't the last sentence of 5.1 mean basically the same thing as what
is discussed in 5.2? 

Section 5.6 says "they will not get a higher priority". The standard
will not mandate prioritization because that is an implementation
decision and would not affect interoperability on-the-wire, but a
sending implementation might provide such prioritization, so the
document should not say they will not get a higher priority. It might
even be a good idea to suggest that implementers of sending
applications and relays consider support for prioritization based on
the <PRI> label.

Section 5.7 discusses DoS attacks. Should the MIB include the ability
to restrict the nuber of messages sent per minute?

David Harrington
[email-masked] 
[email-masked]
[email-masked]

_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog