Subject: RE: [Syslog] WGLC: udp-07

From: "Anton Okmianski \(aokmians\)" <[email-masked]>
Date: Thu, 31 Aug 2006 23:45:34 -0400

David and all:

Thanks for a thorough review.  I updated the draft according to your
comments. Generated text version from XML using tool at
http://xml.resource.org/.  Please see below for a couple of items for
clarifications.  Please let me know if I addressed this sufficiently to
post the attached draft.

I will be traveling starting September 8th for 3 weeks and will only
have sporadic access to email.  So, I'd prefer to finalize whatever we
can before than.  

Thanks,
Anton.  

> -----Original Message-----
> From: David Harrington [mailto:[email-masked]] 
> Sent: Monday, August 28, 2006 2:40 PM
> To: [email-masked]
> Subject: [Syslog] WGLC: udp-07
> 
> 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 ---

All of these are un-used anchors.  I don't see a problem.  

> 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.

Done.

> 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?

Done.

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

Yes, it is correct.

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

Done. 

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

Done.

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

Done.

> "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.

Done.

> 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".

Done. 

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

Done.

> --- 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.

Replaced "may" with can/could. It is a bit akward English in places, but
meaning is clear I think. 

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

I found one place. Replaced can with MAY here:  "Each syslog UDP
datagram MUST contain only one syslog message, which MAY be complete or
truncated." Any other placed you had in mind?

> 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? 

I don't know what a "system" is.  I can have different interfaces on a
single system. Regardless of what's available, I may want to use IPv4 on
one interface and IPv6 on another. I can run completely different syslog
stacks on different applications.  Is not it obvious that if syslog
client is configured with IPv6, it need to send UDP packets using IPv6
and can only send those to server that supports IPv6? And if I am
configured with IPv4 source IP, I need ot send IPv4 packets?   

> 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.

Is this over-specifying? Why are we talking about "devices"? 

I drafted the following text as best as I understood your suggestion for
people to comment, but I am not very comfortable that this is helpful:

"The IPv4 version of this transport mapping is REQUIRED for all syslog
protocol implementations on devices supporting IPv4. The IPv6 version of
this transport mapping is REQUIRED for all syslog protocol
implementations on IPv6-only devices. These requirements are mandated
for interoperability purposes."

> --- 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. 

It specifies 2 bytes for length of UDP datagram payload.   

We specified earlier in the text that "Each syslog UDP datagram MUST
contain only one syslog message..."

Hence, it apears correct to say that "This transport mapping supports
transmission of syslog messages up to 65535 octets in size."

What am I missing?

> 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.

I believe it is 65535 octets in addition to UDP header fields.  

Or are you referriung to syslog protocol headers?  Those, at the
transport layer I consider part of syslog message payload.  Just like IP
counts payload with whatever internal headers the payload may have. 

I did not make any changes here. Need to understand the issue. 

> "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.

Done.

> 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.

I changed this to RECOMMENDED for both sender and receiver instead of
MUST/SHOULD.  I think recommending how you should use a lower layer is
fine. This is often done. A MUST and SHOULD may be too much.  

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

Pretty much - just different examples (copied from syslog RFC 3164).
Maybe worthwhile to keep the different examples.  I combined the text
into a section with heading "Sender Authentication and Message Forgery".
I am happy to get rid of content of 5.2 if peopl ethink it does not add
value. 
 
> 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.

Changed to: "Unless some prioritization is implemented by the syslog
sender, receiver and/or the network devices, the security implication of
such behavior is that the syslog receiver or network devices could get
overwhelmed with low-severity messages and be forced to discard
potentially high-severity messages."

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

I am fine with that - probably a MIB document issue.  But restricting
compliant implementions of senders will not eliminate the DoS thread
from a real attacker. So, this text likely needs to stay.  

Thanks,
Anton. 

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