Subject: RE: [Syslog-sec] I-D ACTION:draft-ietf-syslog-transport-udp-02.txt

From: "Rainer Gerhards" <[email-masked]>
Date: Mon, 6 Sep 2004 14:25:35 +0200

Anton,

thanks for your great work.

Some points:

- you use "domain.com" in some examples. I recommend changing this to
"example.com", which has been reserved for this use.

- In 3.4, the draft says:

######
   All implementations MUST support sending and receiving syslog
   messages up to and including the size which does not require
   fragmentation (507 bytes for IPv4 and 1191 bytes for IPv6).  This
   size excludes the overhead of the syslog transport and UDP/IP
   headers.  Support for larger messages is encouraged.  Implementors
   SHOULD clearly state the maximum supported message size in
   documentation.
######

Actually, all implementations MUST support a message size of 65,000
bytes, because this is the required minimum in -protocol 4.1. We agreeed
on this minimum after long discussions on the message size. I'd actually
prefer not to re-iterate this. But if we must, let me say that a
guaranteed message size of 507 bytes looks far too low to me.

Please note that the -protcol requirement meant that all implementations
MUST support fragmentation.

Sorry I didn't spot this in the -01 version...

I've also noticed that in -protocol, I have limited that max message
size to 16,000,000 bytes in -protocol. It might make sense to sync this.
I can go up with my number.

I do not fully understand what you mean in 4.2 by:

#####
 No concurrent port reuse on the same host is
   allowed.
#####

It's probably just my English, but I do not get it. I'd appreciate if
you could elaborate a little.

Thanks for the great draft!
Rainer

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> Anton Okmianski
> Sent: Thursday, September 02, 2004 4:20 PM
> To: [email-masked]
> Subject: RE: [Syslog-sec] I-D 
> ACTION:draft-ietf-syslog-transport-udp-02.txt
> 
> Hi!
> 
> Updates in this draft include:
> 
> 1. UDP checksums are now a SHOULD instead of a MUST for IPv4.
> Checking checksums by receiver when available is still a MUST.   
> 
> 2. Requirement about using the same port for a given process was
> removed.  This opens up the possibility for a given process to have
> multiple sockets sending syslog messages.  The requirement about using
> the same MessageId and source port for fragments of a given message is
> still there, so we are covered for message reassembly. 
> 
> 3. The references were split into Normative and Informative.
> 
> Based on limited feedback I got for previous version, I believe the
> draft is ready to be published.  It has to be published together with
> syslog-protocol when both are ready.   
> 
> Thanks,
> Anton.
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf 
> > Of [email-masked]
> > Sent: Wednesday, September 01, 2004 4:10 PM
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: [Syslog-sec] I-D 
> > ACTION:draft-ietf-syslog-transport-udp-02.txt
> > 
> > 
> > A New Internet-Draft is available from the on-line 
> > Internet-Drafts directories. This draft is a work item of the 
> > Security Issues in Network Event Logging Working Group of the IETF.
> > 
> > 	Title		: Transmission of syslog messages over UDP
> > 	Author(s)	: A. Okmianski
> > 	Filename	: draft-ietf-syslog-transport-udp-02.txt
> > 	Pages		: 21
> > 	Date		: 2004-9-1
> > 	
> > This document describes the transport for syslog messages over UDP/
> >    IPv4 or UDP/IPv6.  While several transport mappings are
> envisioned
> >    for the syslog protocol, syslog protocol implementors are 
> > required to
> >    support the transport mapping described in this document.  This
> >    transport specification overcomes limitations of UDP/IP 
> > datagram size
> >    by introducing support for fragmentation of large messages.
> > 
> > A URL for this Internet-Draft is: 
> > http://www.ietf.org/internet-drafts/draft-ietf-syslog-transpor
> > t-udp-02.txt
> > 
> > To remove yourself from the I-D Announcement list, send a message to
> 
> > [email-masked] with the word unsubscribe in 
> > the body of the message.  
> > You can also visit 
> > https://www1.ietf.org/mailman/listinfo/I-D-announce 
> > to change your subscription settings.
> > 
> > 
> > Internet-Drafts are also available by anonymous FTP. Login 
> > with the username "anonymous" and a password of your e-mail 
> > address. After logging in, type "cd internet-drafts" and then
> > 	"get draft-ietf-syslog-transport-udp-02.txt".
> > 
> > A list of Internet-Drafts directories can be found in 
> > http://www.ietf.org/shadow.html 
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > 
> > 
> > Internet-Drafts can also be obtained by e-mail.
> > 
> > Send a message to:
> > 	[email-masked].
> > In the body type:
> > 	"FILE
> /internet-drafts/draft-ietf-syslog-transport-udp-02.txt".
> > 	
> > NOTE:	The mail server at ietf.org can return the document in
> > 	MIME-encoded form by using the "mpack" utility.  To use this
> > 	feature, insert the command "ENCODING mime" before the "FILE"
> > 	command.  To decode the response(s), you will need "munpack"
> or
> > 	a MIME-compliant mail reader.  Different MIME-compliant 
> > mail readers
> > 	exhibit different behavior, especially when dealing with
> > 	"multipart" MIME messages (i.e. documents which have been
> split
> > 	up into multiple messages), so check your local documentation
> on
> > 	how to manipulate these messages.
> > 		
> > 		
> > Below is the data which will enable a MIME compliant mail 
> > reader implementation to automatically retrieve the ASCII 
> > version of the Internet-Draft.
> > 
> > --------------------------------------------------------------
> > -----------
> > In order to maintain computing infrastructure integrity, 
> > Cisco Systems Enterprise Messaging Services and InfoSec teams 
> > have set a mail policy disallowing executable attachments in email.
> > 
> > This message contained an executable attachment type that is 
> > prohibited 
> > by this policy. The attachment has been removed from this message
> and 
> > copied to quarantine by our systems. It will be held in 
> > quarantine for seven days in the event that the content needs 
> > to be retrieved.
> > 
> > 
> > --------------------------------------------------------------
> > -----------
> > For further reference information about viruses and email antivirus 
> > efforts within Cisco, please visit:
> > 
> http://wwwin.cisco.com/it/ems/services/antiviral
> 
> 
> If your concern isn't addressed by the information in this
> notification 
> or the above web page, you may open a support request:
> 
> http://wwwin.cisco.com/support/
> 
> Select "Messaging", "Email-Related", "Mail Routing"
> 
> Please include in the text of your case the following information:
> 
> * Full headers of the message. Documentation on displaying the full 
> headers is available at this URL:
> 
> http://wwwin.cisco.com/support/library/faqs/solution002471.html 
> 
> * This unique quarantine identifier: i81M6jA3002394
> 
> If the matter is urgent, you may follow up by calling one of the below
> 
> referenced numbers. Please make every effort to provide the above 
> requested information via the support web tool prior to calling as it 
> will greatly aid the resolution of your issue.
> 
> Americas:
> 1 408 526 8888
> 
> Asiapac
> +61 2 8446 8888
> 
> EMEA
> +31 20 485 4888
> 
> Japan
> +81 3 5549 6888
> 
> US (Toll Free)
> 1| 800| 888| 8187| (ext.68888)
> 
> Thank you for your cooperation,
> 
> Enterprise Messaging Services
> Cisco Systems, Inc
> 
> _______________________________________________
> Syslog-sec mailing list
> [email-masked]
> http://www.employees.org/mailman/listinfo/syslog-sec
> 
_______________________________________________
Syslog-sec mailing list
[email-masked]
http://www.employees.org/mailman/listinfo/syslog-sec

---

From: "Anton Okmianski" <[email-masked]>
Date: Tue, 7 Sep 2004 11:03:42 -0400

Rainer:

> Some points:
> 
> - you use "domain.com" in some examples. I recommend changing 
> this to "example.com", which has been reserved for this use.

Yes, will change.  You already commented on this, and I just lost
track of this issue.  Sorry about it.  

> Actually, all implementations MUST support a message size of 
> 65,000 bytes, because this is the required minimum in 
> -protocol 4.1. We agreed on this minimum after long 
> discussions on the message size. I'd actually prefer not to 
> re-iterate this. But if we must, let me say that a guaranteed 
> message size of 507 bytes looks far too low to me.
> 
> Please note that the -protcol requirement meant that all 
> implementations MUST support fragmentation.
> 
> I've also noticed that in -protocol, I have limited that max 
> message size to 16,000,000 bytes in -protocol. It might make 
> sense to sync this. I can go up with my number.

Indeed we discussed this at length, but my recollection of conclusions
was different. :)  Let's revisit.  We decided (I thought) that we
can't force transport implementors into supporting fragmentation as it
was too complicated. Plus, we can't them into supporting the maximum
message size as the common denominator may be too small. 

Hence, only the size that can be transported without fragmentation
must be supported by transport implementors.  However, a full
transport implementation will support fragmentation and size of up to
16777216 bytes.   

I think what we need is a statement in -protocol that it supports a
message size up to 16777216, but transports MAY impose a different
limit. 

It was mentioned that some devices will physically not be able to
handle large messages, where "large" can be quite a small number.
Restricting all messages to this common denominator is not good, so we
have a multi-tier support system. People are not likely to support
streaming of message parts in their implementations, so available
memory will be an issue.  

Administrators will choose the appropriate implementations. Should we
add a statement that transport implementations MUST document maximum
supported message size? 

I know it is less than optimal, but requiring all transports to
support some huge size is not a good idea either IMO. 

You also had an idea for doing fragmentation within the -protocol by
upper layer. I originally liked it.  But later people commented that
this was improper layering and shifted responsibilities of transport
layer up the stack.  I agree with this.  It would have introduced
potential fragmentation on several layers and we would have still
forced the higher layer to deal with UDP sizing constraints. 

I agree this issue deserves discussion. Let's have it and put it bed
for good. 

> It's probably just my English, but I do not get it. I'd 
> appreciate if you could elaborate a little.

What this refers to is the use of SO_REUSEPORT socket option which
allows multiple sockets to be bound to the same port.  I guess it
would not be a problem if the two different consumers of the socket
(maybe threads) use different MessageId numbers.  And this is stated
as requirement elsewhere: all message parts must be send using the
same MessageId and source port among other things.   

Following your suggestion, we already allow multiple different ports
to be used concurrent within a single process, so I have no problem
with removing this restriction. It is too implementation-specific
anyway.  What do you think?

Thanks,
Anton.