Subject: syslog transport fragmentation
From: "Anton Okmianski" <[email-masked]>
Date: Mon, 3 May 2004 15:37:23 -0400

Hi!

I am pondering what recommendations/requirements we should set for
maximum datagram sizes in syslog UDP transport protocol.  Messages of
certain size would have to be fragmented.  I have done some research
and want to propose that we set the following strict limits on
datagram sizes:

 - IPv4 - fragment to max datagram size of 512 bytes
 - IPv6 - fragment to max datagram size of 1196 bytes

This means that the maximum size of non-fragmented syslog message
would be about:

 - IPv4 - 499 bytes
 - IPv6 - 1183 bytes

Now, the justification.  At first, I was going to propose that the
limit for non-fragmented message would be just the max IP datagram
size of 65,536 bytes and then suggest the above only as a
recommendation.  However, it is quite clear from reading the
literature that many UDP/IP implementations out there do not support
large packet sizes even though they are allowed by specifications.
This means that we will be risking low interoperability if we leave it
up to implementors or administrators to figure out when fragmentation
should kick in.  The disadvantage of specifying low size limits is
that fragmentation (and its huge overhead) kicks in faster.

Many successful UDP protocols limit IPv4 datagrams to somewhere in the
range of 512 bytes: TFTP, DNS, BOOTP, SNMP, RIP...  So, if we go with
that size, we will be safe. I presume they do it for the same reasons
of interoperability and avoiding IP fragmentation.  The 512 byte limit
for IPv4 datagrams let you stay under the 576 minimum MTU for IPv4
with all the IP headers. I derived a similar number for IPv6 (1196),
but taking its minimum MTU of 1280 and subtracting the same amount of
padding for IP header + 20 bytes for the extra size of IPv6 header.
This is the methodology suggested by IPv6 spec (rfc2460 sec 8.3).

I think that most syslog messages should be smaller than 499 bytes
and, therefore, it would good compromise between performance and
interoperability consideration to specify the above datagrams size
limits. Let me know if you agree or disagree.

Thanks,
Anton.

------------------------------

Date: Tue, 4 May 2004 08:38:47 +0200
From: "Rainer Gerhards" <[email-masked]>
Subject: RE: syslog transport fragmentation

I think this is reasonable, so I agree. Probably -protocol should  recommend that the message is below 500 bytes - an efficiency hint...

Rainer
PS: I am out of office during most of this month with limited connectivity.

- ----- Ursprüngliche Nachricht -----
   >Von: "Anton Okmianski"<[email-masked]>
   >Gesendet: 03.05.04 21:37:23
   >An: "[email-masked]"<[email-masked]>
   >Betreff: syslog transport fragmentation
   >
   >Hi!
   >
   >I am pondering what recommendations/requirements we should set for
   >maximum datagram sizes in syslog UDP transport protocol.  Messages of
   >certain size would have to be fragmented.  I have done some research
   >and want to propose that we set the following strict limits on
   >datagram sizes:
   >
   > - IPv4 - fragment to max datagram size of 512 bytes
   > - IPv6 - fragment to max datagram size of 1196 bytes
   >
   >This means that the maximum size of non-fragmented syslog message
   >would be about:
   >
   > - IPv4 - 499 bytes
   > - IPv6 - 1183 bytes
   >
   >Now, the justification.  At first, I was going to propose that the
   >limit for non-fragmented message would be just the max IP datagram
   >size of 65,536 bytes and then suggest the above only as a
   >recommendation.  However, it is quite clear from reading the
   >literature that many UDP/IP implementations out there do not support
   >large packet sizes even though they are allowed by specifications.
   >This means that we will be risking low interoperability if we leave it
   >up to implementors or administrators to figure out when fragmentation
   >should kick in.  The disadvantage of specifying low size limits is
   >that fragmentation (and its huge overhead) kicks in faster.
   >
   >Many successful UDP protocols limit IPv4 datagrams to somewhere in the
   >range of 512 bytes: TFTP, DNS, BOOTP, SNMP, RIP...  So, if we go with
   >that size, we will be safe. I presume they do it for the same reasons
   >of interoperability and avoiding IP fragmentation.  The 512 byte limit
   >for IPv4 datagrams let you stay under the 576 minimum MTU for IPv4
   >with all the IP headers. I derived a similar number for IPv6 (1196),
   >but taking its minimum MTU of 1280 and subtracting the same amount of
   >padding for IP header + 20 bytes for the extra size of IPv6 header.
   >This is the methodology suggested by IPv6 spec (rfc2460 sec 8.3).
   >
   >I think that most syslog messages should be smaller than 499 bytes
   >and, therefore, it would good compromise between performance and
   >interoperability consideration to specify the above datagrams size
   >limits. Let me know if you agree or disagree.
   >
   >Thanks,
   >Anton.
   >
   >

------------------------------

Date: Tue, 4 May 2004 11:23:12 -0400
From: "Harrington, David" <[email-masked]>
Subject: RE: syslog transport fragmentation

Hi,

If I remember correctly, the 484 byte limit of SNMP was the amount available within the UDP message. So your numbers may be slightly high still. Did you calculate in the overhead of the transport layer headers? If you plan to allow different transport mappings you should probably calculate the limit for each mapping.

dbh

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Rainer Gerhards
> Sent: Tuesday, May 04, 2004 2:39 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: syslog transport fragmentation
>
> I think this is reasonable, so I agree. Probably -protocol
> should  recommend that the message is below 500 bytes - an
> efficiency hint...
>
> Rainer
> PS: I am out of office during most of this month with limited
> connectivity.
>
> ----- Ursprüngliche Nachricht -----
>    >Von: "Anton Okmianski"<[email-masked]>
>    >Gesendet: 03.05.04 21:37:23
>    >An: "[email-masked]"<[email-masked]>
>    >Betreff: syslog transport fragmentation
>    >
>    >Hi!
>    >
>    >I am pondering what recommendations/requirements we should set for
>    >maximum datagram sizes in syslog UDP transport protocol.
> Messages of
>    >certain size would have to be fragmented.  I have done
> some research
>    >and want to propose that we set the following strict limits on
>    >datagram sizes:
>    >
>    > - IPv4 - fragment to max datagram size of 512 bytes
>    > - IPv6 - fragment to max datagram size of 1196 bytes
>    >
>    >This means that the maximum size of non-fragmented syslog message
>    >would be about:
>    >
>    > - IPv4 - 499 bytes
>    > - IPv6 - 1183 bytes
>    >
>    >Now, the justification.  At first, I was going to propose that the
>    >limit for non-fragmented message would be just the max IP datagram
>    >size of 65,536 bytes and then suggest the above only as a
>    >recommendation.  However, it is quite clear from reading the
>    >literature that many UDP/IP implementations out there do
> not support
>    >large packet sizes even though they are allowed by specifications.
>    >This means that we will be risking low interoperability
> if we leave it
>    >up to implementors or administrators to figure out when
> fragmentation
>    >should kick in.  The disadvantage of specifying low size limits is
>    >that fragmentation (and its huge overhead) kicks in faster.
>    >
>    >Many successful UDP protocols limit IPv4 datagrams to
> somewhere in the
>    >range of 512 bytes: TFTP, DNS, BOOTP, SNMP, RIP...  So,
> if we go with
>    >that size, we will be safe. I presume they do it for the
> same reasons
>    >of interoperability and avoiding IP fragmentation.  The
> 512 byte limit
>    >for IPv4 datagrams let you stay under the 576 minimum MTU for IPv4
>    >with all the IP headers. I derived a similar number for
> IPv6 (1196),
>    >but taking its minimum MTU of 1280 and subtracting the
> same amount of
>    >padding for IP header + 20 bytes for the extra size of
> IPv6 header.
>    >This is the methodology suggested by IPv6 spec (rfc2460 sec 8.3).
>    >
>    >I think that most syslog messages should be smaller than 499 bytes
>    >and, therefore, it would good compromise between performance and
>    >interoperability consideration to specify the above datagrams size
>    >limits. Let me know if you agree or disagree.
>    >
>    >Thanks,
>    >Anton.
>    >
>    >
>
>
>
>

------------------------------

Date: Wed, 5 May 2004 16:25:32 -0400
From: "Anton Okmianski" <[email-masked]>
Subject: RE: syslog transport fragmentation

David, Andrew & all:

> If I remember correctly, the 484 byte limit of SNMP was the
> amount available within the UDP message. So your numbers may
> be slightly high still. Did you calculate in the overhead of
> the transport layer headers? If you plan to allow different
> transport mappings you should probably calculate the limit
> for each mapping.

Indeed, I am proposing specific limits for UDP over IPv4 and IPv6.
This is the scope of my transport draft.

IPv4 hosts must support IP datagrams of at least 576 bytes per RFC791.
IPv4 header is min 20 bytes and max of 60 bytes. UDP header is fixed
at 8 bytes. This leaves 508-548 bytes for UDP data.

So, I am not clear where the 484 byte SNMP's minimum supported size
comes from. I can't find any rational in SNMP RFCs I looked over. Let
me know if you can shed any light or give me pointers on whom to ping.

Here is some more details on various UDP protocols I have mentioned:

DNS (RFC1035) - Hard limit: 512 bytes + UDP/IP headers

RIP (RFC1058) - Hard limit: 512 bytes + UDP/IP headers

TFTP (RFC1350) - Hard limit: 512 bytes + 4 byte header + UDP/IP header

SNMP (RFC3417) - Hosts must support 484 bytes messages, support for up
to 1472 bytes recommended and larger values are encouraged.  It is not
clear to me how it can be larger. The maximum with UDP over IPv4 and
over Ethernet is: 1500(ethernet data) - 20(ip header) - 8(udp header)
= 1472. SNMP RFC does not clearly define what a "message" is. I assume
it is the customary meaning of protocol message without UDP and IP
headers.

DHCPv4 (RFC2131) - Hosts must supports IP datagram size of 576 bytes
(this includes UDP/IP headers) + negotiable to higher size through
DHCP protocol exchange. Path MTU discovery is mentioned in related
work, but it is not clear if its use is suggested.

DHCPv6 (RFC3315) - refers readers to IPv6 RFC2460 recommendations for
packet size. IPv6 RFC sets the minimum MTU hosts must support at 1280
bytes and suggests Path MTU discovery for determining optimal MTU.  I
am not sure if this will be different for IPv6, but at least for IPv4
people have not been using Path MTU discovery for UDP much because of
non-uniform support of ICMP errors and the need for retransmissions.

BOOTP (RFC951) - can’t find any restrictions in RFCs, although 512
byte limit was mentioned in some literature about this protocol.

Based on the above, I think I'd go with what DNS and RIP do and
declare that UDP transport message over IPv4 must be within 512 bytes
without UDP/IP headers.  Given the basic header size of syslog UDP
transport of 5 bytes, this would leave 507 bytes for the maximum
non-fragmented syslog message size.

Alternatively, we can go with what I suggested earlier: 512 (or 516)
bytes including UDP header, or 504 bytes for syslog transport message
and 499 for maximum non-fragmented syslog message.  The advantage of
this approach is that even with the largest supported IPv6 header of
60 bytes, we will fit fine.

Doing what DHCPv4 does is a more flexible alternative, but it would be
more complicated for implementors to figure the exact size of IP
header (which varies), so that they don't violate the 576 byte limit
including the UDP/IP header. So, I'd rather not do it.

Anybody know of any UDP protocols that specifically talk about size of
datagrams over IPv6?

Anton.

------------------------------

>
> dbh
>
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Rainer
Gerhards
> > Sent: Tuesday, May 04, 2004 2:39 AM
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: RE: syslog transport fragmentation
> >
> > I think this is reasonable, so I agree. Probably -protocol
> > should  recommend that the message is below 500 bytes - an
> > efficiency hint...
> >
> > Rainer
> > PS: I am out of office during most of this month with limited
> > connectivity.
> >
> > ----- Ursprüngliche Nachricht -----
> >    >Von: "Anton Okmianski"<[email-masked]>
> >    >Gesendet: 03.05.04 21:37:23
> >    >An: "[email-masked]"<[email-masked]>
> >    >Betreff: syslog transport fragmentation
> >    >
> >    >Hi!
> >    >
> >    >I am pondering what recommendations/requirements we
> should set for
> >    >maximum datagram sizes in syslog UDP transport protocol.
> > Messages of
> >    >certain size would have to be fragmented.  I have done
> > some research
> >    >and want to propose that we set the following strict limits on
> >    >datagram sizes:
> >    >
> >    > - IPv4 - fragment to max datagram size of 512 bytes
> >    > - IPv6 - fragment to max datagram size of 1196 bytes
> >    >
> >    >This means that the maximum size of non-fragmented
> syslog message
> >    >would be about:
> >    >
> >    > - IPv4 - 499 bytes
> >    > - IPv6 - 1183 bytes
> >    >
> >    >Now, the justification.  At first, I was going to
> propose that the
> >    >limit for non-fragmented message would be just the max
> IP datagram
> >    >size of 65,536 bytes and then suggest the above only as a
> >    >recommendation.  However, it is quite clear from reading the
> >    >literature that many UDP/IP implementations out there do
> > not support
> >    >large packet sizes even though they are allowed by
> specifications.
> >    >This means that we will be risking low interoperability
> > if we leave it
> >    >up to implementors or administrators to figure out when
> > fragmentation
> >    >should kick in.  The disadvantage of specifying low
> size limits is
> >    >that fragmentation (and its huge overhead) kicks in faster.
> >    >
> >    >Many successful UDP protocols limit IPv4 datagrams to
> > somewhere in the
> >    >range of 512 bytes: TFTP, DNS, BOOTP, SNMP, RIP...  So,
> > if we go with
> >    >that size, we will be safe. I presume they do it for the
> > same reasons
> >    >of interoperability and avoiding IP fragmentation.  The
> > 512 byte limit
> >    >for IPv4 datagrams let you stay under the 576 minimum
> MTU for IPv4
> >    >with all the IP headers. I derived a similar number for
> > IPv6 (1196),
> >    >but taking its minimum MTU of 1280 and subtracting the
> > same amount of
> >    >padding for IP header + 20 bytes for the extra size of
> > IPv6 header.
> >    >This is the methodology suggested by IPv6 spec (rfc2460
> sec 8.3).
> >    >
> >    >I think that most syslog messages should be smaller
> than 499 bytes
> >    >and, therefore, it would good compromise between performance
and
> >    >interoperability consideration to specify the above
> datagrams size
> >    >limits. Let me know if you agree or disagree.
> >    >
> >    >Thanks,
> >    >Anton.
> >    >
> >    >
> >
> >
> >
> >
>

------------------------------

Date: Fri, 7 May 2004 06:55:18 -0700 (PDT)
From: Chris Lonvick <[email-masked]>
Subject: Updated Web Page

Hi Folks,

We've had some good discussion on Rainer's issues and he's used that to
get his latest ID out.  We are focusing on this and on Anton's ID at the
moment so we can deliver the fundamental protocol that will be used by
syslog.  We need your help.  :-)  Please review Rainer's latest work and
send your comments to the WG list.  We need reviewers to look this over
and people to say that it can be implemented well.  Once we get these
items submitted to the IESG, then we can focus on syslog-sign and the
syslog-device-mib.

Just for your reference, our web page is here:
  http://www.employees.org/~lonvick/index.shtml

Rainer's ID on the syslog protocol is here:
  http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-04.txt

Anton's ID on using UDP as the transport is here:

http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-udp-00.txt

Thanks,
Chris

------------------------------

Date: Fri, 7 May 2004 16:36:25 -0400
From: "Anton Okmianski" <[email-masked]>
Subject: Transport draft preview

This is a multi-part message in MIME format.

- ------=_NextPart_000_0005_01C43451.70B0D950
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hi!

I am about to publish the new UDP syslog transport draft. I thought I'd =
show it this forum first before making it publicly available to a wider =
audience.  In particular, I want to make sure we have rough consensus on =
support for fragmentation feature.  I have specified the header format =
using ASCII encoding as was suggested by Rainer and Andrew. =20

I plan on submitting this as an official draft next week.  One area I am =
not quite sure about yet is what minimum size of messages should =
implementations be forced to support. It definitely can't be the full =
allowed size of 16MB as some hardware won't support it. Right now it is =
set at 65k, which means implementations are forced to support =
fragmentation.  I wonder if reducing it to the size where fragmentation =
would be optional (507 bytes for IPv4 and 1911 for IPv6) would increase =
the adoption of the protocol without sacrificing too much of =
interoperability. Fragmentation feature adds orders of magnitude more =
complexity than non-fragmented syslog transport.  Any opinions?

Thanks,
Anton.=20

- ------=_NextPart_000_0005_01C43451.70B0D950
Content-Type: text/plain;
	name="draft-ietf-syslog-transport-udp-01.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="draft-ietf-syslog-transport-udp-01.txt"

=0A=
=0A=
=0A=
syslog Working Group                                        A. Okmianski=0A=
Internet-Draft                                       Cisco Systems, Inc.=0A=
Expires: November 5, 2004                                    May 7, 2004=0A=
=0A=
=0A=
                Transmission of syslog messages over UDP=0A=
                   draft-ietf-syslog-transport-udp-01=0A=
=0A=
Status of this Memo=0A=
=0A=
   This document is an Internet-Draft and is in full conformance with=0A=
   all provisions of Section 10 of RFC2026.=0A=
=0A=
   Internet-Drafts are working documents of the Internet Engineering=0A=
   Task Force (IETF), its areas, and its working groups. Note that other=0A=
   groups may also distribute working documents as Internet-Drafts.=0A=
=0A=
   Internet-Drafts are draft documents valid for a maximum of six months=0A=
   and may be updated, replaced, or obsoleted by other documents at any=0A=
   time. It is inappropriate to use Internet-Drafts as reference=0A=
   material or to cite them other than as "work in progress."=0A=
=0A=
   The list of current Internet-Drafts can be accessed at http://=0A=
   www.ietf.org/ietf/1id-abstracts.txt.=0A=
=0A=
   The list of Internet-Draft Shadow Directories can be accessed at=0A=
   http://www.ietf.org/shadow.html.=0A=
=0A=
   This Internet-Draft will expire on November 5, 2004.=0A=
=0A=
Copyright Notice=0A=
=0A=
   Copyright (C) The Internet Society (2004). All Rights Reserved.=0A=
=0A=
Abstract=0A=
=0A=
   This document describes the transport for the syslog message over=0A=
   UDP/IPv4 or UDP/IPv6. While several transport mappings are envisioned=0A=
   for the syslog protocol, syslog protocol implementors are required to=0A=
   support the transport mapping described in this document.  This=0A=
   transport specification overcomes limitations of UDP/IP datagram size=0A=
   by introducing support for fragmentation of large messages using=0A=
   multiple datagrams.=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Okmianski               Expires November 5, 2004                [Page 1]=0A=
=0C=0A=
Internet-Draft            syslog udp transport                  May 2004=0A=
=0A=
=0A=
Table of Contents=0A=
=0A=
   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3=0A=
   2.  Transport Protocol Overview  . . . . . . . . . . . . . . . . .  4=0A=
     2.1   Definitions and Architecture . . . . . . . . . . . . . . .  4=0A=
     2.2   Required Transport Protocol  . . . . . . . . . . . . . . .  4=0A=
     2.3   Encapsulation Layers . . . . . . . . . . . . . . . . . . .  4=0A=
   3.  Message Format . . . . . . . . . . . . . . . . . . . . . . . .  6=0A=
     3.1   Basic Header Format  . . . . . . . . . . . . . . . . . . .  6=0A=
     3.2   Extended Header Format . . . . . . . . . . . . . . . . . .  7=0A=
       3.2.1   Message Identifier . . . . . . . . . . . . . . . . . .  7=0A=
       3.2.2   Total Length . . . . . . . . . . . . . . . . . . . . .  7=0A=
       3.2.3   Fragment Offset  . . . . . . . . . . . . . . . . . . .  8=0A=
       3.2.4   Extended Header Example  . . . . . . . . . . . . . . .  8=0A=
     3.3   Payload  . . . . . . . . . . . . . . . . . . . . . . . . .  9=0A=
     3.4   Supported Message Length . . . . . . . . . . . . . . . . .  9=0A=
   4.  UDP/IP Layer Considerations  . . . . . . . . . . . . . . . . . 10=0A=
     4.1   Target Port  . . . . . . . . . . . . . . . . . . . . . . . 10=0A=
     4.2   Source Port  . . . . . . . . . . . . . . . . . . . . . . . 10=0A=
     4.3   Source IP Address  . . . . . . . . . . . . . . . . . . . . 10=0A=
     4.4   UDP/IP Headers . . . . . . . . . . . . . . . . . . . . . . 10=0A=
   5.  Fragmentation and Reassembley  . . . . . . . . . . . . . . . . 12=0A=
     5.1   Message Fragmentation  . . . . . . . . . . . . . . . . . . 12=0A=
     5.2   Message Reassembley  . . . . . . . . . . . . . . . . . . . 12=0A=
     5.3   Avoiding Fragmentation . . . . . . . . . . . . . . . . . . 13=0A=
   6.  Reliability Considerations . . . . . . . . . . . . . . . . . . 14=0A=
     6.1   Lost Datagrams . . . . . . . . . . . . . . . . . . . . . . 14=0A=
     6.2   Message Corruption and Checksums . . . . . . . . . . . . . 14=0A=
     6.3   Congestion Control . . . . . . . . . . . . . . . . . . . . 14=0A=
     6.4   Sequenced Delivery . . . . . . . . . . . . . . . . . . . . 14=0A=
     6.5   Sender Authentication  . . . . . . . . . . . . . . . . . . 15=0A=
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16=0A=
     7.1   Message Authenticity . . . . . . . . . . . . . . . . . . . 16=0A=
     7.2   Message Forgery  . . . . . . . . . . . . . . . . . . . . . 16=0A=
     7.3   Message Observation  . . . . . . . . . . . . . . . . . . . 16=0A=
     7.4   Replaying  . . . . . . . . . . . . . . . . . . . . . . . . 17=0A=
     7.5   Unreliable Delivery  . . . . . . . . . . . . . . . . . . . 17=0A=
     7.6   Message Prioritization and Differentiation . . . . . . . . 17=0A=
     7.7   Denial of Service  . . . . . . . . . . . . . . . . . . . . 18=0A=
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19=0A=
   9.  Notice to RFC Editor . . . . . . . . . . . . . . . . . . . . . 20=0A=
   10.   Authors and Working Group Chair  . . . . . . . . . . . . . . 21=0A=
   11.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22=0A=
   12.   References . . . . . . . . . . . . . . . . . . . . . . . . . 22=0A=
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 23=0A=
   A.  Rational For Transport Message Size Restrictions . . . . . . . 24=0A=
       Intellectual Property and Copyright Statements . . . . . . . . 26=0A=
=0A=
=0A=
=0A=
=0A=
Okmianski               Expires November 5, 2004                [Page 2]=0A=
=0C=0A=
Internet-Draft            syslog udp transport                  May 2004=0A=
=0A=
=0A=
1.  Introduction=0A=
=0A=
   The original syslog protocol has been described in an informational=0A=
   RFC 3164 [1] as it has been observed in existing implementations. It=0A=
   describes both the semantics of syslog message format as well as a=0A=
   UDP transport.  Subsequently, the syslog protocol has been formally=0A=
   defined in a standards track RFC-protocol [2].=0A=
=0A=
   The RFC-protocol [2] has provided for support of any number of=0A=
   transport layer protocols for transmitting syslog messages and left=0A=
   it to subsequent RFCs to specify transport protocols. This standards=0A=
   track RFC describes the UDP transport for the syslog protocol. This=0A=
   transport protocol is REQUIRED for all syslog protocol=0A=
   implementations.=0A=
=0A=
   This transport protocol was designed to work on top of UDP [3] over=0A=
   both IPv4 [4] and IPv6 [5]. This protocol overcomes the data size=0A=
   restrictions of the UDP protocol by introducing message fragmentation=0A=
   feature.=0A=
=0A=
   As we will show in this specification, this protocol has significant=0A=
   reliability and security issues stemming from the use of UDP.=0A=
   However, this protocol is lightweight and extends on the existing=0A=
   popular use of UDP for syslog. Network administrators and architects=0A=
   should be aware of the shortcomings of this protocol and plan=0A=
   accordingly.=0A=
=0A=
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0A=
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=0A=
   document are to be interpreted as described in RFC 2119 [6]. The=0A=
   words 'byte' and 'octet' are used interchangeably in this=0A=
   specification.=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Okmianski               Expires November 5, 2004                [Page 3]=0A=
=0C=0A=
Internet-Draft            syslog udp transport                  May 2004=0A=
=0A=
=0A=
2.  Transport Protocol Overview=0A=
=0A=
2.1  Definitions and Architecture=0A=
=0A=
   The following definitions will be used in this document:=0A=
   o  An application that can generate syslog messages will be referred=0A=
      to as a "sender";=0A=
   o  An application that can receive syslog messages will be referred=0A=
      to as a "receiver".=0A=
=0A=
   An application can function in dual capacity. For example, a syslog=0A=
   relay may receive and forward messages. A single system can host any=0A=
   number of syslog senders. Only one syslog receiver can be hosted on a=0A=
   single system using the standard listening port.=0A=
=0A=
2.2  Required Transport Protocol=0A=
=0A=
   This document describes the UDP transport layer protocol for the=0A=
   syslog protocol RFC-protocol [2]. Every syslog sender and receiver=0A=
   implementation which adheres to the RFC-protocol [2] MUST fully=0A=
   implement the transport protocol specified in this document.=0A=
   Implementations does not have to support both IPv4 and IPv6 if it is=0A=
   designed to be used over only one of these protocols.=0A=
=0A=
2.3  Encapsulation Layers=0A=
=0A=
   Syslog UDP transport carries syslog messages as generic payload=0A=
   encapsulated with a syslog transport header, UDP header and an IP=0A=
   header. Below is a summary of syslog UDP/IP packet structure as used=0A=
   this transport protocol:=0A=
=0A=
=0A=
   		+--------------------------------+=0A=
   		|       IPv4 or IPv6 Header      |=0A=
   		|        (20 or more bytes)      |=0A=
   		+--------------------------------+=0A=
   		|           UDP Header           |=0A=
   		|           (8 bytes)            |=0A=
   		+--------------------------------+=0A=
   		|    Syslog Transport Header     |=0A=
   		|        (5 or 32 bytes)         |=0A=
   		+--------------------------------+=0A=
   		|     Syslog Message Payload     |=0A=
   		|       (1 to 1191 bytes)        |=0A=
   		+--------------------------------+=0A=
=0A=
   Small syslog messages are transmitted using one UDP/IP datagram per=0A=
   message. However, syslog protocol [2] allows messages as large as=0A=
=0A=
=0A=
=0A=
Okmianski               Expires November 5, 2004                [Page 4]=0A=
=0C=0A=
Internet-Draft            syslog udp transport                  May 2004=0A=
=0A=
=0A=
   16777216 bytes, while UDP/IP datagram cannot exceed a total size of=0A=
   65526 bytes [3] and most existing protocols restrict the size of UDP=0A=
   data to much less. In order to support transmitting large messages=0A=
   over UDP/IP, this transport protocol supports fragmentation of large=0A=
   syslog messages into multiple UDP/IP datagrams for transmission and=0A=
   reassembley on the receiving end.=0A=
=0A=
   Each syslog UDP/IP datagram MUST contain one and only one complete=0A=
   syslog message or one fragment of a message.  Transmitting multiple=0A=
   messages or multiple fragments of different messages in a single UDP=0A=
   datagram is not supported by this protocol.=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Okmianski               Expires November 5, 2004                [Page 5]=0A=
=0C=0A=
Internet-Draft            syslog udp transport                  May 2004=0A=
=0A=
=0A=
3.  Message Format=0A=
=0A=
   The syslog transport message consist of a transport header and a=0A=
   syslog message payload. The format of the transport header is=0A=
   different for fragmented and non-fragmented messages.  Basic=0A=
   transport header is used for non-fragmented messages and extended=0A=
   transport header is used for fragmented messages.=0A=
=0A=
   An ASCII-based encoding was chosen for the syslog transport for=0A=
   consistency with the RFC-protocol [2].  Syslog transport datagrams=0A=
   without required UDP and IP headers have the following format in ABNF=0A=
   [7] notation:=0A=
=0A=
=0A=
       SyslogTransportMessage =3D ( BasicHeader / ExtendedHeader )=0A=
                                         SP Payload=0A=
=0A=
       BasicHeader     =3D Version SP "0"=0A=
       Version         =3D %d118 1*3DIGIT   ; "v1" in this version=0A=
=0A=
       ExtendedHeader  =3D Version SP "1" SP MessageId=0A=
                         SP TotalLength SP FragmentOffset=0A=
=0A=
       MessageId       =3D 1*8DIGIT        ; 0 to 16777215=0A=
       TotalLength     =3D 1*8DIGIT        ; 1 to 16777216=0A=
       FragmentOffset  =3D 1*8DIGIT        ; 0 to 16777215=0A=
       Payload         =3D 1*1191OCTET=0A=
=0A=
       OCTET           =3D %d00-255=0A=
       DIGIT           =3D %d48-57=0A=
       SP              =3D %d32=0A=
=0A=
=0A=
3.1  Basic Header Format=0A=
=0A=
   When no fragmentation is used and the entire syslog message is=0A=
   transferred as a single UDP/IP datagram, a basic syslog transport=0A=
   header MUST be used.  The version for this protocol is "1". It must=0A=
   be followed by one space and a "0" to indicate that this is a basic=0A=
   header.   Therefore, the only possible value for the basic header in=0A=
   this protocol is as follows:=0A=
=0A=
=0A=
      "v1 0 "=0A=
=0A=
   Example of a syslog message without the transport header (message is=0A=
   wrapped for display):=0A=
=0A=
=0A=
=0A=
=0A=
Okmianski               Expires November 5, 2004                [Page 6]=0A=
=0C=0A=
Internet-Draft            syslog udp transport                  May 2004=0A=
=0A=
=0A=
      "v1 888 3 2003-10-11T22:14:15.003Z host.domain.com=0A=
      dns: configuration error"=0A=
=0A=
   Example of the same message with the transport header (message is=0A=
   wrapped for display):=0A=
=0A=
=0A=
      "v1 0 v1 888 4 2003-10-11T22:14:15.003Z host.domain.com=0A=
      dns: configuration error"=0A=
=0A=
=0A=
3.2  Extended Header Format=0A=
=0A=
   When syslog message is fragmented by the sender, multiple UDP=0A=
   datagrams must be used and each datagram MUST contain an extended=0A=
   syslog transport header. The version for this protocol is "1". The=0A=
   version field MUST be followed by a single space and a "1" to=0A=
   indicate that this is an extended header.  Thus, an extended header=0A=
   MUST always begin with "v1 1 ", but MUST also have additional fields=0A=
   which aid in fragmentation.=0A=
=0A=
   The MessageId, TotalLength and FragmentOffset fields are used solely=0A=
   for fragmentation of long messages and reassembley.  They SHOULD NOT=0A=
   be used for other purposes.=0A=
=0A=
3.2.1  Message Identifier=0A=
=0A=
   The MessageId field (along with the source UDP port and the IP=0A=
   address) is used to identify the message such that fragments of a=0A=
   single syslog message can be reassembled by the receiver into a=0A=
   complete message.  The MessageId field MUST be a numeric value in the=0A=
   range of 0 to 16777215.  Leading zeros MUST not be present in the=0A=
   MessageId field.=0A=
=0A=
   Each syslog sender process MUST choose a random MessageId value=0A=
   within the supported range for its first message. Subsequent messages=0A=
   generated by the same process MUST each increment the MessageId by 1=0A=
   up to 16777215 and then continue at 0. Using random value for the=0A=
   first MessageId helps reduce the possibility of potential errors in=0A=
   message reassembley. Refer to discussion about message reassembley=0A=
   (Section 5.2) for more details.=0A=
=0A=
   All datagrams which represent parts of a given fragmented syslog=0A=
   message MUST have the same MessageId value.=0A=
=0A=
3.2.2  Total Length=0A=
=0A=
   The TotalLength field MUST be a numeric value in the range of 1 to=0A=
=0A=
=0A=
=0A=
Okmianski               Expires November 5, 2004                [Page 7]=0A=
=0C=0A=
Internet-Draft            syslog udp transport                  May 2004=0A=
=0A=
=0A=
   16777216. It MUST indicate the length of a complete syslog message=0A=
   before it was fragmented and before it was encapsulated with=0A=
   transport headers.  The same TotalLength field value MUST be present=0A=
   in all UDP datagrams which represent fragments of the same syslog=0A=
   message. Leading zeros MUST not be present in the TotalLength field.=0A=
=0A=
   Note that in IPv4 the "total length" field identifies the length of a=0A=
   single packet.  In this protocol, the TotalLength field is used to=0A=
   identify the total length of a complete syslog message, which is=0A=
   transmitted using multiple fragments and multiple datagram packets.=0A=
   The fragment length is not specified in the transport header because=0A=
   it can be inferred from the size of the IP packet containing the UDP=0A=
   datagram.=0A=
=0A=
3.2.3  Fragment Offset=0A=
=0A=
   The FragmentOffset field MUST be a numeric value in the range of 0 to=0A=
   16777215. It MUST indicate the byte offset of the fragment data in=0A=
   the complete syslog message. The offset index starts at 0 for the=0A=
   first fragment. For example, if an 700 byte syslog message is=0A=
   fragmented into 480 and 220 byte parts, the FragmentOffset in the=0A=
   first message will be 0 and in the second - 480. Note that fragments=0A=
   don't have to be the same size.  Leading zeros MUST not be present in=0A=
   the FragmentOffset field.=0A=
=0A=
3.2.4  Extended Header Example=0A=
=0A=
   The following is an example of a syslog message without the transport=0A=
   header (message is wrapped for display):=0A=
=0A=
=0A=
      "v1 888 4 2003-10-11T22:14:15.003Z host.domain.com=0A=
      dns: configuration error"=0A=
=0A=
   Suppose this message had to be fragmented by transport layer into two=0A=
   parts at an arbitrary point.  This would result in two separate UDP=0A=
   datagrams being sent - one for each fragment. Below is the content of=0A=
   each of the syslog transport UDP messages with syslog transport=0A=
   headers but without UDP/IP headers:=0A=
=0A=
=0A=
      "v1 1 45612221 74 0 v1 888 4 2003-10-11T22:14:15.003Z host.dom"=0A=
=0A=
      "v1 1 45612221 74 42 ain.com dns: configuration error"=0A=
=0A=
   In the above example, the leading "v1" is the version of the=0A=
   transport protocol, "1" indicates that this is an extended header=0A=
   (fragmentation in use), "45612221" is the MessageId, "74" is the=0A=
=0A=
=0A=
=0A=
Okmianski               Expires November 5, 2004                [Page 8]=0A=
=0C=0A=
Internet-Draft            syslog udp transport                  May 2004=0A=
=0A=
=0A=
   TotalLength of the message, while "0" and "42" are FragmentOffset=0A=
   fields. Everything following the FragmentOffset and a space is a the=0A=
   Payload of each respective message.=0A=
=0A=
3.3  Payload=0A=
=0A=
   The Payload field of the syslog UPD transport message is an entire=0A=
   syslog message or one fragment. The maximum Payload size depends on=0A=
   the IP protocol used and the type header that is used.=0A=
=0A=
      Maximum Payload size:=0A=
=0A=
      With IPv4 and basic header:    507 bytes=0A=
      With IPv4 and extended header: 480 bytes=0A=
=0A=
      With IPv6 and basic header:    1191 bytes=0A=
      With IPv6 and extended header: 1164 bytes=0A=
=0A=
   The Payload size restrictions above effectively mean that the largest=0A=
   syslog message that can be sent non-fragmented is 507 bytes for=0A=
   transport via IPv4 and 1191 bytes for transport via IPv6.=0A=
=0A=
   For a discussion of the relational behind the above size restrictions=0A=
   please refer to Appendix A.=0A=
=0A=
3.4  Supported Message Length=0A=
=0A=
   The maximum syslog message length supported by this protocol is the=0A=
   maximum value of the TotalLength field, which is 16777216 bytes.=0A=
   However, not all deployment scenarios for syslog will be on hosts=0A=
   with hardware capable of supporting the maximum length of messages=0A=
   supported by this protocol. Additionally, extremely large messages=0A=
   may not be needed in many environments. Therefore, implementations=0A=
   are NOT REQUIRED to support the maximum message length allowed by=0A=
   this protocol.=0A=
=0A=
   All implementations MUST support sending and receiving syslog=0A=
   messages up to and including 65536 bytes in size (syslog transport=0A=
   and UDP/IP headers are extra). Support for larger messages is=0A=
   encouraged. Implementors SHOULD clearly state the maximum supported=0A=
   message size in documentation.=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Okmianski               Expires November 5, 2004                [Page 9]=0A=
=0C=0A=
Internet-Draft            syslog udp transport                  May 2004=0A=
=0A=
=0A=
4.  UDP/IP Layer Considerations=0A=
=0A=
4.1  Target Port=0A=
=0A=
   Syslog receivers MUST support accepting syslog message datagrams on a=0A=
   well-known UDP port 514.  Syslog senders MUST support sending syslog=0A=
   message datagrams to the UDP port 514.=0A=
=0A=
4.2  Source Port=0A=
=0A=
   Syslog senders can use any source UDP port for transmitting messages.=0A=
   Senders MAY randomly select a source port, but MUST use the port in=0A=
   an exclusive fashion. No concurrent port reuse on the same host is=0A=
   allowed.=0A=
=0A=
   Each syslog sender process MUST attempt to use the same source port=0A=
   for the life of the the process.  If due to an error or other=0A=
   condition it becomes impossible for the process to continue to use=0A=
   the same port, it MAY start using a new source port, but it MUST=0A=
   generate a new random MessageId for the first message after changing=0A=
   the port and then MUST continue incrementing the new MessageId value=0A=
   for subsequent messages.=0A=
=0A=
   Since source port is used to identify parts of a fragmented message,=0A=
   the sender MUST use the same port to send all fragments of a given=0A=
   message.  If due to an error or other condition, the sender is unable=0A=
   to do that, it MUST resend all message fragments using the new port=0A=
   and a new MessageId field value.=0A=
=0A=
4.3  Source IP Address=0A=
=0A=
   The source IP address of the UDP datagrams is one of the data=0A=
   elements used to identify parts of a fragmented message.  Therefore,=0A=
   a syslog sender MUST attempt to use the same source IP address to=0A=
   send all fragments of a given syslog message.  If due to an error,=0A=
   reconfiguration or other condition it is unable to do so, the sender=0A=
   MUST resend all fragments of the syslog message using the new source=0A=
   IP address and a new MessageId value.=0A=
=0A=
4.4  UDP/IP Headers=0A=
=0A=
   Each UDP/IP datagram sent by the transport layer MUST completely=0A=
   adhere to the structure specified in the UDP RFC 768 [3] and either=0A=
   IPv4 RFC 791 [4] or IPv6 RFC 2640 [5] depending on which protocol is=0A=
   used.=0A=
=0A=
   Use of UDP checksums was defined as optional in RFC 768 [3]. IPv6 has=0A=
   subsequently made UDP checksums required [5].  However, syslog=0A=
=0A=
=0A=
=0A=
Okmianski               Expires November 5, 2004               [Page 10]=0A=
=0C=0A=
Internet-Draft            syslog udp transport                  May 2004=0A=
=0A=
=0A=
   senders MUST utilize valid UDP checksums when sending messages over=0A=
   either IPv4 or IPv6. Syslog receivers MUST check for checksums and=0A=
   discard messages with incorrect checksums. Note that this is=0A=
   typically accomplished by the UDP layer implementation, and some=0A=
   implementations allow for checksum checks to be enabled or disabled.=0A=
=0A=
   Enabling use of checksums serves as an extra measure of corruption=0A=
   detection in addition to checksums performed by IP and Ethernet=0A=
   layers. None of the above checksums provide a complete guarantee of=0A=
   corruption detection. Utilizing checksums on multiple layers reduces=0A=
   the chance of corruption error not being detected.=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Okmianski               Expires November 5, 2004               [Page 11]=0A=
=0C=0A=
Internet-Draft            syslog udp transport                  May 2004=0A=
=0A=
=0A=
5.  Fragmentation and Reassembley=0A=
=0A=
5.1  Message Fragmentation=0A=
=0A=
   The syslog transport layer MUST perform fragmentation if syslog=0A=
   message size exceeds the maximum allowed Payload size. Fragmentation=0A=
   SHOULD NOT be used if message can fit into the maximum allowed=0A=
   Payload size.=0A=
=0A=
   Syslog messages SHOULD be fragmented such that all but last message=0A=
   utilize the Payload to its maximum capacity.  For example, when using=0A=
   IPv4, a 700 byte syslog message SHOULD be fragmented into 480 and 220=0A=
   byte parts because the maximum Payload size with IPv4 and extended=0A=
   header is 480 bytes.=0A=
=0A=
   Each message fragment MUST be sent as a separate UDP/IP datagram with=0A=
   an extended syslog transport header.  The sender MUST use the same=0A=
   MessageId value, source port and source IP address for all fragments=0A=
   of a given message. These three field together uniquely identify=0A=
   fragments belonging to a given message.=0A=
=0A=
   On a system with short-lived sender processes, it may be possible=0A=
   that fragments with the same MessageId value, source port and source=0A=
   IP address will get generated in short time proximity.  This can be=0A=
   possible because a new process may re-use the source port that was=0A=
   freed up by another process that just dies.  Such behavior could=0A=
   confuse the receiver if the datagrams were received out of order or=0A=
   some datagrams got lost.=0A=
=0A=
   In order to reduce the risk of such mistaken identity errors, section=0A=
   3.2.1 specified that each process must start with a random value for=0A=
   MessageId field.  Given a relatively large range of MessageId values=0A=
   and the unlikely event of a coincidence of having the same MessageId=0A=
   value combined with re-used source port and UPD errors, the window=0A=
   for potential mistaken identity errors during message reassembley is=0A=
   very small and tolerable. The users take a greater risk by using this=0A=
   protocol due to general UDP reliability issues discussed later in=0A=
   this specification.=0A=
=0A=
5.2  Message Reassembley=0A=
=0A=
   The reassembley process uses the source IP address from the IP=0A=
   header, the source port from the UDP header and the MessageId field=0A=
   value to identify fragments of a given message. It then uses data=0A=
   from TotalLength and FragmentOffset fields to re-assemble fragments=0A=
   into a complete message.=0A=
=0A=
   Typically, an implementation of fragmentation reassembley involves=0A=
=0A=
=0A=
=0A=
Okmianski               Expires November 5, 2004               [Page 12]=0A=
=0C=0A=
Internet-Draft            syslog udp transport                  May 2004=0A=
=0A=
=0A=
   allocating a buffer for the message when any fragment with a new=0A=
   combination of source IP address, source port and MessageId is=0A=
   received. A timer is used to expire the message reassembley and clean=0A=
   the buffer if all fragments are not received in certain time period.=0A=
   As each fragment is received, it is placed into the buffer at the=0A=
   appropriate offset and a check is performed to determine if all=0A=
   fragments have been received using additional data structures.=0A=
=0A=
   The receiver SHOULD make the timeout interval used for message=0A=
   reassembley configurable for the administrator.  The receiver SHOULD=0A=
   also be able to limit the total amount of memory used for buffers=0A=
   such that it does not run out of resources under a simple denial of=0A=
   service attack involving just one message fragment with a large=0A=
   TotalLength field value. Degrading the service under heavy load or=0A=
   attack is better than crashing and potentially making the service=0A=
   completely unavailable.=0A=
=0A=
5.3  Avoiding Fragmentation=0A=
=0A=
   Fragmentation and reassembley of messages incurs substantial=0A=
   processing overhead on both the sender and the receiver hosts. It=0A=
   also increases the risk of lost messages due to lose of just one=0A=
   fragment. It is RECOMMENDED that syslog senders which anticipate=0A=
   sending messages over this transport protocol attempt to reduce the=0A=
   number of messages which require fragmentation by restricting them to=0A=
   the size which does not require fragmentation.=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Okmianski               Expires November 5, 2004               [Page 13]=0A=
=0C=0A=
Internet-Draft            syslog udp transport                  May 2004=0A=
=0A=
=0A=
6.  Reliability Considerations=0A=
=0A=
   The UDP is an unreliable low-overhead protocol. This section=0A=
   discusses reliability issues inherent in the UDP that implementers=0A=
   and users must be aware of.=0A=
=0A=
6.1  Lost Datagrams=0A=
=0A=
   Neither UDP nor syslog protocol provide any mechanism to detect and=0A=
   correct loss of datagrams.  Datagrams may be lost in transit due to=0A=
   congestion, corruption or any other intermittent network problem.=0A=
   Syslog protocol and IP fragmentation exacerbates the problem because=0A=
   loss of a single fragment would result in entire message being=0A=
   discarded.=0A=
=0A=
   In some circumstances the sender may receive an ICMP error message or=0A=
   other indication of a transmission problem. If the sender receives a=0A=
   reasonable indication that some datagram may have been lost, it MAY=0A=
   retransmit previously sent messages.=0A=
=0A=
6.2  Message Corruption and Checksums=0A=
=0A=
   The UDP/IP datagrams may get corrupted in transit due to software,=0A=
   hardware or network errors. This protocol specified use of UDP=0A=
   checksums to enable corruption detection in addition to checksums=0A=
   utilized in IP and Ethernet layers. However, checksums do not=0A=
   guarantee corruption detection and this protocol does not provide for=0A=
   message retransmission when a corrupt message is detected.=0A=
=0A=
6.3  Congestion Control=0A=
=0A=
   The UDP does not provide for congestion control. Some systems (hosts=0A=
   or routers) may generate ICMP source quench error, but they are not=0A=
   required to do so [8].  Any network host can discard UDP packets when=0A=
   it is overloaded. Due to lack of congestion control one or multiple=0A=
   syslog senders can maliciously or inadvertently overload the receiver=0A=
   or the network infrastructure and cause loss of syslog messages.=0A=
=0A=
6.4  Sequenced Delivery=0A=
=0A=
   The IP transport utilized by the UDP does not guarantee that the=0A=
   sequence of datagram delivery will match the order in which the=0A=
   datagrams have been sent. The time stamp contained within each syslog=0A=
   message may serve as some guide in establishing sequence order, but=0A=
   it will not help in cases when multiple messages were generated=0A=
   during the same time slot or when messages originated from different=0A=
   hosts whose clocks are not synchronized. The order of syslog message=0A=
   arrival via the this syslog transport SHOULD NOT be used as an=0A=
=0A=
=0A=
=0A=
Okmianski               Expires November 5, 2004               [Page 14]=0A=
=0C=0A=
Internet-Draft            syslog udp transport                  May 2004=0A=
=0A=
=0A=
   authoritative guide in establishing the sequence of events on the=0A=
   syslog sender hosts.=0A=
=0A=
6.5  Sender Authentication=0A=
=0A=
   The UDP syslog transport does not strongly associate the message with=0A=
   the message sender.  The receiver of the syslog message will not be=0A=
   able to ascertain that the message was indeed sent from the reported=0A=
   sender, or if the packet was sent from another device.=0A=
=0A=
   One possible consequence of this behavior is that a misconfigured=0A=
   machine may send syslog messages to a receiver representing itself as=0A=
   another machine. The administrators may not be able to readily=0A=
   discern that there are two or more machines representing themselves=0A=
   as the same machine.=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Okmianski               Expires November 5, 2004               [Page 15]=0A=
=0C=0A=
Internet-Draft            syslog udp transport                  May 2004=0A=
=0A=
=0A=
7.  Security Considerations=0A=
=0A=
   Several syslog security considerations have been discussed in=0A=
   RFC-protocol [2] and in the original RFC 3164 [1]. This section=0A=
   focuses on security considerations specific to the syslog transport=0A=
   over UDP.=0A=
=0A=
7.1  Message Authenticity=0A=
=0A=
   This transport protocol does not strongly authenticate the identity=0A=
   of the message sender and does not provide any assurance that the=0A=
   message was not modified in transit. The receiver of the syslog=0A=
   message will not be able to ascertain that the message was indeed=0A=
   sent from the reported sender, or if the packet was sent from another=0A=
   device.=0A=
=0A=
7.2  Message Forgery=0A=
=0A=
   Syslog messages can be easily forged. An attacker may transmit syslog=0A=
   messages (either from the machine from which the messages are=0A=
   purportedly sent or from any other machine) to a receiver.=0A=
=0A=
   In one case, an attacker may hide the true nature of an attack amidst=0A=
   many other messages.  As an example, an attacker may start generating=0A=
   forged messages indicating a problem on some machine.  This may get=0A=
   the attention of the system administrators who will spend their time=0A=
   investigating the alleged problem.  During this time, the attacker=0A=
   may be able to compromise a different machine, or a different process=0A=
   on the same machine.=0A=
=0A=
   Additionally, an attacker may generate false syslog messages to give=0A=
   untrue indications of status or of events.  As an example, an=0A=
   attacker may stop a critical process on a machine, which may generate=0A=
   a notification of exit.  The attacker may subsequently generate a=0A=
   forged notification that the process had been restarted.  The system=0A=
   administrators may accept that misinformation and not verify that the=0A=
   process had indeed been restarted.=0A=
=0A=
7.3  Message Observation=0A=
=0A=
   The transport protocol does not provide confidentiality of the=0A=
   messages in transit. If syslog messages are in clear text, this is=0A=
   how they will be transferred.  In most cases passing clear-text=0A=
   human-readable messages is a benefit to the administrators.=0A=
   Unfortunately, an attacker may also be able to observe the=0A=
   human-readable contents of syslog messages.  The attacker may then=0A=
   use the knowledge gained from those messages to compromise a machine=0A=
   or do other damage. It is RECOMMENDED that no sensitive information=0A=
=0A=
=0A=
=0A=
Okmianski               Expires November 5, 2004               [Page 16]=0A=
=0C=0A=
Internet-Draft            syslog udp transport                  May 2004=0A=
=0A=
=0A=
   is transmitted via this transport protocol or that transmission of=0A=
   such information is restricted to properly secured networks.=0A=
=0A=
7.4  Replaying=0A=
=0A=
   Message forgery and observation can be combined into a replay attack.=0A=
   An attacker may record a set of messages that indicate normal=0A=
   activity of a machine.  At a later time, that attacker may remove=0A=
   that machine from the network and replay the syslog messages to the=0A=
   collector with new time stamps. The administrators may find nothing=0A=
   unusual in the received messages and their receipt would falsely=0A=
   indicate normal activity of the machine.=0A=
=0A=
7.5  Unreliable Delivery=0A=
=0A=
   As was previously discussed in the Reliability Considerations=0A=
   section, the UDP transport is not reliable and packets containing=0A=
   syslog message datagrams can be lost in transit without any notice.=0A=
   There can be security consequences to the loss of one or more syslog=0A=
   messages.  Administrators may not become aware of a developing and=0A=
   potentially serious problem. Messages may also be intercepted and=0A=
   discarded by an attacker as a way to hide unauthorized activities.=0A=
=0A=
7.6  Message Prioritization and Differentiation=0A=
=0A=
   The transport protocol described in this document does not require=0A=
   prioritization of syslog messages on the wire or when processed on=0A=
   the receiving host based on their severity.  The security implication=0A=
   of such behavior is that the syslog receiver or network devices may=0A=
   get overwhelmed with low severity messages and be forced to discard=0A=
   potentially high severity messages. High severity messages may=0A=
   contain indication about serious security problems, but they will not=0A=
   get a higher priority. It is difficult to make sure that high=0A=
   severities messages get higher end-to-end delivery priority,=0A=
   especially over an unreliable UDP transport.=0A=
=0A=
   On a case-by-case basis, device operators may find some way to=0A=
   associate the different severity levels with the quality of service=0A=
   identifiers.  As an example, the operators may elect to define some=0A=
   linkage between syslog messages that have a specific Priority value=0A=
   with a specific value to be used in the IPv4 Precedence field [4],=0A=
   the IPv6 Traffic Class octet [5], or the Differentiated Services=0A=
   field [9].  However, even with this prioritization on the network,=0A=
   high load can lead to buffer starvation on the receiving host and=0A=
   result in dropped messages.=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Okmianski               Expires November 5, 2004               [Page 17]=0A=
=0C=0A=
Internet-Draft            syslog udp transport                  May 2004=0A=
=0A=
=0A=
7.7  Denial of Service=0A=
=0A=
   An attacker may overwhelm a receiver by sending more messages to it=0A=
   than can be handled by the infrastructure or the device itself.=0A=
   Implementers SHOULD attempt to provide features that minimize this=0A=
   threat such as only receiving syslog messages from known IP=0A=
   addresses.=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Okmianski               Expires November 5, 2004               [Page 18]=0A=
=0C=0A=
Internet-Draft            syslog udp transport                  May 2004=0A=
=0A=
=0A=
8.  IANA Considerations=0A=
=0A=
   IANA must reserve UDP port 514 for this transport.=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Okmianski               Expires November 5, 2004               [Page 19]=0A=
=0C=0A=
Internet-Draft            syslog udp transport                  May 2004=0A=
=0A=
=0A=
9.  Notice to RFC Editor=0A=
=0A=
   This is a notice to the RFC editor. This ID is submitted along with=0A=
   ID draft-ietf-syslog-protocol and they cross-reference each other.=0A=
   When RFC numbers are determined for each of these IDs, please replace=0A=
   all references to "RFC-protocol" with the RFC number of=0A=
   draft-ietf-syslog-protocol ID.  Please remove this section after=0A=
   editing.=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Okmianski               Expires November 5, 2004               [Page 20]=0A=
=0C=0A=
Internet-Draft            syslog udp transport                  May 2004=0A=
=0A=
=0A=
10.  Authors and Working Group Chair=0A=
=0A=
   The working group can be contacted via the mailing list:=0A=
=0A=
   [email-masked]=0A=
=0A=
   The current Chair of the Working Group may be contacted at:=0A=
=0A=
   Chris Lonvick=0A=
   Cisco Systems=0A=
   Email: [email-masked]=0A=
=0A=
   The author of this draft is:=0A=
=0A=
   Anton Okmianski=0A=
   Email: [email-masked]=0A=
=0A=
   Phone: (978) 936-1612=0A=
   Fax: (978) 936-2225=0A=
=0A=
   Cisco Systems, Inc=0A=
   1414 Massachusetts Ave.=0A=
   Boxborough, MA 01719-2205=0A=
   USA=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Okmianski               Expires November 5, 2004               [Page 21]=0A=
=0C=0A=
Internet-Draft            syslog udp transport                  May 2004=0A=
=0A=
=0A=
11.  Acknowledgements=0A=
=0A=
   The author wishes to thank Chris Lonvick, Rainer Gerhards, David=0A=
   Harrington, Andrew Ross, Albert Mietus, Bernie Volz, and all others=0A=
   who have commented on the various versions of this proposal.=0A=
=0A=
12  References=0A=
=0A=
   [1]   Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001.=0A=
=0A=
   [2]   Gerhards, R., "The syslog Protocol", RFC RFC-protocol.=0A=
=0A=
   [3]   Postel, J., "User Datagram Protocol", STD 6, RFC 768, August=0A=
         1980.=0A=
=0A=
   [4]   Postel, J., "Internet Protocol", STD 5, RFC 791, September=0A=
         1981.=0A=
=0A=
   [5]   Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)=0A=
         Specification", RFC 2460, December 1998.=0A=
=0A=
   [6]   Bradner, S., "Key words for use in RFCs to Indicate Requirement=0A=
         Levels", BCP 14, RFC 2119, March 1997.=0A=
=0A=
   [7]   Crocker, D. and P. Overell, "Augmented BNF for Syntax=0A=
         Specifications: ABNF", RFC 2234, November 1997.=0A=
=0A=
   [8]   Stevens, W., "TCP/IP Illustrated Volume 1. The Protocols.",=0A=
         January 1994.=0A=
=0A=
   [9]   Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of=0A=
         the Differentiated Services Field (DS Field) in the IPv4 and=0A=
         IPv6 Headers", RFC 2474, December 1998.=0A=
=0A=
   [10]  Mockapetris, P., "Domain names - implementation and=0A=
         specification", STD 13, RFC 1035, November 1987.=0A=
=0A=
   [11]  Hedrick, C., "Routing Information Protocol", RFC 1058, June=0A=
         1988.=0A=
=0A=
   [12]  Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,=0A=
         March 1997.=0A=
=0A=
   [13]  Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC=0A=
         1350, July 1992.=0A=
=0A=
   [14]  Braden, R., "Requirements for Internet Hosts - Communication=0A=
         Layers", STD 3, RFC 1122, October 1989.=0A=
=0A=
=0A=
=0A=
Okmianski               Expires November 5, 2004               [Page 22]=0A=
=0C=0A=
Internet-Draft            syslog udp transport                  May 2004=0A=
=0A=
=0A=
   [15]  Kent, C. and J. Mogul, ""Fragmentation Considered Harmful,"=0A=
         Computer Communications Review, vol.17, no.5, pp.390-401",=0A=
         August 1987.=0A=
=0A=
=0A=
Author's Address=0A=
=0A=
   Anton Okmianski=0A=
   Cisco Systems, Inc.=0A=
   1414 Massachusetts Ave=0A=
   Boxborough, MA  01719-2205=0A=
   USA=0A=
=0A=
   EMail: [email-masked]=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Okmianski               Expires November 5, 2004               [Page 23]=0A=
=0C=0A=
Internet-Draft            syslog udp transport                  May 2004=0A=
=0A=
=0A=
Appendix A.  Rational For Transport Message Size Restrictions=0A=
=0A=
   This appendix provides the rational behind the Payload size=0A=
   restrictions for this protocol.  The Payload restrictions outlined in=0A=
   the specification, essentially ensure that the transport message size=0A=
   does not exceed 512 bytes (without UDP/IP headers) for transport via=0A=
   IPv4 and does not exceed 1196 bytes for transport via IPv6. These=0A=
   restrictions put an upper boundary on the UDP/IP datagram size for=0A=
   this protocol, which accomplishes two goals.=0A=
=0A=
   First, they insure interoperability between various UDP/IP=0A=
   implementations.  Even though the maximum IP datagram size is=0A=
   specified as 65536 bytes, many UDP/IP implementations have been shown=0A=
   not to work with large datagram sizes [8].  Many established=0A=
   UDP-based protocols restrict UDP datagram data size to 512 bytes. For=0A=
   example, DNS [10] and RIP [11] do that. The DHCPv4 [12] restricts the=0A=
   size to 512 bytes, but allows sides to agree on a larger value=0A=
   through the protocol. The TFTP [13] restricts the UDP data size to=0A=
   518 bytes, which is slightly larger.=0A=
=0A=
   The second reason for datagram size restrictions is that it helps=0A=
   reduce the likelihood of the  IP-layer datagram fragmentation.  This=0A=
   could have potentially resulted in fragmentation on two levels:=0A=
   syslog transport protocol and IP layer. Since fragmentation has=0A=
   significant overhead for message reassembley, it is best to avoid=0A=
   double fragmentation. The likelihood of IP fragmentation can be=0A=
   significantly reduced by sending IP datagrams in sizes which all=0A=
   hosts must be able to process.=0A=
=0A=
   The minimum MTU of a transport protocol determines the minimum size=0A=
   of packets that hosts must be able to accept.  For IPv4, the minimum=0A=
   MTU is 576 bytes [4] and for IPv6 - 1280 bytes [5].  In both cases,=0A=
   the maximum message size we chose fits within the MTU of the=0A=
   transport in all cases except for when extremely large IP headers are=0A=
   used.  IPv4 header can range from 20 to 60 bytes in length and UDP=0A=
   header is fixed at 8 bytes. Thus, our message size restrictions=0A=
   ensure that in all cases except for when the IP header is 56 bytes or=0A=
   greater, the size of the packet will within the size of the transport=0A=
   MTU.=0A=
=0A=
   For IPv6, we have left the same amount of padding for UDP/IP headers=0A=
   as was conventionally done for IPv4 in DNS, RIP and DHCPv4 with an=0A=
   additional padding of extra 20 bytes to accommodate a larger IPv6=0A=
   header. This follows the methodology suggested in the IPv6=0A=
   specification for calculating upper-layer payload limits [5].=0A=
=0A=
   Path MTU discovery can generally be used to discover the MTU of the=0A=
   link.  Unfortunately, using path MTU discovery with UDP is not a=0A=
=0A=
=0A=
=0A=
Okmianski               Expires November 5, 2004               [Page 24]=0A=
=0C=0A=
Internet-Draft            syslog udp transport                  May 2004=0A=
=0A=
=0A=
   reliable option because it depends on routers providing ICMP errors=0A=
   and hosts doing retransmission, which are not done consistently.=0A=
   Implementors MUST follow the size restrictions outlined above and not=0A=
   rely on path MTU discovery.=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Okmianski               Expires November 5, 2004               [Page 25]=0A=
=0C=0A=
Internet-Draft            syslog udp transport                  May 2004=0A=
=0A=
=0A=
Intellectual Property Statement=0A=
=0A=
   The IETF takes no position regarding the validity or scope of any=0A=
   intellectual property or other rights that might be claimed to=0A=
   pertain to the implementation or use of the technology described in=0A=
   this document or the extent to which any license under such rights=0A=
   might or might not be available; neither does it represent that it=0A=
   has made any effort to identify any such rights. Information on the=0A=
   IETF's procedures with respect to rights in standards-track and=0A=
   standards-related documentation can be found in BCP-11. Copies of=0A=
   claims of rights made available for publication and any assurances of=0A=
   licenses to be made available, or the result of an attempt made to=0A=
   obtain a general license or permission for the use of such=0A=
   proprietary rights by implementors or users of this specification can=0A=
   be obtained from the IETF Secretariat.=0A=
=0A=
   The IETF invites any interested party to bring to its attention any=0A=
   copyrights, patents or patent applications, or other proprietary=0A=
   rights which may cover technology that may be required to practice=0A=
   this standard. Please address the information to the IETF Executive=0A=
   Director.=0A=
=0A=
=0A=
Full Copyright Statement=0A=
=0A=
   Copyright (C) The Internet Society (2004). All Rights Reserved.=0A=
=0A=
   This document and translations of it may be copied and furnished to=0A=
   others, and derivative works that comment on or otherwise explain it=0A=
   or assist in its implementation may be prepared, copied, published=0A=
   and distributed, in whole or in part, without restriction of any=0A=
   kind, provided that the above copyright notice and this paragraph are=0A=
   included on all such copies and derivative works. However, this=0A=
   document itself may not be modified in any way, such as by removing=0A=
   the copyright notice or references to the Internet Society or other=0A=
   Internet organizations, except as needed for the purpose of=0A=
   developing Internet standards in which case the procedures for=0A=
   copyrights defined in the Internet Standards process must be=0A=
   followed, or as required to translate it into languages other than=0A=
   English.=0A=
=0A=
   The limited permissions granted above are perpetual and will not be=0A=
   revoked by the Internet Society or its successors or assignees.=0A=
=0A=
   This document and the information contained herein is provided on an=0A=
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING=0A=
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING=0A=
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION=0A=
=0A=
=0A=
=0A=
Okmianski               Expires November 5, 2004               [Page 26]=0A=
=0C=0A=
Internet-Draft            syslog udp transport                  May 2004=0A=
=0A=
=0A=
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF=0A=
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=0A=
=0A=
=0A=
Acknowledgment=0A=
=0A=
   Funding for the RFC Editor function is currently provided by the=0A=
   Internet Society.=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Okmianski               Expires November 5, 2004               [Page 27]=0A=
=0C=0A=
=0A=

- ------=_NextPart_000_0005_01C43451.70B0D950
Content-Type: text/html;
	name="draft-ietf-syslog-transport-udp-01.html"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="draft-ietf-syslog-transport-udp-01.html"

=0A=
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" =
"http://www.w3.org/TR/html4/loose.dtd">=0A=
<html lang=3D"en"><head><title>Transmission of syslog messages over =
UDP</title>=0A=
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8">=0A=
<meta name=3D"description" content=3D"Transmission of syslog messages =
over UDP">=0A=
<meta name=3D"keywords" content=3D"syslog, UDP, User Datagram Protocol, =
transport, transmission, syslog UDP transport">=0A=
<meta name=3D"generator" content=3D"xml2rfc v1.24 =
(http://xml.resource.org/)">=0A=
<style type=3D'text/css'>=0A=
<!--=0A=
    body {=0A=
        font-family: verdana, charcoal, helvetica, arial, sans-serif;=0A=
        font-size: small ; color: #000000 ; background-color: #ffffff ; }=0A=
    .title { color: #990000; font-size: x-large ;=0A=
        font-weight: bold; text-align: right;=0A=
        font-family: helvetica, monaco, "MS Sans Serif", arial, =
sans-serif;=0A=
        background-color: transparent; }=0A=
    .filename { color: #666666; font-size: 18px; line-height: 28px;=0A=
        font-weight: bold; text-align: right;=0A=
        font-family: helvetica, arial, sans-serif;=0A=
        background-color: transparent; }=0A=
    td.rfcbug { background-color: #000000 ; width: 30px ; height: 30px ; =0A=
        text-align: justify; vertical-align: middle ; padding-top: 2px ; =
}=0A=
    td.rfcbug span.RFC { color: #666666; font-weight: bold; =
text-decoration: none;=0A=
        background-color: #000000 ;=0A=
        font-family: monaco, charcoal, geneva, "MS Sans Serif", =
helvetica, verdana, sans-serif;=0A=
        font-size: x-small ; }=0A=
    td.rfcbug span.hotText { color: #ffffff; font-weight: normal; =
text-decoration: none;=0A=
        text-align: center ;=0A=
        font-family: charcoal, monaco, geneva, "MS Sans Serif", =
helvetica, verdana, sans-serif;=0A=
        font-size: x-small ; background-color: #000000; }=0A=
/* info code from SantaKlauss at =
http://www.madaboutstyle.com/tooltip2.html */=0A=
    div#counter{margin-top: 100px}=0A=
=0A=
    a.info{=0A=
        position:relative; /*this is the key*/=0A=
        z-index:24;=0A=
        text-decoration:none}=0A=
=0A=
    a.info:hover{z-index:25; background-color:#990000 ; color: #ffffff ;}=0A=
=0A=
    a.info span{display: none}=0A=
=0A=
    a.info:hover span{ /*the span will display just on :hover state*/=0A=
        display:block;=0A=
        position:absolute;=0A=
        font-size: smaller ;=0A=
        top:2em; left:2em; width:15em;=0A=
        padding: 2px ;=0A=
        border:1px solid #333333;=0A=
        background-color:#eeeeee; color:#990000;=0A=
        text-align: left ;}=0A=
=0A=
     A { font-weight: bold; }=0A=
     A:link { color: #990000; background-color: transparent ; }=0A=
     A:visited { color: #333333; background-color: transparent ; }=0A=
     A:active { color: #333333; background-color: transparent ; }=0A=
=0A=
    p { margin-left: 2em; margin-right: 2em; }=0A=
    p.copyright { font-size: x-small ; }=0A=
    p.toc { font-size: small ; font-weight: bold ; margin-left: 3em ;}=0A=
=0A=
    span.emph { font-style: italic; }=0A=
    span.strong { font-weight: bold; }=0A=
    span.verb { font-family: "Courier New", Courier, monospace ; }=0A=
=0A=
    ol.text { margin-left: 2em; margin-right: 2em; }=0A=
    ul.text { margin-left: 2em; margin-right: 2em; }=0A=
    li { margin-left: 3em;  }=0A=
=0A=
    pre { margin-left: 3em; color: #333333;  background-color: =
transparent;=0A=
        font-family: "Courier New", Courier, monospace ; font-size: =
small ;=0A=
        }=0A=
=0A=
    h3 { color: #333333; font-size: medium ;=0A=
        font-family: helvetica, arial, sans-serif ;=0A=
        background-color: transparent; }=0A=
    h4 { font-size: small; font-family: helvetica, arial, sans-serif ; }=0A=
=0A=
    table.bug { width: 30px ; height: 15px ; }=0A=
    td.bug { color: #ffffff ; background-color: #990000 ;=0A=
        text-align: center ; width: 30px ; height: 15px ;=0A=
         }=0A=
    td.bug A.link2 { color: #ffffff ; font-weight: bold;=0A=
        text-decoration: none;=0A=
        font-family: monaco, charcoal, geneva, "MS Sans Serif", =
helvetica, sans-serif;=0A=
        font-size: x-small ; background-color: transparent }=0A=
=0A=
    td.header { color: #ffffff; font-size: x-small ;=0A=
        font-family: arial, helvetica, sans-serif; vertical-align: top;=0A=
        background-color: #666666 ; width: 33% ; }=0A=
    td.author { font-weight: bold; margin-left: 4em; font-size: x-small =
; }=0A=
    td.author-text { font-size: x-small; }=0A=
    table.data { vertical-align: top ; border-collapse: collapse ;=0A=
        border-style: solid solid solid solid ;=0A=
        border-color: black black black black ;=0A=
        font-size: small ; text-align: center ; }=0A=
    table.data th { font-weight: bold ;=0A=
        border-style: solid solid solid solid ;=0A=
        border-color: black black black black ; }=0A=
    table.data td {=0A=
        border-style: solid solid solid solid ;=0A=
        border-color: #333333 #333333 #333333 #333333 ; }=0A=
=0A=
    hr { height: 1px }=0A=
- -->=0A=
</style>=0A=
</head>=0A=
<body>=0A=
<table summary=3D"layout" cellpadding=3D"0" cellspacing=3D"2" =
class=3D"bug" align=3D"right"><tr><td class=3D"bug"><a href=3D"#toc" =
class=3D"link2">&nbsp;TOC&nbsp;</a></td></tr></table>=0A=
<table summary=3D"layout" width=3D"66%" border=3D"0" cellpadding=3D"0" =
cellspacing=3D"0"><tr><td><table summary=3D"layout" width=3D"100%" =
border=3D"0" cellpadding=3D"2" cellspacing=3D"1">=0A=
<tr><td class=3D"header">syslog Working Group</td><td =
class=3D"header">A. Okmianski</td></tr>=0A=
<tr><td class=3D"header">Internet-Draft</td><td class=3D"header">Cisco =
Systems, Inc.</td></tr>=0A=
<tr><td class=3D"header">Expires: November 5, 2004</td><td =
class=3D"header">May 7, 2004</td></tr>=0A=
</table></td></tr></table>=0A=
<div align=3D"right"><span class=3D"title"><br />Transmission of syslog =
messages over UDP</span></div>=0A=
<div align=3D"right"><span class=3D"title"><br =
/>draft-ietf-syslog-transport-udp-01</span></div>=0A=
=0A=
<h3>Status of this Memo</h3>=0A=
<p>=0A=
This document is an Internet-Draft and is=0A=
in full conformance with all provisions of Section 10 of RFC2026.</p>=0A=
<p>=0A=
Internet-Drafts are working documents of the Internet Engineering=0A=
Task Force (IETF), its areas, and its working groups.=0A=
Note that other groups may also distribute working documents as=0A=
Internet-Drafts.</p>=0A=
<p>=0A=
Internet-Drafts are draft documents valid for a maximum of six months=0A=
and may be updated, replaced, or obsoleted by other documents at any =
time.=0A=
It is inappropriate to use Internet-Drafts as reference material or to =
cite=0A=
them other than as "work in progress."</p>=0A=
<p>=0A=
The list of current Internet-Drafts can be accessed at=0A=
<a =
href=3D'http://www.ietf.org/ietf/1id-abstracts.txt'>http://www.ietf.org/i=
etf/1id-abstracts.txt</a>.</p>=0A=
<p>=0A=
The list of Internet-Draft Shadow Directories can be accessed at=0A=
<a =
href=3D'http://www.ietf.org/shadow.html'>http://www.ietf.org/shadow.html<=
/a>.</p>=0A=
<p>=0A=
This Internet-Draft will expire on November 5, 2004.</p>=0A=
=0A=
<h3>Copyright Notice</h3>=0A=
<p>=0A=
Copyright (C) The Internet Society (2004). All Rights Reserved.</p>=0A=
=0A=
<h3>Abstract</h3>=0A=
=0A=
<p>=0A=
		This document describes the transport for the syslog message 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 using multiple =
datagrams.=0A=
		=0A=
</p><a name=3D"toc"></a><br /><hr />=0A=
<h3>Table of Contents</h3>=0A=
<p class=3D"toc">=0A=
<a href=3D"#intro">1.</a>&nbsp;=0A=
Introduction<br />=0A=
<a href=3D"#TransportProtocolOverview">2.</a>&nbsp;=0A=
Transport Protocol Overview<br />=0A=
&nbsp;&nbsp;&nbsp;&nbsp;<a =
href=3D"#DefinitionsAndArchitecture">2.1</a>&nbsp;=0A=
Definitions and Architecture<br />=0A=
&nbsp;&nbsp;&nbsp;&nbsp;<a =
href=3D"#RequiredTransportProtocol">2.2</a>&nbsp;=0A=
Required Transport Protocol<br />=0A=
&nbsp;&nbsp;&nbsp;&nbsp;<a href=3D"#EncapsulationLayers">2.3</a>&nbsp;=0A=
Encapsulation Layers<br />=0A=
<a href=3D"#MessageFormat">3.</a>&nbsp;=0A=
Message Format<br />=0A=
&nbsp;&nbsp;&nbsp;&nbsp;<a href=3D"#BasicHeaderFormat">3.1</a>&nbsp;=0A=
Basic Header Format<br />=0A=
&nbsp;&nbsp;&nbsp;&nbsp;<a href=3D"#ExtendedHeaderFormat">3.2</a>&nbsp;=0A=
Extended Header Format<br />=0A=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href=3D"#Message =
Identifier">3.2.1</a>&nbsp;=0A=
Message Identifier<br />=0A=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a =
href=3D"#TotalLength">3.2.2</a>&nbsp;=0A=
Total Length<br />=0A=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a =
href=3D"#FragmentOffset">3.2.3</a>&nbsp;=0A=
Fragment Offset<br />=0A=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a =
href=3D"#ExtendedHeaderExample">3.2.4</a>&nbsp;=0A=
Extended Header Example<br />=0A=
&nbsp;&nbsp;&nbsp;&nbsp;<a href=3D"#Payload">3.3</a>&nbsp;=0A=
Payload<br />=0A=
&nbsp;&nbsp;&nbsp;&nbsp;<a href=3D"#SupportedMessageLength">3.4</a>&nbsp;=0A=
Supported Message Length<br />=0A=
<a href=3D"#LowerLayerConsiderations">4.</a>&nbsp;=0A=
UDP/IP Layer Considerations<br />=0A=
&nbsp;&nbsp;&nbsp;&nbsp;<a href=3D"#TargetPort">4.1</a>&nbsp;=0A=
Target Port<br />=0A=
&nbsp;&nbsp;&nbsp;&nbsp;<a href=3D"#SourcePort">4.2</a>&nbsp;=0A=
Source Port<br />=0A=
&nbsp;&nbsp;&nbsp;&nbsp;<a href=3D"#SourceIPAddress">4.3</a>&nbsp;=0A=
Source IP Address<br />=0A=
&nbsp;&nbsp;&nbsp;&nbsp;<a href=3D"#UDPIPHeader">4.4</a>&nbsp;=0A=
UDP/IP Headers<br />=0A=
<a href=3D"#FragmentationAndReassembley">5.</a>&nbsp;=0A=
Fragmentation and Reassembley<br />=0A=
&nbsp;&nbsp;&nbsp;&nbsp;<a href=3D"#MessageFragmentation">5.1</a>&nbsp;=0A=
Message Fragmentation<br />=0A=
&nbsp;&nbsp;&nbsp;&nbsp;<a href=3D"#MessageReassembley">5.2</a>&nbsp;=0A=
Message Reassembley<br />=0A=
&nbsp;&nbsp;&nbsp;&nbsp;<a href=3D"#AvoidingFragmentation">5.3</a>&nbsp;=0A=
Avoiding Fragmentation<br />=0A=
<a href=3D"#reliability">6.</a>&nbsp;=0A=
Reliability Considerations<br />=0A=
&nbsp;&nbsp;&nbsp;&nbsp;<a href=3D"#loss">6.1</a>&nbsp;=0A=
Lost Datagrams<br />=0A=
&nbsp;&nbsp;&nbsp;&nbsp;<a href=3D"#corruption">6.2</a>&nbsp;=0A=
Message Corruption and Checksums<br />=0A=
&nbsp;&nbsp;&nbsp;&nbsp;<a href=3D"#overload">6.3</a>&nbsp;=0A=
Congestion Control<br />=0A=
&nbsp;&nbsp;&nbsp;&nbsp;<a href=3D"#sequence">6.4</a>&nbsp;=0A=
Sequenced Delivery<br />=0A=
&nbsp;&nbsp;&nbsp;&nbsp;<a href=3D"#SenderAuthentication">6.5</a>&nbsp;=0A=
Sender Authentication<br />=0A=
<a href=3D"#security">7.</a>&nbsp;=0A=
Security Considerations<br />=0A=
&nbsp;&nbsp;&nbsp;&nbsp;<a href=3D"#SecAuth">7.1</a>&nbsp;=0A=
Message Authenticity<br />=0A=
&nbsp;&nbsp;&nbsp;&nbsp;<a href=3D"#SecForg">7.2</a>&nbsp;=0A=
Message Forgery<br />=0A=
&nbsp;&nbsp;&nbsp;&nbsp;<a href=3D"#SecObs">7.3</a>&nbsp;=0A=
Message Observation<br />=0A=
&nbsp;&nbsp;&nbsp;&nbsp;<a href=3D"#SecReplay">7.4</a>&nbsp;=0A=
Replaying<br />=0A=
&nbsp;&nbsp;&nbsp;&nbsp;<a href=3D"#SecRelDel">7.5</a>&nbsp;=0A=
Unreliable Delivery<br />=0A=
&nbsp;&nbsp;&nbsp;&nbsp;<a href=3D"#SecPri">7.6</a>&nbsp;=0A=
Message Prioritization and Differentiation<br />=0A=
&nbsp;&nbsp;&nbsp;&nbsp;<a href=3D"#SecDen">7.7</a>&nbsp;=0A=
Denial of Service<br />=0A=
<a href=3D"#iana">8.</a>&nbsp;=0A=
IANA Considerations<br />=0A=
<a href=3D"#rfc-editor">9.</a>&nbsp;=0A=
Notice to RFC Editor<br />=0A=
<a href=3D"#authors">10.</a>&nbsp;=0A=
Authors and Working Group Chair<br />=0A=
<a href=3D"#acks">11.</a>&nbsp;=0A=
Acknowledgements<br />=0A=
<a href=3D"#rfc.references1">&#167;.</a>&nbsp;=0A=
References<br />=0A=
<a href=3D"#rfc.authors">&#167;</a>&nbsp;=0A=
Author's Address<br />=0A=
<a href=3D"#AppendixA">A.</a>&nbsp;=0A=
Rational For Transport Message Size Restrictions<br />=0A=
<a href=3D"#rfc.copyright">&#167;</a>&nbsp;=0A=
Intellectual Property and Copyright Statements<br />=0A=
</p>=0A=
<br clear=3D"all" />=0A=
=0A=
<a name=3D"intro"></a><br /><hr />=0A=
<table summary=3D"layout" cellpadding=3D"0" cellspacing=3D"2" =
class=3D"bug" align=3D"right"><tr><td class=3D"bug"><a href=3D"#toc" =
class=3D"link2">&nbsp;TOC&nbsp;</a></td></tr></table>=0A=
<a name=3D"rfc.section.1"></a><h3>1.&nbsp;Introduction</h3>=0A=
=0A=
<p>=0A=
		The original syslog protocol has been described in an informational <a =
class=3D"info" href=3D"#RFC3164">RFC 3164<span>Lonvick, C., The BSD =
Syslog Protocol, August 2001.</span></a>[1] as it has been observed in =
existing implementations. It describes both the semantics of syslog =
message format as well as a UDP transport.  Subsequently, the syslog =
protocol has been formally defined in a standards track <a =
class=3D"info" href=3D"#RFC-protocol">RFC-protocol<span>Gerhards, R., =
The syslog Protocol, .</span></a>[2].=0A=
		=0A=
</p>=0A=
<p>=0A=
		The <a class=3D"info" =
href=3D"#RFC-protocol">RFC-protocol<span>Gerhards, R., The syslog =
Protocol, .</span></a>[2] has provided for support of any number of =
transport layer protocols for transmitting syslog messages and left it =
to subsequent RFCs to specify transport protocols. This standards track =
RFC describes the UDP transport for the syslog protocol. This transport =
protocol is REQUIRED for all syslog protocol implementations.=0A=
		=0A=
</p>=0A=
<p>=0A=
		This transport protocol was designed to work on top of UDP <a =
class=3D"info" href=3D"#RFC0768">[3]<span>Postel, J., User Datagram =
Protocol, August 1980.</span></a> over both IPv4 <a class=3D"info" =
href=3D"#RFC0791">[4]<span>Postel, J., Internet Protocol, September =
1981.</span></a> and IPv6 <a class=3D"info" =
href=3D"#RFC2460">[5]<span>Deering, S. and R. Hinden, Internet Protocol, =
Version 6 (IPv6) Specification, December 1998.</span></a>. This protocol =
overcomes the data size restrictions of the UDP protocol by introducing =
message fragmentation feature.=0A=
		=0A=
</p>=0A=
<p>=0A=
		As we will show in this specification, this protocol has significant =
reliability and security issues stemming from the use of UDP.  However, =
this protocol is lightweight and extends on the existing popular use of =
UDP for syslog. Network administrators and architects should be aware of =
the shortcomings of this protocol and plan accordingly.=0A=
		=0A=
</p>=0A=
<p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", =
"SHOULD",=0A=
		"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document =
are to be=0A=
		interpreted as described in <a class=3D"info" href=3D"#RFC2119">RFC =
2119<span>Bradner, S., Key words for use in RFCs to Indicate Requirement =
Levels, March 1997.</span></a>[6]. The words 'byte' and 'octet' are used =
interchangeably in this specification.=0A=
		=0A=
</p>=0A=
<a name=3D"TransportProtocolOverview"></a><br /><hr />=0A=
<table summary=3D"layout" cellpadding=3D"0" cellspacing=3D"2" =
class=3D"bug" align=3D"right"><tr><td class=3D"bug"><a href=3D"#toc" =
class=3D"link2">&nbsp;TOC&nbsp;</a></td></tr></table>=0A=
<a name=3D"rfc.section.2"></a><h3>2.&nbsp;Transport Protocol =
Overview</h3>=0A=
=0A=
<a name=3D"rfc.section.2.1"></a><h4><a =
name=3D"DefinitionsAndArchitecture">2.1</a>&nbsp;Definitions and =
Architecture</h4>=0A=
=0A=
<p>=0A=
=0A=
   The following definitions will be used in this document:=0A=
=0A=
   </p>=0A=
<ul class=3D"text">=0A=
<li>=0A=
      An application that can generate syslog messages will be referred =
to as a "sender";=0A=
   =0A=
</li>=0A=
<li>=0A=
      An application that can receive syslog messages will be referred =
to as a "receiver".=0A=
   =0A=
</li>=0A=
</ul>=0A=
=0A=
<p>=0A=
   An application can function in dual capacity. For example, a syslog =
relay may receive and forward messages. A single system can host any =
number of syslog senders. Only one syslog receiver can be hosted on a =
single system using the standard listening port.=0A=
=0A=
</p>=0A=
<a name=3D"rfc.section.2.2"></a><h4><a =
name=3D"RequiredTransportProtocol">2.2</a>&nbsp;Required Transport =
Protocol</h4>=0A=
=0A=
<p>=0A=
   This document describes the UDP transport layer protocol for the =
syslog protocol <a class=3D"info" =
href=3D"#RFC-protocol">RFC-protocol<span>Gerhards, R., The syslog =
Protocol, .</span></a>[2]. Every syslog sender and receiver =
implementation which adheres to the <a class=3D"info" =
href=3D"#RFC-protocol">RFC-protocol<span>Gerhards, R., The syslog =
Protocol, .</span></a>[2] MUST fully implement the transport protocol =
specified in this document. Implementations does not have to support =
both IPv4 and IPv6 if it is designed to be used over only one of these =
protocols.=0A=
=0A=
</p>=0A=
<a name=3D"rfc.section.2.3"></a><h4><a =
name=3D"EncapsulationLayers">2.3</a>&nbsp;Encapsulation Layers</h4>=0A=
=0A=
<p>=0A=
   Syslog UDP transport carries syslog messages as generic payload =
encapsulated with a syslog transport header, UDP header and an IP =
header. Below is a summary of syslog UDP/IP packet structure as used =
this transport protocol:=0A=
=0A=
</p>=0A=
<p></p>=0A=
<pre>=0A=
		+--------------------------------+=0A=
		|       IPv4 or IPv6 Header      |=0A=
		|        (20 or more bytes)      |=0A=
		+--------------------------------+=0A=
		|           UDP Header           |=0A=
		|           (8 bytes)            |=0A=
		+--------------------------------+=0A=
		|    Syslog Transport Header     |=0A=
		|        (5 or 32 bytes)         |=0A=
		+--------------------------------+=0A=
		|     Syslog Message Payload     |=0A=
		|       (1 to 1191 bytes)        |=0A=
		+--------------------------------+=0A=
</pre>=0A=
<p>=0A=
=0A=
</p>=0A=
<p>=0A=
   Small syslog messages are transmitted using one UDP/IP datagram per =
message. However, syslog protocol <a class=3D"info" =
href=3D"#RFC-protocol">[2]<span>Gerhards, R., The syslog Protocol, =
.</span></a> allows messages as large as 16777216 bytes, while UDP/IP =
datagram cannot exceed a total size of 65526 bytes <a class=3D"info" =
href=3D"#RFC0768">[3]<span>Postel, J., User Datagram Protocol, August =
1980.</span></a> and most existing protocols restrict the size of UDP =
data to much less. In order to support transmitting large messages over =
UDP/IP, this transport protocol supports fragmentation of large syslog =
messages into multiple UDP/IP datagrams for transmission and reassembley =
on the receiving end.=0A=
=0A=
</p>=0A=
<p>=0A=
   Each syslog UDP/IP datagram MUST contain one and only one complete =
syslog message or one fragment of a message.  Transmitting multiple =
messages or multiple fragments of different messages in a single UDP =
datagram is not supported by this protocol.=0A=
=0A=
</p>=0A=
<a name=3D"MessageFormat"></a><br /><hr />=0A=
<table summary=3D"layout" cellpadding=3D"0" cellspacing=3D"2" =
class=3D"bug" align=3D"right"><tr><td class=3D"bug"><a href=3D"#toc" =
class=3D"link2">&nbsp;TOC&nbsp;</a></td></tr></table>=0A=
<a name=3D"rfc.section.3"></a><h3>3.&nbsp;Message Format</h3>=0A=
=0A=
<p>=0A=
    The syslog transport message consist of a transport header and a =
syslog message payload. The format of the transport header is different =
for fragmented and non-fragmented messages.  Basic transport header is =
used for non-fragmented messages and extended transport header is used =
for fragmented messages.=0A=
=0A=
</p>=0A=
<p>=0A=
    An ASCII-based encoding was chosen for the syslog transport for =
consistency with the <a class=3D"info" =
href=3D"#RFC-protocol">RFC-protocol<span>Gerhards, R., The syslog =
Protocol, .</span></a>[2].  Syslog transport datagrams without required =
UDP and IP headers have the following format in <a class=3D"info" =
href=3D"#RFC2234">ABNF<span>Crocker, D. and P. Overell, Augmented BNF =
for Syntax Specifications: ABNF, November 1997.</span></a>[7] notation:=0A=
=0A=
</p>=0A=
<p></p>=0A=
<pre>=0A=
    SyslogTransportMessage =3D ( BasicHeader / ExtendedHeader )=0A=
                                      SP Payload=0A=
=0A=
    BasicHeader     =3D Version SP "0"=0A=
    Version         =3D %d118 1*3DIGIT   ; "v1" in this version=0A=
=0A=
    ExtendedHeader  =3D Version SP "1" SP MessageId=0A=
                      SP TotalLength SP FragmentOffset=0A=
=0A=
    MessageId       =3D 1*8DIGIT        ; 0 to 16777215=0A=
    TotalLength     =3D 1*8DIGIT        ; 1 to 16777216=0A=
    FragmentOffset  =3D 1*8DIGIT        ; 0 to 16777215=0A=
    Payload         =3D 1*1191OCTET=0A=
=0A=
    OCTET           =3D %d00-255=0A=
    DIGIT           =3D %d48-57=0A=
    SP              =3D %d32=0A=
    </pre>=0A=
<p>=0A=
=0A=
</p>=0A=
<a name=3D"rfc.section.3.1"></a><h4><a =
name=3D"BasicHeaderFormat">3.1</a>&nbsp;Basic Header Format</h4>=0A=
=0A=
<p>=0A=
	When no fragmentation is used and the entire syslog message is =
transferred as a single UDP/IP datagram, a basic syslog transport header =
MUST be used.  The version for this protocol is "1". It must be followed =
by one space and a "0" to indicate that this is a basic header.   =
Therefore, the only possible value for the basic header in this protocol =
is as follows:=0A=
=0A=
</p>=0A=
<p></p>=0A=
<pre>=0A=
   "v1 0 "=0A=
</pre>=0A=
<p>=0A=
=0A=
</p>=0A=
<p>=0A=
   Example of a syslog message without the transport header (message is =
wrapped for display):=0A=
=0A=
</p>=0A=
<p></p>=0A=
<pre>=0A=
   "v1 888 3 2003-10-11T22:14:15.003Z host.domain.com=0A=
   dns: configuration error"=0A=
</pre>=0A=
<p>=0A=
=0A=
</p>=0A=
<p>=0A=
   Example of the same message with the transport header (message is =
wrapped for display):=0A=
=0A=
</p>=0A=
<p></p>=0A=
<pre>=0A=
   "v1 0 v1 888 4 2003-10-11T22:14:15.003Z host.domain.com=0A=
   dns: configuration error"=0A=
</pre>=0A=
<p>=0A=
=0A=
</p>=0A=
<a name=3D"rfc.section.3.2"></a><h4><a =
name=3D"ExtendedHeaderFormat">3.2</a>&nbsp;Extended Header Format</h4>=0A=
=0A=
<p>=0A=
   When syslog message is fragmented by the sender, multiple UDP =
datagrams must be used and each datagram MUST contain an extended syslog =
transport header. The version for this protocol is "1". The version =
field MUST be followed by a single space and a "1" to indicate that this =
is an extended header.  Thus, an extended header MUST always begin with =
"v1 1 ", but MUST also have additional fields which aid in fragmentation.=0A=
=0A=
</p>=0A=
<p>=0A=
   The MessageId, TotalLength and FragmentOffset fields are used solely =
for fragmentation of long messages and reassembley.  They SHOULD NOT be =
used for other purposes.=0A=
=0A=
</p>=0A=
<a name=3D"rfc.section.3.2.1"></a><h4><a name=3D"Message =
Identifier">3.2.1</a>&nbsp;Message Identifier</h4>=0A=
=0A=
<p>=0A=
   The MessageId field (along with the source UDP port and the IP =
address) is used to identify the message such that fragments of a single =
syslog message can be reassembled by the receiver into a complete =
message.  The MessageId field MUST be a numeric value in the range of 0 =
to 16777215.  Leading zeros MUST not be present in the MessageId field.=0A=
=0A=
</p>=0A=
<p>=0A=
   Each syslog sender process MUST choose a random MessageId value =
within the supported range for its first message. Subsequent messages =
generated by the same process MUST each increment the MessageId by 1 up =
to 16777215 and then continue at 0. Using random value for the first =
MessageId helps reduce the possibility of potential errors in message =
reassembley. Refer to discussion about <a class=3D"info" =
href=3D"#MessageReassembley">message reassembley<span>Message =
Reassembley</span></a> for more details.=0A=
=0A=
</p>=0A=
<p>=0A=
   All datagrams which represent parts of a given fragmented syslog =
message MUST have the same MessageId value.=0A=
=0A=
</p>=0A=
<a name=3D"rfc.section.3.2.2"></a><h4><a =
name=3D"TotalLength">3.2.2</a>&nbsp;Total Length</h4>=0A=
=0A=
<p>=0A=
   The TotalLength field MUST be a numeric value in the range of 1 to =
16777216. It MUST indicate the length of a complete syslog message =
before it was fragmented and before it was encapsulated with transport =
headers.  The same TotalLength field value MUST be present in all UDP =
datagrams which represent fragments of the same syslog message. Leading =
zeros MUST not be present in the TotalLength field.=0A=
=0A=
</p>=0A=
<p>=0A=
   Note that in IPv4 the "total length" field identifies the length of a =
single packet.  In this protocol, the TotalLength field is used to =
identify the total length of a complete syslog message, which is =
transmitted using multiple fragments and multiple datagram packets.  The =
fragment length is not specified in the transport header because it can =
be inferred from the size of the IP packet containing the UDP datagram.=0A=
=0A=
</p>=0A=
<a name=3D"rfc.section.3.2.3"></a><h4><a =
name=3D"FragmentOffset">3.2.3</a>&nbsp;Fragment Offset</h4>=0A=
=0A=
<p>=0A=
   The FragmentOffset field MUST be a numeric value in the range of 0 to =
16777215. It MUST indicate the byte offset of the fragment data in the =
complete syslog message. The offset index starts at 0 for the first =
fragment. For example, if an 700 byte syslog message is fragmented into =
480 and 220 byte parts, the FragmentOffset in the first message will be =
0 and in the second - 480. Note that fragments don't have to be the same =
size.  Leading zeros MUST not be present in the FragmentOffset field.=0A=
=0A=
</p>=0A=
<a name=3D"rfc.section.3.2.4"></a><h4><a =
name=3D"ExtendedHeaderExample">3.2.4</a>&nbsp;Extended Header =
Example</h4>=0A=
=0A=
<p>=0A=
   The following is an example of a syslog message without the transport =
header (message is wrapped for display):=0A=
=0A=
</p>=0A=
<p></p>=0A=
<pre>=0A=
   "v1 888 4 2003-10-11T22:14:15.003Z host.domain.com=0A=
   dns: configuration error"=0A=
</pre>=0A=
<p>=0A=
=0A=
</p>=0A=
<p>=0A=
   Suppose this message had to be fragmented by transport layer into two =
parts at an arbitrary point.  This would result in two separate UDP =
datagrams being sent - one for each fragment. Below is the content of =
each of the syslog transport UDP messages with syslog transport headers =
but without UDP/IP headers:=0A=
=0A=
</p>=0A=
<p></p>=0A=
<pre>=0A=
   "v1 1 45612221 74 0 v1 888 4 2003-10-11T22:14:15.003Z host.dom"=0A=
=0A=
   "v1 1 45612221 74 42 ain.com dns: configuration error"=0A=
</pre>=0A=
<p>=0A=
=0A=
</p>=0A=
<p>=0A=
   In the above example, the leading "v1" is the version of the =
transport protocol, "1" indicates that this is an extended header =
(fragmentation in use), "45612221" is the MessageId, "74" is the =
TotalLength of the message, while "0" and "42" are FragmentOffset =
fields. Everything following the FragmentOffset and a space is a the =
Payload of each respective message.=0A=
=0A=
</p>=0A=
<a name=3D"rfc.section.3.3"></a><h4><a =
name=3D"Payload">3.3</a>&nbsp;Payload</h4>=0A=
=0A=
<p>=0A=
   The Payload field of the syslog UPD transport message is an entire =
syslog message or one fragment. The maximum Payload size depends on the =
IP protocol used and the type header that is used.=0A=
=0A=
</p><pre>=0A=
   Maximum Payload size:=0A=
=0A=
   With IPv4 and basic header:    507 bytes=0A=
   With IPv4 and extended header: 480 bytes=0A=
=0A=
   With IPv6 and basic header:    1191 bytes=0A=
   With IPv6 and extended header: 1164 bytes=0A=
</pre>=0A=
=0A=
<p>=0A=
   The Payload size restrictions above effectively mean that the largest =
syslog message that can be sent non-fragmented is 507 bytes for =
transport via IPv4 and 1191 bytes for transport via IPv6.=0A=
=0A=
</p>=0A=
<p>=0A=
   For a discussion of the relational behind the above size restrictions =
please refer to Appendix A.=0A=
=0A=
</p>=0A=
<a name=3D"rfc.section.3.4"></a><h4><a =
name=3D"SupportedMessageLength">3.4</a>&nbsp;Supported Message =
Length</h4>=0A=
=0A=
<p>=0A=
  The maximum syslog message length supported by this protocol is the =
maximum value of the TotalLength field, which is 16777216 bytes. =
However, not all deployment scenarios for syslog will be on hosts with =
hardware capable of supporting the maximum length of messages supported =
by this protocol. Additionally, extremely large messages may not be =
needed in many environments. Therefore, implementations are NOT REQUIRED =
to support the maximum message length allowed by this protocol.=0A=
=0A=
</p>=0A=
<p>=0A=
  All implementations MUST support sending and receiving syslog messages =
up to and including 65536 bytes in size (syslog transport and UDP/IP =
headers are extra). Support for larger messages is encouraged. =
Implementors SHOULD clearly state the maximum supported message size in =
documentation.=0A=
=0A=
</p>=0A=
<a name=3D"LowerLayerConsiderations"></a><br /><hr />=0A=
<table summary=3D"layout" cellpadding=3D"0" cellspacing=3D"2" =
class=3D"bug" align=3D"right"><tr><td class=3D"bug"><a href=3D"#toc" =
class=3D"link2">&nbsp;TOC&nbsp;</a></td></tr></table>=0A=
<a name=3D"rfc.section.4"></a><h3>4.&nbsp;UDP/IP Layer =
Considerations</h3>=0A=
=0A=
<a name=3D"rfc.section.4.1"></a><h4><a =
name=3D"TargetPort">4.1</a>&nbsp;Target Port</h4>=0A=
=0A=
<p>=0A=
   Syslog receivers MUST support accepting syslog message datagrams on a =
well-known UDP port 514.  Syslog senders MUST support sending syslog =
message datagrams to the UDP port 514.=0A=
=0A=
</p>=0A=
<a name=3D"rfc.section.4.2"></a><h4><a =
name=3D"SourcePort">4.2</a>&nbsp;Source Port</h4>=0A=
=0A=
<p>=0A=
   Syslog senders can use any source UDP port for transmitting messages. =
Senders MAY randomly select a source port, but MUST use the port in an =
exclusive fashion. No concurrent port reuse on the same host is allowed.=0A=
=0A=
</p>=0A=
<p>=0A=
   Each syslog sender process MUST attempt to use the same source port =
for the life of the the process.  If due to an error or other condition =
it becomes impossible for the process to continue to use the same port, =
it MAY start using a new source port, but it MUST generate a new random =
MessageId for the first message after changing the port and then MUST =
continue incrementing the new MessageId value for subsequent messages.=0A=
=0A=
</p>=0A=
<p>=0A=
   Since source port is used to identify parts of a fragmented message, =
the sender MUST use the same port to send all fragments of a given =
message.  If due to an error or other condition, the sender is unable to =
do that, it MUST resend all message fragments using the new port and a =
new MessageId field value.=0A=
=0A=
</p>=0A=
<a name=3D"rfc.section.4.3"></a><h4><a =
name=3D"SourceIPAddress">4.3</a>&nbsp;Source IP Address</h4>=0A=
=0A=
<p>=0A=
   The source IP address of the UDP datagrams is one of the data =
elements used to identify parts of a fragmented message.  Therefore, a =
syslog sender MUST attempt to use the same source IP address to send all =
fragments of a given syslog message.  If due to an error, =
reconfiguration or other condition it is unable to do so, the sender =
MUST resend all fragments of the syslog message using the new source IP =
address and a new MessageId value.=0A=
=0A=
</p>=0A=
<a name=3D"rfc.section.4.4"></a><h4><a =
name=3D"UDPIPHeader">4.4</a>&nbsp;UDP/IP Headers</h4>=0A=
=0A=
<p>=0A=
   Each UDP/IP datagram sent by the transport layer MUST completely =
adhere to the structure specified in the UDP <a class=3D"info" =
href=3D"#RFC0768">RFC 768<span>Postel, J., User Datagram Protocol, =
August 1980.</span></a>[3] and either IPv4 <a class=3D"info" =
href=3D"#RFC0791">RFC 791<span>Postel, J., Internet Protocol, September =
1981.</span></a>[4] or IPv6 <a class=3D"info" href=3D"#RFC2460">RFC =
2640<span>Deering, S. and R. Hinden, Internet Protocol, Version 6 (IPv6) =
Specification, December 1998.</span></a>[5] depending on which protocol =
is used.=0A=
=0A=
</p>=0A=
<p>=0A=
   Use of UDP checksums was defined as optional in <a class=3D"info" =
href=3D"#RFC0768">RFC 768<span>Postel, J., User Datagram Protocol, =
August 1980.</span></a>[3]. IPv6 has subsequently made UDP checksums =
required <a class=3D"info" href=3D"#RFC2460">[5]<span>Deering, S. and R. =
Hinden, Internet Protocol, Version 6 (IPv6) Specification, December =
1998.</span></a>.  However, syslog senders MUST utilize valid UDP =
checksums when sending messages over either IPv4 or IPv6. Syslog =
receivers MUST check for checksums and discard messages with incorrect =
checksums. Note that this is typically accomplished by the UDP layer =
implementation, and some implementations allow for checksum checks to be =
enabled or disabled.=0A=
=0A=
</p>=0A=
<p>=0A=
   Enabling use of checksums serves as an extra measure of corruption =
detection in addition to checksums performed by IP and Ethernet layers. =
None of the above checksums provide a complete guarantee of corruption =
detection. Utilizing checksums on multiple layers reduces the chance of =
corruption error not being detected.=0A=
=0A=
</p>=0A=
<a name=3D"FragmentationAndReassembley"></a><br /><hr />=0A=
<table summary=3D"layout" cellpadding=3D"0" cellspacing=3D"2" =
class=3D"bug" align=3D"right"><tr><td class=3D"bug"><a href=3D"#toc" =
class=3D"link2">&nbsp;TOC&nbsp;</a></td></tr></table>=0A=
<a name=3D"rfc.section.5"></a><h3>5.&nbsp;Fragmentation and =
Reassembley</h3>=0A=
=0A=
<a name=3D"rfc.section.5.1"></a><h4><a =
name=3D"MessageFragmentation">5.1</a>&nbsp;Message Fragmentation</h4>=0A=
=0A=
<p>=0A=
   The syslog transport layer MUST perform fragmentation if syslog =
message size exceeds the maximum allowed Payload size. Fragmentation =
SHOULD NOT be used if message can fit into the maximum allowed Payload =
size.=0A=
=0A=
</p>=0A=
<p>=0A=
   Syslog messages SHOULD be fragmented such that all but last message =
utilize the Payload to its maximum capacity.  For example, when using =
IPv4, a 700 byte syslog message SHOULD be fragmented into 480 and 220 =
byte parts because the maximum Payload size with IPv4 and extended =
header is 480 bytes.=0A=
=0A=
</p>=0A=
<p>=0A=
   Each message fragment MUST be sent as a separate UDP/IP datagram with =
an extended syslog transport header.  The sender MUST use the same =
MessageId value, source port and source IP address for all fragments of =
a given message. These three field together uniquely identify fragments =
belonging to a given message.=0A=
=0A=
</p>=0A=
<p>=0A=
   On a system with short-lived sender processes, it may be possible =
that fragments with the same MessageId value, source port and source IP =
address will get generated in short time proximity.  This can be =
possible because a new process may re-use the source port that was freed =
up by another process that just dies.  Such behavior could confuse the =
receiver if the datagrams were received out of order or some datagrams =
got lost.=0A=
=0A=
</p>=0A=
<p>=0A=
   In order to reduce the risk of such mistaken identity errors, section =
3.2.1 specified that each process must start with a random value for =
MessageId field.  Given a relatively large range of MessageId values and =
the unlikely event of a coincidence of having the same MessageId value =
combined with re-used source port and UPD errors, the window for =
potential mistaken identity errors during message reassembley is very =
small and tolerable. The users take a greater risk by using this =
protocol due to general UDP reliability issues discussed later in this =
specification.=0A=
=0A=
</p>=0A=
<a name=3D"rfc.section.5.2"></a><h4><a =
name=3D"MessageReassembley">5.2</a>&nbsp;Message Reassembley</h4>=0A=
=0A=
<p>=0A=
   The reassembley process uses the source IP address from the IP =
header, the source port from the UDP header and the MessageId field =
value to identify fragments of a given message. It then uses data from =
TotalLength and FragmentOffset fields to re-assemble fragments into a =
complete message.=0A=
=0A=
</p>=0A=
<p>=0A=
   Typically, an implementation of fragmentation reassembley involves =
allocating a buffer for the message when any fragment with a new =
combination of source IP address, source port and MessageId is received. =
A timer is used to expire the message reassembley and clean the buffer =
if all fragments are not received in certain time period. As each =
fragment is received, it is placed into the buffer at the appropriate =
offset and a check is performed to determine if all fragments have been =
received using additional data structures.=0A=
=0A=
</p>=0A=
<p>=0A=
   The receiver SHOULD make the timeout interval used for message =
reassembley configurable for the administrator.  The receiver SHOULD =
also be able to limit the total amount of memory used for buffers such =
that it does not run out of resources under a simple denial of service =
attack involving just one message fragment with a large TotalLength =
field value. Degrading the service under heavy load or attack is better =
than crashing and potentially making the service completely unavailable.=0A=
=0A=
</p>=0A=
<a name=3D"rfc.section.5.3"></a><h4><a =
name=3D"AvoidingFragmentation">5.3</a>&nbsp;Avoiding Fragmentation</h4>=0A=
=0A=
<p>=0A=
   Fragmentation and reassembley of messages incurs substantial =
processing overhead on both the sender and the receiver hosts. It also =
increases the risk of lost messages due to lose of just one fragment. It =
is RECOMMENDED that syslog senders which anticipate sending messages =
over this transport protocol attempt to reduce the number of messages =
which require fragmentation by restricting them to the size which does =
not require fragmentation.=0A=
=0A=
</p>=0A=
<a name=3D"reliability"></a><br /><hr />=0A=
<table summary=3D"layout" cellpadding=3D"0" cellspacing=3D"2" =
class=3D"bug" align=3D"right"><tr><td class=3D"bug"><a href=3D"#toc" =
class=3D"link2">&nbsp;TOC&nbsp;</a></td></tr></table>=0A=
<a name=3D"rfc.section.6"></a><h3>6.&nbsp;Reliability Considerations</h3>=0A=
=0A=
<p>=0A=
  The UDP is an unreliable low-overhead protocol. This section discusses =
reliability issues inherent in the UDP that implementers and users must =
be aware of.=0A=
=0A=
</p>=0A=
<a name=3D"rfc.section.6.1"></a><h4><a name=3D"loss">6.1</a>&nbsp;Lost =
Datagrams</h4>=0A=
=0A=
<p>=0A=
  Neither UDP nor syslog protocol provide any mechanism to detect and =
correct loss of datagrams.  Datagrams may be lost in transit due to =
congestion, corruption or any other intermittent network problem. Syslog =
protocol and IP fragmentation exacerbates the problem because loss of a =
single fragment would result in entire message being discarded.=0A=
=0A=
</p>=0A=
<p>=0A=
  In some circumstances the sender may receive an ICMP error message or =
other indication of a transmission problem. If the sender receives a =
reasonable indication that some datagram may have been lost, it MAY =
retransmit previously sent messages.=0A=
=0A=
</p>=0A=
<a name=3D"rfc.section.6.2"></a><h4><a =
name=3D"corruption">6.2</a>&nbsp;Message Corruption and Checksums</h4>=0A=
=0A=
<p>=0A=
  The UDP/IP datagrams may get corrupted in transit due to software, =
hardware or network errors. This protocol specified use of UDP checksums =
to enable corruption detection in addition to checksums utilized in IP =
and Ethernet layers. However, checksums do not guarantee corruption =
detection and this protocol does not provide for message retransmission =
when a corrupt message is detected.=0A=
=0A=
</p>=0A=
<a name=3D"rfc.section.6.3"></a><h4><a =
name=3D"overload">6.3</a>&nbsp;Congestion Control</h4>=0A=
=0A=
<p>=0A=
  The UDP does not provide for congestion control. Some systems (hosts =
or routers) may generate ICMP source quench error, but they are not =
required to do so <a class=3D"info" href=3D"#Stevens">[8]<span>Stevens, =
W., TCP/IP Illustrated Volume 1. The Protocols., January =
1994.</span></a>.  Any network host can discard UDP packets when it is =
overloaded. Due to lack of congestion control one or multiple syslog =
senders can maliciously or inadvertently overload the receiver or the =
network infrastructure and cause loss of syslog messages.=0A=
=0A=
</p>=0A=
<a name=3D"rfc.section.6.4"></a><h4><a =
name=3D"sequence">6.4</a>&nbsp;Sequenced Delivery</h4>=0A=
=0A=
<p>=0A=
  The IP transport utilized by the UDP does not guarantee that the =
sequence of datagram delivery will match the order in which the =
datagrams have been sent. The time stamp contained within each syslog =
message may serve as some guide in establishing sequence order, but it =
will not help in cases when multiple messages were generated during the =
same time slot or when messages originated from different hosts whose =
clocks are not synchronized. The order of syslog message arrival via the =
this syslog transport SHOULD NOT be used as an authoritative guide in =
establishing the sequence of events on the syslog sender hosts.=0A=
=0A=
</p>=0A=
<a name=3D"rfc.section.6.5"></a><h4><a =
name=3D"SenderAuthentication">6.5</a>&nbsp;Sender Authentication</h4>=0A=
=0A=
<p>=0A=
  The UDP syslog transport does not strongly associate the message with =
the message sender.  The receiver of the syslog message will not be able =
to ascertain that the message was indeed sent from the reported sender, =
or if the packet was sent from another device.=0A=
=0A=
</p>=0A=
<p>=0A=
  One possible consequence of this behavior is that a misconfigured =
machine may send syslog messages to a receiver representing itself as =
another machine. The administrators may not be able to readily discern =
that there are two or more machines representing themselves as the same =
machine.=0A=
=0A=
</p>=0A=
<a name=3D"security"></a><br /><hr />=0A=
<table summary=3D"layout" cellpadding=3D"0" cellspacing=3D"2" =
class=3D"bug" align=3D"right"><tr><td class=3D"bug"><a href=3D"#toc" =
class=3D"link2">&nbsp;TOC&nbsp;</a></td></tr></table>=0A=
<a name=3D"rfc.section.7"></a><h3>7.&nbsp;Security Considerations</h3>=0A=
=0A=
<p>=0A=
  Several syslog security considerations have been discussed in <a =
class=3D"info" href=3D"#RFC-protocol">RFC-protocol<span>Gerhards, R., =
The syslog Protocol, .</span></a>[2] and in the original <a =
class=3D"info" href=3D"#RFC3164">RFC 3164<span>Lonvick, C., The BSD =
Syslog Protocol, August 2001.</span></a>[1]. This section focuses on =
security considerations specific to the syslog transport over UDP.=0A=
=0A=
</p>=0A=
<a name=3D"rfc.section.7.1"></a><h4><a =
name=3D"SecAuth">7.1</a>&nbsp;Message Authenticity</h4>=0A=
=0A=
<p>=0A=
  This transport protocol does not strongly authenticate the identity of =
the message sender and does not provide any assurance that the message =
was not modified in transit. The receiver of the syslog message will not =
be able to ascertain that the message was indeed sent from the reported =
sender, or if the packet was sent from another device.=0A=
=0A=
</p>=0A=
<a name=3D"rfc.section.7.2"></a><h4><a =
name=3D"SecForg">7.2</a>&nbsp;Message Forgery</h4>=0A=
=0A=
<p>=0A=
  Syslog messages can be easily forged. An attacker may transmit syslog =
messages (either from the machine from which the messages are =
purportedly sent or from any other machine) to a receiver.=0A=
=0A=
</p>=0A=
<p>=0A=
  In one case, an attacker may hide the true nature of an attack amidst =
many other messages.  As an example, an attacker may start generating =
forged messages indicating a problem on some machine.  This may get the =
attention of the system administrators who will spend their time =
investigating the alleged problem.  During this time, the attacker may =
be able to compromise a different machine, or a different process on the =
same machine.=0A=
=0A=
</p>=0A=
<p>=0A=
  Additionally, an attacker may generate false syslog messages to give =
untrue indications of status or of events.  As an example, an attacker =
may stop a critical process on a machine, which may generate a =
notification of exit.  The attacker may subsequently generate a forged =
notification that the process had been restarted.  The system =
administrators may accept that misinformation and not verify that the =
process had indeed been restarted.=0A=
=0A=
</p>=0A=
<a name=3D"rfc.section.7.3"></a><h4><a =
name=3D"SecObs">7.3</a>&nbsp;Message Observation</h4>=0A=
=0A=
<p>=0A=
  The transport protocol does not provide confidentiality of the =
messages in transit. If syslog messages are in clear text, this is how =
they will be transferred.  In most cases passing clear-text =
human-readable messages is a benefit to the administrators. =
Unfortunately, an attacker may also be able to observe the =
human-readable contents of syslog messages.  The attacker may then use =
the knowledge gained from those messages to compromise a machine or do =
other damage. It is RECOMMENDED that no sensitive information is =
transmitted via this transport protocol or that transmission of such =
information is restricted to properly secured networks.=0A=
=0A=
</p>=0A=
<a name=3D"rfc.section.7.4"></a><h4><a =
name=3D"SecReplay">7.4</a>&nbsp;Replaying</h4>=0A=
=0A=
<p>=0A=
  Message forgery and observation can be combined into a replay attack.  =
An attacker may record a set of messages that indicate normal activity =
of a machine.  At a later time, that attacker may remove that machine =
from the network and replay the syslog messages to the collector with =
new time stamps. The administrators may find nothing unusual in the =
received messages and their receipt would falsely indicate normal =
activity of the machine.=0A=
=0A=
</p>=0A=
<a name=3D"rfc.section.7.5"></a><h4><a =
name=3D"SecRelDel">7.5</a>&nbsp;Unreliable Delivery</h4>=0A=
=0A=
<p>=0A=
  As was previously discussed in the Reliability Considerations section, =
the UDP transport is not reliable and packets containing syslog message =
datagrams can be lost in transit without any notice. There can be =
security consequences to the loss of one or more syslog messages.  =
Administrators may not become aware of a developing and potentially =
serious problem. Messages may also be intercepted and discarded by an =
attacker as a way to hide unauthorized activities.=0A=
=0A=
</p>=0A=
<a name=3D"rfc.section.7.6"></a><h4><a =
name=3D"SecPri">7.6</a>&nbsp;Message Prioritization and =
Differentiation</h4>=0A=
=0A=
<p>=0A=
  The transport protocol described in this document does not require =
prioritization of syslog messages on the wire or when processed on the =
receiving host based on their severity.  The security implication of =
such behavior is that the syslog receiver or network devices may get =
overwhelmed with low severity messages and be forced to discard =
potentially high severity messages. High severity messages may contain =
indication about serious security problems, but they will not get a =
higher priority. It is difficult to make sure that high severities =
messages get higher end-to-end delivery priority, especially over an =
unreliable UDP transport.=0A=
=0A=
</p>=0A=
<p>=0A=
  On a case-by-case basis, device operators may find some way to =
associate the different severity levels with the quality of service =
identifiers.  As an example, the operators may elect to define some =
linkage between syslog messages that have a specific Priority value with =
a specific value to be used in the IPv4 Precedence field <a =
class=3D"info" href=3D"#RFC0791">[4]<span>Postel, J., Internet Protocol, =
September 1981.</span></a>, the IPv6 Traffic Class octet <a =
class=3D"info" href=3D"#RFC2460">[5]<span>Deering, S. and R. Hinden, =
Internet Protocol, Version 6 (IPv6) Specification, December =
1998.</span></a>, or the Differentiated Services field <a class=3D"info" =
href=3D"#RFC2474">[9]<span>Nichols, K., Blake, S., Baker, F. and D. =
Black, Definition of the Differentiated Services Field (DS Field) in the =
IPv4 and IPv6 Headers, December 1998.</span></a>.  However, even with =
this prioritization on the network, high load can lead to buffer =
starvation on the receiving host and result in dropped messages.=0A=
=0A=
</p>=0A=
<a name=3D"rfc.section.7.7"></a><h4><a =
name=3D"SecDen">7.7</a>&nbsp;Denial of Service</h4>=0A=
=0A=
<p>=0A=
  An attacker may overwhelm a receiver by sending more messages to it =
than can be handled by the infrastructure or the device itself. =
Implementers SHOULD attempt to provide features that minimize this =
threat such as only receiving syslog messages from known IP addresses.=0A=
=0A=
</p>=0A=
<a name=3D"iana"></a><br /><hr />=0A=
<table summary=3D"layout" cellpadding=3D"0" cellspacing=3D"2" =
class=3D"bug" align=3D"right"><tr><td class=3D"bug"><a href=3D"#toc" =
class=3D"link2">&nbsp;TOC&nbsp;</a></td></tr></table>=0A=
<a name=3D"rfc.section.8"></a><h3>8.&nbsp;IANA Considerations</h3>=0A=
=0A=
<p>=0A=
	IANA must reserve UDP port 514 for this transport.=0A=
	=0A=
</p>=0A=
<a name=3D"rfc-editor"></a><br /><hr />=0A=
<table summary=3D"layout" cellpadding=3D"0" cellspacing=3D"2" =
class=3D"bug" align=3D"right"><tr><td class=3D"bug"><a href=3D"#toc" =
class=3D"link2">&nbsp;TOC&nbsp;</a></td></tr></table>=0A=
<a name=3D"rfc.section.9"></a><h3>9.&nbsp;Notice to RFC Editor</h3>=0A=
=0A=
<p>=0A=
	This is a notice to the RFC editor. This ID is submitted along with ID =
draft-ietf-syslog-protocol and they cross-reference each other.  When =
RFC numbers are determined for each of these IDs, please replace all =
references to "RFC-protocol" with the RFC number of =
draft-ietf-syslog-protocol ID.  Please remove this section after editing.=0A=
	=0A=
</p>=0A=
<a name=3D"authors"></a><br /><hr />=0A=
<table summary=3D"layout" cellpadding=3D"0" cellspacing=3D"2" =
class=3D"bug" align=3D"right"><tr><td class=3D"bug"><a href=3D"#toc" =
class=3D"link2">&nbsp;TOC&nbsp;</a></td></tr></table>=0A=
<a name=3D"rfc.section.10"></a><h3>10.&nbsp;Authors and Working Group =
Chair</h3>=0A=
=0A=
<p>=0A=
	The working group can be contacted via the mailing list:=0A=
		</p>=0A=
<pre>=0A=
[email-masked]=0A=
		</pre>=0A=
<p>=0A=
=0A=
</p>=0A=
<p>=0A=
	The current Chair of the Working Group may be contacted at:=0A=
		</p>=0A=
<pre>=0A=
Chris Lonvick=0A=
Cisco Systems=0A=
Email: [email-masked]=0A=
		</pre>=0A=
<p>=0A=
=0A=
</p>=0A=
<p>=0A=
	The author of this draft is:=0A=
		</p>=0A=
<pre>=0A=
Anton Okmianski=0A=
Email: [email-masked]=0A=
=0A=
Phone: (978) 936-1612=0A=
Fax: (978) 936-2225=0A=
=0A=
Cisco Systems, Inc=0A=
1414 Massachusetts Ave.=0A=
Boxborough, MA 01719-2205=0A=
USA=0A=
		</pre>=0A=
<p>=0A=
=0A=
</p>=0A=
<a name=3D"acks"></a><br /><hr />=0A=
<table summary=3D"layout" cellpadding=3D"0" cellspacing=3D"2" =
class=3D"bug" align=3D"right"><tr><td class=3D"bug"><a href=3D"#toc" =
class=3D"link2">&nbsp;TOC&nbsp;</a></td></tr></table>=0A=
<a name=3D"rfc.section.11"></a><h3>11.&nbsp;Acknowledgements</h3>=0A=
=0A=
<p>=0A=
	The author wishes to thank Chris Lonvick, Rainer Gerhards, David =
Harrington, Andrew Ross, Albert Mietus, Bernie Volz, and all others who =
have commented on the various versions of this proposal.=0A=
	=0A=
</p>=0A=
<a name=3D"rfc.references1"></a><br /><hr />=0A=
<table summary=3D"layout" cellpadding=3D"0" cellspacing=3D"2" =
class=3D"bug" align=3D"right"><tr><td class=3D"bug"><a href=3D"#toc" =
class=3D"link2">&nbsp;TOC&nbsp;</a></td></tr></table>=0A=
<h3>12&nbsp;References</h3>=0A=
<table width=3D"99%" border=3D"0">=0A=
<tr><td class=3D"author-text" valign=3D"top"><a =
name=3D"RFC3164">[1]</a></td>=0A=
<td class=3D"author-text">Lonvick, C., "<a =
href=3D"ftp://ftp.isi.edu/in-notes/rfc3164.txt">The BSD Syslog =
Protocol</a>", RFC 3164, August 2001.</td></tr>=0A=
<tr><td class=3D"author-text" valign=3D"top"><a =
name=3D"RFC-protocol">[2]</a></td>=0A=
<td class=3D"author-text">Gerhards, R., "<a =
href=3D"ftp://ftp.isi.edu/in-notes/rfc3164.txt">The syslog =
Protocol</a>", RFC RFC-protocol.</td></tr>=0A=
<tr><td class=3D"author-text" valign=3D"top"><a =
name=3D"RFC0768">[3]</a></td>=0A=
<td class=3D"author-text">Postel, J., "<a =
href=3D"ftp://ftp.isi.edu/in-notes/rfc768.txt">User Datagram =
Protocol</a>", STD 6, RFC 768, August 1980.</td></tr>=0A=
<tr><td class=3D"author-text" valign=3D"top"><a =
name=3D"RFC0791">[4]</a></td>=0A=
<td class=3D"author-text">Postel, J., "<a =
href=3D"ftp://ftp.isi.edu/in-notes/rfc791.txt">Internet Protocol</a>", =
STD 5, RFC 791, September 1981.</td></tr>=0A=
<tr><td class=3D"author-text" valign=3D"top"><a =
name=3D"RFC2460">[5]</a></td>=0A=
<td class=3D"author-text"><a href=3D"mailto:[email-masked]">Deering, =
S.</a> and <a href=3D"mailto:[email-masked]">R. Hinden</a>, "<a =
href=3D"ftp://ftp.isi.edu/in-notes/rfc2460.txt">Internet Protocol, =
Version 6 (IPv6) Specification</a>", RFC 2460, December 1998 (<a =
href=3D"http://xml.resource.org/public/rfc/html/rfc2460.html">HTML</a>, =
<a =
href=3D"http://xml.resource.org/public/rfc/xml/rfc2460.xml">XML</a>).</td=
></tr>=0A=
<tr><td class=3D"author-text" valign=3D"top"><a =
name=3D"RFC2119">[6]</a></td>=0A=
<td class=3D"author-text"><a href=3D"mailto:[email-masked]">Bradner, =
S.</a>, "<a href=3D"ftp://ftp.isi.edu/in-notes/rfc2119.txt">Key words =
for use in RFCs to Indicate Requirement Levels</a>", BCP 14, RFC 2119, =
March 1997 (<a =
href=3D"http://xml.resource.org/public/rfc/html/rfc2119.html">HTML</a>, =
<a =
href=3D"http://xml.resource.org/public/rfc/xml/rfc2119.xml">XML</a>).</td=
></tr>=0A=
<tr><td class=3D"author-text" valign=3D"top"><a =
name=3D"RFC2234">[7]</a></td>=0A=
<td class=3D"author-text"><a href=3D"mailto:[email-masked]">Crocker, =
D.</a> and <a href=3D"mailto:[email-masked]">P. Overell</a>, "<a =
href=3D"ftp://ftp.isi.edu/in-notes/rfc2234.txt">Augmented BNF for Syntax =
Specifications: ABNF</a>", RFC 2234, November 1997.</td></tr>=0A=
<tr><td class=3D"author-text" valign=3D"top"><a =
name=3D"Stevens">[8]</a></td>=0A=
<td class=3D"author-text">Stevens, W., "TCP/IP Illustrated Volume 1. The =
Protocols.", January 1994.</td></tr>=0A=
<tr><td class=3D"author-text" valign=3D"top"><a =
name=3D"RFC2474">[9]</a></td>=0A=
<td class=3D"author-text"><a href=3D"mailto:[email-masked]">Nichols, =
K.</a>, <a href=3D"mailto:[email-masked]">Blake, S.</a>, <a =
href=3D"mailto:[email-masked]">Baker, F.</a> and <a =
href=3D"mailto:[email-masked]">D. Black</a>, "<a =
href=3D"ftp://ftp.isi.edu/in-notes/rfc2474.txt">Definition of the =
Differentiated Services Field (DS Field) in the IPv4 and IPv6 =
Headers</a>", RFC 2474, December 1998 (<a =
href=3D"http://xml.resource.org/public/rfc/html/rfc2474.html">HTML</a>, =
<a =
href=3D"http://xml.resource.org/public/rfc/xml/rfc2474.xml">XML</a>).</td=
></tr>=0A=
<tr><td class=3D"author-text" valign=3D"top"><a =
name=3D"RFC1035">[10]</a></td>=0A=
<td class=3D"author-text">Mockapetris, P., "<a =
href=3D"ftp://ftp.isi.edu/in-notes/rfc1035.txt">Domain names - =
implementation and specification</a>", STD 13, RFC 1035, November =
1987.</td></tr>=0A=
<tr><td class=3D"author-text" valign=3D"top"><a =
name=3D"RFC1058">[11]</a></td>=0A=
<td class=3D"author-text">Hedrick, C., "<a =
href=3D"ftp://ftp.isi.edu/in-notes/rfc1058.txt">Routing Information =
Protocol</a>", RFC 1058, June 1988.</td></tr>=0A=
<tr><td class=3D"author-text" valign=3D"top"><a =
name=3D"RFC2131">[12]</a></td>=0A=
<td class=3D"author-text"><a href=3D"mailto:[email-masked]">Droms, =
R.</a>, "<a href=3D"ftp://ftp.isi.edu/in-notes/rfc2131.txt">Dynamic Host =
Configuration Protocol</a>", RFC 2131, March 1997 (<a =
href=3D"http://xml.resource.org/public/rfc/html/rfc2131.html">HTML</a>, =
<a =
href=3D"http://xml.resource.org/public/rfc/xml/rfc2131.xml">XML</a>).</td=
></tr>=0A=
<tr><td class=3D"author-text" valign=3D"top"><a =
name=3D"RFC1350">[13]</a></td>=0A=
<td class=3D"author-text"><a =
href=3D"mailto:[email-masked]">Sollins, K.</a>, "<a =
href=3D"ftp://ftp.isi.edu/in-notes/rfc1350.txt">The TFTP Protocol =
(Revision 2)</a>", STD 33, RFC 1350, July 1992.</td></tr>=0A=
<tr><td class=3D"author-text" valign=3D"top"><a =
name=3D"RFC1122">[14]</a></td>=0A=
<td class=3D"author-text"><a href=3D"mailto:[email-masked]">Braden, =
R.</a>, "<a href=3D"ftp://ftp.isi.edu/in-notes/rfc1122.txt">Requirements =
for Internet Hosts - Communication Layers</a>", STD 3, RFC 1122, October =
1989.</td></tr>=0A=
<tr><td class=3D"author-text" valign=3D"top"><a =
name=3D"Kent">[15]</a></td>=0A=
<td class=3D"author-text">Kent, C. and J. Mogul, ""Fragmentation =
Considered Harmful," Computer Communications Review, vol.17, no.5, =
pp.390-401", August 1987.</td></tr>=0A=
</table>=0A=
=0A=
<a name=3D"rfc.authors"></a><br /><hr />=0A=
<table summary=3D"layout" cellpadding=3D"0" cellspacing=3D"2" =
class=3D"bug" align=3D"right"><tr><td class=3D"bug"><a href=3D"#toc" =
class=3D"link2">&nbsp;TOC&nbsp;</a></td></tr></table>=0A=
<h3>Author's Address</h3>=0A=
<table width=3D"99%" border=3D"0" cellpadding=3D"0" cellspacing=3D"0">=0A=
<tr><td class=3D"author-text">&nbsp;</td>=0A=
<td class=3D"author-text">Anton Okmianski</td></tr>=0A=
<tr><td class=3D"author-text">&nbsp;</td>=0A=
<td class=3D"author-text">Cisco Systems, Inc.</td></tr>=0A=
<tr><td class=3D"author-text">&nbsp;</td>=0A=
<td class=3D"author-text">1414 Massachusetts Ave</td></tr>=0A=
<tr><td class=3D"author-text">&nbsp;</td>=0A=
<td class=3D"author-text">Boxborough, MA  01719-2205</td></tr>=0A=
<tr><td class=3D"author-text">&nbsp;</td>=0A=
<td class=3D"author-text">USA</td></tr>=0A=
<tr><td class=3D"author" align=3D"right">EMail:&nbsp;</td>=0A=
<td class=3D"author-text">[email-masked]</td></tr>=0A=
</table>=0A=
=0A=
<a name=3D"AppendixA"></a><br /><hr />=0A=
<table summary=3D"layout" cellpadding=3D"0" cellspacing=3D"2" =
class=3D"bug" align=3D"right"><tr><td class=3D"bug"><a href=3D"#toc" =
class=3D"link2">&nbsp;TOC&nbsp;</a></td></tr></table>=0A=
<a name=3D"rfc.section.A"></a><h3>Appendix A.&nbsp;Rational For =
Transport Message Size Restrictions</h3>=0A=
=0A=
<p>=0A=
   This appendix provides the rational behind the Payload size =
restrictions for this protocol.  The Payload restrictions outlined in =
the specification, essentially ensure that the transport message size =
does not exceed 512 bytes (without UDP/IP headers) for transport via =
IPv4 and does not exceed 1196 bytes for transport via IPv6. These =
restrictions put an upper boundary on the UDP/IP datagram size for this =
protocol, which accomplishes two goals.=0A=
=0A=
</p>=0A=
<p>=0A=
   First, they insure interoperability between various UDP/IP =
implementations.  Even though the maximum IP datagram size is specified =
as 65536 bytes, many UDP/IP implementations have been shown not to work =
with large datagram sizes <a class=3D"info" =
href=3D"#Stevens">[8]<span>Stevens, W., TCP/IP Illustrated Volume 1. The =
Protocols., January 1994.</span></a>.  Many established UDP-based =
protocols restrict UDP datagram data size to 512 bytes. For example, DNS =
<a class=3D"info" href=3D"#RFC1035">[10]<span>Mockapetris, P., Domain =
names - implementation and specification, November 1987.</span></a> and =
RIP <a class=3D"info" href=3D"#RFC1058">[11]<span>Hedrick, C., Routing =
Information Protocol, June 1988.</span></a> do that. The DHCPv4 <a =
class=3D"info" href=3D"#RFC2131">[12]<span>Droms, R., Dynamic Host =
Configuration Protocol, March 1997.</span></a> restricts the size to 512 =
bytes, but allows sides to agree on a larger value through the protocol. =
The TFTP <a class=3D"info" href=3D"#RFC1350">[13]<span>Sollins, K., The =
TFTP Protocol (Revision 2), July 1992.</span></a> restricts the UDP data =
size to 518 bytes, which is slightly larger.=0A=
=0A=
</p>=0A=
<p>=0A=
   The second reason for datagram size restrictions is that it helps =
reduce the likelihood of the  IP-layer datagram fragmentation.  This =
could have potentially resulted in fragmentation on two levels: syslog =
transport protocol and IP layer. Since fragmentation has significant =
overhead for message reassembley, it is best to avoid double =
fragmentation. The likelihood of IP fragmentation can be significantly =
reduced by sending IP datagrams in sizes which all hosts must be able to =
process.=0A=
=0A=
</p>=0A=
<p>=0A=
   The minimum MTU of a transport protocol determines the minimum size =
of packets that hosts must be able to accept.  For IPv4, the minimum MTU =
is 576 bytes <a class=3D"info" href=3D"#RFC0791">[4]<span>Postel, J., =
Internet Protocol, September 1981.</span></a> and for IPv6 - 1280 bytes =
<a class=3D"info" href=3D"#RFC2460">[5]<span>Deering, S. and R. Hinden, =
Internet Protocol, Version 6 (IPv6) Specification, December =
1998.</span></a>.  In both cases, the maximum message size we chose fits =
within the MTU of the transport in all cases except for when extremely =
large IP headers are used.  IPv4 header can range from 20 to 60 bytes in =
length and UDP header is fixed at 8 bytes. Thus, our message size =
restrictions ensure that in all cases except for when the IP header is =
56 bytes or greater, the size of the packet will within the size of the =
transport MTU.=0A=
=0A=
</p>=0A=
<p>=0A=
   For IPv6, we have left the same amount of padding for UDP/IP headers =
as was conventionally done for IPv4 in DNS, RIP and DHCPv4 with an =
additional padding of extra 20 bytes to accommodate a larger IPv6 =
header. This follows the methodology suggested in the IPv6 specification =
for calculating upper-layer payload limits <a class=3D"info" =
href=3D"#RFC2460">[5]<span>Deering, S. and R. Hinden, Internet Protocol, =
Version 6 (IPv6) Specification, December 1998.</span></a>.=0A=
=0A=
</p>=0A=
<p>=0A=
   Path MTU discovery can generally be used to discover the MTU of the =
link.  Unfortunately, using path MTU discovery with UDP is not a =
reliable option because it depends on routers providing ICMP errors and =
hosts doing retransmission, which are not done consistently. =
Implementors MUST follow the size restrictions outlined above and not =
rely on path MTU discovery.=0A=
=0A=
</p><a name=3D"rfc.copyright"></a><br /><hr />=0A=
<table summary=3D"layout" cellpadding=3D"0" cellspacing=3D"2" =
class=3D"bug" align=3D"right"><tr><td class=3D"bug"><a href=3D"#toc" =
class=3D"link2">&nbsp;TOC&nbsp;</a></td></tr></table>=0A=
<h3>Intellectual Property Statement</h3>=0A=
<p class=3D'copyright'>=0A=
The IETF takes no position regarding the validity or scope of=0A=
any intellectual property or other rights that might be claimed=0A=
to  pertain to the implementation or use of the technology=0A=
described in this document or the extent to which any license=0A=
under such rights might or might not be available; neither does=0A=
it represent that it has made any effort to identify any such=0A=
rights. Information on the IETF's procedures with respect to=0A=
rights in standards-track and standards-related documentation=0A=
can be found in BCP-11. Copies of claims of rights made=0A=
available for publication and any assurances of licenses to=0A=
be made available, or the result of an attempt made=0A=
to obtain a general license or permission for the use of such=0A=
proprietary rights by implementors or users of this=0A=
specification can be obtained from the IETF Secretariat.</p>=0A=
<p class=3D'copyright'>=0A=
The IETF invites any interested party to bring to its=0A=
attention any copyrights, patents or patent applications, or=0A=
other proprietary rights which may cover technology that may be=0A=
required to practice this standard. Please address the=0A=
information to the IETF Executive Director.</p>=0A=
<h3>Full Copyright Statement</h3>=0A=
<p class=3D'copyright'>=0A=
Copyright (C) The Internet Society (2004). All Rights Reserved.</p>=0A=
<p class=3D'copyright'>=0A=
This document and translations of it may be copied and furnished to=0A=
others, and derivative works that comment on or otherwise explain it=0A=
or assist in its implementation may be prepared, copied, published and=0A=
distributed, in whole or in part, without restriction of any kind,=0A=
provided that the above copyright notice and this paragraph are=0A=
included on all such copies and derivative works. However, this=0A=
document itself may not be modified in any way, such as by removing=0A=
the copyright notice or references to the Internet Society or other=0A=
Internet organizations, except as needed for the purpose of=0A=
developing Internet standards in which case the procedures for=0A=
copyrights defined in the Internet Standards process must be=0A=
followed, or as required to translate it into languages other than=0A=
English.</p>=0A=
<p class=3D'copyright'>=0A=
The limited permissions granted above are perpetual and will not be=0A=
revoked by the Internet Society or its successors or assignees.</p>=0A=
<p class=3D'copyright'>=0A=
This document and the information contained herein is provided on an=0A=
&quot;AS IS&quot; basis and THE INTERNET SOCIETY AND THE INTERNET =
ENGINEERING=0A=
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING=0A=
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION=0A=
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF=0A=
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.</p>=0A=
<h3>Acknowledgment</h3>=0A=
<p class=3D'copyright'>=0A=
Funding for the RFC Editor function is currently provided by the=0A=
Internet Society.</p>=0A=
</body></html>=0A=
=0A=

- ------=_NextPart_000_0005_01C43451.70B0D950--

------------------------------

Date: Sun, 9 May 2004 04:03:03 +0200
From: "Rainer Gerhards" <[email-masked]>
Subject: RE: Transport draft preview

Anton,

I could not go in-depth through the draft, but I have some comments...

> One area I am not quite sure about yet is what minimum size
> of messages should implementations be forced to support. It
> definitely can't be the full allowed size of 16MB as some
> hardware won't support it. Right now it is set at 65k, which
> means implementations are forced to support fragmentation.  I

I think this is the most important one. I strongly think that we should
NOT say the max MUST is 65k - if we really do this, we acutally say that
everything beyond 65k can not really be expected to work. We must
guarantee that the max size of 16 MB can be reliably transmitted, else
the whole thing is useless.

After reading this parts of the draft, I have to admit I am not sure if
it really was a good idea to move the fragmentation into the transport.
As it was designed in -protocol, it were multi-part message, very low
overhead, very easy to deal with enourmous amounts of data. A key to
that simplicity was that each receiver was free to *ignore* multi-part
messaging, because each multi-part message was a valid syslog message in
itself and could be treated as such - no complexity at the
receiver/relay, nothing that could overrun a low-end device. Now, we
mandate that everybody support the full sizes ... And begin to get into
trouble.

In any case, however, I strongly suggest that we require that full
message size is supported, because otherwise it is pointless to mention
it. As I said, with the current proposed ID the max size is actually
65k, which I think is not in the spirit of -protocol.

Re 4.1:
###
4.1 Target Port
Syslog receivers MUST support accepting syslog message datagrams on a
well-known UDP port 514. Syslog senders MUST support sending syslog
message datagrams to the UDP port 514.
##

Is this really a MUST? Many admins will not allow this, any real-world
syslog deamon must support non-514 ports (only), because else it will
probably be ditched for security reasons by some admins.

Re 4.2:
###
4.2 Source Port
Syslog senders can use any source UDP port for transmitting messages.
Senders MAY randomly select a source port, but MUST use the port in an
exclusive fashion. No concurrent port reuse on the same host is allowed.

###
I think I can not guarantee "no concurrent port reuse" in our
implementatons - this may be very hard to avoid in multi-process,
multi-threading apps. I suggest we drop this requirement.

I've seen RFC 3164 being referenced multiple times. AFIK, this can cause
problems in becomeing a standards-track RFC (because 3164 is
informational). Just a hint to check with those experienced in these
issues - I may be totally wrong.

Rainer

------------------------------

Date: Mon, 10 May 2004 04:10:45 +0200
From: "Rainer Gerhards" <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-syslog-protocol-04.txt

Anton,

I am on the road with bad connectivity, so it took some time to get to
this..

> From a quick glance, it seems the max length is not specified although
> somewhere there is a reference to section 4 for it.

I don't have access to the published draft right now, but at least it
was supposed to say "max of ~16MB". I'll check ASAP and eventually
re-adjust. It should also say "keep it below 499 bytes".

>
> Definitions & Architecture sections talks about senders and receivers,
> which is good, but still has the picture with various relay/collector
> stuff.  Are you planning on removing it?

Well, if there is strong objection, I can remove that. But I think it is
better to keep it in, because it defines names for several roles - this
may make it easier in the future to use the same name for the same
thing.

>
> Again, I have a problem with a term "machine can generate".  I think
> we need to refer to applications or processes.  Syslog is not a
> protocol for "machine-to-machine" (host-to-host) communication only.
> Like we said before, receiver and sender can be on the same machine.
> So, we have applications or processes interacting, not "machines".  I
> think we need to mention that multiple senders and multiple receivers
> can co-exist on the same host.  A particular transport protocol can
> impose restrictions on receivers. In my sec, I say that receiver MUST
> support listening on a standard syslog port and MAY listen on another
> port.

I basically agree - I've not re-worded this so far, because I am
focussing on the other things, first. I thought, however, that the
description of the relay with the original sender process already
covered at least some of this idea... But definitely not enough of it ;)

> Why do we default to IPv6 unknown IP?  It is longer.

I can change this, but I think/hope some time IPv6 will look more
natural - no other reasoning for this.

> I also don't
> understand the value of distinguishing the IPv4 unknown IP and IPv6
> address. It is still unknown.  It also creates ambiguity, what is the
> stack supports both.

I found this possibility while describing the scenarios. I can remove
it, if that is concensus.

> "The TAG is used to denote the process sending the message."  Should
> this be a MUST?

I pass this on to the list... It sounds good, but doesn't we need to
create a TAG value repository in this case?

>
> "The static ID SHOULD always remain the same for a given sender
> process."  I think you mean "application" here.  The process is a
> specific instance of an application which is identified with dynamic
> part, right? If you referred to process name, then it is the same for
> different process instances.

You are right, "application" is the right term here.

>
> "The full-dyn-id SHOULD change with each new instance of the sending
> process." SHOULD or MUST?

Strongly opt for SHOULD - else you need to make sure that the OS does
not accidently assing you the same PID as a previous process. And, yes,
I agree this is extremely unlikely, but it is a possibility...

>
> "Traditionally, the full-dyn-id should reflect the process ID of the
> new instance."  I think the word "traditionally" implies we are trying
> to follow some established standard, but there is no such thing.
> "Traditionally... Should..." does not sound right.

Agree, "traditionally" needs to be removed. SHOULD must be upper case.
The rest - I think - is right.

>
> I know you wanted to keep some resemblance of the old ad-hoc syslog
> format, but two separate fields for TAG would make life much easier
> then having to find the last [ and only if there is ] at the end.  If
> we make two fields, they would be APP-NAME (or PROCESS-NAME) and
> PROCESS-ID.  This is much more intuitive then describing it as static
> vs. dynamic. And this is what people are after in the end. We could
> allow for say "-" for unknown process ID. But I think requiring
> APP-NAME is a must. What do you think?

That sounds good - I actually did not have this good idea. If there is
no objection, I'll change it to this in the next draft.

Rainer

------------------------------

Date: Mon, 10 May 2004 16:02:50 +1200
From: "Andrew Ross" <[email-masked]>
Subject: RE: Transport draft preview

Hi All,

Can anyone tell me why we are talking about 16MB syslog messages at all?

I thought the spirit of syslog was a quick, human readable, single
lined, informational message that can be logged to disk and be parsed by
a reporting tool. Even taking into account UTF-8 encoding and the
possibility of some binary data, do we *really* need 16MB? 1024 bytes
does nicely in most cases, taking the max to 64KB is workable, but
taking it to 16MB is just making a rod for our own backs. Even on a nice
machine with stacks of memory, having to buffer and rebuild 16MB
multipart messages will just be a nightmare.

If we want to send huge dumps of binary data, we should use TFTP or FTP
to transfer it. Let's keep the concept of syslog to something that is
sensible.

Thoughts?

Andrew

------------------------------

Date: Mon, 10 May 2004 10:57:30 -0400
From: "Anton Okmianski" <[email-masked]>
Subject: RE: Transport draft preview

Rainer:

> > One area I am not quite sure about yet is what minimum size
> > of messages should implementations be forced to support. It
> > definitely can't be the full allowed size of 16MB as some
> > hardware won't support it. Right now it is set at 65k, which
> > means implementations are forced to support fragmentation.  I
>
> I think this is the most important one. I strongly think that
> we should NOT say the max MUST is 65k - if we really do this,
> we acutally say that everything beyond 65k can not really be
> expected to work. We must guarantee that the max size of 16
> MB can be reliably transmitted, else the whole thing is useless.

I think we need to find some compromise. Requiring 16MB would not be a
good idea for cases where implementation runs on systems with less
than 16MB of RAM. My compromise suggests that you can send 65K message
to any implementation.  In very rare cases when your systems is
designed to send larger messages, you would need to use specific
implementations that support it.

> After reading this parts of the draft, I have to admit I am
> not sure if it really was a good idea to move the
> fragmentation into the transport. As it was designed in
> -protocol, it were multi-part message, very low overhead,
> very easy to deal with enourmous amounts of data. A key to
> that simplicity was that each receiver was free to *ignore*
> multi-part messaging, because each multi-part message was a
> valid syslog message in itself and could be treated as such -
> no complexity at the receiver/relay, nothing that could
> overrun a low-end device. Now, we mandate that everybody
> support the full sizes ... And begin to get into trouble.

I see your point, but I think these are different scenarios.  If
somebody wants to associate multiple regular syslog messages into one
using some structured content tags (including parts or whatever) it is
fine.  But there are cases when user specifically needs to transmit a
big message and, in this case, making the user break it or just
receive it as broken into pieces is not user-friendly.  I think
pushing things like re-assembly on the user is not good. If you deal
with reassembly, the other approach is the same in that regard.

The only real difference is that the other approach also replicated
syslog header in every message.  We can do it.  This obviously has it
is pros and cons.  Waste is obviously a disadvantage (space, more
parsing during reassembly, more fragmentation because of header
overhead, etc).

The only advantage is that you could potentially make stateless relay
routing decisions without re-assembly by parsing header of every
message. I don't believe it is a big deal.  Do you?

If we are talking about using source IP and source port during
re-assembly of messages like the current draft does, I do think that
transport layer is the appropriate place for fragmentation.

> In any case, however, I strongly suggest that we require that
> full message size is supported, because otherwise it is
> pointless to mention it. As I said, with the current proposed
> ID the max size is actually 65k, which I think is not in the
> spirit of -protocol.
>
>
> Re 4.1:
> ###
> 4.1 Target Port
> Syslog receivers MUST support accepting syslog message
> datagrams on a well-known UDP port 514. Syslog senders MUST
> support sending syslog message datagrams to the UDP port 514.
> ##
>
> Is this really a MUST? Many admins will not allow this, any
> real-world syslog deamon must support non-514 ports (only),
> because else it will probably be ditched for security reasons
> by some admins.

It says "MUST support". This means an implementation must be *capable*
of doing this.  It does not say "MUST accept".  So, my wording was
meant to imply that it can, indeed, be changed administratively or
implementation can listen on multiple ports or whatever.  I can
wordsmith it to make it clearer.

> Re 4.2:
> ###
> 4.2 Source Port
> Syslog senders can use any source UDP port for transmitting
> messages. Senders MAY randomly select a source port, but MUST
> use the port in an exclusive fashion. No concurrent port
> reuse on the same host is allowed.
>
> ###
> I think I can not guarantee "no concurrent port reuse" in our
> implementatons - this may be very hard to avoid in
> multi-process, multi-threading apps. I suggest we drop this
> requirement.

I want to understand your issues here better. Can you elaborate?

The guarantee of no concurrent use of the same port (or socket) is
typically provided by the UDP/IP software stack.  Basically, it is the
default behavior (you get a random available port assigned) unless you
specify a flag to force it behave otherwise (on Unix, SO_REUSEPORT or
SO_REUSEADDR). The reason I kind of want this there is that it allows
to distinguish sending processes and not confuse fragments from two
different processes.

> I've seen RFC 3164 being referenced multiple times. AFIK,
> this can cause problems in becomeing a standards-track RFC
> (because 3164 is informational). Just a hint to check with
> those experienced in these issues - I may be totally wrong.

I don't think it references it as an authoritative source of anything,
more as a historical reference. But I'd be happy to remove references
if people think it is important. I kind of wanted to give some context
for this standard.

Thanks,
Anton.

>
> Rainer
>

------------------------------

Date: Mon, 10 May 2004 11:23:07 -0400
From: "Anton Okmianski" <[email-masked]>
Subject: RE: Transport draft preview

Andrew:

Good question...

Well, Rainer mentioned some Windows event Log message that he had to
make into syslog message that could reach as large as 1MB if I recall
correctly.  Then, as we were designing fragmentation, we had to choose
some size limit. I was initially looking at binary encoding, so
looking at how many bits to allocate to message length.  16-bit value
gave us 65k. 24-bit value gave us 16MB. This is where 16MB came from.

I do not believe we can legitimately require everyone to support 16MB
multi-part messages.  I would never allow such default in my
implementation.  I would maybe allow it to be configured.  For one it
is really not smart to send 16MB over unreliable UDP using about 32000
UDP datagrams without any acknowledgments.

I would even consider lowering the 16MB significantly.  We just have
to keep in mind that we are talking about a consistent message size
limit for syslog-protocol regardless of the transport mapping. So, the
transport may indeed be TFTP for 16MB message.  Maybe it makes sense
to say in syslog-protocol what the minimum size the implementations
are required to support regardless of transport? Although I can see
how it can come back to bite us.

Anton.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Andrew Ross
> Sent: Monday, May 10, 2004 12:03 AM
> To: 'Rainer Gerhards'; 'Anton Okmianski'; [email-masked]
> Subject: RE: Transport draft preview
>
>
>
> Hi All,
>
> Can anyone tell me why we are talking about 16MB syslog
> messages at all?
>
>
> I thought the spirit of syslog was a quick, human readable,
> single lined, informational message that can be logged to
> disk and be parsed by a reporting tool. Even taking into
> account UTF-8 encoding and the possibility of some binary
> data, do we *really* need 16MB? 1024 bytes does nicely in
> most cases, taking the max to 64KB is workable, but taking it
> to 16MB is just making a rod for our own backs. Even on a
> nice machine with stacks of memory, having to buffer and
> rebuild 16MB multipart messages will just be a nightmare.
>
> If we want to send huge dumps of binary data, we should use
> TFTP or FTP to transfer it. Let's keep the concept of syslog
> to something that is sensible.
>
> Thoughts?
>
> Andrew
>
>
>

------------------------------

Date: Mon, 10 May 2004 15:26:14 -0400
From: "Anton Okmianski" <[email-masked]>
Subject: RE: Transport draft preview

Devin:

> There is one point which I'm not completely clear on.  What
> happens to a fragmented message when one ore more parts of
> that message get dropped?

Just like with IP fragmentation, the whole message (all other
fragments) gets discarded.  It is mentioned in the Message Reassembly
section. A couple other sections (Avoiding Fragmentation and Lost
Datagrams) imply it.  But since you are not the first person to ask
this, I will make sure to put this more prominently somewhere in the
draft.

Of course we should not prevent the implementation from logging the
received fragments of an incomplete message somewhere for debugging.
So, I am not clear if a putting a MUST is a good idea.

> One other suggestion ... why not just limit UDP packets to
> 1024 bytes, whith no fragmentation?

With IPv4, transferring UDP datagrams of that size may not be reliable
to my knowledge (well less reliable than it is UDP usually is :)).
Most UDP protocols restrict the size to a much smaller size. I don't
know of popular UDP-based protocols that allow 1024 bytes UDP
datagrams. If there are some they could serve as sufficient proof that
this datagram size in UDP is acceptable. See discussion of packets
sizes in Appendix A of my draft.

> For large syslog
> messages, require a reliable transport layer (TCP) which
> means you can just properly frame the message and send it (or
> use something like BEEP which already deals with
> fragmentation) ...

I am not sure if it is a good idea to require different transport
depending on a message size.

I am also not sure if 1024 bytes is sufficient.  I know one product I
work on at Cisco which has a crash diagnostic message which consists
of about 1000-1500 lines.  So, it is about 80-130K. Even bigger than
the 65K MUST-support size I proposed for udp-transport. I just think
transferring huge fragmented messages over unreliable transport is not
a good idea. Hence, larger size are not a requirement, but a
recommendation.

As far as using TCP, I am actually thinking more along the lines of
UDP with acknowledgements (like in TFTP) for a future protocol. It
would still be lighter and the acknowledgments would be more high
level. For example, a receiver can acknowledge the message after it
persisted it to disk instead of like in TCP, where a stack
acknowledges the message as it is received by the host (and if the
systems crashes an the message is lost, oh well). Using TCP often
results in additional higher-level protocol acknowledgements being
sent.

I was thinking about putting a MessageId field into every message
(including basic header) such that adding acknowledgements later would
not change the format of the message, but I bailed out on that as I
think this increases scope.  If people think that this may not be a
bad idea, I can put it in there.

Thanks,
Anton.

>
> On Fri, May 07, 2004 at 04:36:25PM -0400, Anton Okmianski wrote:
> > Hi!
> >
> > I am about to publish the new UDP syslog transport draft. I
thought
> > I'd show it this forum first before making it publicly
> available to a wider audience.  In particular, I want to make
> sure we have rough consensus on support for fragmentation
> feature.  I have specified the header format using ASCII
> encoding as was suggested by Rainer and Andrew.
> >
> > I plan on submitting this as an official draft next week.
> One area I
> > am not quite sure about yet is what minimum size of messages
should
> > implementations be forced to support. It definitely can't
> be the full
> > allowed size of 16MB as some hardware won't support it.
> Right now it
> > is set at 65k, which means implementations are forced to support
> > fragmentation.  I wonder if reducing it to the size where
> > fragmentation would be optional (507 bytes for IPv4 and
> 1911 for IPv6)
> > would increase the adoption of the protocol without sacrificing
too
> > much of interoperability. Fragmentation feature adds orders of
> > magnitude more complexity than non-fragmented syslog
> transport.  Any
> > opinions?
> >
> > Thanks,
> > Anton.
>
> >
> >
> >
> > syslog Working Group
> A. Okmianski
> > Internet-Draft                                       Cisco
> Systems, Inc.
> > Expires: November 5, 2004
>  May 7, 2004
> >
> >
> >                 Transmission of syslog messages over UDP
> >                    draft-ietf-syslog-transport-udp-01
> >
> > Status of this Memo
> >
> >    This document is an Internet-Draft and is in full
> conformance with
> >    all provisions of Section 10 of RFC2026.
> >
> >    Internet-Drafts are working documents of the Internet
Engineering
> >    Task Force (IETF), its areas, and its working groups.
> Note that other
> >    groups may also distribute working documents as
Internet-Drafts.
> >
> >    Internet-Drafts are draft documents valid for a maximum
> of six months
> >    and may be updated, replaced, or obsoleted by other
> documents at any
> >    time. It is inappropriate to use Internet-Drafts as reference
> >    material or to cite them other than as "work in progress."
> >
> >    The list of current Internet-Drafts can be accessed at http://
> >    www.ietf.org/ietf/1id-abstracts.txt.
> >
> >    The list of Internet-Draft Shadow Directories can be accessed
at
> >    http://www.ietf.org/shadow.html.
> >
> >    This Internet-Draft will expire on November 5, 2004.
> >
> > Copyright Notice
> >
> >    Copyright (C) The Internet Society (2004). All Rights Reserved.
> >
> > Abstract
> >
> >    This document describes the transport for the syslog message
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
using
> >    multiple datagrams.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Okmianski               Expires November 5, 2004
>     [Page 1]
> > >
> > Internet-Draft            syslog udp transport
>     May 2004
> >
> >
> > Table of Contents
> >
> >    1.  Introduction . . . . . . . . . . . . . . . . . . . .
> . . . . .  3
> >    2.  Transport Protocol Overview  . . . . . . . . . . . .
> . . . . .  4
> >      2.1   Definitions and Architecture . . . . . . . . . .
> . . . . .  4
> >      2.2   Required Transport Protocol  . . . . . . . . . .
> . . . . .  4
> >      2.3   Encapsulation Layers . . . . . . . . . . . . . .
> . . . . .  4
> >    3.  Message Format . . . . . . . . . . . . . . . . . . .
> . . . . .  6
> >      3.1   Basic Header Format  . . . . . . . . . . . . . .
> . . . . .  6
> >      3.2   Extended Header Format . . . . . . . . . . . . .
> . . . . .  7
> >        3.2.1   Message Identifier . . . . . . . . . . . . .
> . . . . .  7
> >        3.2.2   Total Length . . . . . . . . . . . . . . . .
> . . . . .  7
> >        3.2.3   Fragment Offset  . . . . . . . . . . . . . .
> . . . . .  8
> >        3.2.4   Extended Header Example  . . . . . . . . . .
> . . . . .  8
> >      3.3   Payload  . . . . . . . . . . . . . . . . . . . .
> . . . . .  9
> >      3.4   Supported Message Length . . . . . . . . . . . .
> . . . . .  9
> >    4.  UDP/IP Layer Considerations  . . . . . . . . . . . .
> . . . . . 10
> >      4.1   Target Port  . . . . . . . . . . . . . . . . . .
> . . . . . 10
> >      4.2   Source Port  . . . . . . . . . . . . . . . . . .
> . . . . . 10
> >      4.3   Source IP Address  . . . . . . . . . . . . . . .
> . . . . . 10
> >      4.4   UDP/IP Headers . . . . . . . . . . . . . . . . .
> . . . . . 10
> >    5.  Fragmentation and Reassembley  . . . . . . . . . . .
> . . . . . 12
> >      5.1   Message Fragmentation  . . . . . . . . . . . . .
> . . . . . 12
> >      5.2   Message Reassembley  . . . . . . . . . . . . . .
> . . . . . 12
> >      5.3   Avoiding Fragmentation . . . . . . . . . . . . .
> . . . . . 13
> >    6.  Reliability Considerations . . . . . . . . . . . . .
> . . . . . 14
> >      6.1   Lost Datagrams . . . . . . . . . . . . . . . . .
> . . . . . 14
> >      6.2   Message Corruption and Checksums . . . . . . . .
> . . . . . 14
> >      6.3   Congestion Control . . . . . . . . . . . . . . .
> . . . . . 14
> >      6.4   Sequenced Delivery . . . . . . . . . . . . . . .
> . . . . . 14
> >      6.5   Sender Authentication  . . . . . . . . . . . . .
> . . . . . 15
> >    7.  Security Considerations  . . . . . . . . . . . . . .
> . . . . . 16
> >      7.1   Message Authenticity . . . . . . . . . . . . . .
> . . . . . 16
> >      7.2   Message Forgery  . . . . . . . . . . . . . . . .
> . . . . . 16
> >      7.3   Message Observation  . . . . . . . . . . . . . .
> . . . . . 16
> >      7.4   Replaying  . . . . . . . . . . . . . . . . . . .
> . . . . . 17
> >      7.5   Unreliable Delivery  . . . . . . . . . . . . . .
> . . . . . 17
> >      7.6   Message Prioritization and Differentiation . . .
> . . . . . 17
> >      7.7   Denial of Service  . . . . . . . . . . . . . . .
> . . . . . 18
> >    8.  IANA Considerations  . . . . . . . . . . . . . . . .
> . . . . . 19
> >    9.  Notice to RFC Editor . . . . . . . . . . . . . . . .
> . . . . . 20
> >    10.   Authors and Working Group Chair  . . . . . . . . .
> . . . . . 21
> >    11.   Acknowledgements . . . . . . . . . . . . . . . . .
> . . . . . 22
> >    12.   References . . . . . . . . . . . . . . . . . . . .
> . . . . . 22
> >        Author's Address . . . . . . . . . . . . . . . . . .
> . . . . . 23
> >    A.  Rational For Transport Message Size Restrictions . .
> . . . . . 24
> >        Intellectual Property and Copyright Statements . . .
> . . . . .
> > 26
> >
> >
> >
> >
> > Okmianski               Expires November 5, 2004
>     [Page 2]
> > >
> > Internet-Draft            syslog udp transport
>     May 2004
> >
> >
> > 1.  Introduction
> >
> >    The original syslog protocol has been described in an
> informational
> >    RFC 3164 [1] as it has been observed in existing
> implementations. It
> >    describes both the semantics of syslog message format as
> well as a
> >    UDP transport.  Subsequently, the syslog protocol has
> been formally
> >    defined in a standards track RFC-protocol [2].
> >
> >    The RFC-protocol [2] has provided for support of any number of
> >    transport layer protocols for transmitting syslog
> messages and left
> >    it to subsequent RFCs to specify transport protocols.
> This standards
> >    track RFC describes the UDP transport for the syslog
> protocol. This
> >    transport protocol is REQUIRED for all syslog protocol
> >    implementations.
> >
> >    This transport protocol was designed to work on top of
> UDP [3] over
> >    both IPv4 [4] and IPv6 [5]. This protocol overcomes the data
size
> >    restrictions of the UDP protocol by introducing message
> fragmentation
> >    feature.
> >
> >    As we will show in this specification, this protocol has
> significant
> >    reliability and security issues stemming from the use of UDP.
> >    However, this protocol is lightweight and extends on the
existing
> >    popular use of UDP for syslog. Network administrators
> and architects
> >    should be aware of the shortcomings of this protocol and plan
> >    accordingly.
> >
> >    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
> "SHALL NOT",
> >    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
> "OPTIONAL" in this
> >    document are to be interpreted as described in RFC 2119 [6].
The
> >    words 'byte' and 'octet' are used interchangeably in this
> >    specification.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Okmianski               Expires November 5, 2004
>     [Page 3]
> > >
> > Internet-Draft            syslog udp transport
>     May 2004
> >
> >
> > 2.  Transport Protocol Overview
> >
> > 2.1  Definitions and Architecture
> >
> >    The following definitions will be used in this document:
> >    o  An application that can generate syslog messages will
> be referred
> >       to as a "sender";
> >    o  An application that can receive syslog messages will
> be referred
> >       to as a "receiver".
> >
> >    An application can function in dual capacity. For
> example, a syslog
> >    relay may receive and forward messages. A single system
> can host any
> >    number of syslog senders. Only one syslog receiver can
> be hosted on a
> >    single system using the standard listening port.
> >
> > 2.2  Required Transport Protocol
> >
> >    This document describes the UDP transport layer protocol for
the
> >    syslog protocol RFC-protocol [2]. Every syslog sender
> and receiver
> >    implementation which adheres to the RFC-protocol [2] MUST fully
> >    implement the transport protocol specified in this document.
> >    Implementations does not have to support both IPv4 and
> IPv6 if it is
> >    designed to be used over only one of these protocols.
> >
> > 2.3  Encapsulation Layers
> >
> >    Syslog UDP transport carries syslog messages as generic payload
> >    encapsulated with a syslog transport header, UDP header and an
IP
> >    header. Below is a summary of syslog UDP/IP packet
> structure as used
> >    this transport protocol:
> >
> >
> >    		+--------------------------------+
> >    		|       IPv4 or IPv6 Header      |
> >    		|        (20 or more bytes)      |
> >    		+--------------------------------+
> >    		|           UDP Header           |
> >    		|           (8 bytes)            |
> >    		+--------------------------------+
> >    		|    Syslog Transport Header     |
> >    		|        (5 or 32 bytes)         |
> >    		+--------------------------------+
> >    		|     Syslog Message Payload     |
> >    		|       (1 to 1191 bytes)        |
> >    		+--------------------------------+
> >
> >    Small syslog messages are transmitted using one UDP/IP
> datagram per
> >    message. However, syslog protocol [2] allows messages as large
as
> >
> >
> >
> > Okmianski               Expires November 5, 2004
>     [Page 4]
> > >
> > Internet-Draft            syslog udp transport
>     May 2004
> >
> >
> >    16777216 bytes, while UDP/IP datagram cannot exceed a
> total size of
> >    65526 bytes [3] and most existing protocols restrict the
> size of UDP
> >    data to much less. In order to support transmitting
> large messages
> >    over UDP/IP, this transport protocol supports
> fragmentation of large
> >    syslog messages into multiple UDP/IP datagrams for
> transmission and
> >    reassembley on the receiving end.
> >
> >    Each syslog UDP/IP datagram MUST contain one and only
> one complete
> >    syslog message or one fragment of a message.
> Transmitting multiple
> >    messages or multiple fragments of different messages in
> a single UDP
> >    datagram is not supported by this protocol.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Okmianski               Expires November 5, 2004
>     [Page 5]
> > >
> > Internet-Draft            syslog udp transport
>     May 2004
> >
> >
> > 3.  Message Format
> >
> >    The syslog transport message consist of a transport header and
a
> >    syslog message payload. The format of the transport header is
> >    different for fragmented and non-fragmented messages.  Basic
> >    transport header is used for non-fragmented messages and
extended
> >    transport header is used for fragmented messages.
> >
> >    An ASCII-based encoding was chosen for the syslog transport for
> >    consistency with the RFC-protocol [2].  Syslog transport
> datagrams
> >    without required UDP and IP headers have the following
> format in ABNF
> >    [7] notation:
> >
> >
> >        SyslogTransportMessage = ( BasicHeader / ExtendedHeader )
> >                                          SP Payload
> >
> >        BasicHeader     = Version SP "0"
> >        Version         = %d118 1*3DIGIT   ; "v1" in this version
> >
> >        ExtendedHeader  = Version SP "1" SP MessageId
> >                          SP TotalLength SP FragmentOffset
> >
> >        MessageId       = 1*8DIGIT        ; 0 to 16777215
> >        TotalLength     = 1*8DIGIT        ; 1 to 16777216
> >        FragmentOffset  = 1*8DIGIT        ; 0 to 16777215
> >        Payload         = 1*1191OCTET
> >
> >        OCTET           = %d00-255
> >        DIGIT           = %d48-57
> >        SP              = %d32
> >
> >
> > 3.1  Basic Header Format
> >
> >    When no fragmentation is used and the entire syslog message is
> >    transferred as a single UDP/IP datagram, a basic syslog
transport
> >    header MUST be used.  The version for this protocol is
> "1". It must
> >    be followed by one space and a "0" to indicate that this
> is a basic
> >    header.   Therefore, the only possible value for the
> basic header in
> >    this protocol is as follows:
> >
> >
> >       "v1 0 "
> >
> >    Example of a syslog message without the transport header
> (message is
> >    wrapped for display):
> >
> >
> >
> >
> > Okmianski               Expires November 5, 2004
>     [Page 6]
> > >
> > Internet-Draft            syslog udp transport
>     May 2004
> >
> >
> >       "v1 888 3 2003-10-11T22:14:15.003Z host.domain.com
> >       dns: configuration error"
> >
> >    Example of the same message with the transport header (message
is
> >    wrapped for display):
> >
> >
> >       "v1 0 v1 888 4 2003-10-11T22:14:15.003Z host.domain.com
> >       dns: configuration error"
> >
> >
> > 3.2  Extended Header Format
> >
> >    When syslog message is fragmented by the sender, multiple UDP
> >    datagrams must be used and each datagram MUST contain an
extended
> >    syslog transport header. The version for this protocol
> is "1". The
> >    version field MUST be followed by a single space and a "1" to
> >    indicate that this is an extended header.  Thus, an
> extended header
> >    MUST always begin with "v1 1 ", but MUST also have
> additional fields
> >    which aid in fragmentation.
> >
> >    The MessageId, TotalLength and FragmentOffset fields are
> used solely
> >    for fragmentation of long messages and reassembley.
> They SHOULD NOT
> >    be used for other purposes.
> >
> > 3.2.1  Message Identifier
> >
> >    The MessageId field (along with the source UDP port and the IP
> >    address) is used to identify the message such that fragments of
a
> >    single syslog message can be reassembled by the receiver into a
> >    complete message.  The MessageId field MUST be a numeric
> value in the
> >    range of 0 to 16777215.  Leading zeros MUST not be present in
the
> >    MessageId field.
> >
> >    Each syslog sender process MUST choose a random MessageId value
> >    within the supported range for its first message.
> Subsequent messages
> >    generated by the same process MUST each increment the
> MessageId by 1
> >    up to 16777215 and then continue at 0. Using random value for
the
> >    first MessageId helps reduce the possibility of
> potential errors in
> >    message reassembley. Refer to discussion about message
> reassembley
> >    (Section 5.2) for more details.
> >
> >    All datagrams which represent parts of a given fragmented
syslog
> >    message MUST have the same MessageId value.
> >
> > 3.2.2  Total Length
> >
> >    The TotalLength field MUST be a numeric value in the
> range of 1 to
> >
> >
> >
> > Okmianski               Expires November 5, 2004
>     [Page 7]
> > >
> > Internet-Draft            syslog udp transport
>     May 2004
> >
> >
> >    16777216. It MUST indicate the length of a complete
> syslog message
> >    before it was fragmented and before it was encapsulated with
> >    transport headers.  The same TotalLength field value
> MUST be present
> >    in all UDP datagrams which represent fragments of the same
syslog
> >    message. Leading zeros MUST not be present in the TotalLength
> > field.
> >
> >    Note that in IPv4 the "total length" field identifies
> the length of a
> >    single packet.  In this protocol, the TotalLength field
> is used to
> >    identify the total length of a complete syslog message, which
is
> >    transmitted using multiple fragments and multiple
> datagram packets.
> >    The fragment length is not specified in the transport
> header because
> >    it can be inferred from the size of the IP packet
> containing the UDP
> >    datagram.
> >
> > 3.2.3  Fragment Offset
> >
> >    The FragmentOffset field MUST be a numeric value in the
> range of 0 to
> >    16777215. It MUST indicate the byte offset of the
> fragment data in
> >    the complete syslog message. The offset index starts at 0 for
the
> >    first fragment. For example, if an 700 byte syslog message is
> >    fragmented into 480 and 220 byte parts, the FragmentOffset in
the
> >    first message will be 0 and in the second - 480. Note
> that fragments
> >    don't have to be the same size.  Leading zeros MUST not
> be present in
> >    the FragmentOffset field.
> >
> > 3.2.4  Extended Header Example
> >
> >    The following is an example of a syslog message without
> the transport
> >    header (message is wrapped for display):
> >
> >
> >       "v1 888 4 2003-10-11T22:14:15.003Z host.domain.com
> >       dns: configuration error"
> >
> >    Suppose this message had to be fragmented by transport
> layer into two
> >    parts at an arbitrary point.  This would result in two
> separate UDP
> >    datagrams being sent - one for each fragment. Below is
> the content of
> >    each of the syslog transport UDP messages with syslog transport
> >    headers but without UDP/IP headers:
> >
> >
> >       "v1 1 45612221 74 0 v1 888 4 2003-10-11T22:14:15.003Z
> host.dom"
> >
> >       "v1 1 45612221 74 42 ain.com dns: configuration error"
> >
> >    In the above example, the leading "v1" is the version of the
> >    transport protocol, "1" indicates that this is an extended
header
> >    (fragmentation in use), "45612221" is the MessageId, "74" is
the
> >
> >
> >
> > Okmianski               Expires November 5, 2004
>     [Page 8]
> > >
> > Internet-Draft            syslog udp transport
>     May 2004
> >
> >
> >    TotalLength of the message, while "0" and "42" are
FragmentOffset
> >    fields. Everything following the FragmentOffset and a
> space is a the
> >    Payload of each respective message.
> >
> > 3.3  Payload
> >
> >    The Payload field of the syslog UPD transport message is
> an entire
> >    syslog message or one fragment. The maximum Payload size
> depends on
> >    the IP protocol used and the type header that is used.
> >
> >       Maximum Payload size:
> >
> >       With IPv4 and basic header:    507 bytes
> >       With IPv4 and extended header: 480 bytes
> >
> >       With IPv6 and basic header:    1191 bytes
> >       With IPv6 and extended header: 1164 bytes
> >
> >    The Payload size restrictions above effectively mean
> that the largest
> >    syslog message that can be sent non-fragmented is 507 bytes for
> >    transport via IPv4 and 1191 bytes for transport via IPv6.
> >
> >    For a discussion of the relational behind the above size
> restrictions
> >    please refer to Appendix A.
> >
> > 3.4  Supported Message Length
> >
> >    The maximum syslog message length supported by this
> protocol is the
> >    maximum value of the TotalLength field, which is 16777216
bytes.
> >    However, not all deployment scenarios for syslog will be on
hosts
> >    with hardware capable of supporting the maximum length
> of messages
> >    supported by this protocol. Additionally, extremely
> large messages
> >    may not be needed in many environments. Therefore,
> implementations
> >    are NOT REQUIRED to support the maximum message length allowed
by
> >    this protocol.
> >
> >    All implementations MUST support sending and receiving syslog
> >    messages up to and including 65536 bytes in size (syslog
> transport
> >    and UDP/IP headers are extra). Support for larger messages is
> >    encouraged. Implementors SHOULD clearly state the
> maximum supported
> >    message size in documentation.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Okmianski               Expires November 5, 2004
>     [Page 9]
> > >
> > Internet-Draft            syslog udp transport
>     May 2004
> >
> >
> > 4.  UDP/IP Layer Considerations
> >
> > 4.1  Target Port
> >
> >    Syslog receivers MUST support accepting syslog message
> datagrams on a
> >    well-known UDP port 514.  Syslog senders MUST support
> sending syslog
> >    message datagrams to the UDP port 514.
> >
> > 4.2  Source Port
> >
> >    Syslog senders can use any source UDP port for
> transmitting messages.
> >    Senders MAY randomly select a source port, but MUST use
> the port in
> >    an exclusive fashion. No concurrent port reuse on the
> same host is
> >    allowed.
> >
> >    Each syslog sender process MUST attempt to use the same
> source port
> >    for the life of the the process.  If due to an error or other
> >    condition it becomes impossible for the process to
> continue to use
> >    the same port, it MAY start using a new source port, but it
MUST
> >    generate a new random MessageId for the first message
> after changing
> >    the port and then MUST continue incrementing the new
> MessageId value
> >    for subsequent messages.
> >
> >    Since source port is used to identify parts of a
> fragmented message,
> >    the sender MUST use the same port to send all fragments
> of a given
> >    message.  If due to an error or other condition, the
> sender is unable
> >    to do that, it MUST resend all message fragments using
> the new port
> >    and a new MessageId field value.
> >
> > 4.3  Source IP Address
> >
> >    The source IP address of the UDP datagrams is one of the data
> >    elements used to identify parts of a fragmented message.
>  Therefore,
> >    a syslog sender MUST attempt to use the same source IP address
to
> >    send all fragments of a given syslog message.  If due to
> an error,
> >    reconfiguration or other condition it is unable to do
> so, the sender
> >    MUST resend all fragments of the syslog message using
> the new source
> >    IP address and a new MessageId value.
> >
> > 4.4  UDP/IP Headers
> >
> >    Each UDP/IP datagram sent by the transport layer MUST
completely
> >    adhere to the structure specified in the UDP RFC 768 [3]
> and either
> >    IPv4 RFC 791 [4] or IPv6 RFC 2640 [5] depending on which
> protocol is
> >    used.
> >
> >    Use of UDP checksums was defined as optional in RFC 768
> [3]. IPv6 has
> >    subsequently made UDP checksums required [5].  However, syslog
> >
> >
> >
> > Okmianski               Expires November 5, 2004
>    [Page 10]
> > >
> > Internet-Draft            syslog udp transport
>     May 2004
> >
> >
> >    senders MUST utilize valid UDP checksums when sending
> messages over
> >    either IPv4 or IPv6. Syslog receivers MUST check for
> checksums and
> >    discard messages with incorrect checksums. Note that this is
> >    typically accomplished by the UDP layer implementation, and
some
> >    implementations allow for checksum checks to be enabled or
> > disabled.
> >
> >    Enabling use of checksums serves as an extra measure of
> corruption
> >    detection in addition to checksums performed by IP and Ethernet
> >    layers. None of the above checksums provide a complete
> guarantee of
> >    corruption detection. Utilizing checksums on multiple
> layers reduces
> >    the chance of corruption error not being detected.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Okmianski               Expires November 5, 2004
>    [Page 11]
> > >
> > Internet-Draft            syslog udp transport
>     May 2004
> >
> >
> > 5.  Fragmentation and Reassembley
> >
> > 5.1  Message Fragmentation
> >
> >    The syslog transport layer MUST perform fragmentation if syslog
> >    message size exceeds the maximum allowed Payload size.
> Fragmentation
> >    SHOULD NOT be used if message can fit into the maximum allowed
> >    Payload size.
> >
> >    Syslog messages SHOULD be fragmented such that all but
> last message
> >    utilize the Payload to its maximum capacity.  For
> example, when using
> >    IPv4, a 700 byte syslog message SHOULD be fragmented
> into 480 and 220
> >    byte parts because the maximum Payload size with IPv4
> and extended
> >    header is 480 bytes.
> >
> >    Each message fragment MUST be sent as a separate UDP/IP
> datagram with
> >    an extended syslog transport header.  The sender MUST
> use the same
> >    MessageId value, source port and source IP address for
> all fragments
> >    of a given message. These three field together uniquely
identify
> >    fragments belonging to a given message.
> >
> >    On a system with short-lived sender processes, it may be
possible
> >    that fragments with the same MessageId value, source
> port and source
> >    IP address will get generated in short time proximity.
> This can be
> >    possible because a new process may re-use the source
> port that was
> >    freed up by another process that just dies.  Such behavior
could
> >    confuse the receiver if the datagrams were received out
> of order or
> >    some datagrams got lost.
> >
> >    In order to reduce the risk of such mistaken identity
> errors, section
> >    3.2.1 specified that each process must start with a
> random value for
> >    MessageId field.  Given a relatively large range of
> MessageId values
> >    and the unlikely event of a coincidence of having the
> same MessageId
> >    value combined with re-used source port and UPD errors,
> the window
> >    for potential mistaken identity errors during message
> reassembley is
> >    very small and tolerable. The users take a greater risk
> by using this
> >    protocol due to general UDP reliability issues discussed later
in
> >    this specification.
> >
> > 5.2  Message Reassembley
> >
> >    The reassembley process uses the source IP address from the IP
> >    header, the source port from the UDP header and the
> MessageId field
> >    value to identify fragments of a given message. It then uses
data
> >    from TotalLength and FragmentOffset fields to
> re-assemble fragments
> >    into a complete message.
> >
> >    Typically, an implementation of fragmentation
> reassembley involves
> >
> >
> >
> > Okmianski               Expires November 5, 2004
>    [Page 12]
> > >
> > Internet-Draft            syslog udp transport
>     May 2004
> >
> >
> >    allocating a buffer for the message when any fragment with a
new
> >    combination of source IP address, source port and MessageId is
> >    received. A timer is used to expire the message
> reassembley and clean
> >    the buffer if all fragments are not received in certain
> time period.
> >    As each fragment is received, it is placed into the buffer at
the
> >    appropriate offset and a check is performed to determine if all
> >    fragments have been received using additional data structures.
> >
> >    The receiver SHOULD make the timeout interval used for message
> >    reassembley configurable for the administrator.  The
> receiver SHOULD
> >    also be able to limit the total amount of memory used for
buffers
> >    such that it does not run out of resources under a
> simple denial of
> >    service attack involving just one message fragment with a large
> >    TotalLength field value. Degrading the service under
> heavy load or
> >    attack is better than crashing and potentially making the
service
> >    completely unavailable.
> >
> > 5.3  Avoiding Fragmentation
> >
> >    Fragmentation and reassembley of messages incurs substantial
> >    processing overhead on both the sender and the receiver hosts.
It
> >    also increases the risk of lost messages due to lose of just
one
> >    fragment. It is RECOMMENDED that syslog senders which
anticipate
> >    sending messages over this transport protocol attempt to
> reduce the
> >    number of messages which require fragmentation by
> restricting them to
> >    the size which does not require fragmentation.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Okmianski               Expires November 5, 2004
>    [Page 13]
> > >
> > Internet-Draft            syslog udp transport
>     May 2004
> >
> >
> > 6.  Reliability Considerations
> >
> >    The UDP is an unreliable low-overhead protocol. This section
> >    discusses reliability issues inherent in the UDP that
> implementers
> >    and users must be aware of.
> >
> > 6.1  Lost Datagrams
> >
> >    Neither UDP nor syslog protocol provide any mechanism to
> detect and
> >    correct loss of datagrams.  Datagrams may be lost in
> transit due to
> >    congestion, corruption or any other intermittent network
problem.
> >    Syslog protocol and IP fragmentation exacerbates the
> problem because
> >    loss of a single fragment would result in entire message being
> >    discarded.
> >
> >    In some circumstances the sender may receive an ICMP
> error message or
> >    other indication of a transmission problem. If the
> sender receives a
> >    reasonable indication that some datagram may have been
> lost, it MAY
> >    retransmit previously sent messages.
> >
> > 6.2  Message Corruption and Checksums
> >
> >    The UDP/IP datagrams may get corrupted in transit due to
> software,
> >    hardware or network errors. This protocol specified use of UDP
> >    checksums to enable corruption detection in addition to
checksums
> >    utilized in IP and Ethernet layers. However, checksums do not
> >    guarantee corruption detection and this protocol does
> not provide for
> >    message retransmission when a corrupt message is detected.
> >
> > 6.3  Congestion Control
> >
> >    The UDP does not provide for congestion control. Some
> systems (hosts
> >    or routers) may generate ICMP source quench error, but
> they are not
> >    required to do so [8].  Any network host can discard UDP
> packets when
> >    it is overloaded. Due to lack of congestion control one
> or multiple
> >    syslog senders can maliciously or inadvertently overload
> the receiver
> >    or the network infrastructure and cause loss of syslog
messages.
> >
> > 6.4  Sequenced Delivery
> >
> >    The IP transport utilized by the UDP does not guarantee that
the
> >    sequence of datagram delivery will match the order in which the
> >    datagrams have been sent. The time stamp contained
> within each syslog
> >    message may serve as some guide in establishing sequence
> order, but
> >    it will not help in cases when multiple messages were generated
> >    during the same time slot or when messages originated
> from different
> >    hosts whose clocks are not synchronized. The order of
> syslog message
> >    arrival via the this syslog transport SHOULD NOT be used as an
> >
> >
> >
> > Okmianski               Expires November 5, 2004
>    [Page 14]
> > >
> > Internet-Draft            syslog udp transport
>     May 2004
> >
> >
> >    authoritative guide in establishing the sequence of events on
the
> >    syslog sender hosts.
> >
> > 6.5  Sender Authentication
> >
> >    The UDP syslog transport does not strongly associate the
> message with
> >    the message sender.  The receiver of the syslog message
> will not be
> >    able to ascertain that the message was indeed sent from
> the reported
> >    sender, or if the packet was sent from another device.
> >
> >    One possible consequence of this behavior is that a
misconfigured
> >    machine may send syslog messages to a receiver
> representing itself as
> >    another machine. The administrators may not be able to readily
> >    discern that there are two or more machines representing
> themselves
> >    as the same machine.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Okmianski               Expires November 5, 2004
>    [Page 15]
> > >
> > Internet-Draft            syslog udp transport
>     May 2004
> >
> >
> > 7.  Security Considerations
> >
> >    Several syslog security considerations have been discussed in
> >    RFC-protocol [2] and in the original RFC 3164 [1]. This section
> >    focuses on security considerations specific to the
> syslog transport
> >    over UDP.
> >
> > 7.1  Message Authenticity
> >
> >    This transport protocol does not strongly authenticate
> the identity
> >    of the message sender and does not provide any assurance that
the
> >    message was not modified in transit. The receiver of the syslog
> >    message will not be able to ascertain that the message was
indeed
> >    sent from the reported sender, or if the packet was sent
> from another
> >    device.
> >
> > 7.2  Message Forgery
> >
> >    Syslog messages can be easily forged. An attacker may
> transmit syslog
> >    messages (either from the machine from which the messages are
> >    purportedly sent or from any other machine) to a receiver.
> >
> >    In one case, an attacker may hide the true nature of an
> attack amidst
> >    many other messages.  As an example, an attacker may
> start generating
> >    forged messages indicating a problem on some machine.
> This may get
> >    the attention of the system administrators who will
> spend their time
> >    investigating the alleged problem.  During this time,
> the attacker
> >    may be able to compromise a different machine, or a
> different process
> >    on the same machine.
> >
> >    Additionally, an attacker may generate false syslog
> messages to give
> >    untrue indications of status or of events.  As an example, an
> >    attacker may stop a critical process on a machine, which
> may generate
> >    a notification of exit.  The attacker may subsequently generate
a
> >    forged notification that the process had been restarted.
>  The system
> >    administrators may accept that misinformation and not
> verify that the
> >    process had indeed been restarted.
> >
> > 7.3  Message Observation
> >
> >    The transport protocol does not provide confidentiality of the
> >    messages in transit. If syslog messages are in clear
> text, this is
> >    how they will be transferred.  In most cases passing clear-text
> >    human-readable messages is a benefit to the administrators.
> >    Unfortunately, an attacker may also be able to observe the
> >    human-readable contents of syslog messages.  The
> attacker may then
> >    use the knowledge gained from those messages to
> compromise a machine
> >    or do other damage. It is RECOMMENDED that no sensitive
> information
> >
> >
> >
> > Okmianski               Expires November 5, 2004
>    [Page 16]
> > >
> > Internet-Draft            syslog udp transport
>     May 2004
> >
> >
> >    is transmitted via this transport protocol or that
> transmission of
> >    such information is restricted to properly secured networks.
> >
> > 7.4  Replaying
> >
> >    Message forgery and observation can be combined into a
> replay attack.
> >    An attacker may record a set of messages that indicate normal
> >    activity of a machine.  At a later time, that attacker may
remove
> >    that machine from the network and replay the syslog
> messages to the
> >    collector with new time stamps. The administrators may
> find nothing
> >    unusual in the received messages and their receipt would
falsely
> >    indicate normal activity of the machine.
> >
> > 7.5  Unreliable Delivery
> >
> >    As was previously discussed in the Reliability Considerations
> >    section, the UDP transport is not reliable and packets
containing
> >    syslog message datagrams can be lost in transit without
> any notice.
> >    There can be security consequences to the loss of one or
> more syslog
> >    messages.  Administrators may not become aware of a
> developing and
> >    potentially serious problem. Messages may also be intercepted
and
> >    discarded by an attacker as a way to hide unauthorized
> activities.
> >
> > 7.6  Message Prioritization and Differentiation
> >
> >    The transport protocol described in this document does
> not require
> >    prioritization of syslog messages on the wire or when
> processed on
> >    the receiving host based on their severity.  The
> security implication
> >    of such behavior is that the syslog receiver or network
> devices may
> >    get overwhelmed with low severity messages and be forced
> to discard
> >    potentially high severity messages. High severity messages may
> >    contain indication about serious security problems, but
> they will not
> >    get a higher priority. It is difficult to make sure that high
> >    severities messages get higher end-to-end delivery priority,
> >    especially over an unreliable UDP transport.
> >
> >    On a case-by-case basis, device operators may find some way to
> >    associate the different severity levels with the quality
> of service
> >    identifiers.  As an example, the operators may elect to
> define some
> >    linkage between syslog messages that have a specific
> Priority value
> >    with a specific value to be used in the IPv4 Precedence
> field [4],
> >    the IPv6 Traffic Class octet [5], or the Differentiated
Services
> >    field [9].  However, even with this prioritization on
> the network,
> >    high load can lead to buffer starvation on the receiving host
and
> >    result in dropped messages.
> >
> >
> >
> >
> >
> >
> > Okmianski               Expires November 5, 2004
>    [Page 17]
> > >
> > Internet-Draft            syslog udp transport
>     May 2004
> >
> >
> > 7.7  Denial of Service
> >
> >    An attacker may overwhelm a receiver by sending more
> messages to it
> >    than can be handled by the infrastructure or the device itself.
> >    Implementers SHOULD attempt to provide features that
> minimize this
> >    threat such as only receiving syslog messages from known IP
> >    addresses.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Okmianski               Expires November 5, 2004
>    [Page 18]
> > >
> > Internet-Draft            syslog udp transport
>     May 2004
> >
> >
> > 8.  IANA Considerations
> >
> >    IANA must reserve UDP port 514 for this transport.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Okmianski               Expires November 5, 2004
>    [Page 19]
> > >
> > Internet-Draft            syslog udp transport
>     May 2004
> >
> >
> > 9.  Notice to RFC Editor
> >
> >    This is a notice to the RFC editor. This ID is submitted
> along with
> >    ID draft-ietf-syslog-protocol and they cross-reference
> each other.
> >    When RFC numbers are determined for each of these IDs,
> please replace
> >    all references to "RFC-protocol" with the RFC number of
> >    draft-ietf-syslog-protocol ID.  Please remove this section
after
> >    editing.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Okmianski               Expires November 5, 2004
>    [Page 20]
> > >
> > Internet-Draft            syslog udp transport
>     May 2004
> >
> >
> > 10.  Authors and Working Group Chair
> >
> >    The working group can be contacted via the mailing list:
> >
> >    [email-masked]
> >
> >    The current Chair of the Working Group may be contacted at:
> >
> >    Chris Lonvick
> >    Cisco Systems
> >    Email: [email-masked]
> >
> >    The author of this draft is:
> >
> >    Anton Okmianski
> >    Email: [email-masked]
> >
> >    Phone: (978) 936-1612
> >    Fax: (978) 936-2225
> >
> >    Cisco Systems, Inc
> >    1414 Massachusetts Ave.
> >    Boxborough, MA 01719-2205
> >    USA
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Okmianski               Expires November 5, 2004
>    [Page 21]
> > >
> > Internet-Draft            syslog udp transport
>     May 2004
> >
> >
> > 11.  Acknowledgements
> >
> >    The author wishes to thank Chris Lonvick, Rainer Gerhards,
David
> >    Harrington, Andrew Ross, Albert Mietus, Bernie Volz, and
> all others
> >    who have commented on the various versions of this proposal.
> >
> > 12  References
> >
> >    [1]   Lonvick, C., "The BSD Syslog Protocol", RFC 3164,
> August 2001.
> >
> >    [2]   Gerhards, R., "The syslog Protocol", RFC RFC-protocol.
> >
> >    [3]   Postel, J., "User Datagram Protocol", STD 6, RFC
> 768, August
> >          1980.
> >
> >    [4]   Postel, J., "Internet Protocol", STD 5, RFC 791,
September
> >          1981.
> >
> >    [5]   Deering, S. and R. Hinden, "Internet Protocol,
> Version 6 (IPv6)
> >          Specification", RFC 2460, December 1998.
> >
> >    [6]   Bradner, S., "Key words for use in RFCs to
> Indicate Requirement
> >          Levels", BCP 14, RFC 2119, March 1997.
> >
> >    [7]   Crocker, D. and P. Overell, "Augmented BNF for Syntax
> >          Specifications: ABNF", RFC 2234, November 1997.
> >
> >    [8]   Stevens, W., "TCP/IP Illustrated Volume 1. The
Protocols.",
> >          January 1994.
> >
> >    [9]   Nichols, K., Blake, S., Baker, F. and D. Black,
> "Definition of
> >          the Differentiated Services Field (DS Field) in
> the IPv4 and
> >          IPv6 Headers", RFC 2474, December 1998.
> >
> >    [10]  Mockapetris, P., "Domain names - implementation and
> >          specification", STD 13, RFC 1035, November 1987.
> >
> >    [11]  Hedrick, C., "Routing Information Protocol", RFC 1058,
June
> >          1988.
> >
> >    [12]  Droms, R., "Dynamic Host Configuration Protocol", RFC
2131,
> >          March 1997.
> >
> >    [13]  Sollins, K., "The TFTP Protocol (Revision 2)", STD 33,
RFC
> >          1350, July 1992.
> >
> >    [14]  Braden, R., "Requirements for Internet Hosts -
> Communication
> >          Layers", STD 3, RFC 1122, October 1989.
> >
> >
> >
> > Okmianski               Expires November 5, 2004
>    [Page 22]
> > >
> > Internet-Draft            syslog udp transport
>     May 2004
> >
> >
> >    [15]  Kent, C. and J. Mogul, ""Fragmentation Considered
Harmful,"
> >          Computer Communications Review, vol.17, no.5,
pp.390-401",
> >          August 1987.
> >
> >
> > Author's Address
> >
> >    Anton Okmianski
> >    Cisco Systems, Inc.
> >    1414 Massachusetts Ave
> >    Boxborough, MA  01719-2205
> >    USA
> >
> >    EMail: [email-masked]
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Okmianski               Expires November 5, 2004
>    [Page 23]
> > >
> > Internet-Draft            syslog udp transport
>     May 2004
> >
> >
> > Appendix A.  Rational For Transport Message Size Restrictions
> >
> >    This appendix provides the rational behind the Payload size
> >    restrictions for this protocol.  The Payload
> restrictions outlined in
> >    the specification, essentially ensure that the transport
> message size
> >    does not exceed 512 bytes (without UDP/IP headers) for
> transport via
> >    IPv4 and does not exceed 1196 bytes for transport via IPv6.
These
> >    restrictions put an upper boundary on the UDP/IP
> datagram size for
> >    this protocol, which accomplishes two goals.
> >
> >    First, they insure interoperability between various UDP/IP
> >    implementations.  Even though the maximum IP datagram size is
> >    specified as 65536 bytes, many UDP/IP implementations
> have been shown
> >    not to work with large datagram sizes [8].  Many established
> >    UDP-based protocols restrict UDP datagram data size to
> 512 bytes. For
> >    example, DNS [10] and RIP [11] do that. The DHCPv4 [12]
> restricts the
> >    size to 512 bytes, but allows sides to agree on a larger value
> >    through the protocol. The TFTP [13] restricts the UDP
> data size to
> >    518 bytes, which is slightly larger.
> >
> >    The second reason for datagram size restrictions is that it
helps
> >    reduce the likelihood of the  IP-layer datagram
> fragmentation.  This
> >    could have potentially resulted in fragmentation on two levels:
> >    syslog transport protocol and IP layer. Since fragmentation has
> >    significant overhead for message reassembley, it is best to
avoid
> >    double fragmentation. The likelihood of IP fragmentation can be
> >    significantly reduced by sending IP datagrams in sizes which
all
> >    hosts must be able to process.
> >
> >    The minimum MTU of a transport protocol determines the
> minimum size
> >    of packets that hosts must be able to accept.  For IPv4,
> the minimum
> >    MTU is 576 bytes [4] and for IPv6 - 1280 bytes [5].  In
> both cases,
> >    the maximum message size we chose fits within the MTU of the
> >    transport in all cases except for when extremely large
> IP headers are
> >    used.  IPv4 header can range from 20 to 60 bytes in
> length and UDP
> >    header is fixed at 8 bytes. Thus, our message size restrictions
> >    ensure that in all cases except for when the IP header
> is 56 bytes or
> >    greater, the size of the packet will within the size of
> the transport
> >    MTU.
> >
> >    For IPv6, we have left the same amount of padding for
> UDP/IP headers
> >    as was conventionally done for IPv4 in DNS, RIP and
> DHCPv4 with an
> >    additional padding of extra 20 bytes to accommodate a larger
IPv6
> >    header. This follows the methodology suggested in the IPv6
> >    specification for calculating upper-layer payload limits [5].
> >
> >    Path MTU discovery can generally be used to discover the
> MTU of the
> >    link.  Unfortunately, using path MTU discovery with UDP is not
a
> >
> >
> >
> > Okmianski               Expires November 5, 2004
>    [Page 24]
> > >
> > Internet-Draft            syslog udp transport
>     May 2004
> >
> >
> >    reliable option because it depends on routers providing
> ICMP errors
> >    and hosts doing retransmission, which are not done
consistently.
> >    Implementors MUST follow the size restrictions outlined
> above and not
> >    rely on path MTU discovery.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Okmianski               Expires November 5, 2004
>    [Page 25]
> > >
> > Internet-Draft            syslog udp transport
>     May 2004
> >
> >
> > Intellectual Property Statement
> >
> >    The IETF takes no position regarding the validity or scope of
any
> >    intellectual property or other rights that might be claimed to
> >    pertain to the implementation or use of the technology
> described in
> >    this document or the extent to which any license under
> such rights
> >    might or might not be available; neither does it
> represent that it
> >    has made any effort to identify any such rights.
> Information on the
> >    IETF's procedures with respect to rights in standards-track and
> >    standards-related documentation can be found in BCP-11. Copies
of
> >    claims of rights made available for publication and any
> assurances of
> >    licenses to be made available, or the result of an
> attempt made to
> >    obtain a general license or permission for the use of such
> >    proprietary rights by implementors or users of this
> specification can
> >    be obtained from the IETF Secretariat.
> >
> >    The IETF invites any interested party to bring to its
> attention any
> >    copyrights, patents or patent applications, or other
proprietary
> >    rights which may cover technology that may be required
> to practice
> >    this standard. Please address the information to the
> IETF Executive
> >    Director.
> >
> >
> > Full Copyright Statement
> >
> >    Copyright (C) The Internet Society (2004). All Rights Reserved.
> >
> >    This document and translations of it may be copied and
> furnished to
> >    others, and derivative works that comment on or
> otherwise explain it
> >    or assist in its implementation may be prepared, copied,
> published
> >    and distributed, in whole or in part, without restriction of
any
> >    kind, provided that the above copyright notice and this
> paragraph are
> >    included on all such copies and derivative works. However, this
> >    document itself may not be modified in any way, such as
> by removing
> >    the copyright notice or references to the Internet
> Society or other
> >    Internet organizations, except as needed for the purpose of
> >    developing Internet standards in which case the procedures for
> >    copyrights defined in the Internet Standards process must be
> >    followed, or as required to translate it into languages
> other than
> >    English.
> >
> >    The limited permissions granted above are perpetual and
> will not be
> >    revoked by the Internet Society or its successors or assignees.
> >
> >    This document and the information contained herein is
> provided on an
> >    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
> ENGINEERING
> >    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
> INCLUDING
> >    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
> >
> >
> >
> > Okmianski               Expires November 5, 2004
>    [Page 26]
> > >
> > Internet-Draft            syslog udp transport
>     May 2004
> >
> >
> >    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
OF
> >    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
> >
> >
> > Acknowledgment
> >
> >    Funding for the RFC Editor function is currently provided by
the
> >    Internet Society.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Okmianski               Expires November 5, 2004
>    [Page 27]
> > >
> >
>
> >
> >
>      [1]
> > TOC
> >
> >    syslog Working Group      A. Okmianski
> >    Internet-Draft            Cisco Systems, Inc.
> >    Expires: November 5, 2004 May 7, 2004
> >
> >                                  Transmission of syslog
> messages over
> > UDP
> >
> >
> > draft-ietf-syslog-transport-udp-01
> >
> >   Status of this Memo
> >
> >    This document is an Internet-Draft and is in full
> conformance with all
> >    provisions of Section 10 of RFC2026.
> >
> >    Internet-Drafts are working documents of the Internet
> Engineering Task
> >    Force  (IETF),  its  areas,  and  its  working groups.
> Note that other
> >    groups may also distribute working documents as
Internet-Drafts.
> >
> >    Internet-Drafts  are draft documents valid for a maximum
> of six months
> >    and  may  be updated, replaced, or obsoleted by other
> documents at any
> >    time. It is inappropriate to use Internet-Drafts as
> reference material
> >    or to cite them other than as "work in progress."
> >
> >    The   list   of   current   Internet-Drafts   can   be
> accessed   at
> >    [2]http://www.ietf.org/ietf/1id-abstracts.txt.
> >
> >    The  list  of  Internet-Draft  Shadow  Directories  can
> be accessed at
> >    [3]http://www.ietf.org/shadow.html.
> >
> >    This Internet-Draft will expire on November 5, 2004.
> >
> >   Copyright Notice
> >
> >    Copyright (C) The Internet Society (2004). All Rights Reserved.
> >
> >   Abstract
> >
> >    This  document  describes  the  transport  for the
> syslog message 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 using
> >    multiple datagrams.
> >
> _________________________________________________________________
> >
> >   Table of Contents
> >
> >    [4]1.  Introduction
> >    [5]2.  Transport Protocol Overview
> >        [6]2.1  Definitions and Architecture
> >        [7]2.2  Required Transport Protocol
> >        [8]2.3  Encapsulation Layers
> >    [9]3.  Message Format
> >        [10]3.1  Basic Header Format
> >        [11]3.2  Extended Header Format
> >            [12]3.2.1  Message Identifier
> >            [13]3.2.2  Total Length
> >            [14]3.2.3  Fragment Offset
> >            [15]3.2.4  Extended Header Example
> >        [16]3.3  Payload
> >        [17]3.4  Supported Message Length
> >    [18]4.  UDP/IP Layer Considerations
> >        [19]4.1  Target Port
> >        [20]4.2  Source Port
> >        [21]4.3  Source IP Address
> >        [22]4.4  UDP/IP Headers
> >    [23]5.  Fragmentation and Reassembley
> >        [24]5.1  Message Fragmentation
> >        [25]5.2  Message Reassembley
> >        [26]5.3  Avoiding Fragmentation
> >    [27]6.  Reliability Considerations
> >        [28]6.1  Lost Datagrams
> >        [29]6.2  Message Corruption and Checksums
> >        [30]6.3  Congestion Control
> >        [31]6.4  Sequenced Delivery
> >        [32]6.5  Sender Authentication
> >    [33]7.  Security Considerations
> >        [34]7.1  Message Authenticity
> >        [35]7.2  Message Forgery
> >        [36]7.3  Message Observation
> >        [37]7.4  Replaying
> >        [38]7.5  Unreliable Delivery
> >        [39]7.6  Message Prioritization and Differentiation
> >        [40]7.7  Denial of Service
> >    [41]8.  IANA Considerations
> >    [42]9.  Notice to RFC Editor
> >    [43]10.  Authors and Working Group Chair
> >    [44]11.  Acknowledgements
> >    [45]§.  References
> >    [46]§  Author's Address
> >    [47]A.  Rational For Transport Message Size Restrictions
> >    [48]§  Intellectual Property and Copyright Statements
> >
> _________________________________________________________________
> >
> >
>     [49]
> > TOC
> >
> >   1. Introduction
> >
> >    The  original  syslog  protocol has been described in an
> informational
> >    [50]RFC  3164Lonvick,  C., The BSD Syslog Protocol,
> August 2001.[1] as
> >    it  has  been  observed in existing implementations. It
> describes both
> >    the  semantics  of  syslog  message format as well as a
> UDP transport.
> >    Subsequently,  the  syslog  protocol  has  been
> formally defined in a
> >    standards  track  [51]RFC-protocolGerhards,  R.,  The
> syslog Protocol,
> >    .[2].
> >
> >    The  [52]RFC-protocolGerhards,  R.,  The  syslog
> Protocol,  .[2]  has
> >    provided  for  support  of any number of transport layer
> protocols for
> >    transmitting syslog messages and left it to subsequent
> RFCs to specify
> >    transport  protocols.  This  standards  track  RFC
> describes  the UDP
> >    transport for the syslog protocol. This transport
> protocol is REQUIRED
> >    for all syslog protocol implementations.
> >
> >    This   transport   protocol  was  designed  to  work  on
>  top  of  UDP
> >    [53][3]Postel, J., User Datagram Protocol, August 1980.
> over both IPv4
> >    [54][4]Postel,   J.,  Internet  Protocol,  September
> 1981.  and  IPv6
> >    [55][5]Deering,  S. and R. Hinden, Internet Protocol,
> Version 6 (IPv6)
> >    Specification,  December  1998.. This protocol overcomes
> the data size
> >    restrictions  of the UDP protocol by introducing message
> fragmentation
> >    feature.
> >
> >    As  we  will show in this specification, this protocol
> has significant
> >    reliability and security issues stemming from the use of
> UDP. However,
> >    this  protocol  is lightweight and extends on the
> existing popular use
> >    of  UDP  for  syslog.  Network administrators and
> architects should be
> >    aware of the shortcomings of this protocol and plan
accordingly.
> >
> >    The  key  words  "MUST", "MUST NOT", "REQUIRED",
> "SHALL", "SHALL NOT",
> >    "SHOULD",  "SHOULD  NOT", "RECOMMENDED", "MAY", and
> "OPTIONAL" in this
> >    document  are  to  be interpreted as described in
> [56]RFC 2119Bradner,
> >    S.,  Key  words  for use in RFCs to Indicate Requirement
> Levels, March
> >    1997.[6].  The  words  'byte'  and 'octet' are used
> interchangeably in
> >    this specification.
> >
> _________________________________________________________________
> >
> >
>     [57]
> > TOC
> >
> >   2. Transport Protocol Overview
> >
> >     2.1 Definitions and Architecture
> >
> >    The following definitions will be used in this document:
> >      * An  application that can generate syslog messages
> will be referred
> >        to as a "sender";
> >      * An  application  that can receive syslog messages
> will be referred
> >        to as a "receiver".
> >
> >    An  application  can  function in dual capacity. For
> example, a syslog
> >    relay  may  receive and forward messages. A single
> system can host any
> >    number  of syslog senders. Only one syslog receiver can
> be hosted on a
> >    single system using the standard listening port.
> >
> >     2.2 Required Transport Protocol
> >
> >    This  document  describes  the  UDP  transport  layer
> protocol for the
> >    syslog  protocol  [58]RFC-protocolGerhards,  R.,  The
> syslog Protocol,
> >    .[2]. Every syslog sender and receiver implementation
> which adheres to
> >    the [59]RFC-protocolGerhards, R., The syslog Protocol,
> .[2] MUST fully
> >    implement   the   transport   protocol  specified  in
> this  document.
> >    Implementations  does  not have to support both IPv4 and
> IPv6 if it is
> >    designed to be used over only one of these protocols.
> >
> >     2.3 Encapsulation Layers
> >
> >    Syslog  UDP  transport  carries  syslog  messages  as
> generic payload
> >    encapsulated  with  a  syslog  transport  header, UDP
> header and an IP
> >    header.  Below  is a summary of syslog UDP/IP packet
> structure as used
> >    this transport protocol:
> >
> >                 +--------------------------------+
> >                 |       IPv4 or IPv6 Header      |
> >                 |        (20 or more bytes)      |
> >                 +--------------------------------+
> >                 |           UDP Header           |
> >                 |           (8 bytes)            |
> >                 +--------------------------------+
> >                 |    Syslog Transport Header     |
> >                 |        (5 or 32 bytes)         |
> >                 +--------------------------------+
> >                 |     Syslog Message Payload     |
> >                 |       (1 to 1191 bytes)        |
> >                 +--------------------------------+
> >
> >    Small  syslog  messages  are transmitted using one
> UDP/IP datagram per
> >    message.  However,  syslog  protocol  [60][2]Gerhards,
> R., The syslog
> >    Protocol,  .  allows messages as large as 16777216
> bytes, while UDP/IP
> >    datagram  cannot exceed a total size of 65526 bytes
> [61][3]Postel, J.,
> >    User  Datagram  Protocol,  August  1980.  and  most
> existing protocols
> >    restrict  the  size  of  UDP  data  to  much less. In
> order to support
> >    transmitting  large  messages  over  UDP/IP,  this
> transport protocol
> >    supports  fragmentation  of large syslog messages into
> multiple UDP/IP
> >    datagrams for transmission and reassembley on the receiving
end.
> >
> >    Each  syslog  UDP/IP  datagram  MUST contain one and
> only one complete
> >    syslog  message  or  one  fragment of a message.
> Transmitting multiple
> >    messages  or  multiple fragments of different messages
> in a single UDP
> >    datagram is not supported by this protocol.
> >
> _________________________________________________________________
> >
> >
>     [62]
> > TOC
> >
> >   3. Message Format
> >
> >    The  syslog  transport  message  consist  of  a
> transport header and a
> >    syslog  message  payload.  The  format  of  the
> transport  header  is
> >    different  for fragmented and non-fragmented messages.
> Basic transport
> >    header  is  used  for  non-fragmented  messages and
> extended transport
> >    header is used for fragmented messages.
> >
> >    An  ASCII-based  encoding  was  chosen  for  the  syslog
> transport for
> >    consistency   with   the   [63]RFC-protocolGerhards,
> R.,  The  syslog
> >    Protocol, .[2]. Syslog transport datagrams without
> required UDP and IP
> >    headers  have  the  following  format  in
> [64]ABNFCrocker,  D. and P.
> >    Overell,  Augmented  BNF  for  Syntax  Specifications:
> ABNF, November
> >    1997.[7] notation:
> >
> >     SyslogTransportMessage = ( BasicHeader / ExtendedHeader )
> >                                       SP Payload
> >
> >     BasicHeader     = Version SP "0"
> >     Version         = %d118 1*3DIGIT   ; "v1" in this version
> >
> >     ExtendedHeader  = Version SP "1" SP MessageId
> >                       SP TotalLength SP FragmentOffset
> >
> >     MessageId       = 1*8DIGIT        ; 0 to 16777215
> >     TotalLength     = 1*8DIGIT        ; 1 to 16777216
> >     FragmentOffset  = 1*8DIGIT        ; 0 to 16777215
> >     Payload         = 1*1191OCTET
> >
> >     OCTET           = %d00-255
> >     DIGIT           = %d48-57
> >     SP              = %d32
> >
> >
> >     3.1 Basic Header Format
> >
> >    When  no  fragmentation  is  used  and  the  entire
> syslog message is
> >    transferred  as  a  single  UDP/IP  datagram, a basic
> syslog transport
> >    header  MUST be used. The version for this protocol is
> "1". It must be
> >    followed  by  one  space  and  a  "0" to indicate that
> this is a basic
> >    header.  Therefore,  the  only  possible value for the
> basic header in
> >    this protocol is as follows:
> >
> >    "v1 0 "
> >
> >    Example  of  a syslog message without the transport
> header (message is
> >    wrapped for display):
> >
> >    "v1 888 3 2003-10-11T22:14:15.003Z host.domain.com
> >    dns: configuration error"
> >
> >    Example  of  the  same  message  with the transport
> header (message is
> >    wrapped for display):
> >
> >    "v1 0 v1 888 4 2003-10-11T22:14:15.003Z host.domain.com
> >    dns: configuration error"
> >
> >     3.2 Extended Header Format
> >
> >    When  syslog  message  is  fragmented  by  the  sender,
> multiple  UDP
> >    datagrams  must  be  used  and  each datagram MUST
> contain an extended
> >    syslog  transport  header.  The  version for this
> protocol is "1". The
> >    version field MUST be followed by a single space and a
> "1" to indicate
> >    that  this is an extended header. Thus, an extended
> header MUST always
> >    begin  with "v1 1 ", but MUST also have additional
> fields which aid in
> >    fragmentation.
> >
> >    The  MessageId,  TotalLength and FragmentOffset fields
> are used solely
> >    for fragmentation of long messages and reassembley. They
> SHOULD NOT be
> >    used for other purposes.
> >
> >     3.2.1 Message Identifier
> >
> >    The  MessageId  field  (along  with  the  source  UDP
> port and the IP
> >    address)  is  used  to  identify  the message such that
> fragments of a
> >    single  syslog  message  can  be  reassembled  by  the
> receiver into a
> >    complete  message.  The MessageId field MUST be a
> numeric value in the
> >    range  of  0  to  16777215.  Leading  zeros MUST not be
> present in the
> >    MessageId field.
> >
> >    Each syslog sender process MUST choose a random
> MessageId value within
> >    the  supported  range  for  its  first  message.
> Subsequent  messages
> >    generated  by  the same process MUST each increment the
> MessageId by 1
> >    up  to  16777215  and  then  continue at 0. Using random
> value for the
> >    first  MessageId  helps  reduce the possibility of
> potential errors in
> >    message   reassembley.   Refer   to   discussion   about
>   [65]message
> >    reassembleyMessage Reassembley for more details.
> >
> >    All  datagrams  which  represent  parts  of  a given
> fragmented syslog
> >    message MUST have the same MessageId value.
> >
> >     3.2.2 Total Length
> >
> >    The  TotalLength  field  MUST  be a numeric value in the
> range of 1 to
> >    16777216.  It  MUST  indicate  the length of a complete
> syslog message
> >    before it was fragmented and before it was encapsulated
> with transport
> >    headers.  The  same TotalLength field value MUST be
> present in all UDP
> >    datagrams  which  represent  fragments  of  the  same
> syslog message.
> >    Leading zeros MUST not be present in the TotalLength field.
> >
> >    Note  that in IPv4 the "total length" field identifies
> the length of a
> >    single  packet.  In  this  protocol,  the TotalLength
> field is used to
> >    identify  the  total  length  of  a  complete syslog
> message, which is
> >    transmitted  using  multiple  fragments and multiple
> datagram packets.
> >    The  fragment  length is not specified in the transport
> header because
> >    it  can  be inferred from the size of the IP packet
> containing the UDP
> >    datagram.
> >
> >     3.2.3 Fragment Offset
> >
> >    The  FragmentOffset field MUST be a numeric value in the
> range of 0 to
> >    16777215. It MUST indicate the byte offset of the
> fragment data in the
> >    complete  syslog  message.  The offset index starts at 0
> for the first
> >    fragment.  For  example,  if  an 700 byte syslog message
> is fragmented
> >    into  480  and 220 byte parts, the FragmentOffset in the
> first message
> >    will  be  0 and in the second - 480. Note that fragments
> don't have to
> >    be   the  same  size.  Leading  zeros  MUST  not  be
> present  in  the
> >    FragmentOffset field.
> >
> >     3.2.4 Extended Header Example
> >
> >    The  following is an example of a syslog message without
> the transport
> >    header (message is wrapped for display):
> >
> >    "v1 888 4 2003-10-11T22:14:15.003Z host.domain.com
> >    dns: configuration error"
> >
> >    Suppose  this message had to be fragmented by transport
> layer into two
> >    parts  at  an  arbitrary  point. This would result in
> two separate UDP
> >    datagrams  being sent - one for each fragment. Below is
> the content of
> >    each  of  the  syslog  transport  UDP  messages  with
> syslog transport
> >    headers but without UDP/IP headers:
> >
> >    "v1 1 45612221 74 0 v1 888 4 2003-10-11T22:14:15.003Z host.dom"
> >
> >    "v1 1 45612221 74 42 ain.com dns: configuration error"
> >
> >    In the above example, the leading "v1" is the version of
> the transport
> >    protocol, "1" indicates that this is an extended header
> (fragmentation
> >    in  use),  "45612221" is the MessageId, "74" is the
> TotalLength of the
> >    message,  while  "0"  and  "42"  are FragmentOffset
> fields. Everything
> >    following  the  FragmentOffset  and  a  space is a the
> Payload of each
> >    respective message.
> >
> >     3.3 Payload
> >
> >    The  Payload  field  of  the syslog UPD transport
> message is an entire
> >    syslog  message  or  one fragment. The maximum Payload
> size depends on
> >    the IP protocol used and the type header that is used.
> >    Maximum Payload size:
> >
> >    With IPv4 and basic header:    507 bytes
> >    With IPv4 and extended header: 480 bytes
> >
> >    With IPv6 and basic header:    1191 bytes
> >    With IPv6 and extended header: 1164 bytes
> >
> >    The  Payload size restrictions above effectively mean
> that the largest
> >    syslog  message  that  can  be  sent  non-fragmented  is
> 507 bytes for
> >    transport via IPv4 and 1191 bytes for transport via IPv6.
> >
> >    For  a discussion of the relational behind the above
> size restrictions
> >    please refer to Appendix A.
> >
> >     3.4 Supported Message Length
> >
> >    The  maximum  syslog  message length supported by this
> protocol is the
> >    maximum  value  of  the  TotalLength  field,  which is
> 16777216 bytes.
> >    However, not all deployment scenarios for syslog will be
> on hosts with
> >    hardware   capable  of  supporting  the  maximum  length
>  of  messages
> >    supported by this protocol. Additionally, extremely
> large messages may
> >    not be needed in many environments. Therefore,
> implementations are NOT
> >    REQUIRED  to  support  the  maximum  message  length
> allowed  by this
> >    protocol.
> >
> >    All implementations MUST support sending and receiving
> syslog messages
> >    up  to  and including 65536 bytes in size (syslog
> transport and UDP/IP
> >    headers  are  extra).  Support  for  larger  messages
> is  encouraged.
> >    Implementors  SHOULD  clearly state the maximum
> supported message size
> >    in documentation.
> >
> _________________________________________________________________
> >
> >
>     [66]
> > TOC
> >
> >   4. UDP/IP Layer Considerations
> >
> >     4.1 Target Port
> >
> >    Syslog  receivers MUST support accepting syslog message
> datagrams on a
> >    well-known  UDP  port  514. Syslog senders MUST support
> sending syslog
> >    message datagrams to the UDP port 514.
> >
> >     4.2 Source Port
> >
> >    Syslog  senders can use any source UDP port for
> transmitting messages.
> >    Senders MAY randomly select a source port, but MUST use
> the port in an
> >    exclusive  fashion.  No  concurrent  port  reuse  on
> the same host is
> >    allowed.
> >
> >    Each  syslog  sender  process MUST attempt to use the
> same source port
> >    for the life of the the process. If due to an error or
> other condition
> >    it  becomes  impossible  for  the  process to continue
> to use the same
> >    port, it MAY start using a new source port, but it MUST
> generate a new
> >    random  MessageId  for  the  first message after
> changing the port and
> >    then MUST continue incrementing the new MessageId value
> for subsequent
> >    messages.
> >
> >    Since  source  port is used to identify parts of a
> fragmented message,
> >    the  sender  MUST  use  the same port to send all
> fragments of a given
> >    message.  If  due to an error or other condition, the
> sender is unable
> >    to  do  that,  it MUST resend all message fragments
> using the new port
> >    and a new MessageId field value.
> >
> >     4.3 Source IP Address
> >
> >    The source IP address of the UDP datagrams is one of the
> data elements
> >    used  to  identify  parts of a fragmented message.
> Therefore, a syslog
> >    sender  MUST  attempt  to  use  the same source IP
> address to send all
> >    fragments   of   a   given   syslog  message.  If  due
> to  an  error,
> >    reconfiguration  or  other condition it is unable to do
> so, the sender
> >    MUST  resend  all fragments of the syslog message using
> the new source
> >    IP address and a new MessageId value.
> >
> >     4.4 UDP/IP Headers
> >
> >    Each  UDP/IP  datagram  sent  by  the  transport layer
> MUST completely
> >    adhere  to  the  structure specified in the UDP [67]RFC
> 768Postel, J.,
> >    User  Datagram  Protocol,  August  1980.[3]  and  either
>  IPv4 [68]RFC
> >    791Postel,  J.,  Internet Protocol, September 1981.[4]
> or IPv6 [69]RFC
> >    2640Deering,  S.  and  R.  Hinden, Internet Protocol,
> Version 6 (IPv6)
> >    Specification, December 1998.[5] depending on which protocol is

> > used.
> >
> >    Use of UDP checksums was defined as optional in [70]RFC
> 768Postel, J.,
> >    User  Datagram  Protocol,  August 1980.[3]. IPv6 has
> subsequently made
> >    UDP  checksums  required  [71][5]Deering,  S.  and R.
> Hinden, Internet
> >    Protocol,  Version  6  (IPv6)  Specification, December
> 1998.. However,
> >    syslog  senders MUST utilize valid UDP checksums when
> sending messages
> >    over  either  IPv4  or IPv6. Syslog receivers MUST check
> for checksums
> >    and  discard  messages  with  incorrect  checksums.
> Note that this is
> >    typically  accomplished  by  the  UDP  layer
> implementation, and some
> >    implementations allow for checksum checks to be enabled or
> > disabled.
> >
> >    Enabling  use  of  checksums  serves as an extra measure
> of corruption
> >    detection  in  addition  to  checksums  performed  by
> IP and Ethernet
> >    layers.  None  of  the above checksums provide a
> complete guarantee of
> >    corruption  detection.  Utilizing checksums on multiple
> layers reduces
> >    the chance of corruption error not being detected.
> >
> _________________________________________________________________
> >
> >
>     [72]
> > TOC
> >
> >   5. Fragmentation and Reassembley
> >
> >     5.1 Message Fragmentation
> >
> >    The  syslog  transport  layer  MUST  perform
> fragmentation  if syslog
> >    message  size  exceeds the maximum allowed Payload size.
> Fragmentation
> >    SHOULD NOT be used if message can fit into the maximum
> allowed Payload
> >    size.
> >
> >    Syslog  messages  SHOULD  be fragmented such that all
> but last message
> >    utilize  the  Payload to its maximum capacity. For
> example, when using
> >    IPv4,  a 700 byte syslog message SHOULD be fragmented
> into 480 and 220
> >    byte  parts  because  the  maximum Payload size with
> IPv4 and extended
> >    header is 480 bytes.
> >
> >    Each  message fragment MUST be sent as a separate UDP/IP
> datagram with
> >    an  extended  syslog  transport  header.  The sender
> MUST use the same
> >    MessageId  value,  source port and source IP address for
> all fragments
> >    of  a  given  message.  These  three  field together
> uniquely identify
> >    fragments belonging to a given message.
> >
> >    On a system with short-lived sender processes, it may be
> possible that
> >    fragments  with  the  same  MessageId value, source port
> and source IP
> >    address  will  get  generated  in  short  time
> proximity. This can be
> >    possible  because  a  new  process may re-use the source
> port that was
> >    freed  up  by  another  process  that  just  dies. Such
> behavior could
> >    confuse  the  receiver  if the datagrams were received
> out of order or
> >    some datagrams got lost.
> >
> >    In  order to reduce the risk of such mistaken identity
> errors, section
> >    3.2.1  specified  that each process must start with a
> random value for
> >    MessageId  field.  Given  a relatively large range of
> MessageId values
> >    and  the  unlikely event of a coincidence of having the
> same MessageId
> >    value combined with re-used source port and UPD errors,
> the window for
> >    potential  mistaken identity errors during message
> reassembley is very
> >    small  and  tolerable.  The  users  take  a greater risk
> by using this
> >    protocol due to general UDP reliability issues discussed
> later in this
> >    specification.
> >
> >     5.2 Message Reassembley
> >
> >    The reassembley process uses the source IP address from
> the IP header,
> >    the  source  port from the UDP header and the MessageId
> field value to
> >    identify  fragments  of  a  given  message.  It  then
> uses  data from
> >    TotalLength  and FragmentOffset fields to re-assemble
> fragments into a
> >    complete message.
> >
> >    Typically,  an  implementation  of  fragmentation
> reassembley involves
> >    allocating  a  buffer  for  the  message  when any
> fragment with a new
> >    combination  of  source  IP  address,  source  port  and
>  MessageId is
> >    received.  A timer is used to expire the message
> reassembley and clean
> >    the  buffer  if all fragments are not received in
> certain time period.
> >    As  each  fragment  is  received,  it is placed into the
> buffer at the
> >    appropriate  offset  and  a  check  is  performed  to
> determine if all
> >    fragments have been received using additional data structures.
> >
> >    The  receiver  SHOULD  make  the  timeout  interval
> used  for message
> >    reassembley  configurable  for  the administrator. The
> receiver SHOULD
> >    also be able to limit the total amount of memory used
> for buffers such
> >    that it does not run out of resources under a simple
> denial of service
> >    attack  involving  just  one message fragment with a
> large TotalLength
> >    field  value.  Degrading  the  service  under  heavy
> load or attack is
> >    better  than  crashing  and  potentially making the
> service completely
> >    unavailable.
> >
> >     5.3 Avoiding Fragmentation
> >
> >    Fragmentation   and   reassembley   of   messages
> incurs  substantial
> >    processing overhead on both the sender and the receiver
> hosts. It also
> >    increases  the risk of lost messages due to lose of just
> one fragment.
> >    It  is  RECOMMENDED  that  syslog  senders  which
> anticipate  sending
> >    messages  over this transport protocol attempt to reduce
> the number of
> >    messages  which  require fragmentation by restricting
> them to the size
> >    which does not require fragmentation.
> >
> _________________________________________________________________
> >
> >
>     [73]
> > TOC
> >
> >   6. Reliability Considerations
> >
> >    The UDP is an unreliable low-overhead protocol. This
> section discusses
> >    reliability  issues  inherent  in  the UDP that
> implementers and users
> >    must be aware of.
> >
> >     6.1 Lost Datagrams
> >
> >    Neither  UDP  nor  syslog protocol provide any mechanism
> to detect and
> >    correct  loss  of  datagrams.  Datagrams may be lost in
> transit due to
> >    congestion,  corruption  or  any  other  intermittent
> network problem.
> >    Syslog  protocol  and IP fragmentation exacerbates the
> problem because
> >    loss  of  a  single  fragment  would  result  in  entire
> message being
> >    discarded.
> >
> >    In  some circumstances the sender may receive an ICMP
> error message or
> >    other  indication  of a transmission problem. If the
> sender receives a
> >    reasonable  indication  that  some datagram may have
> been lost, it MAY
> >    retransmit previously sent messages.
> >
> >     6.2 Message Corruption and Checksums
> >
> >    The  UDP/IP  datagrams  may  get corrupted in transit
> due to software,
> >    hardware  or  network  errors.  This  protocol
> specified  use  of UDP
> >    checksums  to  enable  corruption  detection  in
> addition to checksums
> >    utilized  in  IP  and  Ethernet  layers.  However,
> checksums  do  not
> >    guarantee  corruption detection and this protocol does
> not provide for
> >    message retransmission when a corrupt message is detected.
> >
> >     6.3 Congestion Control
> >
> >    The  UDP  does not provide for congestion control. Some
> systems (hosts
> >    or  routers)  may  generate ICMP source quench error,
> but they are not
> >    required to do so [74][8]Stevens, W., TCP/IP Illustrated
> Volume 1. The
> >    Protocols.,  January  1994..  Any network host can
> discard UDP packets
> >    when  it  is  overloaded.  Due  to  lack  of congestion
> control one or
> >    multiple  syslog senders can maliciously or
> inadvertently overload the
> >    receiver  or  the  network  infrastructure  and  cause
> loss of syslog
> >    messages.
> >
> >     6.4 Sequenced Delivery
> >
> >    The  IP  transport  utilized  by  the  UDP does not
> guarantee that the
> >    sequence  of  datagram  delivery  will  match  the
> order in which the
> >    datagrams  have been sent. The time stamp contained
> within each syslog
> >    message may serve as some guide in establishing sequence
> order, but it
> >    will  not  help  in cases when multiple messages were
> generated during
> >    the  same  time  slot or when messages originated from
> different hosts
> >    whose clocks are not synchronized. The order of syslog
> message arrival
> >    via  the  this syslog transport SHOULD NOT be used as an
> authoritative
> >    guide  in  establishing  the  sequence  of events on the
> syslog sender
> >    hosts.
> >
> >     6.5 Sender Authentication
> >
> >    The  UDP syslog transport does not strongly associate
> the message with
> >    the  message  sender.  The  receiver of the syslog
> message will not be
> >    able  to  ascertain that the message was indeed sent
> from the reported
> >    sender, or if the packet was sent from another device.
> >
> >    One  possible  consequence  of  this  behavior is that a
> misconfigured
> >    machine  may send syslog messages to a receiver
> representing itself as
> >    another machine. The administrators may not be able to
> readily discern
> >    that  there  are  two  or more machines representing
> themselves as the
> >    same machine.
> >
> _________________________________________________________________
> >
> >
>     [75]
> > TOC
> >
> >   7. Security Considerations
> >
> >    Several   syslog   security  considerations  have  been
> discussed  in
> >    [76]RFC-protocolGerhards,  R.,  The  syslog  Protocol,
> .[2] and in the
> >    original  [77]RFC  3164Lonvick,  C.,  The  BSD Syslog
> Protocol, August
> >    2001.[1].  This section focuses on security
> considerations specific to
> >    the syslog transport over UDP.
> >
> >     7.1 Message Authenticity
> >
> >    This transport protocol does not strongly authenticate
> the identity of
> >    the message sender and does not provide any assurance
> that the message
> >    was  not  modified in transit. The receiver of the
> syslog message will
> >    not  be  able  to  ascertain that the message was indeed
> sent from the
> >    reported sender, or if the packet was sent from another device.
> >
> >     7.2 Message Forgery
> >
> >    Syslog  messages can be easily forged. An attacker may
> transmit syslog
> >    messages  (either  from  the  machine  from  which  the
> messages  are
> >    purportedly sent or from any other machine) to a receiver.
> >
> >    In  one case, an attacker may hide the true nature of an
> attack amidst
> >    many  other  messages. As an example, an attacker may
> start generating
> >    forged messages indicating a problem on some machine.
> This may get the
> >    attention  of  the  system  administrators  who  will
> spend their time
> >    investigating  the alleged problem. During this time,
> the attacker may
> >    be  able  to compromise a different machine, or a
> different process on
> >    the same machine.
> >
> >    Additionally,  an  attacker may generate false syslog
> messages to give
> >    untrue  indications of status or of events. As an
> example, an attacker
> >    may  stop  a  critical  process  on  a  machine,  which
> may generate a
> >    notification  of exit. The attacker may subsequently
> generate a forged
> >    notification   that   the  process  had  been
> restarted.  The  system
> >    administrators  may accept that misinformation and not
> verify that the
> >    process had indeed been restarted.
> >
> >     7.3 Message Observation
> >
> >    The  transport  protocol  does  not  provide
> confidentiality  of  the
> >    messages in transit. If syslog messages are in clear
> text, this is how
> >    they   will   be   transferred.   In  most  cases
> passing  clear-text
> >    human-readable   messages   is   a   benefit  to  the
> administrators.
> >    Unfortunately,   an   attacker   may  also  be  able  to
>  observe  the
> >    human-readable  contents of syslog messages. The
> attacker may then use
> >    the knowledge gained from those messages to compromise a
> machine or do
> >    other  damage.  It  is  RECOMMENDED  that  no sensitive
> information is
> >    transmitted  via  this transport protocol or that
> transmission of such
> >    information is restricted to properly secured networks.
> >
> >     7.4 Replaying
> >
> >    Message  forgery and observation can be combined into a
> replay attack.
> >    An attacker may record a set of messages that indicate
> normal activity
> >    of  a  machine. At a later time, that attacker may
> remove that machine
> >    from  the network and replay the syslog messages to the
> collector with
> >    new  time  stamps.  The administrators may find nothing
> unusual in the
> >    received  messages  and  their  receipt  would falsely
> indicate normal
> >    activity of the machine.
> >
> >     7.5 Unreliable Delivery
> >
> >    As was previously discussed in the Reliability
> Considerations section,
> >    the  UDP  transport  is  not  reliable  and  packets
> containing syslog
> >    message datagrams can be lost in transit without any
> notice. There can
> >    be  security  consequences to the loss of one or more
> syslog messages.
> >    Administrators  may  not  become aware of a developing
> and potentially
> >    serious  problem. Messages may also be intercepted and
> discarded by an
> >    attacker as a way to hide unauthorized activities.
> >
> >     7.6 Message Prioritization and Differentiation
> >
> >    The  transport  protocol  described  in this document
> does not require
> >    prioritization of syslog messages on the wire or when
> processed on the
> >    receiving  host  based  on their severity. The security
> implication of
> >    such  behavior  is that the syslog receiver or network
> devices may get
> >    overwhelmed  with  low  severity  messages  and  be
> forced to discard
> >    potentially high severity messages. High severity
> messages may contain
> >    indication  about  serious  security problems, but they
> will not get a
> >    higher  priority.  It  is  difficult to make sure that
> high severities
> >    messages  get  higher end-to-end delivery priority,
> especially over an
> >    unreliable UDP transport.
> >
> >    On  a  case-by-case  basis,  device  operators  may
> find  some way to
> >    associate  the  different  severity levels with the
> quality of service
> >    identifiers.  As  an  example,  the operators may elect
> to define some
> >    linkage  between  syslog  messages that have a specific
> Priority value
> >    with  a  specific  value  to  be  used  in  the  IPv4
> Precedence field
> >    [78][4]Postel,  J.,  Internet  Protocol,  September
> 1981.,  the  IPv6
> >    Traffic  Class  octet  [79][5]Deering,  S.  and  R.
> Hinden,  Internet
> >    Protocol,  Version  6  (IPv6)  Specification,  December
> 1998., or the
> >    Differentiated Services field [80][9]Nichols, K., Blake,
> S., Baker, F.
> >    and  D.  Black,  Definition  of  the Differentiated
> Services Field (DS
> >    Field)  in  the  IPv4  and IPv6 Headers, December 1998..
> However, even
> >    with  this prioritization on the network, high load can
> lead to buffer
> >    starvation on the receiving host and result in dropped
messages.
> >
> >     7.7 Denial of Service
> >
> >    An  attacker  may  overwhelm a receiver by sending more
> messages to it
> >    than  can  be  handled  by  the  infrastructure  or the
> device itself.
> >    Implementers  SHOULD  attempt  to  provide features that
> minimize this
> >    threat such as only receiving syslog messages from known
> IP addresses.
> >
> _________________________________________________________________
> >
> >
>     [81]
> > TOC
> >
> >   8. IANA Considerations
> >
> >    IANA must reserve UDP port 514 for this transport.
> >
> _________________________________________________________________
> >
> >
>     [82]
> > TOC
> >
> >   9. Notice to RFC Editor
> >
> >    This is a notice to the RFC editor. This ID is submitted
> along with ID
> >    draft-ietf-syslog-protocol  and  they cross-reference
> each other. When
> >    RFC  numbers  are determined for each of these IDs,
> please replace all
> >    references    to    "RFC-protocol"    with    the    RFC
>   number   of
> >    draft-ietf-syslog-protocol   ID.  Please  remove  this
> section  after
> >    editing.
> >
> _________________________________________________________________
> >
> >
>     [83]
> > TOC
> >
> >   10. Authors and Working Group Chair
> >
> >    The working group can be contacted via the mailing list:
> > [email-masked]
> >
> >    The current Chair of the Working Group may be contacted
> at: Chris
> > Lonvick Cisco Systems
> > Email: [email-masked]
> >
> >    The author of this draft is:
> > Anton Okmianski
> > Email: [email-masked]
> >
> > Phone: (978) 936-1612
> > Fax: (978) 936-2225
> >
> > Cisco Systems, Inc
> > 1414 Massachusetts Ave.
> > Boxborough, MA 01719-2205
> > USA
> >
> _________________________________________________________________
> >
> >
>     [84]
> > TOC
> >
> >   11. Acknowledgements
> >
> >    The  author  wishes  to  thank  Chris  Lonvick, Rainer
> Gerhards, David
> >    Harrington,  Andrew  Ross,  Albert Mietus, Bernie Volz,
> and all others
> >    who have commented on the various versions of this proposal.
> >
> _________________________________________________________________
> >
> >
>     [85]
> > TOC
> >
> >   12 References
> >
> >    [1] Lonvick, C., "[86]The BSD Syslog Protocol", RFC
> 3164, August 2001.
> >    [2] Gerhards, R., "[87]The syslog Protocol", RFC RFC-protocol.
> >    [3] Postel, J., "[88]User Datagram Protocol", STD 6, RFC
> 768, August
> >    1980.
> >    [4]  Postel,  J.,  "[89]Internet  Protocol", STD 5, RFC
> 791, September
> >    1981.
> >    [5] [90]Deering, S. and [91]R. Hinden, "[92]Internet
> Protocol, Version
> >    6 (IPv6) Specification", RFC 2460, December 1998
> ([93]HTML, [94]XML).
> >    [6]  [95]Bradner,  S.,  "[96]Key  words  for  use  in
> RFCs to Indicate
> >    Requirement Levels", BCP 14, RFC 2119, March 1997
> ([97]HTML, [98]XML).
> >    [7]  [99]Crocker,  D.  and  [100]P.  Overell,
> "[101]Augmented BNF for
> >    Syntax Specifications: ABNF", RFC 2234, November 1997.
> >    [8]  Stevens,  W.,  "TCP/IP  Illustrated  Volume  1.
> The Protocols.",
> >    January 1994.
> >    [9]  [102]Nichols,  K.,  [103]Blake,  S.,  [104]Baker,
> F. and [105]D.
> >    Black,  "[106]Definition  of  the  Differentiated
> Services  Field (DS
> >    Field)  in  the  IPv4  and  IPv6  Headers",  RFC  2474,
> December 1998
> >    ([107]HTML, [108]XML).
> >    [10]   Mockapetris,   P.,  "[109]Domain  names  -
> implementation  and
> >    specification", STD 13, RFC 1035, November 1987.
> >    [11]  Hedrick, C., "[110]Routing Information Protocol",
> RFC 1058, June
> >    1988.
> >    [12]  [111]Droms,  R., "[112]Dynamic Host Configuration
> Protocol", RFC
> >    2131, March 1997 ([113]HTML, [114]XML).
> >    [13]  [115]Sollins, K., "[116]The TFTP Protocol
> (Revision 2)", STD 33,
> >    RFC 1350, July 1992.
> >    [14]   [117]Braden,   R.,  "[118]Requirements  for
> Internet  Hosts  -
> >    Communication Layers", STD 3, RFC 1122, October 1989.
> >    [15]  Kent,  C.  and  J.  Mogul,  ""Fragmentation
> Considered Harmful,"
> >    Computer  Communications  Review,  vol.17,  no.5,
> pp.390-401", August
> >    1987.
> >
> _________________________________________________________________
> >
> >
>    [119]
> > TOC
> >
> >   Author's Address
> >
> >            Anton Okmianski
> >            Cisco Systems, Inc.
> >            1414 Massachusetts Ave
> >            Boxborough, MA 01719-2205
> >            USA
> >    EMail:  [email-masked]
> >
> _________________________________________________________________
> >
> >
>    [120]
> > TOC
> >
> >   Appendix A. Rational For Transport Message Size Restrictions
> >
> >    This   appendix   provides   the  rational  behind  the
> Payload  size
> >    restrictions  for  this protocol. The Payload
> restrictions outlined in
> >    the  specification, essentially ensure that the
> transport message size
> >    does  not  exceed 512 bytes (without UDP/IP headers) for
> transport via
> >    IPv4  and  does  not  exceed  1196 bytes for transport
> via IPv6. These
> >    restrictions  put  an  upper  boundary on the UDP/IP
> datagram size for
> >    this protocol, which accomplishes two goals.
> >
> >    First,   they   insure   interoperability   between
> various   UDP/IP
> >    implementations. Even though the maximum IP datagram
> size is specified
> >    as  65536  bytes,  many  UDP/IP implementations have
> been shown not to
> >    work with large datagram sizes [121][8]Stevens, W.,
> TCP/IP Illustrated
> >    Volume  1.  The  Protocols., January 1994.. Many
> established UDP-based
> >    protocols  restrict  UDP datagram data size to 512
> bytes. For example,
> >    DNS  [122][10]Mockapetris,  P.,  Domain  names  -
> implementation  and
> >    specification,  November  1987.  and RIP
> [123][11]Hedrick, C., Routing
> >    Information  Protocol,  June 1988. do that. The DHCPv4
> [124][12]Droms,
> >    R.,  Dynamic  Host  Configuration  Protocol, March 1997.
> restricts the
> >    size to 512 bytes, but allows sides to agree on a larger
> value through
> >    the  protocol.  The  TFTP  [125][13]Sollins,  K.,  The
> TFTP  Protocol
> >    (Revision  2),  July  1992.  restricts the UDP data size
> to 518 bytes,
> >    which is slightly larger.
> >
> >    The  second  reason  for  datagram  size restrictions is
> that it helps
> >    reduce  the  likelihood  of  the IP-layer datagram
> fragmentation. This
> >    could have potentially resulted in fragmentation on two
> levels: syslog
> >    transport  protocol  and IP layer. Since fragmentation
> has significant
> >    overhead   for  message  reassembley,  it  is  best  to
> avoid  double
> >    fragmentation. The likelihood of IP fragmentation can be
> significantly
> >    reduced  by sending IP datagrams in sizes which all
> hosts must be able
> >    to process.
> >
> >    The minimum MTU of a transport protocol determines the
> minimum size of
> >    packets  that  hosts must be able to accept. For IPv4,
> the minimum MTU
> >    is  576  bytes  [126][4]Postel, J., Internet Protocol,
> September 1981.
> >    and  for IPv6 - 1280 bytes [127][5]Deering, S. and R.
> Hinden, Internet
> >    Protocol,  Version  6  (IPv6)  Specification,  December
> 1998.. In both
> >    cases,  the  maximum  message size we chose fits within
> the MTU of the
> >    transport  in all cases except for when extremely large
> IP headers are
> >    used.  IPv4  header  can  range  from 20 to 60 bytes in
> length and UDP
> >    header is fixed at 8 bytes. Thus, our message size
> restrictions ensure
> >    that  in  all  cases  except  for  when  the  IP header
> is 56 bytes or
> >    greater,  the size of the packet will within the size of
> the transport
> >    MTU.
> >
> >    For  IPv6,  we have left the same amount of padding for
> UDP/IP headers
> >    as  was  conventionally  done  for IPv4 in DNS, RIP and
> DHCPv4 with an
> >    additional  padding  of  extra  20  bytes to accommodate
> a larger IPv6
> >    header.   This   follows   the   methodology  suggested
> in  the  IPv6
> >    specification    for    calculating    upper-layer
> payload   limits
> >    [128][5]Deering, S. and R. Hinden, Internet Protocol,
> Version 6 (IPv6)
> >    Specification, December 1998..
> >
> >    Path  MTU  discovery  can generally be used to discover
> the MTU of the
> >    link.  Unfortunately,  using  path  MTU  discovery  with
>  UDP is not a
> >    reliable  option  because  it depends on routers
> providing ICMP errors
> >    and  hosts  doing  retransmission,  which  are  not done
> consistently.
> >    Implementors  MUST follow the size restrictions outlined
> above and not
> >    rely on path MTU discovery.
> >
> _________________________________________________________________
> >
> >
>    [129]
> > TOC
> >
> >   Intellectual Property Statement
> >
> >    The  IETF  takes  no  position  regarding the validity
> or scope of any
> >    intellectual property or other rights that might be
> claimed to pertain
> >    to  the  implementation  or  use  of  the technology
> described in this
> >    document or the extent to which any license under such
> rights might or
> >    might not be available; neither does it represent that
> it has made any
> >    effort  to  identify  any  such  rights.  Information
> on  the  IETF's
> >    procedures   with   respect   to   rights   in
> standards-track   and
> >    standards-related  documentation  can  be  found  in
> BCP-11. Copies of
> >    claims  of rights made available for publication and any
> assurances of
> >    licenses  to  be  made  available, or the result of an
> attempt made to
> >    obtain a general license or permission for the use of
> such proprietary
> >    rights  by implementors or users of this specification
> can be obtained
> >    from the IETF Secretariat.
> >
> >    The  IETF  invites  any interested party to bring to its
> attention any
> >    copyrights,  patents  or  patent  applications,  or
> other proprietary
> >    rights  which  may  cover  technology that may be
> required to practice
> >    this  standard.  Please  address the information to the
> IETF Executive
> >    Director.
> >
> >   Full Copyright Statement
> >
> >    Copyright (C) The Internet Society (2004). All Rights Reserved.
> >
> >    This  document  and  translations of it may be copied
> and furnished to
> >    others,  and  derivative works that comment on or
> otherwise explain it
> >    or assist in its implementation may be prepared, copied,
> published and
> >    distributed,  in  whole  or  in part, without
> restriction of any kind,
> >    provided  that  the  above  copyright  notice  and  this
> paragraph are
> >    included  on  all  such  copies  and  derivative  works.
> However, this
> >    document  itself  may  not be modified in any way, such
> as by removing
> >    the  copyright  notice  or references to the Internet
> Society or other
> >    Internet organizations, except as needed for the purpose
> of developing
> >    Internet standards in which case the procedures for
> copyrights defined
> >    in  the Internet Standards process must be followed, or
> as required to
> >    translate it into languages other than English.
> >
> >    The  limited  permissions  granted above are perpetual
> and will not be
> >    revoked by the Internet Society or its successors or assignees.
> >
> >    This  document  and the information contained herein is
> provided on an
> >    "AS  IS"  basis  and THE INTERNET SOCIETY AND THE
> INTERNET ENGINEERING
> >    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
> INCLUDING BUT
> >    NOT  LIMITED  TO  ANY  WARRANTY THAT THE USE OF THE
> INFORMATION HEREIN
> >    WILL   NOT   INFRINGE   ANY   RIGHTS  OR  ANY  IMPLIED
> WARRANTIES  OF
> >    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
> >
> >   Acknowledgment
> >
> >    Funding  for  the  RFC  Editor  function  is currently
> provided by the
> >    Internet Society.
> >
> > References
> >
> >    1.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
> >    2. http://www.ietf.org/ietf/1id-abstracts.txt
> >    3. http://www.ietf.org/shadow.html
> >    4.
>
file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#intro
> >    5.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#TransportProtocolOverview
> >    6.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#DefinitionsAndArchitecture
> >    7.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#RequiredTransportProtocol
> >    8.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#EncapsulationLayers
> >    9.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#MessageFormat
> >   10.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#BasicHeaderFormat
> >   11.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#ExtendedHeaderFormat
> >   12.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#Message Identifier
> >   13.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#TotalLength
> >   14.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#FragmentOffset
> >   15.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#ExtendedHeaderExample
> >   16.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#Payload
> >   17.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#SupportedMessageLength
> >   18.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#LowerLayerConsiderations
> >   19.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#TargetPort
> >   20.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#SourcePort
> >   21.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#SourceIPAddress
> >   22.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#UDPIPHeader
> >   23.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
ml#FragmentationAndReassembley
> >   24.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#MessageFragmentation
> >   25.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#MessageReassembley
> >   26.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#AvoidingFragmentation
> >   27.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#reliability
> >   28.
>
file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#loss
> >   29.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#corruption
> >   30.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#overload
> >   31.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#sequence
> >   32.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#SenderAuthentication
> >   33.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#security
> >   34.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#SecAuth
> >   35.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#SecForg
> >   36.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#SecObs
> >   37.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#SecReplay
> >   38.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#SecRelDel
> >   39.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#SecPri
> >   40.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#SecDen
> >   41.
>
file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#iana
> >   42.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#rfc-editor
> >   43.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#authors
> >   44.
>
file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#acks
> >   45.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#rfc.references1
> >   46.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#rfc.authors
> >   47.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#AppendixA
> >   48.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#rfc.copyright
> >   49.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
> >   50.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#RFC3164
> >   51.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#RFC-protocol
> >   52.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#RFC-protocol
> >   53.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#RFC0768
> >   54.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#RFC0791
> >   55.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#RFC2460
> >   56.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#RFC2119
> >   57.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
> >   58.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#RFC-protocol
> >   59.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#RFC-protocol
> >   60.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#RFC-protocol
> >   61.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#RFC0768
> >   62.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
> >   63.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#RFC-protocol
> >   64.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#RFC2234
> >   65.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#MessageReassembley
> >   66.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
> >   67.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#RFC0768
> >   68.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#RFC0791
> >   69.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#RFC2460
> >   70.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#RFC0768
> >   71.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#RFC2460
> >   72.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
> >   73.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
> >   74.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#Stevens
> >   75.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
> >   76.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#RFC-protocol
> >   77.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#RFC3164
> >   78.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#RFC0791
> >   79.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#RFC2460
> >   80.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#RFC2474
> >   81.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
> >   82.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
> >   83.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
> >   84.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
> >   85.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
> >   86. ftp://ftp.isi.edu/in-notes/rfc3164.txt
> >   87. ftp://ftp.isi.edu/in-notes/rfc3164.txt
> >   88. ftp://ftp.isi.edu/in-notes/rfc768.txt
> >   89. ftp://ftp.isi.edu/in-notes/rfc791.txt
> >   90. mailto:[email-masked]
> >   91. mailto:[email-masked]
> >   92. ftp://ftp.isi.edu/in-notes/rfc2460.txt
> >   93. http://xml.resource.org/public/rfc/html/rfc2460.html
> >   94. http://xml.resource.org/public/rfc/xml/rfc2460.xml
> >   95. mailto:[email-masked]
> >   96. ftp://ftp.isi.edu/in-notes/rfc2119.txt
> >   97. http://xml.resource.org/public/rfc/html/rfc2119.html
> >   98. http://xml.resource.org/public/rfc/xml/rfc2119.xml
> >   99. mailto:[email-masked]
> >  100. mailto:[email-masked]
> >  101. ftp://ftp.isi.edu/in-notes/rfc2234.txt
> >  102. mailto:[email-masked]
> >  103. mailto:[email-masked]
> >  104. mailto:[email-masked]
> >  105. mailto:[email-masked]
> >  106. ftp://ftp.isi.edu/in-notes/rfc2474.txt
> >  107. http://xml.resource.org/public/rfc/html/rfc2474.html
> >  108. http://xml.resource.org/public/rfc/xml/rfc2474.xml
> >  109. ftp://ftp.isi.edu/in-notes/rfc1035.txt
> >  110. ftp://ftp.isi.edu/in-notes/rfc1058.txt
> >  111. mailto:[email-masked]
> >  112. ftp://ftp.isi.edu/in-notes/rfc2131.txt
> >  113. http://xml.resource.org/public/rfc/html/rfc2131.html
> >  114. http://xml.resource.org/public/rfc/xml/rfc2131.xml
> >  115. mailto:[email-masked]
> >  116. ftp://ftp.isi.edu/in-notes/rfc1350.txt
> >  117. mailto:[email-masked]
> >  118. ftp://ftp.isi.edu/in-notes/rfc1122.txt
> >  119.
> >
file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
> >  120.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
ml#toc
>  121.
file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#Steve
ns
>  122.
file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#RFC10
35
>  123.
file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#RFC10
58
>  124.
file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#RFC21
31
>  125.
file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#RFC13
50
>  126.
file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#RFC07
91
>  127.
file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#RFC24
60
>  128.
file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#RFC24
60
>  129.
file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc

- -- 
Devin Kowatch
[email-masked]

------------------------------

Date: Mon, 10 May 2004 11:44:04 -0700
From: Devin Kowatch <[email-masked]>
Subject: Re: Transport draft preview

Hi,

There is one point which I'm not completely clear on.  What happens to a
fragmented message when one ore more parts of that message get dropped?

One other suggestion ... why not just limit UDP packets to 1024 bytes,
whith no fragmentation?  For large syslog messages, require a reliable
transport layer (TCP) which means you can just properly frame the
message and send it (or use something like BEEP which already deals with
fragmentation) ...

On Fri, May 07, 2004 at 04:36:25PM -0400, Anton Okmianski wrote:
> Hi!
>
> I am about to publish the new UDP syslog transport draft. I thought I'd show it this forum first before making it publicly available to a wider audience.  In particular, I want to make sure we have rough consensus on support for fragmentation feature.  I have specified the header format using ASCII encoding as was suggested by Rainer and Andrew.
>
> I plan on submitting this as an official draft next week.  One area I am not quite sure about yet is what minimum size of messages should implementations be forced to support. It definitely can't be the full allowed size of 16MB as some hardware won't support it. Right now it is set at 65k, which means implementations are forced to support fragmentation.  I wonder if reducing it to the size where fragmentation would be optional (507 bytes for IPv4 and 1911 for IPv6) would increase the adoption of the protocol without sacrificing too much of interoperability. Fragmentation feature adds orders of magnitude more complexity than non-fragmented syslog transport.  Any opinions?
>
> Thanks,
> Anton.

>
>
>
> syslog Working Group                                        A. Okmianski
> Internet-Draft                                       Cisco Systems, Inc.
> Expires: November 5, 2004                                    May 7, 2004
>
>
>                 Transmission of syslog messages over UDP
>                    draft-ietf-syslog-transport-udp-01
>
> Status of this Memo
>
>    This document is an Internet-Draft and is in full conformance with
>    all provisions of Section 10 of RFC2026.
>
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF), its areas, and its working groups. Note that other
>    groups may also distribute working documents as Internet-Drafts.
>
>    Internet-Drafts are draft documents valid for a maximum of six months
>    and may be updated, replaced, or obsoleted by other documents at any
>    time. It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as "work in progress."
>
>    The list of current Internet-Drafts can be accessed at http://
>    www.ietf.org/ietf/1id-abstracts.txt.
>
>    The list of Internet-Draft Shadow Directories can be accessed at
>    http://www.ietf.org/shadow.html.
>
>    This Internet-Draft will expire on November 5, 2004.
>
> Copyright Notice
>
>    Copyright (C) The Internet Society (2004). All Rights Reserved.
>
> Abstract
>
>    This document describes the transport for the syslog message 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 using
>    multiple datagrams.
>
>
>
>
>
>
>
>
>
> Okmianski               Expires November 5, 2004                [Page 1]
>
> Internet-Draft            syslog udp transport                  May 2004
>
>
> Table of Contents
>
>    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
>    2.  Transport Protocol Overview  . . . . . . . . . . . . . . . . .  4
>      2.1   Definitions and Architecture . . . . . . . . . . . . . . .  4
>      2.2   Required Transport Protocol  . . . . . . . . . . . . . . .  4
>      2.3   Encapsulation Layers . . . . . . . . . . . . . . . . . . .  4
>    3.  Message Format . . . . . . . . . . . . . . . . . . . . . . . .  6
>      3.1   Basic Header Format  . . . . . . . . . . . . . . . . . . .  6
>      3.2   Extended Header Format . . . . . . . . . . . . . . . . . .  7
>        3.2.1   Message Identifier . . . . . . . . . . . . . . . . . .  7
>        3.2.2   Total Length . . . . . . . . . . . . . . . . . . . . .  7
>        3.2.3   Fragment Offset  . . . . . . . . . . . . . . . . . . .  8
>        3.2.4   Extended Header Example  . . . . . . . . . . . . . . .  8
>      3.3   Payload  . . . . . . . . . . . . . . . . . . . . . . . . .  9
>      3.4   Supported Message Length . . . . . . . . . . . . . . . . .  9
>    4.  UDP/IP Layer Considerations  . . . . . . . . . . . . . . . . . 10
>      4.1   Target Port  . . . . . . . . . . . . . . . . . . . . . . . 10
>      4.2   Source Port  . . . . . . . . . . . . . . . . . . . . . . . 10
>      4.3   Source IP Address  . . . . . . . . . . . . . . . . . . . . 10
>      4.4   UDP/IP Headers . . . . . . . . . . . . . . . . . . . . . . 10
>    5.  Fragmentation and Reassembley  . . . . . . . . . . . . . . . . 12
>      5.1   Message Fragmentation  . . . . . . . . . . . . . . . . . . 12
>      5.2   Message Reassembley  . . . . . . . . . . . . . . . . . . . 12
>      5.3   Avoiding Fragmentation . . . . . . . . . . . . . . . . . . 13
>    6.  Reliability Considerations . . . . . . . . . . . . . . . . . . 14
>      6.1   Lost Datagrams . . . . . . . . . . . . . . . . . . . . . . 14
>      6.2   Message Corruption and Checksums . . . . . . . . . . . . . 14
>      6.3   Congestion Control . . . . . . . . . . . . . . . . . . . . 14
>      6.4   Sequenced Delivery . . . . . . . . . . . . . . . . . . . . 14
>      6.5   Sender Authentication  . . . . . . . . . . . . . . . . . . 15
>    7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
>      7.1   Message Authenticity . . . . . . . . . . . . . . . . . . . 16
>      7.2   Message Forgery  . . . . . . . . . . . . . . . . . . . . . 16
>      7.3   Message Observation  . . . . . . . . . . . . . . . . . . . 16
>      7.4   Replaying  . . . . . . . . . . . . . . . . . . . . . . . . 17
>      7.5   Unreliable Delivery  . . . . . . . . . . . . . . . . . . . 17
>      7.6   Message Prioritization and Differentiation . . . . . . . . 17
>      7.7   Denial of Service  . . . . . . . . . . . . . . . . . . . . 18
>    8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
>    9.  Notice to RFC Editor . . . . . . . . . . . . . . . . . . . . . 20
>    10.   Authors and Working Group Chair  . . . . . . . . . . . . . . 21
>    11.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
>    12.   References . . . . . . . . . . . . . . . . . . . . . . . . . 22
>        Author's Address . . . . . . . . . . . . . . . . . . . . . . . 23
>    A.  Rational For Transport Message Size Restrictions . . . . . . . 24
>        Intellectual Property and Copyright Statements . . . . . . . . 26
>
>
>
>
> Okmianski               Expires November 5, 2004                [Page 2]
>
> Internet-Draft            syslog udp transport                  May 2004
>
>
> 1.  Introduction
>
>    The original syslog protocol has been described in an informational
>    RFC 3164 [1] as it has been observed in existing implementations. It
>    describes both the semantics of syslog message format as well as a
>    UDP transport.  Subsequently, the syslog protocol has been formally
>    defined in a standards track RFC-protocol [2].
>
>    The RFC-protocol [2] has provided for support of any number of
>    transport layer protocols for transmitting syslog messages and left
>    it to subsequent RFCs to specify transport protocols. This standards
>    track RFC describes the UDP transport for the syslog protocol. This
>    transport protocol is REQUIRED for all syslog protocol
>    implementations.
>
>    This transport protocol was designed to work on top of UDP [3] over
>    both IPv4 [4] and IPv6 [5]. This protocol overcomes the data size
>    restrictions of the UDP protocol by introducing message fragmentation
>    feature.
>
>    As we will show in this specification, this protocol has significant
>    reliability and security issues stemming from the use of UDP.
>    However, this protocol is lightweight and extends on the existing
>    popular use of UDP for syslog. Network administrators and architects
>    should be aware of the shortcomings of this protocol and plan
>    accordingly.
>
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>    document are to be interpreted as described in RFC 2119 [6]. The
>    words 'byte' and 'octet' are used interchangeably in this
>    specification.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Okmianski               Expires November 5, 2004                [Page 3]
>
> Internet-Draft            syslog udp transport                  May 2004
>
>
> 2.  Transport Protocol Overview
>
> 2.1  Definitions and Architecture
>
>    The following definitions will be used in this document:
>    o  An application that can generate syslog messages will be referred
>       to as a "sender";
>    o  An application that can receive syslog messages will be referred
>       to as a "receiver".
>
>    An application can function in dual capacity. For example, a syslog
>    relay may receive and forward messages. A single system can host any
>    number of syslog senders. Only one syslog receiver can be hosted on a
>    single system using the standard listening port.
>
> 2.2  Required Transport Protocol
>
>    This document describes the UDP transport layer protocol for the
>    syslog protocol RFC-protocol [2]. Every syslog sender and receiver
>    implementation which adheres to the RFC-protocol [2] MUST fully
>    implement the transport protocol specified in this document.
>    Implementations does not have to support both IPv4 and IPv6 if it is
>    designed to be used over only one of these protocols.
>
> 2.3  Encapsulation Layers
>
>    Syslog UDP transport carries syslog messages as generic payload
>    encapsulated with a syslog transport header, UDP header and an IP
>    header. Below is a summary of syslog UDP/IP packet structure as used
>    this transport protocol:
>
>
>    		+--------------------------------+
>    		|       IPv4 or IPv6 Header      |
>    		|        (20 or more bytes)      |
>    		+--------------------------------+
>    		|           UDP Header           |
>    		|           (8 bytes)            |
>    		+--------------------------------+
>    		|    Syslog Transport Header     |
>    		|        (5 or 32 bytes)         |
>    		+--------------------------------+
>    		|     Syslog Message Payload     |
>    		|       (1 to 1191 bytes)        |
>    		+--------------------------------+
>
>    Small syslog messages are transmitted using one UDP/IP datagram per
>    message. However, syslog protocol [2] allows messages as large as
>
>
>
> Okmianski               Expires November 5, 2004                [Page 4]
>
> Internet-Draft            syslog udp transport                  May 2004
>
>
>    16777216 bytes, while UDP/IP datagram cannot exceed a total size of
>    65526 bytes [3] and most existing protocols restrict the size of UDP
>    data to much less. In order to support transmitting large messages
>    over UDP/IP, this transport protocol supports fragmentation of large
>    syslog messages into multiple UDP/IP datagrams for transmission and
>    reassembley on the receiving end.
>
>    Each syslog UDP/IP datagram MUST contain one and only one complete
>    syslog message or one fragment of a message.  Transmitting multiple
>    messages or multiple fragments of different messages in a single UDP
>    datagram is not supported by this protocol.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Okmianski               Expires November 5, 2004                [Page 5]
>
> Internet-Draft            syslog udp transport                  May 2004
>
>
> 3.  Message Format
>
>    The syslog transport message consist of a transport header and a
>    syslog message payload. The format of the transport header is
>    different for fragmented and non-fragmented messages.  Basic
>    transport header is used for non-fragmented messages and extended
>    transport header is used for fragmented messages.
>
>    An ASCII-based encoding was chosen for the syslog transport for
>    consistency with the RFC-protocol [2].  Syslog transport datagrams
>    without required UDP and IP headers have the following format in ABNF
>    [7] notation:
>
>
>        SyslogTransportMessage = ( BasicHeader / ExtendedHeader )
>                                          SP Payload
>
>        BasicHeader     = Version SP "0"
>        Version         = %d118 1*3DIGIT   ; "v1" in this version
>
>        ExtendedHeader  = Version SP "1" SP MessageId
>                          SP TotalLength SP FragmentOffset
>
>        MessageId       = 1*8DIGIT        ; 0 to 16777215
>        TotalLength     = 1*8DIGIT        ; 1 to 16777216
>        FragmentOffset  = 1*8DIGIT        ; 0 to 16777215
>        Payload         = 1*1191OCTET
>
>        OCTET           = %d00-255
>        DIGIT           = %d48-57
>        SP              = %d32
>
>
> 3.1  Basic Header Format
>
>    When no fragmentation is used and the entire syslog message is
>    transferred as a single UDP/IP datagram, a basic syslog transport
>    header MUST be used.  The version for this protocol is "1". It must
>    be followed by one space and a "0" to indicate that this is a basic
>    header.   Therefore, the only possible value for the basic header in
>    this protocol is as follows:
>
>
>       "v1 0 "
>
>    Example of a syslog message without the transport header (message is
>    wrapped for display):
>
>
>
>
> Okmianski               Expires November 5, 2004                [Page 6]
>
> Internet-Draft            syslog udp transport                  May 2004
>
>
>       "v1 888 3 2003-10-11T22:14:15.003Z host.domain.com
>       dns: configuration error"
>
>    Example of the same message with the transport header (message is
>    wrapped for display):
>
>
>       "v1 0 v1 888 4 2003-10-11T22:14:15.003Z host.domain.com
>       dns: configuration error"
>
>
> 3.2  Extended Header Format
>
>    When syslog message is fragmented by the sender, multiple UDP
>    datagrams must be used and each datagram MUST contain an extended
>    syslog transport header. The version for this protocol is "1". The
>    version field MUST be followed by a single space and a "1" to
>    indicate that this is an extended header.  Thus, an extended header
>    MUST always begin with "v1 1 ", but MUST also have additional fields
>    which aid in fragmentation.
>
>    The MessageId, TotalLength and FragmentOffset fields are used solely
>    for fragmentation of long messages and reassembley.  They SHOULD NOT
>    be used for other purposes.
>
> 3.2.1  Message Identifier
>
>    The MessageId field (along with the source UDP port and the IP
>    address) is used to identify the message such that fragments of a
>    single syslog message can be reassembled by the receiver into a
>    complete message.  The MessageId field MUST be a numeric value in the
>    range of 0 to 16777215.  Leading zeros MUST not be present in the
>    MessageId field.
>
>    Each syslog sender process MUST choose a random MessageId value
>    within the supported range for its first message. Subsequent messages
>    generated by the same process MUST each increment the MessageId by 1
>    up to 16777215 and then continue at 0. Using random value for the
>    first MessageId helps reduce the possibility of potential errors in
>    message reassembley. Refer to discussion about message reassembley
>    (Section 5.2) for more details.
>
>    All datagrams which represent parts of a given fragmented syslog
>    message MUST have the same MessageId value.
>
> 3.2.2  Total Length
>
>    The TotalLength field MUST be a numeric value in the range of 1 to
>
>
>
> Okmianski               Expires November 5, 2004                [Page 7]
>
> Internet-Draft            syslog udp transport                  May 2004
>
>
>    16777216. It MUST indicate the length of a complete syslog message
>    before it was fragmented and before it was encapsulated with
>    transport headers.  The same TotalLength field value MUST be present
>    in all UDP datagrams which represent fragments of the same syslog
>    message. Leading zeros MUST not be present in the TotalLength field.
>
>    Note that in IPv4 the "total length" field identifies the length of a
>    single packet.  In this protocol, the TotalLength field is used to
>    identify the total length of a complete syslog message, which is
>    transmitted using multiple fragments and multiple datagram packets.
>    The fragment length is not specified in the transport header because
>    it can be inferred from the size of the IP packet containing the UDP
>    datagram.
>
> 3.2.3  Fragment Offset
>
>    The FragmentOffset field MUST be a numeric value in the range of 0 to
>    16777215. It MUST indicate the byte offset of the fragment data in
>    the complete syslog message. The offset index starts at 0 for the
>    first fragment. For example, if an 700 byte syslog message is
>    fragmented into 480 and 220 byte parts, the FragmentOffset in the
>    first message will be 0 and in the second - 480. Note that fragments
>    don't have to be the same size.  Leading zeros MUST not be present in
>    the FragmentOffset field.
>
> 3.2.4  Extended Header Example
>
>    The following is an example of a syslog message without the transport
>    header (message is wrapped for display):
>
>
>       "v1 888 4 2003-10-11T22:14:15.003Z host.domain.com
>       dns: configuration error"
>
>    Suppose this message had to be fragmented by transport layer into two
>    parts at an arbitrary point.  This would result in two separate UDP
>    datagrams being sent - one for each fragment. Below is the content of
>    each of the syslog transport UDP messages with syslog transport
>    headers but without UDP/IP headers:
>
>
>       "v1 1 45612221 74 0 v1 888 4 2003-10-11T22:14:15.003Z host.dom"
>
>       "v1 1 45612221 74 42 ain.com dns: configuration error"
>
>    In the above example, the leading "v1" is the version of the
>    transport protocol, "1" indicates that this is an extended header
>    (fragmentation in use), "45612221" is the MessageId, "74" is the
>
>
>
> Okmianski               Expires November 5, 2004                [Page 8]
>
> Internet-Draft            syslog udp transport                  May 2004
>
>
>    TotalLength of the message, while "0" and "42" are FragmentOffset
>    fields. Everything following the FragmentOffset and a space is a the
>    Payload of each respective message.
>
> 3.3  Payload
>
>    The Payload field of the syslog UPD transport message is an entire
>    syslog message or one fragment. The maximum Payload size depends on
>    the IP protocol used and the type header that is used.
>
>       Maximum Payload size:
>
>       With IPv4 and basic header:    507 bytes
>       With IPv4 and extended header: 480 bytes
>
>       With IPv6 and basic header:    1191 bytes
>       With IPv6 and extended header: 1164 bytes
>
>    The Payload size restrictions above effectively mean that the largest
>    syslog message that can be sent non-fragmented is 507 bytes for
>    transport via IPv4 and 1191 bytes for transport via IPv6.
>
>    For a discussion of the relational behind the above size restrictions
>    please refer to Appendix A.
>
> 3.4  Supported Message Length
>
>    The maximum syslog message length supported by this protocol is the
>    maximum value of the TotalLength field, which is 16777216 bytes.
>    However, not all deployment scenarios for syslog will be on hosts
>    with hardware capable of supporting the maximum length of messages
>    supported by this protocol. Additionally, extremely large messages
>    may not be needed in many environments. Therefore, implementations
>    are NOT REQUIRED to support the maximum message length allowed by
>    this protocol.
>
>    All implementations MUST support sending and receiving syslog
>    messages up to and including 65536 bytes in size (syslog transport
>    and UDP/IP headers are extra). Support for larger messages is
>    encouraged. Implementors SHOULD clearly state the maximum supported
>    message size in documentation.
>
>
>
>
>
>
>
>
>
>
> Okmianski               Expires November 5, 2004                [Page 9]
>
> Internet-Draft            syslog udp transport                  May 2004
>
>
> 4.  UDP/IP Layer Considerations
>
> 4.1  Target Port
>
>    Syslog receivers MUST support accepting syslog message datagrams on a
>    well-known UDP port 514.  Syslog senders MUST support sending syslog
>    message datagrams to the UDP port 514.
>
> 4.2  Source Port
>
>    Syslog senders can use any source UDP port for transmitting messages.
>    Senders MAY randomly select a source port, but MUST use the port in
>    an exclusive fashion. No concurrent port reuse on the same host is
>    allowed.
>
>    Each syslog sender process MUST attempt to use the same source port
>    for the life of the the process.  If due to an error or other
>    condition it becomes impossible for the process to continue to use
>    the same port, it MAY start using a new source port, but it MUST
>    generate a new random MessageId for the first message after changing
>    the port and then MUST continue incrementing the new MessageId value
>    for subsequent messages.
>
>    Since source port is used to identify parts of a fragmented message,
>    the sender MUST use the same port to send all fragments of a given
>    message.  If due to an error or other condition, the sender is unable
>    to do that, it MUST resend all message fragments using the new port
>    and a new MessageId field value.
>
> 4.3  Source IP Address
>
>    The source IP address of the UDP datagrams is one of the data
>    elements used to identify parts of a fragmented message.  Therefore,
>    a syslog sender MUST attempt to use the same source IP address to
>    send all fragments of a given syslog message.  If due to an error,
>    reconfiguration or other condition it is unable to do so, the sender
>    MUST resend all fragments of the syslog message using the new source
>    IP address and a new MessageId value.
>
> 4.4  UDP/IP Headers
>
>    Each UDP/IP datagram sent by the transport layer MUST completely
>    adhere to the structure specified in the UDP RFC 768 [3] and either
>    IPv4 RFC 791 [4] or IPv6 RFC 2640 [5] depending on which protocol is
>    used.
>
>    Use of UDP checksums was defined as optional in RFC 768 [3]. IPv6 has
>    subsequently made UDP checksums required [5].  However, syslog
>
>
>
> Okmianski               Expires November 5, 2004               [Page 10]
>
> Internet-Draft            syslog udp transport                  May 2004
>
>
>    senders MUST utilize valid UDP checksums when sending messages over
>    either IPv4 or IPv6. Syslog receivers MUST check for checksums and
>    discard messages with incorrect checksums. Note that this is
>    typically accomplished by the UDP layer implementation, and some
>    implementations allow for checksum checks to be enabled or disabled.
>
>    Enabling use of checksums serves as an extra measure of corruption
>    detection in addition to checksums performed by IP and Ethernet
>    layers. None of the above checksums provide a complete guarantee of
>    corruption detection. Utilizing checksums on multiple layers reduces
>    the chance of corruption error not being detected.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Okmianski               Expires November 5, 2004               [Page 11]
>
> Internet-Draft            syslog udp transport                  May 2004
>
>
> 5.  Fragmentation and Reassembley
>
> 5.1  Message Fragmentation
>
>    The syslog transport layer MUST perform fragmentation if syslog
>    message size exceeds the maximum allowed Payload size. Fragmentation
>    SHOULD NOT be used if message can fit into the maximum allowed
>    Payload size.
>
>    Syslog messages SHOULD be fragmented such that all but last message
>    utilize the Payload to its maximum capacity.  For example, when using
>    IPv4, a 700 byte syslog message SHOULD be fragmented into 480 and 220
>    byte parts because the maximum Payload size with IPv4 and extended
>    header is 480 bytes.
>
>    Each message fragment MUST be sent as a separate UDP/IP datagram with
>    an extended syslog transport header.  The sender MUST use the same
>    MessageId value, source port and source IP address for all fragments
>    of a given message. These three field together uniquely identify
>    fragments belonging to a given message.
>
>    On a system with short-lived sender processes, it may be possible
>    that fragments with the same MessageId value, source port and source
>    IP address will get generated in short time proximity.  This can be
>    possible because a new process may re-use the source port that was
>    freed up by another process that just dies.  Such behavior could
>    confuse the receiver if the datagrams were received out of order or
>    some datagrams got lost.
>
>    In order to reduce the risk of such mistaken identity errors, section
>    3.2.1 specified that each process must start with a random value for
>    MessageId field.  Given a relatively large range of MessageId values
>    and the unlikely event of a coincidence of having the same MessageId
>    value combined with re-used source port and UPD errors, the window
>    for potential mistaken identity errors during message reassembley is
>    very small and tolerable. The users take a greater risk by using this
>    protocol due to general UDP reliability issues discussed later in
>    this specification.
>
> 5.2  Message Reassembley
>
>    The reassembley process uses the source IP address from the IP
>    header, the source port from the UDP header and the MessageId field
>    value to identify fragments of a given message. It then uses data
>    from TotalLength and FragmentOffset fields to re-assemble fragments
>    into a complete message.
>
>    Typically, an implementation of fragmentation reassembley involves
>
>
>
> Okmianski               Expires November 5, 2004               [Page 12]
>
> Internet-Draft            syslog udp transport                  May 2004
>
>
>    allocating a buffer for the message when any fragment with a new
>    combination of source IP address, source port and MessageId is
>    received. A timer is used to expire the message reassembley and clean
>    the buffer if all fragments are not received in certain time period.
>    As each fragment is received, it is placed into the buffer at the
>    appropriate offset and a check is performed to determine if all
>    fragments have been received using additional data structures.
>
>    The receiver SHOULD make the timeout interval used for message
>    reassembley configurable for the administrator.  The receiver SHOULD
>    also be able to limit the total amount of memory used for buffers
>    such that it does not run out of resources under a simple denial of
>    service attack involving just one message fragment with a large
>    TotalLength field value. Degrading the service under heavy load or
>    attack is better than crashing and potentially making the service
>    completely unavailable.
>
> 5.3  Avoiding Fragmentation
>
>    Fragmentation and reassembley of messages incurs substantial
>    processing overhead on both the sender and the receiver hosts. It
>    also increases the risk of lost messages due to lose of just one
>    fragment. It is RECOMMENDED that syslog senders which anticipate
>    sending messages over this transport protocol attempt to reduce the
>    number of messages which require fragmentation by restricting them to
>    the size which does not require fragmentation.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Okmianski               Expires November 5, 2004               [Page 13]
>
> Internet-Draft            syslog udp transport                  May 2004
>
>
> 6.  Reliability Considerations
>
>    The UDP is an unreliable low-overhead protocol. This section
>    discusses reliability issues inherent in the UDP that implementers
>    and users must be aware of.
>
> 6.1  Lost Datagrams
>
>    Neither UDP nor syslog protocol provide any mechanism to detect and
>    correct loss of datagrams.  Datagrams may be lost in transit due to
>    congestion, corruption or any other intermittent network problem.
>    Syslog protocol and IP fragmentation exacerbates the problem because
>    loss of a single fragment would result in entire message being
>    discarded.
>
>    In some circumstances the sender may receive an ICMP error message or
>    other indication of a transmission problem. If the sender receives a
>    reasonable indication that some datagram may have been lost, it MAY
>    retransmit previously sent messages.
>
> 6.2  Message Corruption and Checksums
>
>    The UDP/IP datagrams may get corrupted in transit due to software,
>    hardware or network errors. This protocol specified use of UDP
>    checksums to enable corruption detection in addition to checksums
>    utilized in IP and Ethernet layers. However, checksums do not
>    guarantee corruption detection and this protocol does not provide for
>    message retransmission when a corrupt message is detected.
>
> 6.3  Congestion Control
>
>    The UDP does not provide for congestion control. Some systems (hosts
>    or routers) may generate ICMP source quench error, but they are not
>    required to do so [8].  Any network host can discard UDP packets when
>    it is overloaded. Due to lack of congestion control one or multiple
>    syslog senders can maliciously or inadvertently overload the receiver
>    or the network infrastructure and cause loss of syslog messages.
>
> 6.4  Sequenced Delivery
>
>    The IP transport utilized by the UDP does not guarantee that the
>    sequence of datagram delivery will match the order in which the
>    datagrams have been sent. The time stamp contained within each syslog
>    message may serve as some guide in establishing sequence order, but
>    it will not help in cases when multiple messages were generated
>    during the same time slot or when messages originated from different
>    hosts whose clocks are not synchronized. The order of syslog message
>    arrival via the this syslog transport SHOULD NOT be used as an
>
>
>
> Okmianski               Expires November 5, 2004               [Page 14]
>
> Internet-Draft            syslog udp transport                  May 2004
>
>
>    authoritative guide in establishing the sequence of events on the
>    syslog sender hosts.
>
> 6.5  Sender Authentication
>
>    The UDP syslog transport does not strongly associate the message with
>    the message sender.  The receiver of the syslog message will not be
>    able to ascertain that the message was indeed sent from the reported
>    sender, or if the packet was sent from another device.
>
>    One possible consequence of this behavior is that a misconfigured
>    machine may send syslog messages to a receiver representing itself as
>    another machine. The administrators may not be able to readily
>    discern that there are two or more machines representing themselves
>    as the same machine.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Okmianski               Expires November 5, 2004               [Page 15]
>
> Internet-Draft            syslog udp transport                  May 2004
>
>
> 7.  Security Considerations
>
>    Several syslog security considerations have been discussed in
>    RFC-protocol [2] and in the original RFC 3164 [1]. This section
>    focuses on security considerations specific to the syslog transport
>    over UDP.
>
> 7.1  Message Authenticity
>
>    This transport protocol does not strongly authenticate the identity
>    of the message sender and does not provide any assurance that the
>    message was not modified in transit. The receiver of the syslog
>    message will not be able to ascertain that the message was indeed
>    sent from the reported sender, or if the packet was sent from another
>    device.
>
> 7.2  Message Forgery
>
>    Syslog messages can be easily forged. An attacker may transmit syslog
>    messages (either from the machine from which the messages are
>    purportedly sent or from any other machine) to a receiver.
>
>    In one case, an attacker may hide the true nature of an attack amidst
>    many other messages.  As an example, an attacker may start generating
>    forged messages indicating a problem on some machine.  This may get
>    the attention of the system administrators who will spend their time
>    investigating the alleged problem.  During this time, the attacker
>    may be able to compromise a different machine, or a different process
>    on the same machine.
>
>    Additionally, an attacker may generate false syslog messages to give
>    untrue indications of status or of events.  As an example, an
>    attacker may stop a critical process on a machine, which may generate
>    a notification of exit.  The attacker may subsequently generate a
>    forged notification that the process had been restarted.  The system
>    administrators may accept that misinformation and not verify that the
>    process had indeed been restarted.
>
> 7.3  Message Observation
>
>    The transport protocol does not provide confidentiality of the
>    messages in transit. If syslog messages are in clear text, this is
>    how they will be transferred.  In most cases passing clear-text
>    human-readable messages is a benefit to the administrators.
>    Unfortunately, an attacker may also be able to observe the
>    human-readable contents of syslog messages.  The attacker may then
>    use the knowledge gained from those messages to compromise a machine
>    or do other damage. It is RECOMMENDED that no sensitive information
>
>
>
> Okmianski               Expires November 5, 2004               [Page 16]
>
> Internet-Draft            syslog udp transport                  May 2004
>
>
>    is transmitted via this transport protocol or that transmission of
>    such information is restricted to properly secured networks.
>
> 7.4  Replaying
>
>    Message forgery and observation can be combined into a replay attack.
>    An attacker may record a set of messages that indicate normal
>    activity of a machine.  At a later time, that attacker may remove
>    that machine from the network and replay the syslog messages to the
>    collector with new time stamps. The administrators may find nothing
>    unusual in the received messages and their receipt would falsely
>    indicate normal activity of the machine.
>
> 7.5  Unreliable Delivery
>
>    As was previously discussed in the Reliability Considerations
>    section, the UDP transport is not reliable and packets containing
>    syslog message datagrams can be lost in transit without any notice.
>    There can be security consequences to the loss of one or more syslog
>    messages.  Administrators may not become aware of a developing and
>    potentially serious problem. Messages may also be intercepted and
>    discarded by an attacker as a way to hide unauthorized activities.
>
> 7.6  Message Prioritization and Differentiation
>
>    The transport protocol described in this document does not require
>    prioritization of syslog messages on the wire or when processed on
>    the receiving host based on their severity.  The security implication
>    of such behavior is that the syslog receiver or network devices may
>    get overwhelmed with low severity messages and be forced to discard
>    potentially high severity messages. High severity messages may
>    contain indication about serious security problems, but they will not
>    get a higher priority. It is difficult to make sure that high
>    severities messages get higher end-to-end delivery priority,
>    especially over an unreliable UDP transport.
>
>    On a case-by-case basis, device operators may find some way to
>    associate the different severity levels with the quality of service
>    identifiers.  As an example, the operators may elect to define some
>    linkage between syslog messages that have a specific Priority value
>    with a specific value to be used in the IPv4 Precedence field [4],
>    the IPv6 Traffic Class octet [5], or the Differentiated Services
>    field [9].  However, even with this prioritization on the network,
>    high load can lead to buffer starvation on the receiving host and
>    result in dropped messages.
>
>
>
>
>
>
> Okmianski               Expires November 5, 2004               [Page 17]
>
> Internet-Draft            syslog udp transport                  May 2004
>
>
> 7.7  Denial of Service
>
>    An attacker may overwhelm a receiver by sending more messages to it
>    than can be handled by the infrastructure or the device itself.
>    Implementers SHOULD attempt to provide features that minimize this
>    threat such as only receiving syslog messages from known IP
>    addresses.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Okmianski               Expires November 5, 2004               [Page 18]
>
> Internet-Draft            syslog udp transport                  May 2004
>
>
> 8.  IANA Considerations
>
>    IANA must reserve UDP port 514 for this transport.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Okmianski               Expires November 5, 2004               [Page 19]
>
> Internet-Draft            syslog udp transport                  May 2004
>
>
> 9.  Notice to RFC Editor
>
>    This is a notice to the RFC editor. This ID is submitted along with
>    ID draft-ietf-syslog-protocol and they cross-reference each other.
>    When RFC numbers are determined for each of these IDs, please replace
>    all references to "RFC-protocol" with the RFC number of
>    draft-ietf-syslog-protocol ID.  Please remove this section after
>    editing.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Okmianski               Expires November 5, 2004               [Page 20]
>
> Internet-Draft            syslog udp transport                  May 2004
>
>
> 10.  Authors and Working Group Chair
>
>    The working group can be contacted via the mailing list:
>
>    [email-masked]
>
>    The current Chair of the Working Group may be contacted at:
>
>    Chris Lonvick
>    Cisco Systems
>    Email: [email-masked]
>
>    The author of this draft is:
>
>    Anton Okmianski
>    Email: [email-masked]
>
>    Phone: (978) 936-1612
>    Fax: (978) 936-2225
>
>    Cisco Systems, Inc
>    1414 Massachusetts Ave.
>    Boxborough, MA 01719-2205
>    USA
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Okmianski               Expires November 5, 2004               [Page 21]
>
> Internet-Draft            syslog udp transport                  May 2004
>
>
> 11.  Acknowledgements
>
>    The author wishes to thank Chris Lonvick, Rainer Gerhards, David
>    Harrington, Andrew Ross, Albert Mietus, Bernie Volz, and all others
>    who have commented on the various versions of this proposal.
>
> 12  References
>
>    [1]   Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001.
>
>    [2]   Gerhards, R., "The syslog Protocol", RFC RFC-protocol.
>
>    [3]   Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
>          1980.
>
>    [4]   Postel, J., "Internet Protocol", STD 5, RFC 791, September
>          1981.
>
>    [5]   Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
>          Specification", RFC 2460, December 1998.
>
>    [6]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
>          Levels", BCP 14, RFC 2119, March 1997.
>
>    [7]   Crocker, D. and P. Overell, "Augmented BNF for Syntax
>          Specifications: ABNF", RFC 2234, November 1997.
>
>    [8]   Stevens, W., "TCP/IP Illustrated Volume 1. The Protocols.",
>          January 1994.
>
>    [9]   Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of
>          the Differentiated Services Field (DS Field) in the IPv4 and
>          IPv6 Headers", RFC 2474, December 1998.
>
>    [10]  Mockapetris, P., "Domain names - implementation and
>          specification", STD 13, RFC 1035, November 1987.
>
>    [11]  Hedrick, C., "Routing Information Protocol", RFC 1058, June
>          1988.
>
>    [12]  Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
>          March 1997.
>
>    [13]  Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC
>          1350, July 1992.
>
>    [14]  Braden, R., "Requirements for Internet Hosts - Communication
>          Layers", STD 3, RFC 1122, October 1989.
>
>
>
> Okmianski               Expires November 5, 2004               [Page 22]
>
> Internet-Draft            syslog udp transport                  May 2004
>
>
>    [15]  Kent, C. and J. Mogul, ""Fragmentation Considered Harmful,"
>          Computer Communications Review, vol.17, no.5, pp.390-401",
>          August 1987.
>
>
> Author's Address
>
>    Anton Okmianski
>    Cisco Systems, Inc.
>    1414 Massachusetts Ave
>    Boxborough, MA  01719-2205
>    USA
>
>    EMail: [email-masked]
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Okmianski               Expires November 5, 2004               [Page 23]
>
> Internet-Draft            syslog udp transport                  May 2004
>
>
> Appendix A.  Rational For Transport Message Size Restrictions
>
>    This appendix provides the rational behind the Payload size
>    restrictions for this protocol.  The Payload restrictions outlined in
>    the specification, essentially ensure that the transport message size
>    does not exceed 512 bytes (without UDP/IP headers) for transport via
>    IPv4 and does not exceed 1196 bytes for transport via IPv6. These
>    restrictions put an upper boundary on the UDP/IP datagram size for
>    this protocol, which accomplishes two goals.
>
>    First, they insure interoperability between various UDP/IP
>    implementations.  Even though the maximum IP datagram size is
>    specified as 65536 bytes, many UDP/IP implementations have been shown
>    not to work with large datagram sizes [8].  Many established
>    UDP-based protocols restrict UDP datagram data size to 512 bytes. For
>    example, DNS [10] and RIP [11] do that. The DHCPv4 [12] restricts the
>    size to 512 bytes, but allows sides to agree on a larger value
>    through the protocol. The TFTP [13] restricts the UDP data size to
>    518 bytes, which is slightly larger.
>
>    The second reason for datagram size restrictions is that it helps
>    reduce the likelihood of the  IP-layer datagram fragmentation.  This
>    could have potentially resulted in fragmentation on two levels:
>    syslog transport protocol and IP layer. Since fragmentation has
>    significant overhead for message reassembley, it is best to avoid
>    double fragmentation. The likelihood of IP fragmentation can be
>    significantly reduced by sending IP datagrams in sizes which all
>    hosts must be able to process.
>
>    The minimum MTU of a transport protocol determines the minimum size
>    of packets that hosts must be able to accept.  For IPv4, the minimum
>    MTU is 576 bytes [4] and for IPv6 - 1280 bytes [5].  In both cases,
>    the maximum message size we chose fits within the MTU of the
>    transport in all cases except for when extremely large IP headers are
>    used.  IPv4 header can range from 20 to 60 bytes in length and UDP
>    header is fixed at 8 bytes. Thus, our message size restrictions
>    ensure that in all cases except for when the IP header is 56 bytes or
>    greater, the size of the packet will within the size of the transport
>    MTU.
>
>    For IPv6, we have left the same amount of padding for UDP/IP headers
>    as was conventionally done for IPv4 in DNS, RIP and DHCPv4 with an
>    additional padding of extra 20 bytes to accommodate a larger IPv6
>    header. This follows the methodology suggested in the IPv6
>    specification for calculating upper-layer payload limits [5].
>
>    Path MTU discovery can generally be used to discover the MTU of the
>    link.  Unfortunately, using path MTU discovery with UDP is not a
>
>
>
> Okmianski               Expires November 5, 2004               [Page 24]
>
> Internet-Draft            syslog udp transport                  May 2004
>
>
>    reliable option because it depends on routers providing ICMP errors
>    and hosts doing retransmission, which are not done consistently.
>    Implementors MUST follow the size restrictions outlined above and not
>    rely on path MTU discovery.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Okmianski               Expires November 5, 2004               [Page 25]
>
> Internet-Draft            syslog udp transport                  May 2004
>
>
> Intellectual Property Statement
>
>    The IETF takes no position regarding the validity or scope of any
>    intellectual property or other rights that might be claimed to
>    pertain to the implementation or use of the technology described in
>    this document or the extent to which any license under such rights
>    might or might not be available; neither does it represent that it
>    has made any effort to identify any such rights. Information on the
>    IETF's procedures with respect to rights in standards-track and
>    standards-related documentation can be found in BCP-11. Copies of
>    claims of rights made available for publication and any assurances of
>    licenses to be made available, or the result of an attempt made to
>    obtain a general license or permission for the use of such
>    proprietary rights by implementors or users of this specification can
>    be obtained from the IETF Secretariat.
>
>    The IETF invites any interested party to bring to its attention any
>    copyrights, patents or patent applications, or other proprietary
>    rights which may cover technology that may be required to practice
>    this standard. Please address the information to the IETF Executive
>    Director.
>
>
> Full Copyright Statement
>
>    Copyright (C) The Internet Society (2004). All Rights Reserved.
>
>    This document and translations of it may be copied and furnished to
>    others, and derivative works that comment on or otherwise explain it
>    or assist in its implementation may be prepared, copied, published
>    and distributed, in whole or in part, without restriction of any
>    kind, provided that the above copyright notice and this paragraph are
>    included on all such copies and derivative works. However, this
>    document itself may not be modified in any way, such as by removing
>    the copyright notice or references to the Internet Society or other
>    Internet organizations, except as needed for the purpose of
>    developing Internet standards in which case the procedures for
>    copyrights defined in the Internet Standards process must be
>    followed, or as required to translate it into languages other than
>    English.
>
>    The limited permissions granted above are perpetual and will not be
>    revoked by the Internet Society or its successors or assignees.
>
>    This document and the information contained herein is provided on an
>    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
>    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
>    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
>
>
>
> Okmianski               Expires November 5, 2004               [Page 26]
>
> Internet-Draft            syslog udp transport                  May 2004
>
>
>    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
>    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
>
>
> Acknowledgment
>
>    Funding for the RFC Editor function is currently provided by the
>    Internet Society.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Okmianski               Expires November 5, 2004               [Page 27]
>
>

>
>                                                                  [1] TOC
>
>    syslog Working Group      A. Okmianski
>    Internet-Draft            Cisco Systems, Inc.
>    Expires: November 5, 2004 May 7, 2004
>
>                                  Transmission of syslog messages over UDP
>
>                                        draft-ietf-syslog-transport-udp-01
>
>   Status of this Memo
>
>    This document is an Internet-Draft and is in full conformance with all
>    provisions of Section 10 of RFC2026.
>
>    Internet-Drafts are working documents of the Internet Engineering Task
>    Force  (IETF),  its  areas,  and  its  working groups. Note that other
>    groups may also distribute working documents as Internet-Drafts.
>
>    Internet-Drafts  are draft documents valid for a maximum of six months
>    and  may  be updated, replaced, or obsoleted by other documents at any
>    time. It is inappropriate to use Internet-Drafts as reference material
>    or to cite them other than as "work in progress."
>
>    The   list   of   current   Internet-Drafts   can   be   accessed   at
>    [2]http://www.ietf.org/ietf/1id-abstracts.txt.
>
>    The  list  of  Internet-Draft  Shadow  Directories  can be accessed at
>    [3]http://www.ietf.org/shadow.html.
>
>    This Internet-Draft will expire on November 5, 2004.
>
>   Copyright Notice
>
>    Copyright (C) The Internet Society (2004). All Rights Reserved.
>
>   Abstract
>
>    This  document  describes  the  transport  for the syslog message 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 using
>    multiple datagrams.
>      _________________________________________________________________
>
>   Table of Contents
>
>    [4]1.  Introduction
>    [5]2.  Transport Protocol Overview
>        [6]2.1  Definitions and Architecture
>        [7]2.2  Required Transport Protocol
>        [8]2.3  Encapsulation Layers
>    [9]3.  Message Format
>        [10]3.1  Basic Header Format
>        [11]3.2  Extended Header Format
>            [12]3.2.1  Message Identifier
>            [13]3.2.2  Total Length
>            [14]3.2.3  Fragment Offset
>            [15]3.2.4  Extended Header Example
>        [16]3.3  Payload
>        [17]3.4  Supported Message Length
>    [18]4.  UDP/IP Layer Considerations
>        [19]4.1  Target Port
>        [20]4.2  Source Port
>        [21]4.3  Source IP Address
>        [22]4.4  UDP/IP Headers
>    [23]5.  Fragmentation and Reassembley
>        [24]5.1  Message Fragmentation
>        [25]5.2  Message Reassembley
>        [26]5.3  Avoiding Fragmentation
>    [27]6.  Reliability Considerations
>        [28]6.1  Lost Datagrams
>        [29]6.2  Message Corruption and Checksums
>        [30]6.3  Congestion Control
>        [31]6.4  Sequenced Delivery
>        [32]6.5  Sender Authentication
>    [33]7.  Security Considerations
>        [34]7.1  Message Authenticity
>        [35]7.2  Message Forgery
>        [36]7.3  Message Observation
>        [37]7.4  Replaying
>        [38]7.5  Unreliable Delivery
>        [39]7.6  Message Prioritization and Differentiation
>        [40]7.7  Denial of Service
>    [41]8.  IANA Considerations
>    [42]9.  Notice to RFC Editor
>    [43]10.  Authors and Working Group Chair
>    [44]11.  Acknowledgements
>    [45]§.  References
>    [46]§  Author's Address
>    [47]A.  Rational For Transport Message Size Restrictions
>    [48]§  Intellectual Property and Copyright Statements
>      _________________________________________________________________
>
>                                                                 [49] TOC
>
>   1. Introduction
>
>    The  original  syslog  protocol has been described in an informational
>    [50]RFC  3164Lonvick,  C., The BSD Syslog Protocol, August 2001.[1] as
>    it  has  been  observed in existing implementations. It describes both
>    the  semantics  of  syslog  message format as well as a UDP transport.
>    Subsequently,  the  syslog  protocol  has  been  formally defined in a
>    standards  track  [51]RFC-protocolGerhards,  R.,  The syslog Protocol,
>    .[2].
>
>    The  [52]RFC-protocolGerhards,  R.,  The  syslog  Protocol,  .[2]  has
>    provided  for  support  of any number of transport layer protocols for
>    transmitting syslog messages and left it to subsequent RFCs to specify
>    transport  protocols.  This  standards  track  RFC  describes  the UDP
>    transport for the syslog protocol. This transport protocol is REQUIRED
>    for all syslog protocol implementations.
>
>    This   transport   protocol  was  designed  to  work  on  top  of  UDP
>    [53][3]Postel, J., User Datagram Protocol, August 1980. over both IPv4
>    [54][4]Postel,   J.,  Internet  Protocol,  September  1981.  and  IPv6
>    [55][5]Deering,  S. and R. Hinden, Internet Protocol, Version 6 (IPv6)
>    Specification,  December  1998.. This protocol overcomes the data size
>    restrictions  of the UDP protocol by introducing message fragmentation
>    feature.
>
>    As  we  will show in this specification, this protocol has significant
>    reliability and security issues stemming from the use of UDP. However,
>    this  protocol  is lightweight and extends on the existing popular use
>    of  UDP  for  syslog.  Network administrators and architects should be
>    aware of the shortcomings of this protocol and plan accordingly.
>
>    The  key  words  "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD",  "SHOULD  NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>    document  are  to  be interpreted as described in [56]RFC 2119Bradner,
>    S.,  Key  words  for use in RFCs to Indicate Requirement Levels, March
>    1997.[6].  The  words  'byte'  and 'octet' are used interchangeably in
>    this specification.
>      _________________________________________________________________
>
>                                                                 [57] TOC
>
>   2. Transport Protocol Overview
>
>     2.1 Definitions and Architecture
>
>    The following definitions will be used in this document:
>      * An  application that can generate syslog messages will be referred
>        to as a "sender";
>      * An  application  that can receive syslog messages will be referred
>        to as a "receiver".
>
>    An  application  can  function in dual capacity. For example, a syslog
>    relay  may  receive and forward messages. A single system can host any
>    number  of syslog senders. Only one syslog receiver can be hosted on a
>    single system using the standard listening port.
>
>     2.2 Required Transport Protocol
>
>    This  document  describes  the  UDP  transport  layer protocol for the
>    syslog  protocol  [58]RFC-protocolGerhards,  R.,  The syslog Protocol,
>    .[2]. Every syslog sender and receiver implementation which adheres to
>    the [59]RFC-protocolGerhards, R., The syslog Protocol, .[2] MUST fully
>    implement   the   transport   protocol  specified  in  this  document.
>    Implementations  does  not have to support both IPv4 and IPv6 if it is
>    designed to be used over only one of these protocols.
>
>     2.3 Encapsulation Layers
>
>    Syslog  UDP  transport  carries  syslog  messages  as  generic payload
>    encapsulated  with  a  syslog  transport  header, UDP header and an IP
>    header.  Below  is a summary of syslog UDP/IP packet structure as used
>    this transport protocol:
>
>                 +--------------------------------+
>                 |       IPv4 or IPv6 Header      |
>                 |        (20 or more bytes)      |
>                 +--------------------------------+
>                 |           UDP Header           |
>                 |           (8 bytes)            |
>                 +--------------------------------+
>                 |    Syslog Transport Header     |
>                 |        (5 or 32 bytes)         |
>                 +--------------------------------+
>                 |     Syslog Message Payload     |
>                 |       (1 to 1191 bytes)        |
>                 +--------------------------------+
>
>    Small  syslog  messages  are transmitted using one UDP/IP datagram per
>    message.  However,  syslog  protocol  [60][2]Gerhards,  R., The syslog
>    Protocol,  .  allows messages as large as 16777216 bytes, while UDP/IP
>    datagram  cannot exceed a total size of 65526 bytes [61][3]Postel, J.,
>    User  Datagram  Protocol,  August  1980.  and  most existing protocols
>    restrict  the  size  of  UDP  data  to  much less. In order to support
>    transmitting  large  messages  over  UDP/IP,  this  transport protocol
>    supports  fragmentation  of large syslog messages into multiple UDP/IP
>    datagrams for transmission and reassembley on the receiving end.
>
>    Each  syslog  UDP/IP  datagram  MUST contain one and only one complete
>    syslog  message  or  one  fragment of a message. Transmitting multiple
>    messages  or  multiple fragments of different messages in a single UDP
>    datagram is not supported by this protocol.
>      _________________________________________________________________
>
>                                                                 [62] TOC
>
>   3. Message Format
>
>    The  syslog  transport  message  consist  of  a transport header and a
>    syslog  message  payload.  The  format  of  the  transport  header  is
>    different  for fragmented and non-fragmented messages. Basic transport
>    header  is  used  for  non-fragmented  messages and extended transport
>    header is used for fragmented messages.
>
>    An  ASCII-based  encoding  was  chosen  for  the  syslog transport for
>    consistency   with   the   [63]RFC-protocolGerhards,  R.,  The  syslog
>    Protocol, .[2]. Syslog transport datagrams without required UDP and IP
>    headers  have  the  following  format  in  [64]ABNFCrocker,  D. and P.
>    Overell,  Augmented  BNF  for  Syntax  Specifications:  ABNF, November
>    1997.[7] notation:
>
>     SyslogTransportMessage = ( BasicHeader / ExtendedHeader )
>                                       SP Payload
>
>     BasicHeader     = Version SP "0"
>     Version         = %d118 1*3DIGIT   ; "v1" in this version
>
>     ExtendedHeader  = Version SP "1" SP MessageId
>                       SP TotalLength SP FragmentOffset
>
>     MessageId       = 1*8DIGIT        ; 0 to 16777215
>     TotalLength     = 1*8DIGIT        ; 1 to 16777216
>     FragmentOffset  = 1*8DIGIT        ; 0 to 16777215
>     Payload         = 1*1191OCTET
>
>     OCTET           = %d00-255
>     DIGIT           = %d48-57
>     SP              = %d32
>
>
>     3.1 Basic Header Format
>
>    When  no  fragmentation  is  used  and  the  entire  syslog message is
>    transferred  as  a  single  UDP/IP  datagram, a basic syslog transport
>    header  MUST be used. The version for this protocol is "1". It must be
>    followed  by  one  space  and  a  "0" to indicate that this is a basic
>    header.  Therefore,  the  only  possible value for the basic header in
>    this protocol is as follows:
>
>    "v1 0 "
>
>    Example  of  a syslog message without the transport header (message is
>    wrapped for display):
>
>    "v1 888 3 2003-10-11T22:14:15.003Z host.domain.com
>    dns: configuration error"
>
>    Example  of  the  same  message  with the transport header (message is
>    wrapped for display):
>
>    "v1 0 v1 888 4 2003-10-11T22:14:15.003Z host.domain.com
>    dns: configuration error"
>
>     3.2 Extended Header Format
>
>    When  syslog  message  is  fragmented  by  the  sender,  multiple  UDP
>    datagrams  must  be  used  and  each datagram MUST contain an extended
>    syslog  transport  header.  The  version for this protocol is "1". The
>    version field MUST be followed by a single space and a "1" to indicate
>    that  this is an extended header. Thus, an extended header MUST always
>    begin  with "v1 1 ", but MUST also have additional fields which aid in
>    fragmentation.
>
>    The  MessageId,  TotalLength and FragmentOffset fields are used solely
>    for fragmentation of long messages and reassembley. They SHOULD NOT be
>    used for other purposes.
>
>     3.2.1 Message Identifier
>
>    The  MessageId  field  (along  with  the  source  UDP  port and the IP
>    address)  is  used  to  identify  the message such that fragments of a
>    single  syslog  message  can  be  reassembled  by  the receiver into a
>    complete  message.  The MessageId field MUST be a numeric value in the
>    range  of  0  to  16777215.  Leading  zeros MUST not be present in the
>    MessageId field.
>
>    Each syslog sender process MUST choose a random MessageId value within
>    the  supported  range  for  its  first  message.  Subsequent  messages
>    generated  by  the same process MUST each increment the MessageId by 1
>    up  to  16777215  and  then  continue at 0. Using random value for the
>    first  MessageId  helps  reduce the possibility of potential errors in
>    message   reassembley.   Refer   to   discussion   about   [65]message
>    reassembleyMessage Reassembley for more details.
>
>    All  datagrams  which  represent  parts  of  a given fragmented syslog
>    message MUST have the same MessageId value.
>
>     3.2.2 Total Length
>
>    The  TotalLength  field  MUST  be a numeric value in the range of 1 to
>    16777216.  It  MUST  indicate  the length of a complete syslog message
>    before it was fragmented and before it was encapsulated with transport
>    headers.  The  same TotalLength field value MUST be present in all UDP
>    datagrams  which  represent  fragments  of  the  same  syslog message.
>    Leading zeros MUST not be present in the TotalLength field.
>
>    Note  that in IPv4 the "total length" field identifies the length of a
>    single  packet.  In  this  protocol,  the TotalLength field is used to
>    identify  the  total  length  of  a  complete syslog message, which is
>    transmitted  using  multiple  fragments and multiple datagram packets.
>    The  fragment  length is not specified in the transport header because
>    it  can  be inferred from the size of the IP packet containing the UDP
>    datagram.
>
>     3.2.3 Fragment Offset
>
>    The  FragmentOffset field MUST be a numeric value in the range of 0 to
>    16777215. It MUST indicate the byte offset of the fragment data in the
>    complete  syslog  message.  The offset index starts at 0 for the first
>    fragment.  For  example,  if  an 700 byte syslog message is fragmented
>    into  480  and 220 byte parts, the FragmentOffset in the first message
>    will  be  0 and in the second - 480. Note that fragments don't have to
>    be   the  same  size.  Leading  zeros  MUST  not  be  present  in  the
>    FragmentOffset field.
>
>     3.2.4 Extended Header Example
>
>    The  following is an example of a syslog message without the transport
>    header (message is wrapped for display):
>
>    "v1 888 4 2003-10-11T22:14:15.003Z host.domain.com
>    dns: configuration error"
>
>    Suppose  this message had to be fragmented by transport layer into two
>    parts  at  an  arbitrary  point. This would result in two separate UDP
>    datagrams  being sent - one for each fragment. Below is the content of
>    each  of  the  syslog  transport  UDP  messages  with syslog transport
>    headers but without UDP/IP headers:
>
>    "v1 1 45612221 74 0 v1 888 4 2003-10-11T22:14:15.003Z host.dom"
>
>    "v1 1 45612221 74 42 ain.com dns: configuration error"
>
>    In the above example, the leading "v1" is the version of the transport
>    protocol, "1" indicates that this is an extended header (fragmentation
>    in  use),  "45612221" is the MessageId, "74" is the TotalLength of the
>    message,  while  "0"  and  "42"  are FragmentOffset fields. Everything
>    following  the  FragmentOffset  and  a  space is a the Payload of each
>    respective message.
>
>     3.3 Payload
>
>    The  Payload  field  of  the syslog UPD transport message is an entire
>    syslog  message  or  one fragment. The maximum Payload size depends on
>    the IP protocol used and the type header that is used.
>    Maximum Payload size:
>
>    With IPv4 and basic header:    507 bytes
>    With IPv4 and extended header: 480 bytes
>
>    With IPv6 and basic header:    1191 bytes
>    With IPv6 and extended header: 1164 bytes
>
>    The  Payload size restrictions above effectively mean that the largest
>    syslog  message  that  can  be  sent  non-fragmented  is 507 bytes for
>    transport via IPv4 and 1191 bytes for transport via IPv6.
>
>    For  a discussion of the relational behind the above size restrictions
>    please refer to Appendix A.
>
>     3.4 Supported Message Length
>
>    The  maximum  syslog  message length supported by this protocol is the
>    maximum  value  of  the  TotalLength  field,  which is 16777216 bytes.
>    However, not all deployment scenarios for syslog will be on hosts with
>    hardware   capable  of  supporting  the  maximum  length  of  messages
>    supported by this protocol. Additionally, extremely large messages may
>    not be needed in many environments. Therefore, implementations are NOT
>    REQUIRED  to  support  the  maximum  message  length  allowed  by this
>    protocol.
>
>    All implementations MUST support sending and receiving syslog messages
>    up  to  and including 65536 bytes in size (syslog transport and UDP/IP
>    headers  are  extra).  Support  for  larger  messages  is  encouraged.
>    Implementors  SHOULD  clearly state the maximum supported message size
>    in documentation.
>      _________________________________________________________________
>
>                                                                 [66] TOC
>
>   4. UDP/IP Layer Considerations
>
>     4.1 Target Port
>
>    Syslog  receivers MUST support accepting syslog message datagrams on a
>    well-known  UDP  port  514. Syslog senders MUST support sending syslog
>    message datagrams to the UDP port 514.
>
>     4.2 Source Port
>
>    Syslog  senders can use any source UDP port for transmitting messages.
>    Senders MAY randomly select a source port, but MUST use the port in an
>    exclusive  fashion.  No  concurrent  port  reuse  on  the same host is
>    allowed.
>
>    Each  syslog  sender  process MUST attempt to use the same source port
>    for the life of the the process. If due to an error or other condition
>    it  becomes  impossible  for  the  process to continue to use the same
>    port, it MAY start using a new source port, but it MUST generate a new
>    random  MessageId  for  the  first message after changing the port and
>    then MUST continue incrementing the new MessageId value for subsequent
>    messages.
>
>    Since  source  port is used to identify parts of a fragmented message,
>    the  sender  MUST  use  the same port to send all fragments of a given
>    message.  If  due to an error or other condition, the sender is unable
>    to  do  that,  it MUST resend all message fragments using the new port
>    and a new MessageId field value.
>
>     4.3 Source IP Address
>
>    The source IP address of the UDP datagrams is one of the data elements
>    used  to  identify  parts of a fragmented message. Therefore, a syslog
>    sender  MUST  attempt  to  use  the same source IP address to send all
>    fragments   of   a   given   syslog  message.  If  due  to  an  error,
>    reconfiguration  or  other condition it is unable to do so, the sender
>    MUST  resend  all fragments of the syslog message using the new source
>    IP address and a new MessageId value.
>
>     4.4 UDP/IP Headers
>
>    Each  UDP/IP  datagram  sent  by  the  transport layer MUST completely
>    adhere  to  the  structure specified in the UDP [67]RFC 768Postel, J.,
>    User  Datagram  Protocol,  August  1980.[3]  and  either  IPv4 [68]RFC
>    791Postel,  J.,  Internet Protocol, September 1981.[4] or IPv6 [69]RFC
>    2640Deering,  S.  and  R.  Hinden, Internet Protocol, Version 6 (IPv6)
>    Specification, December 1998.[5] depending on which protocol is used.
>
>    Use of UDP checksums was defined as optional in [70]RFC 768Postel, J.,
>    User  Datagram  Protocol,  August 1980.[3]. IPv6 has subsequently made
>    UDP  checksums  required  [71][5]Deering,  S.  and R. Hinden, Internet
>    Protocol,  Version  6  (IPv6)  Specification, December 1998.. However,
>    syslog  senders MUST utilize valid UDP checksums when sending messages
>    over  either  IPv4  or IPv6. Syslog receivers MUST check for checksums
>    and  discard  messages  with  incorrect  checksums.  Note that this is
>    typically  accomplished  by  the  UDP  layer  implementation, and some
>    implementations allow for checksum checks to be enabled or disabled.
>
>    Enabling  use  of  checksums  serves as an extra measure of corruption
>    detection  in  addition  to  checksums  performed  by  IP and Ethernet
>    layers.  None  of  the above checksums provide a complete guarantee of
>    corruption  detection.  Utilizing checksums on multiple layers reduces
>    the chance of corruption error not being detected.
>      _________________________________________________________________
>
>                                                                 [72] TOC
>
>   5. Fragmentation and Reassembley
>
>     5.1 Message Fragmentation
>
>    The  syslog  transport  layer  MUST  perform  fragmentation  if syslog
>    message  size  exceeds the maximum allowed Payload size. Fragmentation
>    SHOULD NOT be used if message can fit into the maximum allowed Payload
>    size.
>
>    Syslog  messages  SHOULD  be fragmented such that all but last message
>    utilize  the  Payload to its maximum capacity. For example, when using
>    IPv4,  a 700 byte syslog message SHOULD be fragmented into 480 and 220
>    byte  parts  because  the  maximum Payload size with IPv4 and extended
>    header is 480 bytes.
>
>    Each  message fragment MUST be sent as a separate UDP/IP datagram with
>    an  extended  syslog  transport  header.  The sender MUST use the same
>    MessageId  value,  source port and source IP address for all fragments
>    of  a  given  message.  These  three  field together uniquely identify
>    fragments belonging to a given message.
>
>    On a system with short-lived sender processes, it may be possible that
>    fragments  with  the  same  MessageId value, source port and source IP
>    address  will  get  generated  in  short  time  proximity. This can be
>    possible  because  a  new  process may re-use the source port that was
>    freed  up  by  another  process  that  just  dies. Such behavior could
>    confuse  the  receiver  if the datagrams were received out of order or
>    some datagrams got lost.
>
>    In  order to reduce the risk of such mistaken identity errors, section
>    3.2.1  specified  that each process must start with a random value for
>    MessageId  field.  Given  a relatively large range of MessageId values
>    and  the  unlikely event of a coincidence of having the same MessageId
>    value combined with re-used source port and UPD errors, the window for
>    potential  mistaken identity errors during message reassembley is very
>    small  and  tolerable.  The  users  take  a greater risk by using this
>    protocol due to general UDP reliability issues discussed later in this
>    specification.
>
>     5.2 Message Reassembley
>
>    The reassembley process uses the source IP address from the IP header,
>    the  source  port from the UDP header and the MessageId field value to
>    identify  fragments  of  a  given  message.  It  then  uses  data from
>    TotalLength  and FragmentOffset fields to re-assemble fragments into a
>    complete message.
>
>    Typically,  an  implementation  of  fragmentation reassembley involves
>    allocating  a  buffer  for  the  message  when any fragment with a new
>    combination  of  source  IP  address,  source  port  and  MessageId is
>    received.  A timer is used to expire the message reassembley and clean
>    the  buffer  if all fragments are not received in certain time period.
>    As  each  fragment  is  received,  it is placed into the buffer at the
>    appropriate  offset  and  a  check  is  performed  to determine if all
>    fragments have been received using additional data structures.
>
>    The  receiver  SHOULD  make  the  timeout  interval  used  for message
>    reassembley  configurable  for  the administrator. The receiver SHOULD
>    also be able to limit the total amount of memory used for buffers such
>    that it does not run out of resources under a simple denial of service
>    attack  involving  just  one message fragment with a large TotalLength
>    field  value.  Degrading  the  service  under  heavy load or attack is
>    better  than  crashing  and  potentially making the service completely
>    unavailable.
>
>     5.3 Avoiding Fragmentation
>
>    Fragmentation   and   reassembley   of   messages  incurs  substantial
>    processing overhead on both the sender and the receiver hosts. It also
>    increases  the risk of lost messages due to lose of just one fragment.
>    It  is  RECOMMENDED  that  syslog  senders  which  anticipate  sending
>    messages  over this transport protocol attempt to reduce the number of
>    messages  which  require fragmentation by restricting them to the size
>    which does not require fragmentation.
>      _________________________________________________________________
>
>                                                                 [73] TOC
>
>   6. Reliability Considerations
>
>    The UDP is an unreliable low-overhead protocol. This section discusses
>    reliability  issues  inherent  in  the UDP that implementers and users
>    must be aware of.
>
>     6.1 Lost Datagrams
>
>    Neither  UDP  nor  syslog protocol provide any mechanism to detect and
>    correct  loss  of  datagrams.  Datagrams may be lost in transit due to
>    congestion,  corruption  or  any  other  intermittent network problem.
>    Syslog  protocol  and IP fragmentation exacerbates the problem because
>    loss  of  a  single  fragment  would  result  in  entire message being
>    discarded.
>
>    In  some circumstances the sender may receive an ICMP error message or
>    other  indication  of a transmission problem. If the sender receives a
>    reasonable  indication  that  some datagram may have been lost, it MAY
>    retransmit previously sent messages.
>
>     6.2 Message Corruption and Checksums
>
>    The  UDP/IP  datagrams  may  get corrupted in transit due to software,
>    hardware  or  network  errors.  This  protocol  specified  use  of UDP
>    checksums  to  enable  corruption  detection  in addition to checksums
>    utilized  in  IP  and  Ethernet  layers.  However,  checksums  do  not
>    guarantee  corruption detection and this protocol does not provide for
>    message retransmission when a corrupt message is detected.
>
>     6.3 Congestion Control
>
>    The  UDP  does not provide for congestion control. Some systems (hosts
>    or  routers)  may  generate ICMP source quench error, but they are not
>    required to do so [74][8]Stevens, W., TCP/IP Illustrated Volume 1. The
>    Protocols.,  January  1994..  Any network host can discard UDP packets
>    when  it  is  overloaded.  Due  to  lack  of congestion control one or
>    multiple  syslog senders can maliciously or inadvertently overload the
>    receiver  or  the  network  infrastructure  and  cause  loss of syslog
>    messages.
>
>     6.4 Sequenced Delivery
>
>    The  IP  transport  utilized  by  the  UDP does not guarantee that the
>    sequence  of  datagram  delivery  will  match  the  order in which the
>    datagrams  have been sent. The time stamp contained within each syslog
>    message may serve as some guide in establishing sequence order, but it
>    will  not  help  in cases when multiple messages were generated during
>    the  same  time  slot or when messages originated from different hosts
>    whose clocks are not synchronized. The order of syslog message arrival
>    via  the  this syslog transport SHOULD NOT be used as an authoritative
>    guide  in  establishing  the  sequence  of events on the syslog sender
>    hosts.
>
>     6.5 Sender Authentication
>
>    The  UDP syslog transport does not strongly associate the message with
>    the  message  sender.  The  receiver of the syslog message will not be
>    able  to  ascertain that the message was indeed sent from the reported
>    sender, or if the packet was sent from another device.
>
>    One  possible  consequence  of  this  behavior is that a misconfigured
>    machine  may send syslog messages to a receiver representing itself as
>    another machine. The administrators may not be able to readily discern
>    that  there  are  two  or more machines representing themselves as the
>    same machine.
>      _________________________________________________________________
>
>                                                                 [75] TOC
>
>   7. Security Considerations
>
>    Several   syslog   security  considerations  have  been  discussed  in
>    [76]RFC-protocolGerhards,  R.,  The  syslog  Protocol, .[2] and in the
>    original  [77]RFC  3164Lonvick,  C.,  The  BSD Syslog Protocol, August
>    2001.[1].  This section focuses on security considerations specific to
>    the syslog transport over UDP.
>
>     7.1 Message Authenticity
>
>    This transport protocol does not strongly authenticate the identity of
>    the message sender and does not provide any assurance that the message
>    was  not  modified in transit. The receiver of the syslog message will
>    not  be  able  to  ascertain that the message was indeed sent from the
>    reported sender, or if the packet was sent from another device.
>
>     7.2 Message Forgery
>
>    Syslog  messages can be easily forged. An attacker may transmit syslog
>    messages  (either  from  the  machine  from  which  the  messages  are
>    purportedly sent or from any other machine) to a receiver.
>
>    In  one case, an attacker may hide the true nature of an attack amidst
>    many  other  messages. As an example, an attacker may start generating
>    forged messages indicating a problem on some machine. This may get the
>    attention  of  the  system  administrators  who  will spend their time
>    investigating  the alleged problem. During this time, the attacker may
>    be  able  to compromise a different machine, or a different process on
>    the same machine.
>
>    Additionally,  an  attacker may generate false syslog messages to give
>    untrue  indications of status or of events. As an example, an attacker
>    may  stop  a  critical  process  on  a  machine,  which may generate a
>    notification  of exit. The attacker may subsequently generate a forged
>    notification   that   the  process  had  been  restarted.  The  system
>    administrators  may accept that misinformation and not verify that the
>    process had indeed been restarted.
>
>     7.3 Message Observation
>
>    The  transport  protocol  does  not  provide  confidentiality  of  the
>    messages in transit. If syslog messages are in clear text, this is how
>    they   will   be   transferred.   In  most  cases  passing  clear-text
>    human-readable   messages   is   a   benefit  to  the  administrators.
>    Unfortunately,   an   attacker   may  also  be  able  to  observe  the
>    human-readable  contents of syslog messages. The attacker may then use
>    the knowledge gained from those messages to compromise a machine or do
>    other  damage.  It  is  RECOMMENDED  that  no sensitive information is
>    transmitted  via  this transport protocol or that transmission of such
>    information is restricted to properly secured networks.
>
>     7.4 Replaying
>
>    Message  forgery and observation can be combined into a replay attack.
>    An attacker may record a set of messages that indicate normal activity
>    of  a  machine. At a later time, that attacker may remove that machine
>    from  the network and replay the syslog messages to the collector with
>    new  time  stamps.  The administrators may find nothing unusual in the
>    received  messages  and  their  receipt  would falsely indicate normal
>    activity of the machine.
>
>     7.5 Unreliable Delivery
>
>    As was previously discussed in the Reliability Considerations section,
>    the  UDP  transport  is  not  reliable  and  packets containing syslog
>    message datagrams can be lost in transit without any notice. There can
>    be  security  consequences to the loss of one or more syslog messages.
>    Administrators  may  not  become aware of a developing and potentially
>    serious  problem. Messages may also be intercepted and discarded by an
>    attacker as a way to hide unauthorized activities.
>
>     7.6 Message Prioritization and Differentiation
>
>    The  transport  protocol  described  in this document does not require
>    prioritization of syslog messages on the wire or when processed on the
>    receiving  host  based  on their severity. The security implication of
>    such  behavior  is that the syslog receiver or network devices may get
>    overwhelmed  with  low  severity  messages  and  be  forced to discard
>    potentially high severity messages. High severity messages may contain
>    indication  about  serious  security problems, but they will not get a
>    higher  priority.  It  is  difficult to make sure that high severities
>    messages  get  higher end-to-end delivery priority, especially over an
>    unreliable UDP transport.
>
>    On  a  case-by-case  basis,  device  operators  may  find  some way to
>    associate  the  different  severity levels with the quality of service
>    identifiers.  As  an  example,  the operators may elect to define some
>    linkage  between  syslog  messages that have a specific Priority value
>    with  a  specific  value  to  be  used  in  the  IPv4 Precedence field
>    [78][4]Postel,  J.,  Internet  Protocol,  September  1981.,  the  IPv6
>    Traffic  Class  octet  [79][5]Deering,  S.  and  R.  Hinden,  Internet
>    Protocol,  Version  6  (IPv6)  Specification,  December  1998., or the
>    Differentiated Services field [80][9]Nichols, K., Blake, S., Baker, F.
>    and  D.  Black,  Definition  of  the Differentiated Services Field (DS
>    Field)  in  the  IPv4  and IPv6 Headers, December 1998.. However, even
>    with  this prioritization on the network, high load can lead to buffer
>    starvation on the receiving host and result in dropped messages.
>
>     7.7 Denial of Service
>
>    An  attacker  may  overwhelm a receiver by sending more messages to it
>    than  can  be  handled  by  the  infrastructure  or the device itself.
>    Implementers  SHOULD  attempt  to  provide features that minimize this
>    threat such as only receiving syslog messages from known IP addresses.
>      _________________________________________________________________
>
>                                                                 [81] TOC
>
>   8. IANA Considerations
>
>    IANA must reserve UDP port 514 for this transport.
>      _________________________________________________________________
>
>                                                                 [82] TOC
>
>   9. Notice to RFC Editor
>
>    This is a notice to the RFC editor. This ID is submitted along with ID
>    draft-ietf-syslog-protocol  and  they cross-reference each other. When
>    RFC  numbers  are determined for each of these IDs, please replace all
>    references    to    "RFC-protocol"    with    the    RFC   number   of
>    draft-ietf-syslog-protocol   ID.  Please  remove  this  section  after
>    editing.
>      _________________________________________________________________
>
>                                                                 [83] TOC
>
>   10. Authors and Working Group Chair
>
>    The working group can be contacted via the mailing list:
> [email-masked]
>
>    The current Chair of the Working Group may be contacted at:
> Chris Lonvick
> Cisco Systems
> Email: [email-masked]
>
>    The author of this draft is:
> Anton Okmianski
> Email: [email-masked]
>
> Phone: (978) 936-1612
> Fax: (978) 936-2225
>
> Cisco Systems, Inc
> 1414 Massachusetts Ave.
> Boxborough, MA 01719-2205
> USA
>      _________________________________________________________________
>
>                                                                 [84] TOC
>
>   11. Acknowledgements
>
>    The  author  wishes  to  thank  Chris  Lonvick, Rainer Gerhards, David
>    Harrington,  Andrew  Ross,  Albert Mietus, Bernie Volz, and all others
>    who have commented on the various versions of this proposal.
>      _________________________________________________________________
>
>                                                                 [85] TOC
>
>   12 References
>
>    [1] Lonvick, C., "[86]The BSD Syslog Protocol", RFC 3164, August 2001.
>    [2] Gerhards, R., "[87]The syslog Protocol", RFC RFC-protocol.
>    [3] Postel, J., "[88]User Datagram Protocol", STD 6, RFC 768, August
>    1980.
>    [4]  Postel,  J.,  "[89]Internet  Protocol", STD 5, RFC 791, September
>    1981.
>    [5] [90]Deering, S. and [91]R. Hinden, "[92]Internet Protocol, Version
>    6 (IPv6) Specification", RFC 2460, December 1998 ([93]HTML, [94]XML).
>    [6]  [95]Bradner,  S.,  "[96]Key  words  for  use  in RFCs to Indicate
>    Requirement Levels", BCP 14, RFC 2119, March 1997 ([97]HTML, [98]XML).
>    [7]  [99]Crocker,  D.  and  [100]P.  Overell,  "[101]Augmented BNF for
>    Syntax Specifications: ABNF", RFC 2234, November 1997.
>    [8]  Stevens,  W.,  "TCP/IP  Illustrated  Volume  1.  The Protocols.",
>    January 1994.
>    [9]  [102]Nichols,  K.,  [103]Blake,  S.,  [104]Baker,  F. and [105]D.
>    Black,  "[106]Definition  of  the  Differentiated  Services  Field (DS
>    Field)  in  the  IPv4  and  IPv6  Headers",  RFC  2474,  December 1998
>    ([107]HTML, [108]XML).
>    [10]   Mockapetris,   P.,  "[109]Domain  names  -  implementation  and
>    specification", STD 13, RFC 1035, November 1987.
>    [11]  Hedrick, C., "[110]Routing Information Protocol", RFC 1058, June
>    1988.
>    [12]  [111]Droms,  R., "[112]Dynamic Host Configuration Protocol", RFC
>    2131, March 1997 ([113]HTML, [114]XML).
>    [13]  [115]Sollins, K., "[116]The TFTP Protocol (Revision 2)", STD 33,
>    RFC 1350, July 1992.
>    [14]   [117]Braden,   R.,  "[118]Requirements  for  Internet  Hosts  -
>    Communication Layers", STD 3, RFC 1122, October 1989.
>    [15]  Kent,  C.  and  J.  Mogul,  ""Fragmentation Considered Harmful,"
>    Computer  Communications  Review,  vol.17,  no.5,  pp.390-401", August
>    1987.
>      _________________________________________________________________
>
>                                                                [119] TOC
>
>   Author's Address
>
>            Anton Okmianski
>            Cisco Systems, Inc.
>            1414 Massachusetts Ave
>            Boxborough, MA 01719-2205
>            USA
>    EMail:  [email-masked]
>      _________________________________________________________________
>
>                                                                [120] TOC
>
>   Appendix A. Rational For Transport Message Size Restrictions
>
>    This   appendix   provides   the  rational  behind  the  Payload  size
>    restrictions  for  this protocol. The Payload restrictions outlined in
>    the  specification, essentially ensure that the transport message size
>    does  not  exceed 512 bytes (without UDP/IP headers) for transport via
>    IPv4  and  does  not  exceed  1196 bytes for transport via IPv6. These
>    restrictions  put  an  upper  boundary on the UDP/IP datagram size for
>    this protocol, which accomplishes two goals.
>
>    First,   they   insure   interoperability   between   various   UDP/IP
>    implementations. Even though the maximum IP datagram size is specified
>    as  65536  bytes,  many  UDP/IP implementations have been shown not to
>    work with large datagram sizes [121][8]Stevens, W., TCP/IP Illustrated
>    Volume  1.  The  Protocols., January 1994.. Many established UDP-based
>    protocols  restrict  UDP datagram data size to 512 bytes. For example,
>    DNS  [122][10]Mockapetris,  P.,  Domain  names  -  implementation  and
>    specification,  November  1987.  and RIP [123][11]Hedrick, C., Routing
>    Information  Protocol,  June 1988. do that. The DHCPv4 [124][12]Droms,
>    R.,  Dynamic  Host  Configuration  Protocol, March 1997. restricts the
>    size to 512 bytes, but allows sides to agree on a larger value through
>    the  protocol.  The  TFTP  [125][13]Sollins,  K.,  The  TFTP  Protocol
>    (Revision  2),  July  1992.  restricts the UDP data size to 518 bytes,
>    which is slightly larger.
>
>    The  second  reason  for  datagram  size restrictions is that it helps
>    reduce  the  likelihood  of  the IP-layer datagram fragmentation. This
>    could have potentially resulted in fragmentation on two levels: syslog
>    transport  protocol  and IP layer. Since fragmentation has significant
>    overhead   for  message  reassembley,  it  is  best  to  avoid  double
>    fragmentation. The likelihood of IP fragmentation can be significantly
>    reduced  by sending IP datagrams in sizes which all hosts must be able
>    to process.
>
>    The minimum MTU of a transport protocol determines the minimum size of
>    packets  that  hosts must be able to accept. For IPv4, the minimum MTU
>    is  576  bytes  [126][4]Postel, J., Internet Protocol, September 1981.
>    and  for IPv6 - 1280 bytes [127][5]Deering, S. and R. Hinden, Internet
>    Protocol,  Version  6  (IPv6)  Specification,  December 1998.. In both
>    cases,  the  maximum  message size we chose fits within the MTU of the
>    transport  in all cases except for when extremely large IP headers are
>    used.  IPv4  header  can  range  from 20 to 60 bytes in length and UDP
>    header is fixed at 8 bytes. Thus, our message size restrictions ensure
>    that  in  all  cases  except  for  when  the  IP header is 56 bytes or
>    greater,  the size of the packet will within the size of the transport
>    MTU.
>
>    For  IPv6,  we have left the same amount of padding for UDP/IP headers
>    as  was  conventionally  done  for IPv4 in DNS, RIP and DHCPv4 with an
>    additional  padding  of  extra  20  bytes to accommodate a larger IPv6
>    header.   This   follows   the   methodology  suggested  in  the  IPv6
>    specification    for    calculating    upper-layer    payload   limits
>    [128][5]Deering, S. and R. Hinden, Internet Protocol, Version 6 (IPv6)
>    Specification, December 1998..
>
>    Path  MTU  discovery  can generally be used to discover the MTU of the
>    link.  Unfortunately,  using  path  MTU  discovery  with  UDP is not a
>    reliable  option  because  it depends on routers providing ICMP errors
>    and  hosts  doing  retransmission,  which  are  not done consistently.
>    Implementors  MUST follow the size restrictions outlined above and not
>    rely on path MTU discovery.
>      _________________________________________________________________
>
>                                                                [129] TOC
>
>   Intellectual Property Statement
>
>    The  IETF  takes  no  position  regarding the validity or scope of any
>    intellectual property or other rights that might be claimed to pertain
>    to  the  implementation  or  use  of  the technology described in this
>    document or the extent to which any license under such rights might or
>    might not be available; neither does it represent that it has made any
>    effort  to  identify  any  such  rights.  Information  on  the  IETF's
>    procedures   with   respect   to   rights   in   standards-track   and
>    standards-related  documentation  can  be  found  in BCP-11. Copies of
>    claims  of rights made available for publication and any assurances of
>    licenses  to  be  made  available, or the result of an attempt made to
>    obtain a general license or permission for the use of such proprietary
>    rights  by implementors or users of this specification can be obtained
>    from the IETF Secretariat.
>
>    The  IETF  invites  any interested party to bring to its attention any
>    copyrights,  patents  or  patent  applications,  or  other proprietary
>    rights  which  may  cover  technology that may be required to practice
>    this  standard.  Please  address the information to the IETF Executive
>    Director.
>
>   Full Copyright Statement
>
>    Copyright (C) The Internet Society (2004). All Rights Reserved.
>
>    This  document  and  translations of it may be copied and furnished to
>    others,  and  derivative works that comment on or otherwise explain it
>    or assist in its implementation may be prepared, copied, published and
>    distributed,  in  whole  or  in part, without restriction of any kind,
>    provided  that  the  above  copyright  notice  and  this paragraph are
>    included  on  all  such  copies  and  derivative  works. However, this
>    document  itself  may  not be modified in any way, such as by removing
>    the  copyright  notice  or references to the Internet Society or other
>    Internet organizations, except as needed for the purpose of developing
>    Internet standards in which case the procedures for copyrights defined
>    in  the Internet Standards process must be followed, or as required to
>    translate it into languages other than English.
>
>    The  limited  permissions  granted above are perpetual and will not be
>    revoked by the Internet Society or its successors or assignees.
>
>    This  document  and the information contained herein is provided on an
>    "AS  IS"  basis  and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
>    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
>    NOT  LIMITED  TO  ANY  WARRANTY THAT THE USE OF THE INFORMATION HEREIN
>    WILL   NOT   INFRINGE   ANY   RIGHTS  OR  ANY  IMPLIED  WARRANTIES  OF
>    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
>
>   Acknowledgment
>
>    Funding  for  the  RFC  Editor  function  is currently provided by the
>    Internet Society.
>
> References
>
>    1. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
>    2. http://www.ietf.org/ietf/1id-abstracts.txt
>    3. http://www.ietf.org/shadow.html
>    4. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#intro
>    5. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#TransportProtocolOverview
>    6. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#DefinitionsAndArchitecture
>    7. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#RequiredTransportProtocol
>    8. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#EncapsulationLayers
>    9. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#MessageFormat
>   10. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#BasicHeaderFormat
>   11. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#ExtendedHeaderFormat
>   12. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#Message Identifier
>   13. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#TotalLength
>   14. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#FragmentOffset
>   15. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#ExtendedHeaderExample
>   16. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#Payload
>   17. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#SupportedMessageLength
>   18. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#LowerLayerConsiderations
>   19. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#TargetPort
>   20. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#SourcePort
>   21. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#SourceIPAddress
>   22. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#UDPIPHeader
>   23. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#FragmentationAndReassembley
>   24. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#MessageFragmentation
>   25. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#MessageReassembley
>   26. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#AvoidingFragmentation
>   27. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#reliability
>   28. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#loss
>   29. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#corruption
>   30. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#overload
>   31. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#sequence
>   32. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#SenderAuthentication
>   33. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#security
>   34. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#SecAuth
>   35. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#SecForg
>   36. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#SecObs
>   37. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#SecReplay
>   38. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#SecRelDel
>   39. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#SecPri
>   40. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#SecDen
>   41. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#iana
>   42. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#rfc-editor
>   43. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#authors
>   44. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#acks
>   45. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#rfc.references1
>   46. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#rfc.authors
>   47. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#AppendixA
>   48. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#rfc.copyright
>   49. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
>   50. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#RFC3164
>   51. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#RFC-protocol
>   52. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#RFC-protocol
>   53. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#RFC0768
>   54. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#RFC0791
>   55. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#RFC2460
>   56. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#RFC2119
>   57. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
>   58. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#RFC-protocol
>   59. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#RFC-protocol
>   60. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#RFC-protocol
>   61. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#RFC0768
>   62. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
>   63. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#RFC-protocol
>   64. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#RFC2234
>   65. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#MessageReassembley
>   66. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
>   67. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#RFC0768
>   68. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#RFC0791
>   69. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#RFC2460
>   70. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#RFC0768
>   71. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#RFC2460
>   72. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
>   73. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
>   74. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#Stevens
>   75. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
>   76. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#RFC-protocol
>   77. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#RFC3164
>   78. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#RFC0791
>   79. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#RFC2460
>   80. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#RFC2474
>   81. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
>   82. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
>   83. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
>   84. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
>   85. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
>   86. ftp://ftp.isi.edu/in-notes/rfc3164.txt
>   87. ftp://ftp.isi.edu/in-notes/rfc3164.txt
>   88. ftp://ftp.isi.edu/in-notes/rfc768.txt
>   89. ftp://ftp.isi.edu/in-notes/rfc791.txt
>   90. mailto:[email-masked]
>   91. mailto:[email-masked]
>   92. ftp://ftp.isi.edu/in-notes/rfc2460.txt
>   93. http://xml.resource.org/public/rfc/html/rfc2460.html
>   94. http://xml.resource.org/public/rfc/xml/rfc2460.xml
>   95. mailto:[email-masked]
>   96. ftp://ftp.isi.edu/in-notes/rfc2119.txt
>   97. http://xml.resource.org/public/rfc/html/rfc2119.html
>   98. http://xml.resource.org/public/rfc/xml/rfc2119.xml
>   99. mailto:[email-masked]
>  100. mailto:[email-masked]
>  101. ftp://ftp.isi.edu/in-notes/rfc2234.txt
>  102. mailto:[email-masked]
>  103. mailto:[email-masked]
>  104. mailto:[email-masked]
>  105. mailto:[email-masked]
>  106. ftp://ftp.isi.edu/in-notes/rfc2474.txt
>  107. http://xml.resource.org/public/rfc/html/rfc2474.html
>  108. http://xml.resource.org/public/rfc/xml/rfc2474.xml
>  109. ftp://ftp.isi.edu/in-notes/rfc1035.txt
>  110. ftp://ftp.isi.edu/in-notes/rfc1058.txt
>  111. mailto:[email-masked]
>  112. ftp://ftp.isi.edu/in-notes/rfc2131.txt
>  113. http://xml.resource.org/public/rfc/html/rfc2131.html
>  114. http://xml.resource.org/public/rfc/xml/rfc2131.xml
>  115. mailto:[email-masked]
>  116. ftp://ftp.isi.edu/in-notes/rfc1350.txt
>  117. mailto:[email-masked]
>  118. ftp://ftp.isi.edu/in-notes/rfc1122.txt
>  119. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
>  120. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
>  121. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#Stevens
>  122. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#RFC1035
>  123. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#RFC1058
>  124. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#RFC2131
>  125. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#RFC1350
>  126. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#RFC0791
>  127. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#RFC2460
>  128. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#RFC2460
>  129. file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc

- -- 
Devin Kowatch
[email-masked]

------------------------------

Date: Mon, 10 May 2004 14:55:59 -0700
From: Devin Kowatch <[email-masked]>
Subject: Re: Transport draft preview

On Mon, May 10, 2004 at 03:26:14PM -0400, Anton Okmianski wrote:
> Devin:
>
> > There is one point which I'm not completely clear on.  What
> > happens to a fragmented message when one ore more parts of
> > that message get dropped?
>
> Just like with IP fragmentation, the whole message (all other
> fragments) gets discarded.  It is mentioned in the Message Reassembly
> section. A couple other sections (Avoiding Fragmentation and Lost
> Datagrams) imply it.  But since you are not the first person to ask
> this, I will make sure to put this more prominently somewhere in the
> draft.
>
> Of course we should not prevent the implementation from logging the
> received fragments of an incomplete message somewhere for debugging.
> So, I am not clear if a putting a MUST is a good idea.

Okay, thanks.
>
> > One other suggestion ... why not just limit UDP packets to
> > 1024 bytes, whith no fragmentation?
>
> With IPv4, transferring UDP datagrams of that size may not be reliable
> to my knowledge (well less reliable than it is UDP usually is :)).
> Most UDP protocols restrict the size to a much smaller size. I don't
> know of popular UDP-based protocols that allow 1024 bytes UDP
> datagrams. If there are some they could serve as sufficient proof that
> this datagram size in UDP is acceptable. See discussion of packets
> sizes in Appendix A of my draft.

I chose 1024 becasue that was the size limit specified in RFC3164
(section 4.1).  Most of the log messages I have seen (under unix) are
less than 300 bytes though.

>
> > For large syslog
> > messages, require a reliable transport layer (TCP) which
> > means you can just properly frame the message and send it (or
> > use something like BEEP which already deals with
> > fragmentation) ...
>
> I am not sure if it is a good idea to require different transport
> depending on a message size.

My biggest argument for doing so, is that it seems eaiser to support
large messages over a reliable transport ... But I see you mostly agree
with that sentiment (last sentence of the next paragraph).

>
> I am also not sure if 1024 bytes is sufficient.  I know one product I
> work on at Cisco which has a crash diagnostic message which consists
> of about 1000-1500 lines.  So, it is about 80-130K. Even bigger than
> the 65K MUST-support size I proposed for udp-transport. I just think
> transferring huge fragmented messages over unreliable transport is not
> a good idea. Hence, larger size are not a requirement, but a
> recommendation.

On the other hand a 1024 byte limit or ever 512 byte limit won't leave
us much worse off than we are with RFC3164, and is sufficient for most
purposes (under unix at least).  Then use a reliable transport to send
larger messages (good encouragement for people to switch too).

>
> As far as using TCP, I am actually thinking more along the lines of
> UDP with acknowledgements (like in TFTP) for a future protocol. It
> would still be lighter and the acknowledgments would be more high
> level. For example, a receiver can acknowledge the message after it
> persisted it to disk instead of like in TCP, where a stack
> acknowledges the message as it is received by the host (and if the
> systems crashes an the message is lost, oh well). Using TCP often
> results in additional higher-level protocol acknowledgements being
> sent.

Ummm... you've heard the saying about thoes who don't understand TCP are
doomed to reimplement it, badly?  Not saying that's the case here ...
just seemed like a good time to rememeber it.

I've looked at this (for my own syslog deamon), and I believe that it's
simpler to build application level ACKS on top of TCP than it is to
build a reliable network protocol on top of UDP.  Also, building on TCP
allows a vastly simpler implementation if the application level ACK is
either skipped or sent back as soon as the message is received, which
isn't a bad thing all the time.  Pushing back the application level ACK
to a point where the message is on disk could be a more advanced
feature (and is more difficult to implement correctly).

>
> I was thinking about putting a MessageId field into every message
> (including basic header) such that adding acknowledgements later would
> not change the format of the message, but I bailed out on that as I
> think this increases scope.  If people think that this may not be a
> bad idea, I can put it in there.
>
> Thanks,
> Anton.
>
>
>
> >
> > On Fri, May 07, 2004 at 04:36:25PM -0400, Anton Okmianski wrote:
> > > Hi!
> > >
> > > I am about to publish the new UDP syslog transport draft. I
> thought
> > > I'd show it this forum first before making it publicly
> > available to a wider audience.  In particular, I want to make
> > sure we have rough consensus on support for fragmentation
> > feature.  I have specified the header format using ASCII
> > encoding as was suggested by Rainer and Andrew.
> > >
> > > I plan on submitting this as an official draft next week.
> > One area I
> > > am not quite sure about yet is what minimum size of messages
> should
> > > implementations be forced to support. It definitely can't
> > be the full
> > > allowed size of 16MB as some hardware won't support it.
> > Right now it
> > > is set at 65k, which means implementations are forced to support
> > > fragmentation.  I wonder if reducing it to the size where
> > > fragmentation would be optional (507 bytes for IPv4 and
> > 1911 for IPv6)
> > > would increase the adoption of the protocol without sacrificing
> too
> > > much of interoperability. Fragmentation feature adds orders of
> > > magnitude more complexity than non-fragmented syslog
> > transport.  Any
> > > opinions?
> > >
> > > Thanks,
> > > Anton.
> >
> > >
> > >
> > >
> > > syslog Working Group
> > A. Okmianski
> > > Internet-Draft                                       Cisco
> > Systems, Inc.
> > > Expires: November 5, 2004
> >  May 7, 2004
> > >
> > >
> > >                 Transmission of syslog messages over UDP
> > >                    draft-ietf-syslog-transport-udp-01
> > >
> > > Status of this Memo
> > >
> > >    This document is an Internet-Draft and is in full
> > conformance with
> > >    all provisions of Section 10 of RFC2026.
> > >
> > >    Internet-Drafts are working documents of the Internet
> Engineering
> > >    Task Force (IETF), its areas, and its working groups.
> > Note that other
> > >    groups may also distribute working documents as
> Internet-Drafts.
> > >
> > >    Internet-Drafts are draft documents valid for a maximum
> > of six months
> > >    and may be updated, replaced, or obsoleted by other
> > documents at any
> > >    time. It is inappropriate to use Internet-Drafts as reference
> > >    material or to cite them other than as "work in progress."
> > >
> > >    The list of current Internet-Drafts can be accessed at http://
> > >    www.ietf.org/ietf/1id-abstracts.txt.
> > >
> > >    The list of Internet-Draft Shadow Directories can be accessed
> at
> > >    http://www.ietf.org/shadow.html.
> > >
> > >    This Internet-Draft will expire on November 5, 2004.
> > >
> > > Copyright Notice
> > >
> > >    Copyright (C) The Internet Society (2004). All Rights Reserved.
> > >
> > > Abstract
> > >
> > >    This document describes the transport for the syslog message
> 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
> using
> > >    multiple datagrams.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Okmianski               Expires November 5, 2004
> >     [Page 1]
> > > >
> > > Internet-Draft            syslog udp transport
> >     May 2004
> > >
> > >
> > > Table of Contents
> > >
> > >    1.  Introduction . . . . . . . . . . . . . . . . . . . .
> > . . . . .  3
> > >    2.  Transport Protocol Overview  . . . . . . . . . . . .
> > . . . . .  4
> > >      2.1   Definitions and Architecture . . . . . . . . . .
> > . . . . .  4
> > >      2.2   Required Transport Protocol  . . . . . . . . . .
> > . . . . .  4
> > >      2.3   Encapsulation Layers . . . . . . . . . . . . . .
> > . . . . .  4
> > >    3.  Message Format . . . . . . . . . . . . . . . . . . .
> > . . . . .  6
> > >      3.1   Basic Header Format  . . . . . . . . . . . . . .
> > . . . . .  6
> > >      3.2   Extended Header Format . . . . . . . . . . . . .
> > . . . . .  7
> > >        3.2.1   Message Identifier . . . . . . . . . . . . .
> > . . . . .  7
> > >        3.2.2   Total Length . . . . . . . . . . . . . . . .
> > . . . . .  7
> > >        3.2.3   Fragment Offset  . . . . . . . . . . . . . .
> > . . . . .  8
> > >        3.2.4   Extended Header Example  . . . . . . . . . .
> > . . . . .  8
> > >      3.3   Payload  . . . . . . . . . . . . . . . . . . . .
> > . . . . .  9
> > >      3.4   Supported Message Length . . . . . . . . . . . .
> > . . . . .  9
> > >    4.  UDP/IP Layer Considerations  . . . . . . . . . . . .
> > . . . . . 10
> > >      4.1   Target Port  . . . . . . . . . . . . . . . . . .
> > . . . . . 10
> > >      4.2   Source Port  . . . . . . . . . . . . . . . . . .
> > . . . . . 10
> > >      4.3   Source IP Address  . . . . . . . . . . . . . . .
> > . . . . . 10
> > >      4.4   UDP/IP Headers . . . . . . . . . . . . . . . . .
> > . . . . . 10
> > >    5.  Fragmentation and Reassembley  . . . . . . . . . . .
> > . . . . . 12
> > >      5.1   Message Fragmentation  . . . . . . . . . . . . .
> > . . . . . 12
> > >      5.2   Message Reassembley  . . . . . . . . . . . . . .
> > . . . . . 12
> > >      5.3   Avoiding Fragmentation . . . . . . . . . . . . .
> > . . . . . 13
> > >    6.  Reliability Considerations . . . . . . . . . . . . .
> > . . . . . 14
> > >      6.1   Lost Datagrams . . . . . . . . . . . . . . . . .
> > . . . . . 14
> > >      6.2   Message Corruption and Checksums . . . . . . . .
> > . . . . . 14
> > >      6.3   Congestion Control . . . . . . . . . . . . . . .
> > . . . . . 14
> > >      6.4   Sequenced Delivery . . . . . . . . . . . . . . .
> > . . . . . 14
> > >      6.5   Sender Authentication  . . . . . . . . . . . . .
> > . . . . . 15
> > >    7.  Security Considerations  . . . . . . . . . . . . . .
> > . . . . . 16
> > >      7.1   Message Authenticity . . . . . . . . . . . . . .
> > . . . . . 16
> > >      7.2   Message Forgery  . . . . . . . . . . . . . . . .
> > . . . . . 16
> > >      7.3   Message Observation  . . . . . . . . . . . . . .
> > . . . . . 16
> > >      7.4   Replaying  . . . . . . . . . . . . . . . . . . .
> > . . . . . 17
> > >      7.5   Unreliable Delivery  . . . . . . . . . . . . . .
> > . . . . . 17
> > >      7.6   Message Prioritization and Differentiation . . .
> > . . . . . 17
> > >      7.7   Denial of Service  . . . . . . . . . . . . . . .
> > . . . . . 18
> > >    8.  IANA Considerations  . . . . . . . . . . . . . . . .
> > . . . . . 19
> > >    9.  Notice to RFC Editor . . . . . . . . . . . . . . . .
> > . . . . . 20
> > >    10.   Authors and Working Group Chair  . . . . . . . . .
> > . . . . . 21
> > >    11.   Acknowledgements . . . . . . . . . . . . . . . . .
> > . . . . . 22
> > >    12.   References . . . . . . . . . . . . . . . . . . . .
> > . . . . . 22
> > >        Author's Address . . . . . . . . . . . . . . . . . .
> > . . . . . 23
> > >    A.  Rational For Transport Message Size Restrictions . .
> > . . . . . 24
> > >        Intellectual Property and Copyright Statements . . .
> > . . . . .
> > > 26
> > >
> > >
> > >
> > >
> > > Okmianski               Expires November 5, 2004
> >     [Page 2]
> > > >
> > > Internet-Draft            syslog udp transport
> >     May 2004
> > >
> > >
> > > 1.  Introduction
> > >
> > >    The original syslog protocol has been described in an
> > informational
> > >    RFC 3164 [1] as it has been observed in existing
> > implementations. It
> > >    describes both the semantics of syslog message format as
> > well as a
> > >    UDP transport.  Subsequently, the syslog protocol has
> > been formally
> > >    defined in a standards track RFC-protocol [2].
> > >
> > >    The RFC-protocol [2] has provided for support of any number of
> > >    transport layer protocols for transmitting syslog
> > messages and left
> > >    it to subsequent RFCs to specify transport protocols.
> > This standards
> > >    track RFC describes the UDP transport for the syslog
> > protocol. This
> > >    transport protocol is REQUIRED for all syslog protocol
> > >    implementations.
> > >
> > >    This transport protocol was designed to work on top of
> > UDP [3] over
> > >    both IPv4 [4] and IPv6 [5]. This protocol overcomes the data
> size
> > >    restrictions of the UDP protocol by introducing message
> > fragmentation
> > >    feature.
> > >
> > >    As we will show in this specification, this protocol has
> > significant
> > >    reliability and security issues stemming from the use of UDP.
> > >    However, this protocol is lightweight and extends on the
> existing
> > >    popular use of UDP for syslog. Network administrators
> > and architects
> > >    should be aware of the shortcomings of this protocol and plan
> > >    accordingly.
> > >
> > >    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
> > "SHALL NOT",
> > >    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
> > "OPTIONAL" in this
> > >    document are to be interpreted as described in RFC 2119 [6].
> The
> > >    words 'byte' and 'octet' are used interchangeably in this
> > >    specification.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Okmianski               Expires November 5, 2004
> >     [Page 3]
> > > >
> > > Internet-Draft            syslog udp transport
> >     May 2004
> > >
> > >
> > > 2.  Transport Protocol Overview
> > >
> > > 2.1  Definitions and Architecture
> > >
> > >    The following definitions will be used in this document:
> > >    o  An application that can generate syslog messages will
> > be referred
> > >       to as a "sender";
> > >    o  An application that can receive syslog messages will
> > be referred
> > >       to as a "receiver".
> > >
> > >    An application can function in dual capacity. For
> > example, a syslog
> > >    relay may receive and forward messages. A single system
> > can host any
> > >    number of syslog senders. Only one syslog receiver can
> > be hosted on a
> > >    single system using the standard listening port.
> > >
> > > 2.2  Required Transport Protocol
> > >
> > >    This document describes the UDP transport layer protocol for
> the
> > >    syslog protocol RFC-protocol [2]. Every syslog sender
> > and receiver
> > >    implementation which adheres to the RFC-protocol [2] MUST fully
> > >    implement the transport protocol specified in this document.
> > >    Implementations does not have to support both IPv4 and
> > IPv6 if it is
> > >    designed to be used over only one of these protocols.
> > >
> > > 2.3  Encapsulation Layers
> > >
> > >    Syslog UDP transport carries syslog messages as generic payload
> > >    encapsulated with a syslog transport header, UDP header and an
> IP
> > >    header. Below is a summary of syslog UDP/IP packet
> > structure as used
> > >    this transport protocol:
> > >
> > >
> > >    		+--------------------------------+
> > >    		|       IPv4 or IPv6 Header      |
> > >    		|        (20 or more bytes)      |
> > >    		+--------------------------------+
> > >    		|           UDP Header           |
> > >    		|           (8 bytes)            |
> > >    		+--------------------------------+
> > >    		|    Syslog Transport Header     |
> > >    		|        (5 or 32 bytes)         |
> > >    		+--------------------------------+
> > >    		|     Syslog Message Payload     |
> > >    		|       (1 to 1191 bytes)        |
> > >    		+--------------------------------+
> > >
> > >    Small syslog messages are transmitted using one UDP/IP
> > datagram per
> > >    message. However, syslog protocol [2] allows messages as large
> as
> > >
> > >
> > >
> > > Okmianski               Expires November 5, 2004
> >     [Page 4]
> > > >
> > > Internet-Draft            syslog udp transport
> >     May 2004
> > >
> > >
> > >    16777216 bytes, while UDP/IP datagram cannot exceed a
> > total size of
> > >    65526 bytes [3] and most existing protocols restrict the
> > size of UDP
> > >    data to much less. In order to support transmitting
> > large messages
> > >    over UDP/IP, this transport protocol supports
> > fragmentation of large
> > >    syslog messages into multiple UDP/IP datagrams for
> > transmission and
> > >    reassembley on the receiving end.
> > >
> > >    Each syslog UDP/IP datagram MUST contain one and only
> > one complete
> > >    syslog message or one fragment of a message.
> > Transmitting multiple
> > >    messages or multiple fragments of different messages in
> > a single UDP
> > >    datagram is not supported by this protocol.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Okmianski               Expires November 5, 2004
> >     [Page 5]
> > > >
> > > Internet-Draft            syslog udp transport
> >     May 2004
> > >
> > >
> > > 3.  Message Format
> > >
> > >    The syslog transport message consist of a transport header and
> a
> > >    syslog message payload. The format of the transport header is
> > >    different for fragmented and non-fragmented messages.  Basic
> > >    transport header is used for non-fragmented messages and
> extended
> > >    transport header is used for fragmented messages.
> > >
> > >    An ASCII-based encoding was chosen for the syslog transport for
> > >    consistency with the RFC-protocol [2].  Syslog transport
> > datagrams
> > >    without required UDP and IP headers have the following
> > format in ABNF
> > >    [7] notation:
> > >
> > >
> > >        SyslogTransportMessage = ( BasicHeader / ExtendedHeader )
> > >                                          SP Payload
> > >
> > >        BasicHeader     = Version SP "0"
> > >        Version         = %d118 1*3DIGIT   ; "v1" in this version
> > >
> > >        ExtendedHeader  = Version SP "1" SP MessageId
> > >                          SP TotalLength SP FragmentOffset
> > >
> > >        MessageId       = 1*8DIGIT        ; 0 to 16777215
> > >        TotalLength     = 1*8DIGIT        ; 1 to 16777216
> > >        FragmentOffset  = 1*8DIGIT        ; 0 to 16777215
> > >        Payload         = 1*1191OCTET
> > >
> > >        OCTET           = %d00-255
> > >        DIGIT           = %d48-57
> > >        SP              = %d32
> > >
> > >
> > > 3.1  Basic Header Format
> > >
> > >    When no fragmentation is used and the entire syslog message is
> > >    transferred as a single UDP/IP datagram, a basic syslog
> transport
> > >    header MUST be used.  The version for this protocol is
> > "1". It must
> > >    be followed by one space and a "0" to indicate that this
> > is a basic
> > >    header.   Therefore, the only possible value for the
> > basic header in
> > >    this protocol is as follows:
> > >
> > >
> > >       "v1 0 "
> > >
> > >    Example of a syslog message without the transport header
> > (message is
> > >    wrapped for display):
> > >
> > >
> > >
> > >
> > > Okmianski               Expires November 5, 2004
> >     [Page 6]
> > > >
> > > Internet-Draft            syslog udp transport
> >     May 2004
> > >
> > >
> > >       "v1 888 3 2003-10-11T22:14:15.003Z host.domain.com
> > >       dns: configuration error"
> > >
> > >    Example of the same message with the transport header (message
> is
> > >    wrapped for display):
> > >
> > >
> > >       "v1 0 v1 888 4 2003-10-11T22:14:15.003Z host.domain.com
> > >       dns: configuration error"
> > >
> > >
> > > 3.2  Extended Header Format
> > >
> > >    When syslog message is fragmented by the sender, multiple UDP
> > >    datagrams must be used and each datagram MUST contain an
> extended
> > >    syslog transport header. The version for this protocol
> > is "1". The
> > >    version field MUST be followed by a single space and a "1" to
> > >    indicate that this is an extended header.  Thus, an
> > extended header
> > >    MUST always begin with "v1 1 ", but MUST also have
> > additional fields
> > >    which aid in fragmentation.
> > >
> > >    The MessageId, TotalLength and FragmentOffset fields are
> > used solely
> > >    for fragmentation of long messages and reassembley.
> > They SHOULD NOT
> > >    be used for other purposes.
> > >
> > > 3.2.1  Message Identifier
> > >
> > >    The MessageId field (along with the source UDP port and the IP
> > >    address) is used to identify the message such that fragments of
> a
> > >    single syslog message can be reassembled by the receiver into a
> > >    complete message.  The MessageId field MUST be a numeric
> > value in the
> > >    range of 0 to 16777215.  Leading zeros MUST not be present in
> the
> > >    MessageId field.
> > >
> > >    Each syslog sender process MUST choose a random MessageId value
> > >    within the supported range for its first message.
> > Subsequent messages
> > >    generated by the same process MUST each increment the
> > MessageId by 1
> > >    up to 16777215 and then continue at 0. Using random value for
> the
> > >    first MessageId helps reduce the possibility of
> > potential errors in
> > >    message reassembley. Refer to discussion about message
> > reassembley
> > >    (Section 5.2) for more details.
> > >
> > >    All datagrams which represent parts of a given fragmented
> syslog
> > >    message MUST have the same MessageId value.
> > >
> > > 3.2.2  Total Length
> > >
> > >    The TotalLength field MUST be a numeric value in the
> > range of 1 to
> > >
> > >
> > >
> > > Okmianski               Expires November 5, 2004
> >     [Page 7]
> > > >
> > > Internet-Draft            syslog udp transport
> >     May 2004
> > >
> > >
> > >    16777216. It MUST indicate the length of a complete
> > syslog message
> > >    before it was fragmented and before it was encapsulated with
> > >    transport headers.  The same TotalLength field value
> > MUST be present
> > >    in all UDP datagrams which represent fragments of the same
> syslog
> > >    message. Leading zeros MUST not be present in the TotalLength
> > > field.
> > >
> > >    Note that in IPv4 the "total length" field identifies
> > the length of a
> > >    single packet.  In this protocol, the TotalLength field
> > is used to
> > >    identify the total length of a complete syslog message, which
> is
> > >    transmitted using multiple fragments and multiple
> > datagram packets.
> > >    The fragment length is not specified in the transport
> > header because
> > >    it can be inferred from the size of the IP packet
> > containing the UDP
> > >    datagram.
> > >
> > > 3.2.3  Fragment Offset
> > >
> > >    The FragmentOffset field MUST be a numeric value in the
> > range of 0 to
> > >    16777215. It MUST indicate the byte offset of the
> > fragment data in
> > >    the complete syslog message. The offset index starts at 0 for
> the
> > >    first fragment. For example, if an 700 byte syslog message is
> > >    fragmented into 480 and 220 byte parts, the FragmentOffset in
> the
> > >    first message will be 0 and in the second - 480. Note
> > that fragments
> > >    don't have to be the same size.  Leading zeros MUST not
> > be present in
> > >    the FragmentOffset field.
> > >
> > > 3.2.4  Extended Header Example
> > >
> > >    The following is an example of a syslog message without
> > the transport
> > >    header (message is wrapped for display):
> > >
> > >
> > >       "v1 888 4 2003-10-11T22:14:15.003Z host.domain.com
> > >       dns: configuration error"
> > >
> > >    Suppose this message had to be fragmented by transport
> > layer into two
> > >    parts at an arbitrary point.  This would result in two
> > separate UDP
> > >    datagrams being sent - one for each fragment. Below is
> > the content of
> > >    each of the syslog transport UDP messages with syslog transport
> > >    headers but without UDP/IP headers:
> > >
> > >
> > >       "v1 1 45612221 74 0 v1 888 4 2003-10-11T22:14:15.003Z
> > host.dom"
> > >
> > >       "v1 1 45612221 74 42 ain.com dns: configuration error"
> > >
> > >    In the above example, the leading "v1" is the version of the
> > >    transport protocol, "1" indicates that this is an extended
> header
> > >    (fragmentation in use), "45612221" is the MessageId, "74" is
> the
> > >
> > >
> > >
> > > Okmianski               Expires November 5, 2004
> >     [Page 8]
> > > >
> > > Internet-Draft            syslog udp transport
> >     May 2004
> > >
> > >
> > >    TotalLength of the message, while "0" and "42" are
> FragmentOffset
> > >    fields. Everything following the FragmentOffset and a
> > space is a the
> > >    Payload of each respective message.
> > >
> > > 3.3  Payload
> > >
> > >    The Payload field of the syslog UPD transport message is
> > an entire
> > >    syslog message or one fragment. The maximum Payload size
> > depends on
> > >    the IP protocol used and the type header that is used.
> > >
> > >       Maximum Payload size:
> > >
> > >       With IPv4 and basic header:    507 bytes
> > >       With IPv4 and extended header: 480 bytes
> > >
> > >       With IPv6 and basic header:    1191 bytes
> > >       With IPv6 and extended header: 1164 bytes
> > >
> > >    The Payload size restrictions above effectively mean
> > that the largest
> > >    syslog message that can be sent non-fragmented is 507 bytes for
> > >    transport via IPv4 and 1191 bytes for transport via IPv6.
> > >
> > >    For a discussion of the relational behind the above size
> > restrictions
> > >    please refer to Appendix A.
> > >
> > > 3.4  Supported Message Length
> > >
> > >    The maximum syslog message length supported by this
> > protocol is the
> > >    maximum value of the TotalLength field, which is 16777216
> bytes.
> > >    However, not all deployment scenarios for syslog will be on
> hosts
> > >    with hardware capable of supporting the maximum length
> > of messages
> > >    supported by this protocol. Additionally, extremely
> > large messages
> > >    may not be needed in many environments. Therefore,
> > implementations
> > >    are NOT REQUIRED to support the maximum message length allowed
> by
> > >    this protocol.
> > >
> > >    All implementations MUST support sending and receiving syslog
> > >    messages up to and including 65536 bytes in size (syslog
> > transport
> > >    and UDP/IP headers are extra). Support for larger messages is
> > >    encouraged. Implementors SHOULD clearly state the
> > maximum supported
> > >    message size in documentation.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Okmianski               Expires November 5, 2004
> >     [Page 9]
> > > >
> > > Internet-Draft            syslog udp transport
> >     May 2004
> > >
> > >
> > > 4.  UDP/IP Layer Considerations
> > >
> > > 4.1  Target Port
> > >
> > >    Syslog receivers MUST support accepting syslog message
> > datagrams on a
> > >    well-known UDP port 514.  Syslog senders MUST support
> > sending syslog
> > >    message datagrams to the UDP port 514.
> > >
> > > 4.2  Source Port
> > >
> > >    Syslog senders can use any source UDP port for
> > transmitting messages.
> > >    Senders MAY randomly select a source port, but MUST use
> > the port in
> > >    an exclusive fashion. No concurrent port reuse on the
> > same host is
> > >    allowed.
> > >
> > >    Each syslog sender process MUST attempt to use the same
> > source port
> > >    for the life of the the process.  If due to an error or other
> > >    condition it becomes impossible for the process to
> > continue to use
> > >    the same port, it MAY start using a new source port, but it
> MUST
> > >    generate a new random MessageId for the first message
> > after changing
> > >    the port and then MUST continue incrementing the new
> > MessageId value
> > >    for subsequent messages.
> > >
> > >    Since source port is used to identify parts of a
> > fragmented message,
> > >    the sender MUST use the same port to send all fragments
> > of a given
> > >    message.  If due to an error or other condition, the
> > sender is unable
> > >    to do that, it MUST resend all message fragments using
> > the new port
> > >    and a new MessageId field value.
> > >
> > > 4.3  Source IP Address
> > >
> > >    The source IP address of the UDP datagrams is one of the data
> > >    elements used to identify parts of a fragmented message.
> >  Therefore,
> > >    a syslog sender MUST attempt to use the same source IP address
> to
> > >    send all fragments of a given syslog message.  If due to
> > an error,
> > >    reconfiguration or other condition it is unable to do
> > so, the sender
> > >    MUST resend all fragments of the syslog message using
> > the new source
> > >    IP address and a new MessageId value.
> > >
> > > 4.4  UDP/IP Headers
> > >
> > >    Each UDP/IP datagram sent by the transport layer MUST
> completely
> > >    adhere to the structure specified in the UDP RFC 768 [3]
> > and either
> > >    IPv4 RFC 791 [4] or IPv6 RFC 2640 [5] depending on which
> > protocol is
> > >    used.
> > >
> > >    Use of UDP checksums was defined as optional in RFC 768
> > [3]. IPv6 has
> > >    subsequently made UDP checksums required [5].  However, syslog
> > >
> > >
> > >
> > > Okmianski               Expires November 5, 2004
> >    [Page 10]
> > > >
> > > Internet-Draft            syslog udp transport
> >     May 2004
> > >
> > >
> > >    senders MUST utilize valid UDP checksums when sending
> > messages over
> > >    either IPv4 or IPv6. Syslog receivers MUST check for
> > checksums and
> > >    discard messages with incorrect checksums. Note that this is
> > >    typically accomplished by the UDP layer implementation, and
> some
> > >    implementations allow for checksum checks to be enabled or
> > > disabled.
> > >
> > >    Enabling use of checksums serves as an extra measure of
> > corruption
> > >    detection in addition to checksums performed by IP and Ethernet
> > >    layers. None of the above checksums provide a complete
> > guarantee of
> > >    corruption detection. Utilizing checksums on multiple
> > layers reduces
> > >    the chance of corruption error not being detected.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Okmianski               Expires November 5, 2004
> >    [Page 11]
> > > >
> > > Internet-Draft            syslog udp transport
> >     May 2004
> > >
> > >
> > > 5.  Fragmentation and Reassembley
> > >
> > > 5.1  Message Fragmentation
> > >
> > >    The syslog transport layer MUST perform fragmentation if syslog
> > >    message size exceeds the maximum allowed Payload size.
> > Fragmentation
> > >    SHOULD NOT be used if message can fit into the maximum allowed
> > >    Payload size.
> > >
> > >    Syslog messages SHOULD be fragmented such that all but
> > last message
> > >    utilize the Payload to its maximum capacity.  For
> > example, when using
> > >    IPv4, a 700 byte syslog message SHOULD be fragmented
> > into 480 and 220
> > >    byte parts because the maximum Payload size with IPv4
> > and extended
> > >    header is 480 bytes.
> > >
> > >    Each message fragment MUST be sent as a separate UDP/IP
> > datagram with
> > >    an extended syslog transport header.  The sender MUST
> > use the same
> > >    MessageId value, source port and source IP address for
> > all fragments
> > >    of a given message. These three field together uniquely
> identify
> > >    fragments belonging to a given message.
> > >
> > >    On a system with short-lived sender processes, it may be
> possible
> > >    that fragments with the same MessageId value, source
> > port and source
> > >    IP address will get generated in short time proximity.
> > This can be
> > >    possible because a new process may re-use the source
> > port that was
> > >    freed up by another process that just dies.  Such behavior
> could
> > >    confuse the receiver if the datagrams were received out
> > of order or
> > >    some datagrams got lost.
> > >
> > >    In order to reduce the risk of such mistaken identity
> > errors, section
> > >    3.2.1 specified that each process must start with a
> > random value for
> > >    MessageId field.  Given a relatively large range of
> > MessageId values
> > >    and the unlikely event of a coincidence of having the
> > same MessageId
> > >    value combined with re-used source port and UPD errors,
> > the window
> > >    for potential mistaken identity errors during message
> > reassembley is
> > >    very small and tolerable. The users take a greater risk
> > by using this
> > >    protocol due to general UDP reliability issues discussed later
> in
> > >    this specification.
> > >
> > > 5.2  Message Reassembley
> > >
> > >    The reassembley process uses the source IP address from the IP
> > >    header, the source port from the UDP header and the
> > MessageId field
> > >    value to identify fragments of a given message. It then uses
> data
> > >    from TotalLength and FragmentOffset fields to
> > re-assemble fragments
> > >    into a complete message.
> > >
> > >    Typically, an implementation of fragmentation
> > reassembley involves
> > >
> > >
> > >
> > > Okmianski               Expires November 5, 2004
> >    [Page 12]
> > > >
> > > Internet-Draft            syslog udp transport
> >     May 2004
> > >
> > >
> > >    allocating a buffer for the message when any fragment with a
> new
> > >    combination of source IP address, source port and MessageId is
> > >    received. A timer is used to expire the message
> > reassembley and clean
> > >    the buffer if all fragments are not received in certain
> > time period.
> > >    As each fragment is received, it is placed into the buffer at
> the
> > >    appropriate offset and a check is performed to determine if all
> > >    fragments have been received using additional data structures.
> > >
> > >    The receiver SHOULD make the timeout interval used for message
> > >    reassembley configurable for the administrator.  The
> > receiver SHOULD
> > >    also be able to limit the total amount of memory used for
> buffers
> > >    such that it does not run out of resources under a
> > simple denial of
> > >    service attack involving just one message fragment with a large
> > >    TotalLength field value. Degrading the service under
> > heavy load or
> > >    attack is better than crashing and potentially making the
> service
> > >    completely unavailable.
> > >
> > > 5.3  Avoiding Fragmentation
> > >
> > >    Fragmentation and reassembley of messages incurs substantial
> > >    processing overhead on both the sender and the receiver hosts.
> It
> > >    also increases the risk of lost messages due to lose of just
> one
> > >    fragment. It is RECOMMENDED that syslog senders which
> anticipate
> > >    sending messages over this transport protocol attempt to
> > reduce the
> > >    number of messages which require fragmentation by
> > restricting them to
> > >    the size which does not require fragmentation.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Okmianski               Expires November 5, 2004
> >    [Page 13]
> > > >
> > > Internet-Draft            syslog udp transport
> >     May 2004
> > >
> > >
> > > 6.  Reliability Considerations
> > >
> > >    The UDP is an unreliable low-overhead protocol. This section
> > >    discusses reliability issues inherent in the UDP that
> > implementers
> > >    and users must be aware of.
> > >
> > > 6.1  Lost Datagrams
> > >
> > >    Neither UDP nor syslog protocol provide any mechanism to
> > detect and
> > >    correct loss of datagrams.  Datagrams may be lost in
> > transit due to
> > >    congestion, corruption or any other intermittent network
> problem.
> > >    Syslog protocol and IP fragmentation exacerbates the
> > problem because
> > >    loss of a single fragment would result in entire message being
> > >    discarded.
> > >
> > >    In some circumstances the sender may receive an ICMP
> > error message or
> > >    other indication of a transmission problem. If the
> > sender receives a
> > >    reasonable indication that some datagram may have been
> > lost, it MAY
> > >    retransmit previously sent messages.
> > >
> > > 6.2  Message Corruption and Checksums
> > >
> > >    The UDP/IP datagrams may get corrupted in transit due to
> > software,
> > >    hardware or network errors. This protocol specified use of UDP
> > >    checksums to enable corruption detection in addition to
> checksums
> > >    utilized in IP and Ethernet layers. However, checksums do not
> > >    guarantee corruption detection and this protocol does
> > not provide for
> > >    message retransmission when a corrupt message is detected.
> > >
> > > 6.3  Congestion Control
> > >
> > >    The UDP does not provide for congestion control. Some
> > systems (hosts
> > >    or routers) may generate ICMP source quench error, but
> > they are not
> > >    required to do so [8].  Any network host can discard UDP
> > packets when
> > >    it is overloaded. Due to lack of congestion control one
> > or multiple
> > >    syslog senders can maliciously or inadvertently overload
> > the receiver
> > >    or the network infrastructure and cause loss of syslog
> messages.
> > >
> > > 6.4  Sequenced Delivery
> > >
> > >    The IP transport utilized by the UDP does not guarantee that
> the
> > >    sequence of datagram delivery will match the order in which the
> > >    datagrams have been sent. The time stamp contained
> > within each syslog
> > >    message may serve as some guide in establishing sequence
> > order, but
> > >    it will not help in cases when multiple messages were generated
> > >    during the same time slot or when messages originated
> > from different
> > >    hosts whose clocks are not synchronized. The order of
> > syslog message
> > >    arrival via the this syslog transport SHOULD NOT be used as an
> > >
> > >
> > >
> > > Okmianski               Expires November 5, 2004
> >    [Page 14]
> > > >
> > > Internet-Draft            syslog udp transport
> >     May 2004
> > >
> > >
> > >    authoritative guide in establishing the sequence of events on
> the
> > >    syslog sender hosts.
> > >
> > > 6.5  Sender Authentication
> > >
> > >    The UDP syslog transport does not strongly associate the
> > message with
> > >    the message sender.  The receiver of the syslog message
> > will not be
> > >    able to ascertain that the message was indeed sent from
> > the reported
> > >    sender, or if the packet was sent from another device.
> > >
> > >    One possible consequence of this behavior is that a
> misconfigured
> > >    machine may send syslog messages to a receiver
> > representing itself as
> > >    another machine. The administrators may not be able to readily
> > >    discern that there are two or more machines representing
> > themselves
> > >    as the same machine.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Okmianski               Expires November 5, 2004
> >    [Page 15]
> > > >
> > > Internet-Draft            syslog udp transport
> >     May 2004
> > >
> > >
> > > 7.  Security Considerations
> > >
> > >    Several syslog security considerations have been discussed in
> > >    RFC-protocol [2] and in the original RFC 3164 [1]. This section
> > >    focuses on security considerations specific to the
> > syslog transport
> > >    over UDP.
> > >
> > > 7.1  Message Authenticity
> > >
> > >    This transport protocol does not strongly authenticate
> > the identity
> > >    of the message sender and does not provide any assurance that
> the
> > >    message was not modified in transit. The receiver of the syslog
> > >    message will not be able to ascertain that the message was
> indeed
> > >    sent from the reported sender, or if the packet was sent
> > from another
> > >    device.
> > >
> > > 7.2  Message Forgery
> > >
> > >    Syslog messages can be easily forged. An attacker may
> > transmit syslog
> > >    messages (either from the machine from which the messages are
> > >    purportedly sent or from any other machine) to a receiver.
> > >
> > >    In one case, an attacker may hide the true nature of an
> > attack amidst
> > >    many other messages.  As an example, an attacker may
> > start generating
> > >    forged messages indicating a problem on some machine.
> > This may get
> > >    the attention of the system administrators who will
> > spend their time
> > >    investigating the alleged problem.  During this time,
> > the attacker
> > >    may be able to compromise a different machine, or a
> > different process
> > >    on the same machine.
> > >
> > >    Additionally, an attacker may generate false syslog
> > messages to give
> > >    untrue indications of status or of events.  As an example, an
> > >    attacker may stop a critical process on a machine, which
> > may generate
> > >    a notification of exit.  The attacker may subsequently generate
> a
> > >    forged notification that the process had been restarted.
> >  The system
> > >    administrators may accept that misinformation and not
> > verify that the
> > >    process had indeed been restarted.
> > >
> > > 7.3  Message Observation
> > >
> > >    The transport protocol does not provide confidentiality of the
> > >    messages in transit. If syslog messages are in clear
> > text, this is
> > >    how they will be transferred.  In most cases passing clear-text
> > >    human-readable messages is a benefit to the administrators.
> > >    Unfortunately, an attacker may also be able to observe the
> > >    human-readable contents of syslog messages.  The
> > attacker may then
> > >    use the knowledge gained from those messages to
> > compromise a machine
> > >    or do other damage. It is RECOMMENDED that no sensitive
> > information
> > >
> > >
> > >
> > > Okmianski               Expires November 5, 2004
> >    [Page 16]
> > > >
> > > Internet-Draft            syslog udp transport
> >     May 2004
> > >
> > >
> > >    is transmitted via this transport protocol or that
> > transmission of
> > >    such information is restricted to properly secured networks.
> > >
> > > 7.4  Replaying
> > >
> > >    Message forgery and observation can be combined into a
> > replay attack.
> > >    An attacker may record a set of messages that indicate normal
> > >    activity of a machine.  At a later time, that attacker may
> remove
> > >    that machine from the network and replay the syslog
> > messages to the
> > >    collector with new time stamps. The administrators may
> > find nothing
> > >    unusual in the received messages and their receipt would
> falsely
> > >    indicate normal activity of the machine.
> > >
> > > 7.5  Unreliable Delivery
> > >
> > >    As was previously discussed in the Reliability Considerations
> > >    section, the UDP transport is not reliable and packets
> containing
> > >    syslog message datagrams can be lost in transit without
> > any notice.
> > >    There can be security consequences to the loss of one or
> > more syslog
> > >    messages.  Administrators may not become aware of a
> > developing and
> > >    potentially serious problem. Messages may also be intercepted
> and
> > >    discarded by an attacker as a way to hide unauthorized
> > activities.
> > >
> > > 7.6  Message Prioritization and Differentiation
> > >
> > >    The transport protocol described in this document does
> > not require
> > >    prioritization of syslog messages on the wire or when
> > processed on
> > >    the receiving host based on their severity.  The
> > security implication
> > >    of such behavior is that the syslog receiver or network
> > devices may
> > >    get overwhelmed with low severity messages and be forced
> > to discard
> > >    potentially high severity messages. High severity messages may
> > >    contain indication about serious security problems, but
> > they will not
> > >    get a higher priority. It is difficult to make sure that high
> > >    severities messages get higher end-to-end delivery priority,
> > >    especially over an unreliable UDP transport.
> > >
> > >    On a case-by-case basis, device operators may find some way to
> > >    associate the different severity levels with the quality
> > of service
> > >    identifiers.  As an example, the operators may elect to
> > define some
> > >    linkage between syslog messages that have a specific
> > Priority value
> > >    with a specific value to be used in the IPv4 Precedence
> > field [4],
> > >    the IPv6 Traffic Class octet [5], or the Differentiated
> Services
> > >    field [9].  However, even with this prioritization on
> > the network,
> > >    high load can lead to buffer starvation on the receiving host
> and
> > >    result in dropped messages.
> > >
> > >
> > >
> > >
> > >
> > >
> > > Okmianski               Expires November 5, 2004
> >    [Page 17]
> > > >
> > > Internet-Draft            syslog udp transport
> >     May 2004
> > >
> > >
> > > 7.7  Denial of Service
> > >
> > >    An attacker may overwhelm a receiver by sending more
> > messages to it
> > >    than can be handled by the infrastructure or the device itself.
> > >    Implementers SHOULD attempt to provide features that
> > minimize this
> > >    threat such as only receiving syslog messages from known IP
> > >    addresses.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Okmianski               Expires November 5, 2004
> >    [Page 18]
> > > >
> > > Internet-Draft            syslog udp transport
> >     May 2004
> > >
> > >
> > > 8.  IANA Considerations
> > >
> > >    IANA must reserve UDP port 514 for this transport.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Okmianski               Expires November 5, 2004
> >    [Page 19]
> > > >
> > > Internet-Draft            syslog udp transport
> >     May 2004
> > >
> > >
> > > 9.  Notice to RFC Editor
> > >
> > >    This is a notice to the RFC editor. This ID is submitted
> > along with
> > >    ID draft-ietf-syslog-protocol and they cross-reference
> > each other.
> > >    When RFC numbers are determined for each of these IDs,
> > please replace
> > >    all references to "RFC-protocol" with the RFC number of
> > >    draft-ietf-syslog-protocol ID.  Please remove this section
> after
> > >    editing.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Okmianski               Expires November 5, 2004
> >    [Page 20]
> > > >
> > > Internet-Draft            syslog udp transport
> >     May 2004
> > >
> > >
> > > 10.  Authors and Working Group Chair
> > >
> > >    The working group can be contacted via the mailing list:
> > >
> > >    [email-masked]
> > >
> > >    The current Chair of the Working Group may be contacted at:
> > >
> > >    Chris Lonvick
> > >    Cisco Systems
> > >    Email: [email-masked]
> > >
> > >    The author of this draft is:
> > >
> > >    Anton Okmianski
> > >    Email: [email-masked]
> > >
> > >    Phone: (978) 936-1612
> > >    Fax: (978) 936-2225
> > >
> > >    Cisco Systems, Inc
> > >    1414 Massachusetts Ave.
> > >    Boxborough, MA 01719-2205
> > >    USA
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Okmianski               Expires November 5, 2004
> >    [Page 21]
> > > >
> > > Internet-Draft            syslog udp transport
> >     May 2004
> > >
> > >
> > > 11.  Acknowledgements
> > >
> > >    The author wishes to thank Chris Lonvick, Rainer Gerhards,
> David
> > >    Harrington, Andrew Ross, Albert Mietus, Bernie Volz, and
> > all others
> > >    who have commented on the various versions of this proposal.
> > >
> > > 12  References
> > >
> > >    [1]   Lonvick, C., "The BSD Syslog Protocol", RFC 3164,
> > August 2001.
> > >
> > >    [2]   Gerhards, R., "The syslog Protocol", RFC RFC-protocol.
> > >
> > >    [3]   Postel, J., "User Datagram Protocol", STD 6, RFC
> > 768, August
> > >          1980.
> > >
> > >    [4]   Postel, J., "Internet Protocol", STD 5, RFC 791,
> September
> > >          1981.
> > >
> > >    [5]   Deering, S. and R. Hinden, "Internet Protocol,
> > Version 6 (IPv6)
> > >          Specification", RFC 2460, December 1998.
> > >
> > >    [6]   Bradner, S., "Key words for use in RFCs to
> > Indicate Requirement
> > >          Levels", BCP 14, RFC 2119, March 1997.
> > >
> > >    [7]   Crocker, D. and P. Overell, "Augmented BNF for Syntax
> > >          Specifications: ABNF", RFC 2234, November 1997.
> > >
> > >    [8]   Stevens, W., "TCP/IP Illustrated Volume 1. The
> Protocols.",
> > >          January 1994.
> > >
> > >    [9]   Nichols, K., Blake, S., Baker, F. and D. Black,
> > "Definition of
> > >          the Differentiated Services Field (DS Field) in
> > the IPv4 and
> > >          IPv6 Headers", RFC 2474, December 1998.
> > >
> > >    [10]  Mockapetris, P., "Domain names - implementation and
> > >          specification", STD 13, RFC 1035, November 1987.
> > >
> > >    [11]  Hedrick, C., "Routing Information Protocol", RFC 1058,
> June
> > >          1988.
> > >
> > >    [12]  Droms, R., "Dynamic Host Configuration Protocol", RFC
> 2131,
> > >          March 1997.
> > >
> > >    [13]  Sollins, K., "The TFTP Protocol (Revision 2)", STD 33,
> RFC
> > >          1350, July 1992.
> > >
> > >    [14]  Braden, R., "Requirements for Internet Hosts -
> > Communication
> > >          Layers", STD 3, RFC 1122, October 1989.
> > >
> > >
> > >
> > > Okmianski               Expires November 5, 2004
> >    [Page 22]
> > > >
> > > Internet-Draft            syslog udp transport
> >     May 2004
> > >
> > >
> > >    [15]  Kent, C. and J. Mogul, ""Fragmentation Considered
> Harmful,"
> > >          Computer Communications Review, vol.17, no.5,
> pp.390-401",
> > >          August 1987.
> > >
> > >
> > > Author's Address
> > >
> > >    Anton Okmianski
> > >    Cisco Systems, Inc.
> > >    1414 Massachusetts Ave
> > >    Boxborough, MA  01719-2205
> > >    USA
> > >
> > >    EMail: [email-masked]
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Okmianski               Expires November 5, 2004
> >    [Page 23]
> > > >
> > > Internet-Draft            syslog udp transport
> >     May 2004
> > >
> > >
> > > Appendix A.  Rational For Transport Message Size Restrictions
> > >
> > >    This appendix provides the rational behind the Payload size
> > >    restrictions for this protocol.  The Payload
> > restrictions outlined in
> > >    the specification, essentially ensure that the transport
> > message size
> > >    does not exceed 512 bytes (without UDP/IP headers) for
> > transport via
> > >    IPv4 and does not exceed 1196 bytes for transport via IPv6.
> These
> > >    restrictions put an upper boundary on the UDP/IP
> > datagram size for
> > >    this protocol, which accomplishes two goals.
> > >
> > >    First, they insure interoperability between various UDP/IP
> > >    implementations.  Even though the maximum IP datagram size is
> > >    specified as 65536 bytes, many UDP/IP implementations
> > have been shown
> > >    not to work with large datagram sizes [8].  Many established
> > >    UDP-based protocols restrict UDP datagram data size to
> > 512 bytes. For
> > >    example, DNS [10] and RIP [11] do that. The DHCPv4 [12]
> > restricts the
> > >    size to 512 bytes, but allows sides to agree on a larger value
> > >    through the protocol. The TFTP [13] restricts the UDP
> > data size to
> > >    518 bytes, which is slightly larger.
> > >
> > >    The second reason for datagram size restrictions is that it
> helps
> > >    reduce the likelihood of the  IP-layer datagram
> > fragmentation.  This
> > >    could have potentially resulted in fragmentation on two levels:
> > >    syslog transport protocol and IP layer. Since fragmentation has
> > >    significant overhead for message reassembley, it is best to
> avoid
> > >    double fragmentation. The likelihood of IP fragmentation can be
> > >    significantly reduced by sending IP datagrams in sizes which
> all
> > >    hosts must be able to process.
> > >
> > >    The minimum MTU of a transport protocol determines the
> > minimum size
> > >    of packets that hosts must be able to accept.  For IPv4,
> > the minimum
> > >    MTU is 576 bytes [4] and for IPv6 - 1280 bytes [5].  In
> > both cases,
> > >    the maximum message size we chose fits within the MTU of the
> > >    transport in all cases except for when extremely large
> > IP headers are
> > >    used.  IPv4 header can range from 20 to 60 bytes in
> > length and UDP
> > >    header is fixed at 8 bytes. Thus, our message size restrictions
> > >    ensure that in all cases except for when the IP header
> > is 56 bytes or
> > >    greater, the size of the packet will within the size of
> > the transport
> > >    MTU.
> > >
> > >    For IPv6, we have left the same amount of padding for
> > UDP/IP headers
> > >    as was conventionally done for IPv4 in DNS, RIP and
> > DHCPv4 with an
> > >    additional padding of extra 20 bytes to accommodate a larger
> IPv6
> > >    header. This follows the methodology suggested in the IPv6
> > >    specification for calculating upper-layer payload limits [5].
> > >
> > >    Path MTU discovery can generally be used to discover the
> > MTU of the
> > >    link.  Unfortunately, using path MTU discovery with UDP is not
> a
> > >
> > >
> > >
> > > Okmianski               Expires November 5, 2004
> >    [Page 24]
> > > >
> > > Internet-Draft            syslog udp transport
> >     May 2004
> > >
> > >
> > >    reliable option because it depends on routers providing
> > ICMP errors
> > >    and hosts doing retransmission, which are not done
> consistently.
> > >    Implementors MUST follow the size restrictions outlined
> > above and not
> > >    rely on path MTU discovery.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Okmianski               Expires November 5, 2004
> >    [Page 25]
> > > >
> > > Internet-Draft            syslog udp transport
> >     May 2004
> > >
> > >
> > > Intellectual Property Statement
> > >
> > >    The IETF takes no position regarding the validity or scope of
> any
> > >    intellectual property or other rights that might be claimed to
> > >    pertain to the implementation or use of the technology
> > described in
> > >    this document or the extent to which any license under
> > such rights
> > >    might or might not be available; neither does it
> > represent that it
> > >    has made any effort to identify any such rights.
> > Information on the
> > >    IETF's procedures with respect to rights in standards-track and
> > >    standards-related documentation can be found in BCP-11. Copies
> of
> > >    claims of rights made available for publication and any
> > assurances of
> > >    licenses to be made available, or the result of an
> > attempt made to
> > >    obtain a general license or permission for the use of such
> > >    proprietary rights by implementors or users of this
> > specification can
> > >    be obtained from the IETF Secretariat.
> > >
> > >    The IETF invites any interested party to bring to its
> > attention any
> > >    copyrights, patents or patent applications, or other
> proprietary
> > >    rights which may cover technology that may be required
> > to practice
> > >    this standard. Please address the information to the
> > IETF Executive
> > >    Director.
> > >
> > >
> > > Full Copyright Statement
> > >
> > >    Copyright (C) The Internet Society (2004). All Rights Reserved.
> > >
> > >    This document and translations of it may be copied and
> > furnished to
> > >    others, and derivative works that comment on or
> > otherwise explain it
> > >    or assist in its implementation may be prepared, copied,
> > published
> > >    and distributed, in whole or in part, without restriction of
> any
> > >    kind, provided that the above copyright notice and this
> > paragraph are
> > >    included on all such copies and derivative works. However, this
> > >    document itself may not be modified in any way, such as
> > by removing
> > >    the copyright notice or references to the Internet
> > Society or other
> > >    Internet organizations, except as needed for the purpose of
> > >    developing Internet standards in which case the procedures for
> > >    copyrights defined in the Internet Standards process must be
> > >    followed, or as required to translate it into languages
> > other than
> > >    English.
> > >
> > >    The limited permissions granted above are perpetual and
> > will not be
> > >    revoked by the Internet Society or its successors or assignees.
> > >
> > >    This document and the information contained herein is
> > provided on an
> > >    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
> > ENGINEERING
> > >    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
> > INCLUDING
> > >    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
> > >
> > >
> > >
> > > Okmianski               Expires November 5, 2004
> >    [Page 26]
> > > >
> > > Internet-Draft            syslog udp transport
> >     May 2004
> > >
> > >
> > >    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
> OF
> > >    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
> > >
> > >
> > > Acknowledgment
> > >
> > >    Funding for the RFC Editor function is currently provided by
> the
> > >    Internet Society.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Okmianski               Expires November 5, 2004
> >    [Page 27]
> > > >
> > >
> >
> > >
> > >
> >      [1]
> > > TOC
> > >
> > >    syslog Working Group      A. Okmianski
> > >    Internet-Draft            Cisco Systems, Inc.
> > >    Expires: November 5, 2004 May 7, 2004
> > >
> > >                                  Transmission of syslog
> > messages over
> > > UDP
> > >
> > >
> > > draft-ietf-syslog-transport-udp-01
> > >
> > >   Status of this Memo
> > >
> > >    This document is an Internet-Draft and is in full
> > conformance with all
> > >    provisions of Section 10 of RFC2026.
> > >
> > >    Internet-Drafts are working documents of the Internet
> > Engineering Task
> > >    Force  (IETF),  its  areas,  and  its  working groups.
> > Note that other
> > >    groups may also distribute working documents as
> Internet-Drafts.
> > >
> > >    Internet-Drafts  are draft documents valid for a maximum
> > of six months
> > >    and  may  be updated, replaced, or obsoleted by other
> > documents at any
> > >    time. It is inappropriate to use Internet-Drafts as
> > reference material
> > >    or to cite them other than as "work in progress."
> > >
> > >    The   list   of   current   Internet-Drafts   can   be
> > accessed   at
> > >    [2]http://www.ietf.org/ietf/1id-abstracts.txt.
> > >
> > >    The  list  of  Internet-Draft  Shadow  Directories  can
> > be accessed at
> > >    [3]http://www.ietf.org/shadow.html.
> > >
> > >    This Internet-Draft will expire on November 5, 2004.
> > >
> > >   Copyright Notice
> > >
> > >    Copyright (C) The Internet Society (2004). All Rights Reserved.
> > >
> > >   Abstract
> > >
> > >    This  document  describes  the  transport  for the
> > syslog message 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 using
> > >    multiple datagrams.
> > >
> > _________________________________________________________________
> > >
> > >   Table of Contents
> > >
> > >    [4]1.  Introduction
> > >    [5]2.  Transport Protocol Overview
> > >        [6]2.1  Definitions and Architecture
> > >        [7]2.2  Required Transport Protocol
> > >        [8]2.3  Encapsulation Layers
> > >    [9]3.  Message Format
> > >        [10]3.1  Basic Header Format
> > >        [11]3.2  Extended Header Format
> > >            [12]3.2.1  Message Identifier
> > >            [13]3.2.2  Total Length
> > >            [14]3.2.3  Fragment Offset
> > >            [15]3.2.4  Extended Header Example
> > >        [16]3.3  Payload
> > >        [17]3.4  Supported Message Length
> > >    [18]4.  UDP/IP Layer Considerations
> > >        [19]4.1  Target Port
> > >        [20]4.2  Source Port
> > >        [21]4.3  Source IP Address
> > >        [22]4.4  UDP/IP Headers
> > >    [23]5.  Fragmentation and Reassembley
> > >        [24]5.1  Message Fragmentation
> > >        [25]5.2  Message Reassembley
> > >        [26]5.3  Avoiding Fragmentation
> > >    [27]6.  Reliability Considerations
> > >        [28]6.1  Lost Datagrams
> > >        [29]6.2  Message Corruption and Checksums
> > >        [30]6.3  Congestion Control
> > >        [31]6.4  Sequenced Delivery
> > >        [32]6.5  Sender Authentication
> > >    [33]7.  Security Considerations
> > >        [34]7.1  Message Authenticity
> > >        [35]7.2  Message Forgery
> > >        [36]7.3  Message Observation
> > >        [37]7.4  Replaying
> > >        [38]7.5  Unreliable Delivery
> > >        [39]7.6  Message Prioritization and Differentiation
> > >        [40]7.7  Denial of Service
> > >    [41]8.  IANA Considerations
> > >    [42]9.  Notice to RFC Editor
> > >    [43]10.  Authors and Working Group Chair
> > >    [44]11.  Acknowledgements
> > >    [45]§.  References
> > >    [46]§  Author's Address
> > >    [47]A.  Rational For Transport Message Size Restrictions
> > >    [48]§  Intellectual Property and Copyright Statements
> > >
> > _________________________________________________________________
> > >
> > >
> >     [49]
> > > TOC
> > >
> > >   1. Introduction
> > >
> > >    The  original  syslog  protocol has been described in an
> > informational
> > >    [50]RFC  3164Lonvick,  C., The BSD Syslog Protocol,
> > August 2001.[1] as
> > >    it  has  been  observed in existing implementations. It
> > describes both
> > >    the  semantics  of  syslog  message format as well as a
> > UDP transport.
> > >    Subsequently,  the  syslog  protocol  has  been
> > formally defined in a
> > >    standards  track  [51]RFC-protocolGerhards,  R.,  The
> > syslog Protocol,
> > >    .[2].
> > >
> > >    The  [52]RFC-protocolGerhards,  R.,  The  syslog
> > Protocol,  .[2]  has
> > >    provided  for  support  of any number of transport layer
> > protocols for
> > >    transmitting syslog messages and left it to subsequent
> > RFCs to specify
> > >    transport  protocols.  This  standards  track  RFC
> > describes  the UDP
> > >    transport for the syslog protocol. This transport
> > protocol is REQUIRED
> > >    for all syslog protocol implementations.
> > >
> > >    This   transport   protocol  was  designed  to  work  on
> >  top  of  UDP
> > >    [53][3]Postel, J., User Datagram Protocol, August 1980.
> > over both IPv4
> > >    [54][4]Postel,   J.,  Internet  Protocol,  September
> > 1981.  and  IPv6
> > >    [55][5]Deering,  S. and R. Hinden, Internet Protocol,
> > Version 6 (IPv6)
> > >    Specification,  December  1998.. This protocol overcomes
> > the data size
> > >    restrictions  of the UDP protocol by introducing message
> > fragmentation
> > >    feature.
> > >
> > >    As  we  will show in this specification, this protocol
> > has significant
> > >    reliability and security issues stemming from the use of
> > UDP. However,
> > >    this  protocol  is lightweight and extends on the
> > existing popular use
> > >    of  UDP  for  syslog.  Network administrators and
> > architects should be
> > >    aware of the shortcomings of this protocol and plan
> accordingly.
> > >
> > >    The  key  words  "MUST", "MUST NOT", "REQUIRED",
> > "SHALL", "SHALL NOT",
> > >    "SHOULD",  "SHOULD  NOT", "RECOMMENDED", "MAY", and
> > "OPTIONAL" in this
> > >    document  are  to  be interpreted as described in
> > [56]RFC 2119Bradner,
> > >    S.,  Key  words  for use in RFCs to Indicate Requirement
> > Levels, March
> > >    1997.[6].  The  words  'byte'  and 'octet' are used
> > interchangeably in
> > >    this specification.
> > >
> > _________________________________________________________________
> > >
> > >
> >     [57]
> > > TOC
> > >
> > >   2. Transport Protocol Overview
> > >
> > >     2.1 Definitions and Architecture
> > >
> > >    The following definitions will be used in this document:
> > >      * An  application that can generate syslog messages
> > will be referred
> > >        to as a "sender";
> > >      * An  application  that can receive syslog messages
> > will be referred
> > >        to as a "receiver".
> > >
> > >    An  application  can  function in dual capacity. For
> > example, a syslog
> > >    relay  may  receive and forward messages. A single
> > system can host any
> > >    number  of syslog senders. Only one syslog receiver can
> > be hosted on a
> > >    single system using the standard listening port.
> > >
> > >     2.2 Required Transport Protocol
> > >
> > >    This  document  describes  the  UDP  transport  layer
> > protocol for the
> > >    syslog  protocol  [58]RFC-protocolGerhards,  R.,  The
> > syslog Protocol,
> > >    .[2]. Every syslog sender and receiver implementation
> > which adheres to
> > >    the [59]RFC-protocolGerhards, R., The syslog Protocol,
> > .[2] MUST fully
> > >    implement   the   transport   protocol  specified  in
> > this  document.
> > >    Implementations  does  not have to support both IPv4 and
> > IPv6 if it is
> > >    designed to be used over only one of these protocols.
> > >
> > >     2.3 Encapsulation Layers
> > >
> > >    Syslog  UDP  transport  carries  syslog  messages  as
> > generic payload
> > >    encapsulated  with  a  syslog  transport  header, UDP
> > header and an IP
> > >    header.  Below  is a summary of syslog UDP/IP packet
> > structure as used
> > >    this transport protocol:
> > >
> > >                 +--------------------------------+
> > >                 |       IPv4 or IPv6 Header      |
> > >                 |        (20 or more bytes)      |
> > >                 +--------------------------------+
> > >                 |           UDP Header           |
> > >                 |           (8 bytes)            |
> > >                 +--------------------------------+
> > >                 |    Syslog Transport Header     |
> > >                 |        (5 or 32 bytes)         |
> > >                 +--------------------------------+
> > >                 |     Syslog Message Payload     |
> > >                 |       (1 to 1191 bytes)        |
> > >                 +--------------------------------+
> > >
> > >    Small  syslog  messages  are transmitted using one
> > UDP/IP datagram per
> > >    message.  However,  syslog  protocol  [60][2]Gerhards,
> > R., The syslog
> > >    Protocol,  .  allows messages as large as 16777216
> > bytes, while UDP/IP
> > >    datagram  cannot exceed a total size of 65526 bytes
> > [61][3]Postel, J.,
> > >    User  Datagram  Protocol,  August  1980.  and  most
> > existing protocols
> > >    restrict  the  size  of  UDP  data  to  much less. In
> > order to support
> > >    transmitting  large  messages  over  UDP/IP,  this
> > transport protocol
> > >    supports  fragmentation  of large syslog messages into
> > multiple UDP/IP
> > >    datagrams for transmission and reassembley on the receiving
> end.
> > >
> > >    Each  syslog  UDP/IP  datagram  MUST contain one and
> > only one complete
> > >    syslog  message  or  one  fragment of a message.
> > Transmitting multiple
> > >    messages  or  multiple fragments of different messages
> > in a single UDP
> > >    datagram is not supported by this protocol.
> > >
> > _________________________________________________________________
> > >
> > >
> >     [62]
> > > TOC
> > >
> > >   3. Message Format
> > >
> > >    The  syslog  transport  message  consist  of  a
> > transport header and a
> > >    syslog  message  payload.  The  format  of  the
> > transport  header  is
> > >    different  for fragmented and non-fragmented messages.
> > Basic transport
> > >    header  is  used  for  non-fragmented  messages and
> > extended transport
> > >    header is used for fragmented messages.
> > >
> > >    An  ASCII-based  encoding  was  chosen  for  the  syslog
> > transport for
> > >    consistency   with   the   [63]RFC-protocolGerhards,
> > R.,  The  syslog
> > >    Protocol, .[2]. Syslog transport datagrams without
> > required UDP and IP
> > >    headers  have  the  following  format  in
> > [64]ABNFCrocker,  D. and P.
> > >    Overell,  Augmented  BNF  for  Syntax  Specifications:
> > ABNF, November
> > >    1997.[7] notation:
> > >
> > >     SyslogTransportMessage = ( BasicHeader / ExtendedHeader )
> > >                                       SP Payload
> > >
> > >     BasicHeader     = Version SP "0"
> > >     Version         = %d118 1*3DIGIT   ; "v1" in this version
> > >
> > >     ExtendedHeader  = Version SP "1" SP MessageId
> > >                       SP TotalLength SP FragmentOffset
> > >
> > >     MessageId       = 1*8DIGIT        ; 0 to 16777215
> > >     TotalLength     = 1*8DIGIT        ; 1 to 16777216
> > >     FragmentOffset  = 1*8DIGIT        ; 0 to 16777215
> > >     Payload         = 1*1191OCTET
> > >
> > >     OCTET           = %d00-255
> > >     DIGIT           = %d48-57
> > >     SP              = %d32
> > >
> > >
> > >     3.1 Basic Header Format
> > >
> > >    When  no  fragmentation  is  used  and  the  entire
> > syslog message is
> > >    transferred  as  a  single  UDP/IP  datagram, a basic
> > syslog transport
> > >    header  MUST be used. The version for this protocol is
> > "1". It must be
> > >    followed  by  one  space  and  a  "0" to indicate that
> > this is a basic
> > >    header.  Therefore,  the  only  possible value for the
> > basic header in
> > >    this protocol is as follows:
> > >
> > >    "v1 0 "
> > >
> > >    Example  of  a syslog message without the transport
> > header (message is
> > >    wrapped for display):
> > >
> > >    "v1 888 3 2003-10-11T22:14:15.003Z host.domain.com
> > >    dns: configuration error"
> > >
> > >    Example  of  the  same  message  with the transport
> > header (message is
> > >    wrapped for display):
> > >
> > >    "v1 0 v1 888 4 2003-10-11T22:14:15.003Z host.domain.com
> > >    dns: configuration error"
> > >
> > >     3.2 Extended Header Format
> > >
> > >    When  syslog  message  is  fragmented  by  the  sender,
> > multiple  UDP
> > >    datagrams  must  be  used  and  each datagram MUST
> > contain an extended
> > >    syslog  transport  header.  The  version for this
> > protocol is "1". The
> > >    version field MUST be followed by a single space and a
> > "1" to indicate
> > >    that  this is an extended header. Thus, an extended
> > header MUST always
> > >    begin  with "v1 1 ", but MUST also have additional
> > fields which aid in
> > >    fragmentation.
> > >
> > >    The  MessageId,  TotalLength and FragmentOffset fields
> > are used solely
> > >    for fragmentation of long messages and reassembley. They
> > SHOULD NOT be
> > >    used for other purposes.
> > >
> > >     3.2.1 Message Identifier
> > >
> > >    The  MessageId  field  (along  with  the  source  UDP
> > port and the IP
> > >    address)  is  used  to  identify  the message such that
> > fragments of a
> > >    single  syslog  message  can  be  reassembled  by  the
> > receiver into a
> > >    complete  message.  The MessageId field MUST be a
> > numeric value in the
> > >    range  of  0  to  16777215.  Leading  zeros MUST not be
> > present in the
> > >    MessageId field.
> > >
> > >    Each syslog sender process MUST choose a random
> > MessageId value within
> > >    the  supported  range  for  its  first  message.
> > Subsequent  messages
> > >    generated  by  the same process MUST each increment the
> > MessageId by 1
> > >    up  to  16777215  and  then  continue at 0. Using random
> > value for the
> > >    first  MessageId  helps  reduce the possibility of
> > potential errors in
> > >    message   reassembley.   Refer   to   discussion   about
> >   [65]message
> > >    reassembleyMessage Reassembley for more details.
> > >
> > >    All  datagrams  which  represent  parts  of  a given
> > fragmented syslog
> > >    message MUST have the same MessageId value.
> > >
> > >     3.2.2 Total Length
> > >
> > >    The  TotalLength  field  MUST  be a numeric value in the
> > range of 1 to
> > >    16777216.  It  MUST  indicate  the length of a complete
> > syslog message
> > >    before it was fragmented and before it was encapsulated
> > with transport
> > >    headers.  The  same TotalLength field value MUST be
> > present in all UDP
> > >    datagrams  which  represent  fragments  of  the  same
> > syslog message.
> > >    Leading zeros MUST not be present in the TotalLength field.
> > >
> > >    Note  that in IPv4 the "total length" field identifies
> > the length of a
> > >    single  packet.  In  this  protocol,  the TotalLength
> > field is used to
> > >    identify  the  total  length  of  a  complete syslog
> > message, which is
> > >    transmitted  using  multiple  fragments and multiple
> > datagram packets.
> > >    The  fragment  length is not specified in the transport
> > header because
> > >    it  can  be inferred from the size of the IP packet
> > containing the UDP
> > >    datagram.
> > >
> > >     3.2.3 Fragment Offset
> > >
> > >    The  FragmentOffset field MUST be a numeric value in the
> > range of 0 to
> > >    16777215. It MUST indicate the byte offset of the
> > fragment data in the
> > >    complete  syslog  message.  The offset index starts at 0
> > for the first
> > >    fragment.  For  example,  if  an 700 byte syslog message
> > is fragmented
> > >    into  480  and 220 byte parts, the FragmentOffset in the
> > first message
> > >    will  be  0 and in the second - 480. Note that fragments
> > don't have to
> > >    be   the  same  size.  Leading  zeros  MUST  not  be
> > present  in  the
> > >    FragmentOffset field.
> > >
> > >     3.2.4 Extended Header Example
> > >
> > >    The  following is an example of a syslog message without
> > the transport
> > >    header (message is wrapped for display):
> > >
> > >    "v1 888 4 2003-10-11T22:14:15.003Z host.domain.com
> > >    dns: configuration error"
> > >
> > >    Suppose  this message had to be fragmented by transport
> > layer into two
> > >    parts  at  an  arbitrary  point. This would result in
> > two separate UDP
> > >    datagrams  being sent - one for each fragment. Below is
> > the content of
> > >    each  of  the  syslog  transport  UDP  messages  with
> > syslog transport
> > >    headers but without UDP/IP headers:
> > >
> > >    "v1 1 45612221 74 0 v1 888 4 2003-10-11T22:14:15.003Z host.dom"
> > >
> > >    "v1 1 45612221 74 42 ain.com dns: configuration error"
> > >
> > >    In the above example, the leading "v1" is the version of
> > the transport
> > >    protocol, "1" indicates that this is an extended header
> > (fragmentation
> > >    in  use),  "45612221" is the MessageId, "74" is the
> > TotalLength of the
> > >    message,  while  "0"  and  "42"  are FragmentOffset
> > fields. Everything
> > >    following  the  FragmentOffset  and  a  space is a the
> > Payload of each
> > >    respective message.
> > >
> > >     3.3 Payload
> > >
> > >    The  Payload  field  of  the syslog UPD transport
> > message is an entire
> > >    syslog  message  or  one fragment. The maximum Payload
> > size depends on
> > >    the IP protocol used and the type header that is used.
> > >    Maximum Payload size:
> > >
> > >    With IPv4 and basic header:    507 bytes
> > >    With IPv4 and extended header: 480 bytes
> > >
> > >    With IPv6 and basic header:    1191 bytes
> > >    With IPv6 and extended header: 1164 bytes
> > >
> > >    The  Payload size restrictions above effectively mean
> > that the largest
> > >    syslog  message  that  can  be  sent  non-fragmented  is
> > 507 bytes for
> > >    transport via IPv4 and 1191 bytes for transport via IPv6.
> > >
> > >    For  a discussion of the relational behind the above
> > size restrictions
> > >    please refer to Appendix A.
> > >
> > >     3.4 Supported Message Length
> > >
> > >    The  maximum  syslog  message length supported by this
> > protocol is the
> > >    maximum  value  of  the  TotalLength  field,  which is
> > 16777216 bytes.
> > >    However, not all deployment scenarios for syslog will be
> > on hosts with
> > >    hardware   capable  of  supporting  the  maximum  length
> >  of  messages
> > >    supported by this protocol. Additionally, extremely
> > large messages may
> > >    not be needed in many environments. Therefore,
> > implementations are NOT
> > >    REQUIRED  to  support  the  maximum  message  length
> > allowed  by this
> > >    protocol.
> > >
> > >    All implementations MUST support sending and receiving
> > syslog messages
> > >    up  to  and including 65536 bytes in size (syslog
> > transport and UDP/IP
> > >    headers  are  extra).  Support  for  larger  messages
> > is  encouraged.
> > >    Implementors  SHOULD  clearly state the maximum
> > supported message size
> > >    in documentation.
> > >
> > _________________________________________________________________
> > >
> > >
> >     [66]
> > > TOC
> > >
> > >   4. UDP/IP Layer Considerations
> > >
> > >     4.1 Target Port
> > >
> > >    Syslog  receivers MUST support accepting syslog message
> > datagrams on a
> > >    well-known  UDP  port  514. Syslog senders MUST support
> > sending syslog
> > >    message datagrams to the UDP port 514.
> > >
> > >     4.2 Source Port
> > >
> > >    Syslog  senders can use any source UDP port for
> > transmitting messages.
> > >    Senders MAY randomly select a source port, but MUST use
> > the port in an
> > >    exclusive  fashion.  No  concurrent  port  reuse  on
> > the same host is
> > >    allowed.
> > >
> > >    Each  syslog  sender  process MUST attempt to use the
> > same source port
> > >    for the life of the the process. If due to an error or
> > other condition
> > >    it  becomes  impossible  for  the  process to continue
> > to use the same
> > >    port, it MAY start using a new source port, but it MUST
> > generate a new
> > >    random  MessageId  for  the  first message after
> > changing the port and
> > >    then MUST continue incrementing the new MessageId value
> > for subsequent
> > >    messages.
> > >
> > >    Since  source  port is used to identify parts of a
> > fragmented message,
> > >    the  sender  MUST  use  the same port to send all
> > fragments of a given
> > >    message.  If  due to an error or other condition, the
> > sender is unable
> > >    to  do  that,  it MUST resend all message fragments
> > using the new port
> > >    and a new MessageId field value.
> > >
> > >     4.3 Source IP Address
> > >
> > >    The source IP address of the UDP datagrams is one of the
> > data elements
> > >    used  to  identify  parts of a fragmented message.
> > Therefore, a syslog
> > >    sender  MUST  attempt  to  use  the same source IP
> > address to send all
> > >    fragments   of   a   given   syslog  message.  If  due
> > to  an  error,
> > >    reconfiguration  or  other condition it is unable to do
> > so, the sender
> > >    MUST  resend  all fragments of the syslog message using
> > the new source
> > >    IP address and a new MessageId value.
> > >
> > >     4.4 UDP/IP Headers
> > >
> > >    Each  UDP/IP  datagram  sent  by  the  transport layer
> > MUST completely
> > >    adhere  to  the  structure specified in the UDP [67]RFC
> > 768Postel, J.,
> > >    User  Datagram  Protocol,  August  1980.[3]  and  either
> >  IPv4 [68]RFC
> > >    791Postel,  J.,  Internet Protocol, September 1981.[4]
> > or IPv6 [69]RFC
> > >    2640Deering,  S.  and  R.  Hinden, Internet Protocol,
> > Version 6 (IPv6)
> > >    Specification, December 1998.[5] depending on which protocol is
>
> > > used.
> > >
> > >    Use of UDP checksums was defined as optional in [70]RFC
> > 768Postel, J.,
> > >    User  Datagram  Protocol,  August 1980.[3]. IPv6 has
> > subsequently made
> > >    UDP  checksums  required  [71][5]Deering,  S.  and R.
> > Hinden, Internet
> > >    Protocol,  Version  6  (IPv6)  Specification, December
> > 1998.. However,
> > >    syslog  senders MUST utilize valid UDP checksums when
> > sending messages
> > >    over  either  IPv4  or IPv6. Syslog receivers MUST check
> > for checksums
> > >    and  discard  messages  with  incorrect  checksums.
> > Note that this is
> > >    typically  accomplished  by  the  UDP  layer
> > implementation, and some
> > >    implementations allow for checksum checks to be enabled or
> > > disabled.
> > >
> > >    Enabling  use  of  checksums  serves as an extra measure
> > of corruption
> > >    detection  in  addition  to  checksums  performed  by
> > IP and Ethernet
> > >    layers.  None  of  the above checksums provide a
> > complete guarantee of
> > >    corruption  detection.  Utilizing checksums on multiple
> > layers reduces
> > >    the chance of corruption error not being detected.
> > >
> > _________________________________________________________________
> > >
> > >
> >     [72]
> > > TOC
> > >
> > >   5. Fragmentation and Reassembley
> > >
> > >     5.1 Message Fragmentation
> > >
> > >    The  syslog  transport  layer  MUST  perform
> > fragmentation  if syslog
> > >    message  size  exceeds the maximum allowed Payload size.
> > Fragmentation
> > >    SHOULD NOT be used if message can fit into the maximum
> > allowed Payload
> > >    size.
> > >
> > >    Syslog  messages  SHOULD  be fragmented such that all
> > but last message
> > >    utilize  the  Payload to its maximum capacity. For
> > example, when using
> > >    IPv4,  a 700 byte syslog message SHOULD be fragmented
> > into 480 and 220
> > >    byte  parts  because  the  maximum Payload size with
> > IPv4 and extended
> > >    header is 480 bytes.
> > >
> > >    Each  message fragment MUST be sent as a separate UDP/IP
> > datagram with
> > >    an  extended  syslog  transport  header.  The sender
> > MUST use the same
> > >    MessageId  value,  source port and source IP address for
> > all fragments
> > >    of  a  given  message.  These  three  field together
> > uniquely identify
> > >    fragments belonging to a given message.
> > >
> > >    On a system with short-lived sender processes, it may be
> > possible that
> > >    fragments  with  the  same  MessageId value, source port
> > and source IP
> > >    address  will  get  generated  in  short  time
> > proximity. This can be
> > >    possible  because  a  new  process may re-use the source
> > port that was
> > >    freed  up  by  another  process  that  just  dies. Such
> > behavior could
> > >    confuse  the  receiver  if the datagrams were received
> > out of order or
> > >    some datagrams got lost.
> > >
> > >    In  order to reduce the risk of such mistaken identity
> > errors, section
> > >    3.2.1  specified  that each process must start with a
> > random value for
> > >    MessageId  field.  Given  a relatively large range of
> > MessageId values
> > >    and  the  unlikely event of a coincidence of having the
> > same MessageId
> > >    value combined with re-used source port and UPD errors,
> > the window for
> > >    potential  mistaken identity errors during message
> > reassembley is very
> > >    small  and  tolerable.  The  users  take  a greater risk
> > by using this
> > >    protocol due to general UDP reliability issues discussed
> > later in this
> > >    specification.
> > >
> > >     5.2 Message Reassembley
> > >
> > >    The reassembley process uses the source IP address from
> > the IP header,
> > >    the  source  port from the UDP header and the MessageId
> > field value to
> > >    identify  fragments  of  a  given  message.  It  then
> > uses  data from
> > >    TotalLength  and FragmentOffset fields to re-assemble
> > fragments into a
> > >    complete message.
> > >
> > >    Typically,  an  implementation  of  fragmentation
> > reassembley involves
> > >    allocating  a  buffer  for  the  message  when any
> > fragment with a new
> > >    combination  of  source  IP  address,  source  port  and
> >  MessageId is
> > >    received.  A timer is used to expire the message
> > reassembley and clean
> > >    the  buffer  if all fragments are not received in
> > certain time period.
> > >    As  each  fragment  is  received,  it is placed into the
> > buffer at the
> > >    appropriate  offset  and  a  check  is  performed  to
> > determine if all
> > >    fragments have been received using additional data structures.
> > >
> > >    The  receiver  SHOULD  make  the  timeout  interval
> > used  for message
> > >    reassembley  configurable  for  the administrator. The
> > receiver SHOULD
> > >    also be able to limit the total amount of memory used
> > for buffers such
> > >    that it does not run out of resources under a simple
> > denial of service
> > >    attack  involving  just  one message fragment with a
> > large TotalLength
> > >    field  value.  Degrading  the  service  under  heavy
> > load or attack is
> > >    better  than  crashing  and  potentially making the
> > service completely
> > >    unavailable.
> > >
> > >     5.3 Avoiding Fragmentation
> > >
> > >    Fragmentation   and   reassembley   of   messages
> > incurs  substantial
> > >    processing overhead on both the sender and the receiver
> > hosts. It also
> > >    increases  the risk of lost messages due to lose of just
> > one fragment.
> > >    It  is  RECOMMENDED  that  syslog  senders  which
> > anticipate  sending
> > >    messages  over this transport protocol attempt to reduce
> > the number of
> > >    messages  which  require fragmentation by restricting
> > them to the size
> > >    which does not require fragmentation.
> > >
> > _________________________________________________________________
> > >
> > >
> >     [73]
> > > TOC
> > >
> > >   6. Reliability Considerations
> > >
> > >    The UDP is an unreliable low-overhead protocol. This
> > section discusses
> > >    reliability  issues  inherent  in  the UDP that
> > implementers and users
> > >    must be aware of.
> > >
> > >     6.1 Lost Datagrams
> > >
> > >    Neither  UDP  nor  syslog protocol provide any mechanism
> > to detect and
> > >    correct  loss  of  datagrams.  Datagrams may be lost in
> > transit due to
> > >    congestion,  corruption  or  any  other  intermittent
> > network problem.
> > >    Syslog  protocol  and IP fragmentation exacerbates the
> > problem because
> > >    loss  of  a  single  fragment  would  result  in  entire
> > message being
> > >    discarded.
> > >
> > >    In  some circumstances the sender may receive an ICMP
> > error message or
> > >    other  indication  of a transmission problem. If the
> > sender receives a
> > >    reasonable  indication  that  some datagram may have
> > been lost, it MAY
> > >    retransmit previously sent messages.
> > >
> > >     6.2 Message Corruption and Checksums
> > >
> > >    The  UDP/IP  datagrams  may  get corrupted in transit
> > due to software,
> > >    hardware  or  network  errors.  This  protocol
> > specified  use  of UDP
> > >    checksums  to  enable  corruption  detection  in
> > addition to checksums
> > >    utilized  in  IP  and  Ethernet  layers.  However,
> > checksums  do  not
> > >    guarantee  corruption detection and this protocol does
> > not provide for
> > >    message retransmission when a corrupt message is detected.
> > >
> > >     6.3 Congestion Control
> > >
> > >    The  UDP  does not provide for congestion control. Some
> > systems (hosts
> > >    or  routers)  may  generate ICMP source quench error,
> > but they are not
> > >    required to do so [74][8]Stevens, W., TCP/IP Illustrated
> > Volume 1. The
> > >    Protocols.,  January  1994..  Any network host can
> > discard UDP packets
> > >    when  it  is  overloaded.  Due  to  lack  of congestion
> > control one or
> > >    multiple  syslog senders can maliciously or
> > inadvertently overload the
> > >    receiver  or  the  network  infrastructure  and  cause
> > loss of syslog
> > >    messages.
> > >
> > >     6.4 Sequenced Delivery
> > >
> > >    The  IP  transport  utilized  by  the  UDP does not
> > guarantee that the
> > >    sequence  of  datagram  delivery  will  match  the
> > order in which the
> > >    datagrams  have been sent. The time stamp contained
> > within each syslog
> > >    message may serve as some guide in establishing sequence
> > order, but it
> > >    will  not  help  in cases when multiple messages were
> > generated during
> > >    the  same  time  slot or when messages originated from
> > different hosts
> > >    whose clocks are not synchronized. The order of syslog
> > message arrival
> > >    via  the  this syslog transport SHOULD NOT be used as an
> > authoritative
> > >    guide  in  establishing  the  sequence  of events on the
> > syslog sender
> > >    hosts.
> > >
> > >     6.5 Sender Authentication
> > >
> > >    The  UDP syslog transport does not strongly associate
> > the message with
> > >    the  message  sender.  The  receiver of the syslog
> > message will not be
> > >    able  to  ascertain that the message was indeed sent
> > from the reported
> > >    sender, or if the packet was sent from another device.
> > >
> > >    One  possible  consequence  of  this  behavior is that a
> > misconfigured
> > >    machine  may send syslog messages to a receiver
> > representing itself as
> > >    another machine. The administrators may not be able to
> > readily discern
> > >    that  there  are  two  or more machines representing
> > themselves as the
> > >    same machine.
> > >
> > _________________________________________________________________
> > >
> > >
> >     [75]
> > > TOC
> > >
> > >   7. Security Considerations
> > >
> > >    Several   syslog   security  considerations  have  been
> > discussed  in
> > >    [76]RFC-protocolGerhards,  R.,  The  syslog  Protocol,
> > .[2] and in the
> > >    original  [77]RFC  3164Lonvick,  C.,  The  BSD Syslog
> > Protocol, August
> > >    2001.[1].  This section focuses on security
> > considerations specific to
> > >    the syslog transport over UDP.
> > >
> > >     7.1 Message Authenticity
> > >
> > >    This transport protocol does not strongly authenticate
> > the identity of
> > >    the message sender and does not provide any assurance
> > that the message
> > >    was  not  modified in transit. The receiver of the
> > syslog message will
> > >    not  be  able  to  ascertain that the message was indeed
> > sent from the
> > >    reported sender, or if the packet was sent from another device.
> > >
> > >     7.2 Message Forgery
> > >
> > >    Syslog  messages can be easily forged. An attacker may
> > transmit syslog
> > >    messages  (either  from  the  machine  from  which  the
> > messages  are
> > >    purportedly sent or from any other machine) to a receiver.
> > >
> > >    In  one case, an attacker may hide the true nature of an
> > attack amidst
> > >    many  other  messages. As an example, an attacker may
> > start generating
> > >    forged messages indicating a problem on some machine.
> > This may get the
> > >    attention  of  the  system  administrators  who  will
> > spend their time
> > >    investigating  the alleged problem. During this time,
> > the attacker may
> > >    be  able  to compromise a different machine, or a
> > different process on
> > >    the same machine.
> > >
> > >    Additionally,  an  attacker may generate false syslog
> > messages to give
> > >    untrue  indications of status or of events. As an
> > example, an attacker
> > >    may  stop  a  critical  process  on  a  machine,  which
> > may generate a
> > >    notification  of exit. The attacker may subsequently
> > generate a forged
> > >    notification   that   the  process  had  been
> > restarted.  The  system
> > >    administrators  may accept that misinformation and not
> > verify that the
> > >    process had indeed been restarted.
> > >
> > >     7.3 Message Observation
> > >
> > >    The  transport  protocol  does  not  provide
> > confidentiality  of  the
> > >    messages in transit. If syslog messages are in clear
> > text, this is how
> > >    they   will   be   transferred.   In  most  cases
> > passing  clear-text
> > >    human-readable   messages   is   a   benefit  to  the
> > administrators.
> > >    Unfortunately,   an   attacker   may  also  be  able  to
> >  observe  the
> > >    human-readable  contents of syslog messages. The
> > attacker may then use
> > >    the knowledge gained from those messages to compromise a
> > machine or do
> > >    other  damage.  It  is  RECOMMENDED  that  no sensitive
> > information is
> > >    transmitted  via  this transport protocol or that
> > transmission of such
> > >    information is restricted to properly secured networks.
> > >
> > >     7.4 Replaying
> > >
> > >    Message  forgery and observation can be combined into a
> > replay attack.
> > >    An attacker may record a set of messages that indicate
> > normal activity
> > >    of  a  machine. At a later time, that attacker may
> > remove that machine
> > >    from  the network and replay the syslog messages to the
> > collector with
> > >    new  time  stamps.  The administrators may find nothing
> > unusual in the
> > >    received  messages  and  their  receipt  would falsely
> > indicate normal
> > >    activity of the machine.
> > >
> > >     7.5 Unreliable Delivery
> > >
> > >    As was previously discussed in the Reliability
> > Considerations section,
> > >    the  UDP  transport  is  not  reliable  and  packets
> > containing syslog
> > >    message datagrams can be lost in transit without any
> > notice. There can
> > >    be  security  consequences to the loss of one or more
> > syslog messages.
> > >    Administrators  may  not  become aware of a developing
> > and potentially
> > >    serious  problem. Messages may also be intercepted and
> > discarded by an
> > >    attacker as a way to hide unauthorized activities.
> > >
> > >     7.6 Message Prioritization and Differentiation
> > >
> > >    The  transport  protocol  described  in this document
> > does not require
> > >    prioritization of syslog messages on the wire or when
> > processed on the
> > >    receiving  host  based  on their severity. The security
> > implication of
> > >    such  behavior  is that the syslog receiver or network
> > devices may get
> > >    overwhelmed  with  low  severity  messages  and  be
> > forced to discard
> > >    potentially high severity messages. High severity
> > messages may contain
> > >    indication  about  serious  security problems, but they
> > will not get a
> > >    higher  priority.  It  is  difficult to make sure that
> > high severities
> > >    messages  get  higher end-to-end delivery priority,
> > especially over an
> > >    unreliable UDP transport.
> > >
> > >    On  a  case-by-case  basis,  device  operators  may
> > find  some way to
> > >    associate  the  different  severity levels with the
> > quality of service
> > >    identifiers.  As  an  example,  the operators may elect
> > to define some
> > >    linkage  between  syslog  messages that have a specific
> > Priority value
> > >    with  a  specific  value  to  be  used  in  the  IPv4
> > Precedence field
> > >    [78][4]Postel,  J.,  Internet  Protocol,  September
> > 1981.,  the  IPv6
> > >    Traffic  Class  octet  [79][5]Deering,  S.  and  R.
> > Hinden,  Internet
> > >    Protocol,  Version  6  (IPv6)  Specification,  December
> > 1998., or the
> > >    Differentiated Services field [80][9]Nichols, K., Blake,
> > S., Baker, F.
> > >    and  D.  Black,  Definition  of  the Differentiated
> > Services Field (DS
> > >    Field)  in  the  IPv4  and IPv6 Headers, December 1998..
> > However, even
> > >    with  this prioritization on the network, high load can
> > lead to buffer
> > >    starvation on the receiving host and result in dropped
> messages.
> > >
> > >     7.7 Denial of Service
> > >
> > >    An  attacker  may  overwhelm a receiver by sending more
> > messages to it
> > >    than  can  be  handled  by  the  infrastructure  or the
> > device itself.
> > >    Implementers  SHOULD  attempt  to  provide features that
> > minimize this
> > >    threat such as only receiving syslog messages from known
> > IP addresses.
> > >
> > _________________________________________________________________
> > >
> > >
> >     [81]
> > > TOC
> > >
> > >   8. IANA Considerations
> > >
> > >    IANA must reserve UDP port 514 for this transport.
> > >
> > _________________________________________________________________
> > >
> > >
> >     [82]
> > > TOC
> > >
> > >   9. Notice to RFC Editor
> > >
> > >    This is a notice to the RFC editor. This ID is submitted
> > along with ID
> > >    draft-ietf-syslog-protocol  and  they cross-reference
> > each other. When
> > >    RFC  numbers  are determined for each of these IDs,
> > please replace all
> > >    references    to    "RFC-protocol"    with    the    RFC
> >   number   of
> > >    draft-ietf-syslog-protocol   ID.  Please  remove  this
> > section  after
> > >    editing.
> > >
> > _________________________________________________________________
> > >
> > >
> >     [83]
> > > TOC
> > >
> > >   10. Authors and Working Group Chair
> > >
> > >    The working group can be contacted via the mailing list:
> > > [email-masked]
> > >
> > >    The current Chair of the Working Group may be contacted
> > at: Chris
> > > Lonvick Cisco Systems
> > > Email: [email-masked]
> > >
> > >    The author of this draft is:
> > > Anton Okmianski
> > > Email: [email-masked]
> > >
> > > Phone: (978) 936-1612
> > > Fax: (978) 936-2225
> > >
> > > Cisco Systems, Inc
> > > 1414 Massachusetts Ave.
> > > Boxborough, MA 01719-2205
> > > USA
> > >
> > _________________________________________________________________
> > >
> > >
> >     [84]
> > > TOC
> > >
> > >   11. Acknowledgements
> > >
> > >    The  author  wishes  to  thank  Chris  Lonvick, Rainer
> > Gerhards, David
> > >    Harrington,  Andrew  Ross,  Albert Mietus, Bernie Volz,
> > and all others
> > >    who have commented on the various versions of this proposal.
> > >
> > _________________________________________________________________
> > >
> > >
> >     [85]
> > > TOC
> > >
> > >   12 References
> > >
> > >    [1] Lonvick, C., "[86]The BSD Syslog Protocol", RFC
> > 3164, August 2001.
> > >    [2] Gerhards, R., "[87]The syslog Protocol", RFC RFC-protocol.
> > >    [3] Postel, J., "[88]User Datagram Protocol", STD 6, RFC
> > 768, August
> > >    1980.
> > >    [4]  Postel,  J.,  "[89]Internet  Protocol", STD 5, RFC
> > 791, September
> > >    1981.
> > >    [5] [90]Deering, S. and [91]R. Hinden, "[92]Internet
> > Protocol, Version
> > >    6 (IPv6) Specification", RFC 2460, December 1998
> > ([93]HTML, [94]XML).
> > >    [6]  [95]Bradner,  S.,  "[96]Key  words  for  use  in
> > RFCs to Indicate
> > >    Requirement Levels", BCP 14, RFC 2119, March 1997
> > ([97]HTML, [98]XML).
> > >    [7]  [99]Crocker,  D.  and  [100]P.  Overell,
> > "[101]Augmented BNF for
> > >    Syntax Specifications: ABNF", RFC 2234, November 1997.
> > >    [8]  Stevens,  W.,  "TCP/IP  Illustrated  Volume  1.
> > The Protocols.",
> > >    January 1994.
> > >    [9]  [102]Nichols,  K.,  [103]Blake,  S.,  [104]Baker,
> > F. and [105]D.
> > >    Black,  "[106]Definition  of  the  Differentiated
> > Services  Field (DS
> > >    Field)  in  the  IPv4  and  IPv6  Headers",  RFC  2474,
> > December 1998
> > >    ([107]HTML, [108]XML).
> > >    [10]   Mockapetris,   P.,  "[109]Domain  names  -
> > implementation  and
> > >    specification", STD 13, RFC 1035, November 1987.
> > >    [11]  Hedrick, C., "[110]Routing Information Protocol",
> > RFC 1058, June
> > >    1988.
> > >    [12]  [111]Droms,  R., "[112]Dynamic Host Configuration
> > Protocol", RFC
> > >    2131, March 1997 ([113]HTML, [114]XML).
> > >    [13]  [115]Sollins, K., "[116]The TFTP Protocol
> > (Revision 2)", STD 33,
> > >    RFC 1350, July 1992.
> > >    [14]   [117]Braden,   R.,  "[118]Requirements  for
> > Internet  Hosts  -
> > >    Communication Layers", STD 3, RFC 1122, October 1989.
> > >    [15]  Kent,  C.  and  J.  Mogul,  ""Fragmentation
> > Considered Harmful,"
> > >    Computer  Communications  Review,  vol.17,  no.5,
> > pp.390-401", August
> > >    1987.
> > >
> > _________________________________________________________________
> > >
> > >
> >    [119]
> > > TOC
> > >
> > >   Author's Address
> > >
> > >            Anton Okmianski
> > >            Cisco Systems, Inc.
> > >            1414 Massachusetts Ave
> > >            Boxborough, MA 01719-2205
> > >            USA
> > >    EMail:  [email-masked]
> > >
> > _________________________________________________________________
> > >
> > >
> >    [120]
> > > TOC
> > >
> > >   Appendix A. Rational For Transport Message Size Restrictions
> > >
> > >    This   appendix   provides   the  rational  behind  the
> > Payload  size
> > >    restrictions  for  this protocol. The Payload
> > restrictions outlined in
> > >    the  specification, essentially ensure that the
> > transport message size
> > >    does  not  exceed 512 bytes (without UDP/IP headers) for
> > transport via
> > >    IPv4  and  does  not  exceed  1196 bytes for transport
> > via IPv6. These
> > >    restrictions  put  an  upper  boundary on the UDP/IP
> > datagram size for
> > >    this protocol, which accomplishes two goals.
> > >
> > >    First,   they   insure   interoperability   between
> > various   UDP/IP
> > >    implementations. Even though the maximum IP datagram
> > size is specified
> > >    as  65536  bytes,  many  UDP/IP implementations have
> > been shown not to
> > >    work with large datagram sizes [121][8]Stevens, W.,
> > TCP/IP Illustrated
> > >    Volume  1.  The  Protocols., January 1994.. Many
> > established UDP-based
> > >    protocols  restrict  UDP datagram data size to 512
> > bytes. For example,
> > >    DNS  [122][10]Mockapetris,  P.,  Domain  names  -
> > implementation  and
> > >    specification,  November  1987.  and RIP
> > [123][11]Hedrick, C., Routing
> > >    Information  Protocol,  June 1988. do that. The DHCPv4
> > [124][12]Droms,
> > >    R.,  Dynamic  Host  Configuration  Protocol, March 1997.
> > restricts the
> > >    size to 512 bytes, but allows sides to agree on a larger
> > value through
> > >    the  protocol.  The  TFTP  [125][13]Sollins,  K.,  The
> > TFTP  Protocol
> > >    (Revision  2),  July  1992.  restricts the UDP data size
> > to 518 bytes,
> > >    which is slightly larger.
> > >
> > >    The  second  reason  for  datagram  size restrictions is
> > that it helps
> > >    reduce  the  likelihood  of  the IP-layer datagram
> > fragmentation. This
> > >    could have potentially resulted in fragmentation on two
> > levels: syslog
> > >    transport  protocol  and IP layer. Since fragmentation
> > has significant
> > >    overhead   for  message  reassembley,  it  is  best  to
> > avoid  double
> > >    fragmentation. The likelihood of IP fragmentation can be
> > significantly
> > >    reduced  by sending IP datagrams in sizes which all
> > hosts must be able
> > >    to process.
> > >
> > >    The minimum MTU of a transport protocol determines the
> > minimum size of
> > >    packets  that  hosts must be able to accept. For IPv4,
> > the minimum MTU
> > >    is  576  bytes  [126][4]Postel, J., Internet Protocol,
> > September 1981.
> > >    and  for IPv6 - 1280 bytes [127][5]Deering, S. and R.
> > Hinden, Internet
> > >    Protocol,  Version  6  (IPv6)  Specification,  December
> > 1998.. In both
> > >    cases,  the  maximum  message size we chose fits within
> > the MTU of the
> > >    transport  in all cases except for when extremely large
> > IP headers are
> > >    used.  IPv4  header  can  range  from 20 to 60 bytes in
> > length and UDP
> > >    header is fixed at 8 bytes. Thus, our message size
> > restrictions ensure
> > >    that  in  all  cases  except  for  when  the  IP header
> > is 56 bytes or
> > >    greater,  the size of the packet will within the size of
> > the transport
> > >    MTU.
> > >
> > >    For  IPv6,  we have left the same amount of padding for
> > UDP/IP headers
> > >    as  was  conventionally  done  for IPv4 in DNS, RIP and
> > DHCPv4 with an
> > >    additional  padding  of  extra  20  bytes to accommodate
> > a larger IPv6
> > >    header.   This   follows   the   methodology  suggested
> > in  the  IPv6
> > >    specification    for    calculating    upper-layer
> > payload   limits
> > >    [128][5]Deering, S. and R. Hinden, Internet Protocol,
> > Version 6 (IPv6)
> > >    Specification, December 1998..
> > >
> > >    Path  MTU  discovery  can generally be used to discover
> > the MTU of the
> > >    link.  Unfortunately,  using  path  MTU  discovery  with
> >  UDP is not a
> > >    reliable  option  because  it depends on routers
> > providing ICMP errors
> > >    and  hosts  doing  retransmission,  which  are  not done
> > consistently.
> > >    Implementors  MUST follow the size restrictions outlined
> > above and not
> > >    rely on path MTU discovery.
> > >
> > _________________________________________________________________
> > >
> > >
> >    [129]
> > > TOC
> > >
> > >   Intellectual Property Statement
> > >
> > >    The  IETF  takes  no  position  regarding the validity
> > or scope of any
> > >    intellectual property or other rights that might be
> > claimed to pertain
> > >    to  the  implementation  or  use  of  the technology
> > described in this
> > >    document or the extent to which any license under such
> > rights might or
> > >    might not be available; neither does it represent that
> > it has made any
> > >    effort  to  identify  any  such  rights.  Information
> > on  the  IETF's
> > >    procedures   with   respect   to   rights   in
> > standards-track   and
> > >    standards-related  documentation  can  be  found  in
> > BCP-11. Copies of
> > >    claims  of rights made available for publication and any
> > assurances of
> > >    licenses  to  be  made  available, or the result of an
> > attempt made to
> > >    obtain a general license or permission for the use of
> > such proprietary
> > >    rights  by implementors or users of this specification
> > can be obtained
> > >    from the IETF Secretariat.
> > >
> > >    The  IETF  invites  any interested party to bring to its
> > attention any
> > >    copyrights,  patents  or  patent  applications,  or
> > other proprietary
> > >    rights  which  may  cover  technology that may be
> > required to practice
> > >    this  standard.  Please  address the information to the
> > IETF Executive
> > >    Director.
> > >
> > >   Full Copyright Statement
> > >
> > >    Copyright (C) The Internet Society (2004). All Rights Reserved.
> > >
> > >    This  document  and  translations of it may be copied
> > and furnished to
> > >    others,  and  derivative works that comment on or
> > otherwise explain it
> > >    or assist in its implementation may be prepared, copied,
> > published and
> > >    distributed,  in  whole  or  in part, without
> > restriction of any kind,
> > >    provided  that  the  above  copyright  notice  and  this
> > paragraph are
> > >    included  on  all  such  copies  and  derivative  works.
> > However, this
> > >    document  itself  may  not be modified in any way, such
> > as by removing
> > >    the  copyright  notice  or references to the Internet
> > Society or other
> > >    Internet organizations, except as needed for the purpose
> > of developing
> > >    Internet standards in which case the procedures for
> > copyrights defined
> > >    in  the Internet Standards process must be followed, or
> > as required to
> > >    translate it into languages other than English.
> > >
> > >    The  limited  permissions  granted above are perpetual
> > and will not be
> > >    revoked by the Internet Society or its successors or assignees.
> > >
> > >    This  document  and the information contained herein is
> > provided on an
> > >    "AS  IS"  basis  and THE INTERNET SOCIETY AND THE
> > INTERNET ENGINEERING
> > >    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
> > INCLUDING BUT
> > >    NOT  LIMITED  TO  ANY  WARRANTY THAT THE USE OF THE
> > INFORMATION HEREIN
> > >    WILL   NOT   INFRINGE   ANY   RIGHTS  OR  ANY  IMPLIED
> > WARRANTIES  OF
> > >    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
> > >
> > >   Acknowledgment
> > >
> > >    Funding  for  the  RFC  Editor  function  is currently
> > provided by the
> > >    Internet Society.
> > >
> > > References
> > >
> > >    1.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
> > >    2. http://www.ietf.org/ietf/1id-abstracts.txt
> > >    3. http://www.ietf.org/shadow.html
> > >    4.
> >
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#intro
> > >    5.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#TransportProtocolOverview
> > >    6.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#DefinitionsAndArchitecture
> > >    7.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#RequiredTransportProtocol
> > >    8.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#EncapsulationLayers
> > >    9.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#MessageFormat
> > >   10.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#BasicHeaderFormat
> > >   11.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#ExtendedHeaderFormat
> > >   12.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#Message Identifier
> > >   13.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#TotalLength
> > >   14.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#FragmentOffset
> > >   15.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#ExtendedHeaderExample
> > >   16.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#Payload
> > >   17.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#SupportedMessageLength
> > >   18.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#LowerLayerConsiderations
> > >   19.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#TargetPort
> > >   20.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#SourcePort
> > >   21.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#SourceIPAddress
> > >   22.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#UDPIPHeader
> > >   23.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#FragmentationAndReassembley
> > >   24.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#MessageFragmentation
> > >   25.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#MessageReassembley
> > >   26.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#AvoidingFragmentation
> > >   27.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#reliability
> > >   28.
> >
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#loss
> > >   29.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#corruption
> > >   30.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#overload
> > >   31.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#sequence
> > >   32.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#SenderAuthentication
> > >   33.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#security
> > >   34.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#SecAuth
> > >   35.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#SecForg
> > >   36.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#SecObs
> > >   37.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#SecReplay
> > >   38.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#SecRelDel
> > >   39.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#SecPri
> > >   40.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#SecDen
> > >   41.
> >
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#iana
> > >   42.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#rfc-editor
> > >   43.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#authors
> > >   44.
> >
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#acks
> > >   45.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#rfc.references1
> > >   46.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#rfc.authors
> > >   47.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#AppendixA
> > >   48.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#rfc.copyright
> > >   49.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
> > >   50.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#RFC3164
> > >   51.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#RFC-protocol
> > >   52.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#RFC-protocol
> > >   53.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#RFC0768
> > >   54.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#RFC0791
> > >   55.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#RFC2460
> > >   56.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#RFC2119
> > >   57.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
> > >   58.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#RFC-protocol
> > >   59.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#RFC-protocol
> > >   60.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#RFC-protocol
> > >   61.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#RFC0768
> > >   62.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
> > >   63.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#RFC-protocol
> > >   64.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#RFC2234
> > >   65.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#MessageReassembley
> > >   66.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
> > >   67.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#RFC0768
> > >   68.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#RFC0791
> > >   69.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#RFC2460
> > >   70.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#RFC0768
> > >   71.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#RFC2460
> > >   72.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
> > >   73.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
> > >   74.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#Stevens
> > >   75.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
> > >   76.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#RFC-protocol
> > >   77.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#RFC3164
> > >   78.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#RFC0791
> > >   79.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#RFC2460
> > >   80.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#RFC2474
> > >   81.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
> > >   82.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
> > >   83.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
> > >   84.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
> > >   85.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
> > >   86. ftp://ftp.isi.edu/in-notes/rfc3164.txt
> > >   87. ftp://ftp.isi.edu/in-notes/rfc3164.txt
> > >   88. ftp://ftp.isi.edu/in-notes/rfc768.txt
> > >   89. ftp://ftp.isi.edu/in-notes/rfc791.txt
> > >   90. mailto:[email-masked]
> > >   91. mailto:[email-masked]
> > >   92. ftp://ftp.isi.edu/in-notes/rfc2460.txt
> > >   93. http://xml.resource.org/public/rfc/html/rfc2460.html
> > >   94. http://xml.resource.org/public/rfc/xml/rfc2460.xml
> > >   95. mailto:[email-masked]
> > >   96. ftp://ftp.isi.edu/in-notes/rfc2119.txt
> > >   97. http://xml.resource.org/public/rfc/html/rfc2119.html
> > >   98. http://xml.resource.org/public/rfc/xml/rfc2119.xml
> > >   99. mailto:[email-masked]
> > >  100. mailto:[email-masked]
> > >  101. ftp://ftp.isi.edu/in-notes/rfc2234.txt
> > >  102. mailto:[email-masked]
> > >  103. mailto:[email-masked]
> > >  104. mailto:[email-masked]
> > >  105. mailto:[email-masked]
> > >  106. ftp://ftp.isi.edu/in-notes/rfc2474.txt
> > >  107. http://xml.resource.org/public/rfc/html/rfc2474.html
> > >  108. http://xml.resource.org/public/rfc/xml/rfc2474.xml
> > >  109. ftp://ftp.isi.edu/in-notes/rfc1035.txt
> > >  110. ftp://ftp.isi.edu/in-notes/rfc1058.txt
> > >  111. mailto:[email-masked]
> > >  112. ftp://ftp.isi.edu/in-notes/rfc2131.txt
> > >  113. http://xml.resource.org/public/rfc/html/rfc2131.html
> > >  114. http://xml.resource.org/public/rfc/xml/rfc2131.xml
> > >  115. mailto:[email-masked]
> > >  116. ftp://ftp.isi.edu/in-notes/rfc1350.txt
> > >  117. mailto:[email-masked]
> > >  118. ftp://ftp.isi.edu/in-notes/rfc1122.txt
> > >  119.
> > >
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
> > >  120.
> > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> ml#toc
> >  121.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#Steve
> ns
> >  122.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#RFC10
> 35
> >  123.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#RFC10
> 58
> >  124.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#RFC21
> 31
> >  125.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#RFC13
> 50
> >  126.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#RFC07
> 91
> >  127.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#RFC24
> 60
> >  128.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#RFC24
> 60
> >  129.
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
>
>
> --
> Devin Kowatch
> [email-masked]

- -- 
Devin Kowatch
[email-masked]

------------------------------

Date: Mon, 10 May 2004 19:16:18 -0400
From: "Anton Okmianski" <[email-masked]>
Subject: RE: Transport draft preview

Devin:

If we limit syslog over UDP to somewhere in the area of 512 bytes and
say that larger messages have to be transported via other
transport(s), are we going to then say that implementation of this
other transport is also required? I think it would be pretty tough to
proposition to require people to implement both transports and it
would be an operational risk to run a mixed environment.

Or should we just say that 512 bytes for IPv4 (and if we want ~1190
for IPv6) is the max size of syslog message. Period. If we think of
syslog as a mechanism to provide notifications only and not a general
logging mechanism it is perfectly acceptable.  The details of the
error could be in the application's log files, state, etc. After all
transmitting an OS core file over syslog while could be helpful is
probably a wrong thing to do. And I think syslog is not a replacement
for logging to a local file.  So, my example of a large crash
diagnostic message that one of our applications logs would be the case
of something that SHOULD NOT go over syslog. Instead only a
notification of a crash with a possible basic reason why and possible
a mention of where extra details can be found should be in a syslog
message.

I am not thrilled at all about supporting fragmentation for UDP
transport.  But I don't like the idea of a mixed environment either.

I am also curious about what people think about how syslog compares
with SNMP notifications (informs - acknowledged and secure, and traps
- - unacknowledged and unreliable).  If syslog is a mechanism to notify
of state changes, then what's its role vis-à-vis SNMP notifications?

Thanks,
Anton.

> -----Original Message-----
> From: Devin Kowatch [mailto:[email-masked]]
> Sent: Monday, May 10, 2004 5:56 PM
> To: Anton Okmianski
> Cc: [email-masked]
> Subject: Re: Transport draft preview
>
>
> On Mon, May 10, 2004 at 03:26:14PM -0400, Anton Okmianski wrote:
> > Devin:
> >
> > > There is one point which I'm not completely clear on.  What
> > > happens to a fragmented message when one ore more parts of
> > > that message get dropped?
> >
> > Just like with IP fragmentation, the whole message (all other
> > fragments) gets discarded.  It is mentioned in the Message
> Reassembly
> > section. A couple other sections (Avoiding Fragmentation and Lost
> > Datagrams) imply it.  But since you are not the first person to
ask
> > this, I will make sure to put this more prominently
> somewhere in the
> > draft.
> >
> > Of course we should not prevent the implementation from logging
the
> > received fragments of an incomplete message somewhere for
> debugging.
> > So, I am not clear if a putting a MUST is a good idea.
>
> Okay, thanks.
> >
> > > One other suggestion ... why not just limit UDP packets to
> > > 1024 bytes, whith no fragmentation?
> >
> > With IPv4, transferring UDP datagrams of that size may not
> be reliable
> > to my knowledge (well less reliable than it is UDP usually is :)).

> > Most UDP protocols restrict the size to a much smaller
> size. I don't
> > know of popular UDP-based protocols that allow 1024 bytes UDP
> > datagrams. If there are some they could serve as sufficient
> proof that
> > this datagram size in UDP is acceptable. See discussion of packets

> > sizes in Appendix A of my draft.
>
> I chose 1024 becasue that was the size limit specified in
> RFC3164 (section 4.1).  Most of the log messages I have seen
> (under unix) are less than 300 bytes though.
>
> >
> > > For large syslog
> > > messages, require a reliable transport layer (TCP) which
> > > means you can just properly frame the message and send it (or
> > > use something like BEEP which already deals with
> > > fragmentation) ...
> >
> > I am not sure if it is a good idea to require different transport
> > depending on a message size.
>
> My biggest argument for doing so, is that it seems eaiser to
> support large messages over a reliable transport ... But I
> see you mostly agree with that sentiment (last sentence of
> the next paragraph).
>
> >
> > I am also not sure if 1024 bytes is sufficient.  I know one
> product I
> > work on at Cisco which has a crash diagnostic message which
> consists
> > of about 1000-1500 lines.  So, it is about 80-130K. Even
> bigger than
> > the 65K MUST-support size I proposed for udp-transport. I
> just think
> > transferring huge fragmented messages over unreliable
> transport is not
> > a good idea. Hence, larger size are not a requirement, but a
> > recommendation.
>
> On the other hand a 1024 byte limit or ever 512 byte limit
> won't leave us much worse off than we are with RFC3164, and
> is sufficient for most purposes (under unix at least).  Then
> use a reliable transport to send larger messages (good
> encouragement for people to switch too).
>
> >
> > As far as using TCP, I am actually thinking more along the lines
of
> > UDP with acknowledgements (like in TFTP) for a future protocol. It

> > would still be lighter and the acknowledgments would be more high
> > level. For example, a receiver can acknowledge the message after
it
> > persisted it to disk instead of like in TCP, where a stack
> > acknowledges the message as it is received by the host (and if the

> > systems crashes an the message is lost, oh well). Using TCP often
> > results in additional higher-level protocol acknowledgements being

> > sent.
>
> Ummm... you've heard the saying about thoes who don't
> understand TCP are doomed to reimplement it, badly?  Not
> saying that's the case here ... just seemed like a good time
> to rememeber it.
>
> I've looked at this (for my own syslog deamon), and I believe
> that it's simpler to build application level ACKS on top of
> TCP than it is to build a reliable network protocol on top of
> UDP.  Also, building on TCP allows a vastly simpler
> implementation if the application level ACK is either skipped
> or sent back as soon as the message is received, which isn't
> a bad thing all the time.  Pushing back the application level
> ACK to a point where the message is on disk could be a more
> advanced feature (and is more difficult to implement correctly).
>
> >
> > I was thinking about putting a MessageId field into every message
> > (including basic header) such that adding acknowledgements
> later would
> > not change the format of the message, but I bailed out on that as
I
> > think this increases scope.  If people think that this may not be
a
> > bad idea, I can put it in there.
> >
> > Thanks,
> > Anton.
> >
> >
> >
> > >
> > > On Fri, May 07, 2004 at 04:36:25PM -0400, Anton Okmianski wrote:
> > > > Hi!
> > > >
> > > > I am about to publish the new UDP syslog transport draft. I
> > thought
> > > > I'd show it this forum first before making it publicly
> > > available to a wider audience.  In particular, I want to make
> > > sure we have rough consensus on support for fragmentation
> > > feature.  I have specified the header format using ASCII
> > > encoding as was suggested by Rainer and Andrew.
> > > >
> > > > I plan on submitting this as an official draft next week.
> > > One area I
> > > > am not quite sure about yet is what minimum size of messages
> > should
> > > > implementations be forced to support. It definitely can't
> > > be the full
> > > > allowed size of 16MB as some hardware won't support it.
> > > Right now it
> > > > is set at 65k, which means implementations are forced to
support
> > > > fragmentation.  I wonder if reducing it to the size where
> > > > fragmentation would be optional (507 bytes for IPv4 and
> > > 1911 for IPv6)
> > > > would increase the adoption of the protocol without
sacrificing
> > too
> > > > much of interoperability. Fragmentation feature adds orders of
> > > > magnitude more complexity than non-fragmented syslog
> > > transport.  Any
> > > > opinions?
> > > >
> > > > Thanks,
> > > > Anton.
> > >
> > > >
> > > >
> > > >
> > > > syslog Working Group
> > > A. Okmianski
> > > > Internet-Draft                                       Cisco
> > > Systems, Inc.
> > > > Expires: November 5, 2004
> > >  May 7, 2004
> > > >
> > > >
> > > >                 Transmission of syslog messages over UDP
> > > >                    draft-ietf-syslog-transport-udp-01
> > > >
> > > > Status of this Memo
> > > >
> > > >    This document is an Internet-Draft and is in full
> > > conformance with
> > > >    all provisions of Section 10 of RFC2026.
> > > >
> > > >    Internet-Drafts are working documents of the Internet
> > Engineering
> > > >    Task Force (IETF), its areas, and its working groups.
> > > Note that other
> > > >    groups may also distribute working documents as
> > Internet-Drafts.
> > > >
> > > >    Internet-Drafts are draft documents valid for a maximum
> > > of six months
> > > >    and may be updated, replaced, or obsoleted by other
> > > documents at any
> > > >    time. It is inappropriate to use Internet-Drafts as
reference
> > > >    material or to cite them other than as "work in progress."
> > > >
> > > >    The list of current Internet-Drafts can be accessed
> at http://
> > > >    www.ietf.org/ietf/1id-abstracts.txt.
> > > >
> > > >    The list of Internet-Draft Shadow Directories can be
accessed
> > at
> > > >    http://www.ietf.org/shadow.html.
> > > >
> > > >    This Internet-Draft will expire on November 5, 2004.
> > > >
> > > > Copyright Notice
> > > >
> > > >    Copyright (C) The Internet Society (2004). All
> Rights Reserved.
> > > >
> > > > Abstract
> > > >
> > > >    This document describes the transport for the syslog
message
> > 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
> > using
> > > >    multiple datagrams.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Okmianski               Expires November 5, 2004
> > >     [Page 1]
> > > > > >
> > > > Internet-Draft            syslog udp transport
> > >     May 2004
> > > >
> > > >
> > > > Table of Contents
> > > >
> > > >    1.  Introduction . . . . . . . . . . . . . . . . . . . .
> > > . . . . .  3
> > > >    2.  Transport Protocol Overview  . . . . . . . . . . . .
> > > . . . . .  4
> > > >      2.1   Definitions and Architecture . . . . . . . . . .
> > > . . . . .  4
> > > >      2.2   Required Transport Protocol  . . . . . . . . . .
> > > . . . . .  4
> > > >      2.3   Encapsulation Layers . . . . . . . . . . . . . .
> > > . . . . .  4
> > > >    3.  Message Format . . . . . . . . . . . . . . . . . . .
> > > . . . . .  6
> > > >      3.1   Basic Header Format  . . . . . . . . . . . . . .
> > > . . . . .  6
> > > >      3.2   Extended Header Format . . . . . . . . . . . . .
> > > . . . . .  7
> > > >        3.2.1   Message Identifier . . . . . . . . . . . . .
> > > . . . . .  7
> > > >        3.2.2   Total Length . . . . . . . . . . . . . . . .
> > > . . . . .  7
> > > >        3.2.3   Fragment Offset  . . . . . . . . . . . . . .
> > > . . . . .  8
> > > >        3.2.4   Extended Header Example  . . . . . . . . . .
> > > . . . . .  8
> > > >      3.3   Payload  . . . . . . . . . . . . . . . . . . . .
> > > . . . . .  9
> > > >      3.4   Supported Message Length . . . . . . . . . . . .
> > > . . . . .  9
> > > >    4.  UDP/IP Layer Considerations  . . . . . . . . . . . .
> > > . . . . . 10
> > > >      4.1   Target Port  . . . . . . . . . . . . . . . . . .
> > > . . . . . 10
> > > >      4.2   Source Port  . . . . . . . . . . . . . . . . . .
> > > . . . . . 10
> > > >      4.3   Source IP Address  . . . . . . . . . . . . . . .
> > > . . . . . 10
> > > >      4.4   UDP/IP Headers . . . . . . . . . . . . . . . . .
> > > . . . . . 10
> > > >    5.  Fragmentation and Reassembley  . . . . . . . . . . .
> > > . . . . . 12
> > > >      5.1   Message Fragmentation  . . . . . . . . . . . . .
> > > . . . . . 12
> > > >      5.2   Message Reassembley  . . . . . . . . . . . . . .
> > > . . . . . 12
> > > >      5.3   Avoiding Fragmentation . . . . . . . . . . . . .
> > > . . . . . 13
> > > >    6.  Reliability Considerations . . . . . . . . . . . . .
> > > . . . . . 14
> > > >      6.1   Lost Datagrams . . . . . . . . . . . . . . . . .
> > > . . . . . 14
> > > >      6.2   Message Corruption and Checksums . . . . . . . .
> > > . . . . . 14
> > > >      6.3   Congestion Control . . . . . . . . . . . . . . .
> > > . . . . . 14
> > > >      6.4   Sequenced Delivery . . . . . . . . . . . . . . .
> > > . . . . . 14
> > > >      6.5   Sender Authentication  . . . . . . . . . . . . .
> > > . . . . . 15
> > > >    7.  Security Considerations  . . . . . . . . . . . . . .
> > > . . . . . 16
> > > >      7.1   Message Authenticity . . . . . . . . . . . . . .
> > > . . . . . 16
> > > >      7.2   Message Forgery  . . . . . . . . . . . . . . . .
> > > . . . . . 16
> > > >      7.3   Message Observation  . . . . . . . . . . . . . .
> > > . . . . . 16
> > > >      7.4   Replaying  . . . . . . . . . . . . . . . . . . .
> > > . . . . . 17
> > > >      7.5   Unreliable Delivery  . . . . . . . . . . . . . .
> > > . . . . . 17
> > > >      7.6   Message Prioritization and Differentiation . . .
> > > . . . . . 17
> > > >      7.7   Denial of Service  . . . . . . . . . . . . . . .
> > > . . . . . 18
> > > >    8.  IANA Considerations  . . . . . . . . . . . . . . . .
> > > . . . . . 19
> > > >    9.  Notice to RFC Editor . . . . . . . . . . . . . . . .
> > > . . . . . 20
> > > >    10.   Authors and Working Group Chair  . . . . . . . . .
> > > . . . . . 21
> > > >    11.   Acknowledgements . . . . . . . . . . . . . . . . .
> > > . . . . . 22
> > > >    12.   References . . . . . . . . . . . . . . . . . . . .
> > > . . . . . 22
> > > >        Author's Address . . . . . . . . . . . . . . . . . .
> > > . . . . . 23
> > > >    A.  Rational For Transport Message Size Restrictions . .
> > > . . . . . 24
> > > >        Intellectual Property and Copyright Statements . . .
> > > . . . . .
> > > > 26
> > > >
> > > >
> > > >
> > > >
> > > > Okmianski               Expires November 5, 2004
> > >     [Page 2]
> > > > > >
> > > > Internet-Draft            syslog udp transport
> > >     May 2004
> > > >
> > > >
> > > > 1.  Introduction
> > > >
> > > >    The original syslog protocol has been described in an
> > > informational
> > > >    RFC 3164 [1] as it has been observed in existing
> > > implementations. It
> > > >    describes both the semantics of syslog message format as
> > > well as a
> > > >    UDP transport.  Subsequently, the syslog protocol has
> > > been formally
> > > >    defined in a standards track RFC-protocol [2].
> > > >
> > > >    The RFC-protocol [2] has provided for support of any
> number of
> > > >    transport layer protocols for transmitting syslog
> > > messages and left
> > > >    it to subsequent RFCs to specify transport protocols.
> > > This standards
> > > >    track RFC describes the UDP transport for the syslog
> > > protocol. This
> > > >    transport protocol is REQUIRED for all syslog protocol
> > > >    implementations.
> > > >
> > > >    This transport protocol was designed to work on top of
> > > UDP [3] over
> > > >    both IPv4 [4] and IPv6 [5]. This protocol overcomes the
data
> > size
> > > >    restrictions of the UDP protocol by introducing message
> > > fragmentation
> > > >    feature.
> > > >
> > > >    As we will show in this specification, this protocol has
> > > significant
> > > >    reliability and security issues stemming from the use of
UDP.
> > > >    However, this protocol is lightweight and extends on the
> > existing
> > > >    popular use of UDP for syslog. Network administrators
> > > and architects
> > > >    should be aware of the shortcomings of this protocol and
plan
> > > >    accordingly.
> > > >
> > > >    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
> > > "SHALL NOT",
> > > >    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
> > > "OPTIONAL" in this
> > > >    document are to be interpreted as described in RFC 2119
[6].
> > The
> > > >    words 'byte' and 'octet' are used interchangeably in this
> > > >    specification.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Okmianski               Expires November 5, 2004
> > >     [Page 3]
> > > > > >
> > > > Internet-Draft            syslog udp transport
> > >     May 2004
> > > >
> > > >
> > > > 2.  Transport Protocol Overview
> > > >
> > > > 2.1  Definitions and Architecture
> > > >
> > > >    The following definitions will be used in this document:
> > > >    o  An application that can generate syslog messages will
> > > be referred
> > > >       to as a "sender";
> > > >    o  An application that can receive syslog messages will
> > > be referred
> > > >       to as a "receiver".
> > > >
> > > >    An application can function in dual capacity. For
> > > example, a syslog
> > > >    relay may receive and forward messages. A single system
> > > can host any
> > > >    number of syslog senders. Only one syslog receiver can
> > > be hosted on a
> > > >    single system using the standard listening port.
> > > >
> > > > 2.2  Required Transport Protocol
> > > >
> > > >    This document describes the UDP transport layer protocol
for
> > the
> > > >    syslog protocol RFC-protocol [2]. Every syslog sender
> > > and receiver
> > > >    implementation which adheres to the RFC-protocol [2]
> MUST fully
> > > >    implement the transport protocol specified in this
document.
> > > >    Implementations does not have to support both IPv4 and
> > > IPv6 if it is
> > > >    designed to be used over only one of these protocols.
> > > >
> > > > 2.3  Encapsulation Layers
> > > >
> > > >    Syslog UDP transport carries syslog messages as
> generic payload
> > > >    encapsulated with a syslog transport header, UDP
> header and an
> > IP
> > > >    header. Below is a summary of syslog UDP/IP packet
> > > structure as used
> > > >    this transport protocol:
> > > >
> > > >
> > > >    		+--------------------------------+
> > > >    		|       IPv4 or IPv6 Header      |
> > > >    		|        (20 or more bytes)      |
> > > >    		+--------------------------------+
> > > >    		|           UDP Header           |
> > > >    		|           (8 bytes)            |
> > > >    		+--------------------------------+
> > > >    		|    Syslog Transport Header     |
> > > >    		|        (5 or 32 bytes)         |
> > > >    		+--------------------------------+
> > > >    		|     Syslog Message Payload     |
> > > >    		|       (1 to 1191 bytes)        |
> > > >    		+--------------------------------+
> > > >
> > > >    Small syslog messages are transmitted using one UDP/IP
> > > datagram per
> > > >    message. However, syslog protocol [2] allows
> messages as large
> > as
> > > >
> > > >
> > > >
> > > > Okmianski               Expires November 5, 2004
> > >     [Page 4]
> > > > > >
> > > > Internet-Draft            syslog udp transport
> > >     May 2004
> > > >
> > > >
> > > >    16777216 bytes, while UDP/IP datagram cannot exceed a
> > > total size of
> > > >    65526 bytes [3] and most existing protocols restrict the
> > > size of UDP
> > > >    data to much less. In order to support transmitting
> > > large messages
> > > >    over UDP/IP, this transport protocol supports
> > > fragmentation of large
> > > >    syslog messages into multiple UDP/IP datagrams for
> > > transmission and
> > > >    reassembley on the receiving end.
> > > >
> > > >    Each syslog UDP/IP datagram MUST contain one and only
> > > one complete
> > > >    syslog message or one fragment of a message.
> > > Transmitting multiple
> > > >    messages or multiple fragments of different messages in
> > > a single UDP
> > > >    datagram is not supported by this protocol.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Okmianski               Expires November 5, 2004
> > >     [Page 5]
> > > > > >
> > > > Internet-Draft            syslog udp transport
> > >     May 2004
> > > >
> > > >
> > > > 3.  Message Format
> > > >
> > > >    The syslog transport message consist of a transport
> header and
> > a
> > > >    syslog message payload. The format of the transport header
is
> > > >    different for fragmented and non-fragmented messages.
Basic
> > > >    transport header is used for non-fragmented messages and
> > extended
> > > >    transport header is used for fragmented messages.
> > > >
> > > >    An ASCII-based encoding was chosen for the syslog
> transport for
> > > >    consistency with the RFC-protocol [2].  Syslog transport
> > > datagrams
> > > >    without required UDP and IP headers have the following
> > > format in ABNF
> > > >    [7] notation:
> > > >
> > > >
> > > >        SyslogTransportMessage = ( BasicHeader / ExtendedHeader
)
> > > >                                          SP Payload
> > > >
> > > >        BasicHeader     = Version SP "0"
> > > >        Version         = %d118 1*3DIGIT   ; "v1" in this
version
> > > >
> > > >        ExtendedHeader  = Version SP "1" SP MessageId
> > > >                          SP TotalLength SP FragmentOffset
> > > >
> > > >        MessageId       = 1*8DIGIT        ; 0 to 16777215
> > > >        TotalLength     = 1*8DIGIT        ; 1 to 16777216
> > > >        FragmentOffset  = 1*8DIGIT        ; 0 to 16777215
> > > >        Payload         = 1*1191OCTET
> > > >
> > > >        OCTET           = %d00-255
> > > >        DIGIT           = %d48-57
> > > >        SP              = %d32
> > > >
> > > >
> > > > 3.1  Basic Header Format
> > > >
> > > >    When no fragmentation is used and the entire syslog
> message is
> > > >    transferred as a single UDP/IP datagram, a basic syslog
> > transport
> > > >    header MUST be used.  The version for this protocol is
> > > "1". It must
> > > >    be followed by one space and a "0" to indicate that this
> > > is a basic
> > > >    header.   Therefore, the only possible value for the
> > > basic header in
> > > >    this protocol is as follows:
> > > >
> > > >
> > > >       "v1 0 "
> > > >
> > > >    Example of a syslog message without the transport header
> > > (message is
> > > >    wrapped for display):
> > > >
> > > >
> > > >
> > > >
> > > > Okmianski               Expires November 5, 2004
> > >     [Page 6]
> > > > > >
> > > > Internet-Draft            syslog udp transport
> > >     May 2004
> > > >
> > > >
> > > >       "v1 888 3 2003-10-11T22:14:15.003Z host.domain.com
> > > >       dns: configuration error"
> > > >
> > > >    Example of the same message with the transport
> header (message
> > is
> > > >    wrapped for display):
> > > >
> > > >
> > > >       "v1 0 v1 888 4 2003-10-11T22:14:15.003Z host.domain.com
> > > >       dns: configuration error"
> > > >
> > > >
> > > > 3.2  Extended Header Format
> > > >
> > > >    When syslog message is fragmented by the sender, multiple
UDP
> > > >    datagrams must be used and each datagram MUST contain an
> > extended
> > > >    syslog transport header. The version for this protocol
> > > is "1". The
> > > >    version field MUST be followed by a single space and a "1"
to
> > > >    indicate that this is an extended header.  Thus, an
> > > extended header
> > > >    MUST always begin with "v1 1 ", but MUST also have
> > > additional fields
> > > >    which aid in fragmentation.
> > > >
> > > >    The MessageId, TotalLength and FragmentOffset fields are
> > > used solely
> > > >    for fragmentation of long messages and reassembley.
> > > They SHOULD NOT
> > > >    be used for other purposes.
> > > >
> > > > 3.2.1  Message Identifier
> > > >
> > > >    The MessageId field (along with the source UDP port
> and the IP
> > > >    address) is used to identify the message such that
> fragments of
> > a
> > > >    single syslog message can be reassembled by the
> receiver into a
> > > >    complete message.  The MessageId field MUST be a numeric
> > > value in the
> > > >    range of 0 to 16777215.  Leading zeros MUST not be present
in
> > the
> > > >    MessageId field.
> > > >
> > > >    Each syslog sender process MUST choose a random
> MessageId value
> > > >    within the supported range for its first message.
> > > Subsequent messages
> > > >    generated by the same process MUST each increment the
> > > MessageId by 1
> > > >    up to 16777215 and then continue at 0. Using random value
for
> > the
> > > >    first MessageId helps reduce the possibility of
> > > potential errors in
> > > >    message reassembley. Refer to discussion about message
> > > reassembley
> > > >    (Section 5.2) for more details.
> > > >
> > > >    All datagrams which represent parts of a given fragmented
> > syslog
> > > >    message MUST have the same MessageId value.
> > > >
> > > > 3.2.2  Total Length
> > > >
> > > >    The TotalLength field MUST be a numeric value in the
> > > range of 1 to
> > > >
> > > >
> > > >
> > > > Okmianski               Expires November 5, 2004
> > >     [Page 7]
> > > > > >
> > > > Internet-Draft            syslog udp transport
> > >     May 2004
> > > >
> > > >
> > > >    16777216. It MUST indicate the length of a complete
> > > syslog message
> > > >    before it was fragmented and before it was encapsulated
with
> > > >    transport headers.  The same TotalLength field value
> > > MUST be present
> > > >    in all UDP datagrams which represent fragments of the same
> > syslog
> > > >    message. Leading zeros MUST not be present in the
TotalLength
> > > > field.
> > > >
> > > >    Note that in IPv4 the "total length" field identifies
> > > the length of a
> > > >    single packet.  In this protocol, the TotalLength field
> > > is used to
> > > >    identify the total length of a complete syslog message,
which
> > is
> > > >    transmitted using multiple fragments and multiple
> > > datagram packets.
> > > >    The fragment length is not specified in the transport
> > > header because
> > > >    it can be inferred from the size of the IP packet
> > > containing the UDP
> > > >    datagram.
> > > >
> > > > 3.2.3  Fragment Offset
> > > >
> > > >    The FragmentOffset field MUST be a numeric value in the
> > > range of 0 to
> > > >    16777215. It MUST indicate the byte offset of the
> > > fragment data in
> > > >    the complete syslog message. The offset index starts at 0
for
> > the
> > > >    first fragment. For example, if an 700 byte syslog message
is
> > > >    fragmented into 480 and 220 byte parts, the FragmentOffset
in
> > the
> > > >    first message will be 0 and in the second - 480. Note
> > > that fragments
> > > >    don't have to be the same size.  Leading zeros MUST not
> > > be present in
> > > >    the FragmentOffset field.
> > > >
> > > > 3.2.4  Extended Header Example
> > > >
> > > >    The following is an example of a syslog message without
> > > the transport
> > > >    header (message is wrapped for display):
> > > >
> > > >
> > > >       "v1 888 4 2003-10-11T22:14:15.003Z host.domain.com
> > > >       dns: configuration error"
> > > >
> > > >    Suppose this message had to be fragmented by transport
> > > layer into two
> > > >    parts at an arbitrary point.  This would result in two
> > > separate UDP
> > > >    datagrams being sent - one for each fragment. Below is
> > > the content of
> > > >    each of the syslog transport UDP messages with
> syslog transport
> > > >    headers but without UDP/IP headers:
> > > >
> > > >
> > > >       "v1 1 45612221 74 0 v1 888 4 2003-10-11T22:14:15.003Z
> > > host.dom"
> > > >
> > > >       "v1 1 45612221 74 42 ain.com dns: configuration error"
> > > >
> > > >    In the above example, the leading "v1" is the version of
the
> > > >    transport protocol, "1" indicates that this is an extended
> > header
> > > >    (fragmentation in use), "45612221" is the MessageId, "74"
is
> > the
> > > >
> > > >
> > > >
> > > > Okmianski               Expires November 5, 2004
> > >     [Page 8]
> > > > > >
> > > > Internet-Draft            syslog udp transport
> > >     May 2004
> > > >
> > > >
> > > >    TotalLength of the message, while "0" and "42" are
> > FragmentOffset
> > > >    fields. Everything following the FragmentOffset and a
> > > space is a the
> > > >    Payload of each respective message.
> > > >
> > > > 3.3  Payload
> > > >
> > > >    The Payload field of the syslog UPD transport message is
> > > an entire
> > > >    syslog message or one fragment. The maximum Payload size
> > > depends on
> > > >    the IP protocol used and the type header that is used.
> > > >
> > > >       Maximum Payload size:
> > > >
> > > >       With IPv4 and basic header:    507 bytes
> > > >       With IPv4 and extended header: 480 bytes
> > > >
> > > >       With IPv6 and basic header:    1191 bytes
> > > >       With IPv6 and extended header: 1164 bytes
> > > >
> > > >    The Payload size restrictions above effectively mean
> > > that the largest
> > > >    syslog message that can be sent non-fragmented is
> 507 bytes for
> > > >    transport via IPv4 and 1191 bytes for transport via IPv6.
> > > >
> > > >    For a discussion of the relational behind the above size
> > > restrictions
> > > >    please refer to Appendix A.
> > > >
> > > > 3.4  Supported Message Length
> > > >
> > > >    The maximum syslog message length supported by this
> > > protocol is the
> > > >    maximum value of the TotalLength field, which is 16777216
> > bytes.
> > > >    However, not all deployment scenarios for syslog will be on
> > hosts
> > > >    with hardware capable of supporting the maximum length
> > > of messages
> > > >    supported by this protocol. Additionally, extremely
> > > large messages
> > > >    may not be needed in many environments. Therefore,
> > > implementations
> > > >    are NOT REQUIRED to support the maximum message
> length allowed
> > by
> > > >    this protocol.
> > > >
> > > >    All implementations MUST support sending and receiving
syslog
> > > >    messages up to and including 65536 bytes in size (syslog
> > > transport
> > > >    and UDP/IP headers are extra). Support for larger messages
is
> > > >    encouraged. Implementors SHOULD clearly state the
> > > maximum supported
> > > >    message size in documentation.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Okmianski               Expires November 5, 2004
> > >     [Page 9]
> > > > > >
> > > > Internet-Draft            syslog udp transport
> > >     May 2004
> > > >
> > > >
> > > > 4.  UDP/IP Layer Considerations
> > > >
> > > > 4.1  Target Port
> > > >
> > > >    Syslog receivers MUST support accepting syslog message
> > > datagrams on a
> > > >    well-known UDP port 514.  Syslog senders MUST support
> > > sending syslog
> > > >    message datagrams to the UDP port 514.
> > > >
> > > > 4.2  Source Port
> > > >
> > > >    Syslog senders can use any source UDP port for
> > > transmitting messages.
> > > >    Senders MAY randomly select a source port, but MUST use
> > > the port in
> > > >    an exclusive fashion. No concurrent port reuse on the
> > > same host is
> > > >    allowed.
> > > >
> > > >    Each syslog sender process MUST attempt to use the same
> > > source port
> > > >    for the life of the the process.  If due to an error or
other
> > > >    condition it becomes impossible for the process to
> > > continue to use
> > > >    the same port, it MAY start using a new source port, but it
> > MUST
> > > >    generate a new random MessageId for the first message
> > > after changing
> > > >    the port and then MUST continue incrementing the new
> > > MessageId value
> > > >    for subsequent messages.
> > > >
> > > >    Since source port is used to identify parts of a
> > > fragmented message,
> > > >    the sender MUST use the same port to send all fragments
> > > of a given
> > > >    message.  If due to an error or other condition, the
> > > sender is unable
> > > >    to do that, it MUST resend all message fragments using
> > > the new port
> > > >    and a new MessageId field value.
> > > >
> > > > 4.3  Source IP Address
> > > >
> > > >    The source IP address of the UDP datagrams is one of the
data
> > > >    elements used to identify parts of a fragmented message.
> > >  Therefore,
> > > >    a syslog sender MUST attempt to use the same source
> IP address
> > to
> > > >    send all fragments of a given syslog message.  If due to
> > > an error,
> > > >    reconfiguration or other condition it is unable to do
> > > so, the sender
> > > >    MUST resend all fragments of the syslog message using
> > > the new source
> > > >    IP address and a new MessageId value.
> > > >
> > > > 4.4  UDP/IP Headers
> > > >
> > > >    Each UDP/IP datagram sent by the transport layer MUST
> > completely
> > > >    adhere to the structure specified in the UDP RFC 768 [3]
> > > and either
> > > >    IPv4 RFC 791 [4] or IPv6 RFC 2640 [5] depending on which
> > > protocol is
> > > >    used.
> > > >
> > > >    Use of UDP checksums was defined as optional in RFC 768
> > > [3]. IPv6 has
> > > >    subsequently made UDP checksums required [5].
> However, syslog
> > > >
> > > >
> > > >
> > > > Okmianski               Expires November 5, 2004
> > >    [Page 10]
> > > > > >
> > > > Internet-Draft            syslog udp transport
> > >     May 2004
> > > >
> > > >
> > > >    senders MUST utilize valid UDP checksums when sending
> > > messages over
> > > >    either IPv4 or IPv6. Syslog receivers MUST check for
> > > checksums and
> > > >    discard messages with incorrect checksums. Note that this
is
> > > >    typically accomplished by the UDP layer implementation, and
> > some
> > > >    implementations allow for checksum checks to be enabled or
> > > > disabled.
> > > >
> > > >    Enabling use of checksums serves as an extra measure of
> > > corruption
> > > >    detection in addition to checksums performed by IP
> and Ethernet
> > > >    layers. None of the above checksums provide a complete
> > > guarantee of
> > > >    corruption detection. Utilizing checksums on multiple
> > > layers reduces
> > > >    the chance of corruption error not being detected.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Okmianski               Expires November 5, 2004
> > >    [Page 11]
> > > > > >
> > > > Internet-Draft            syslog udp transport
> > >     May 2004
> > > >
> > > >
> > > > 5.  Fragmentation and Reassembley
> > > >
> > > > 5.1  Message Fragmentation
> > > >
> > > >    The syslog transport layer MUST perform
> fragmentation if syslog
> > > >    message size exceeds the maximum allowed Payload size.
> > > Fragmentation
> > > >    SHOULD NOT be used if message can fit into the
> maximum allowed
> > > >    Payload size.
> > > >
> > > >    Syslog messages SHOULD be fragmented such that all but
> > > last message
> > > >    utilize the Payload to its maximum capacity.  For
> > > example, when using
> > > >    IPv4, a 700 byte syslog message SHOULD be fragmented
> > > into 480 and 220
> > > >    byte parts because the maximum Payload size with IPv4
> > > and extended
> > > >    header is 480 bytes.
> > > >
> > > >    Each message fragment MUST be sent as a separate UDP/IP
> > > datagram with
> > > >    an extended syslog transport header.  The sender MUST
> > > use the same
> > > >    MessageId value, source port and source IP address for
> > > all fragments
> > > >    of a given message. These three field together uniquely
> > identify
> > > >    fragments belonging to a given message.
> > > >
> > > >    On a system with short-lived sender processes, it may be
> > possible
> > > >    that fragments with the same MessageId value, source
> > > port and source
> > > >    IP address will get generated in short time proximity.
> > > This can be
> > > >    possible because a new process may re-use the source
> > > port that was
> > > >    freed up by another process that just dies.  Such behavior
> > could
> > > >    confuse the receiver if the datagrams were received out
> > > of order or
> > > >    some datagrams got lost.
> > > >
> > > >    In order to reduce the risk of such mistaken identity
> > > errors, section
> > > >    3.2.1 specified that each process must start with a
> > > random value for
> > > >    MessageId field.  Given a relatively large range of
> > > MessageId values
> > > >    and the unlikely event of a coincidence of having the
> > > same MessageId
> > > >    value combined with re-used source port and UPD errors,
> > > the window
> > > >    for potential mistaken identity errors during message
> > > reassembley is
> > > >    very small and tolerable. The users take a greater risk
> > > by using this
> > > >    protocol due to general UDP reliability issues
> discussed later
> > in
> > > >    this specification.
> > > >
> > > > 5.2  Message Reassembley
> > > >
> > > >    The reassembley process uses the source IP address
> from the IP
> > > >    header, the source port from the UDP header and the
> > > MessageId field
> > > >    value to identify fragments of a given message. It then
uses
> > data
> > > >    from TotalLength and FragmentOffset fields to
> > > re-assemble fragments
> > > >    into a complete message.
> > > >
> > > >    Typically, an implementation of fragmentation
> > > reassembley involves
> > > >
> > > >
> > > >
> > > > Okmianski               Expires November 5, 2004
> > >    [Page 12]
> > > > > >
> > > > Internet-Draft            syslog udp transport
> > >     May 2004
> > > >
> > > >
> > > >    allocating a buffer for the message when any fragment with
a
> > new
> > > >    combination of source IP address, source port and
> MessageId is
> > > >    received. A timer is used to expire the message
> > > reassembley and clean
> > > >    the buffer if all fragments are not received in certain
> > > time period.
> > > >    As each fragment is received, it is placed into the buffer
at
> > the
> > > >    appropriate offset and a check is performed to
> determine if all
> > > >    fragments have been received using additional data
> structures.
> > > >
> > > >    The receiver SHOULD make the timeout interval used
> for message
> > > >    reassembley configurable for the administrator.  The
> > > receiver SHOULD
> > > >    also be able to limit the total amount of memory used for
> > buffers
> > > >    such that it does not run out of resources under a
> > > simple denial of
> > > >    service attack involving just one message fragment
> with a large
> > > >    TotalLength field value. Degrading the service under
> > > heavy load or
> > > >    attack is better than crashing and potentially making the
> > service
> > > >    completely unavailable.
> > > >
> > > > 5.3  Avoiding Fragmentation
> > > >
> > > >    Fragmentation and reassembley of messages incurs
substantial
> > > >    processing overhead on both the sender and the
> receiver hosts.
> > It
> > > >    also increases the risk of lost messages due to lose of
just
> > one
> > > >    fragment. It is RECOMMENDED that syslog senders which
> > anticipate
> > > >    sending messages over this transport protocol attempt to
> > > reduce the
> > > >    number of messages which require fragmentation by
> > > restricting them to
> > > >    the size which does not require fragmentation.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Okmianski               Expires November 5, 2004
> > >    [Page 13]
> > > > > >
> > > > Internet-Draft            syslog udp transport
> > >     May 2004
> > > >
> > > >
> > > > 6.  Reliability Considerations
> > > >
> > > >    The UDP is an unreliable low-overhead protocol. This
section
> > > >    discusses reliability issues inherent in the UDP that
> > > implementers
> > > >    and users must be aware of.
> > > >
> > > > 6.1  Lost Datagrams
> > > >
> > > >    Neither UDP nor syslog protocol provide any mechanism to
> > > detect and
> > > >    correct loss of datagrams.  Datagrams may be lost in
> > > transit due to
> > > >    congestion, corruption or any other intermittent network
> > problem.
> > > >    Syslog protocol and IP fragmentation exacerbates the
> > > problem because
> > > >    loss of a single fragment would result in entire
> message being
> > > >    discarded.
> > > >
> > > >    In some circumstances the sender may receive an ICMP
> > > error message or
> > > >    other indication of a transmission problem. If the
> > > sender receives a
> > > >    reasonable indication that some datagram may have been
> > > lost, it MAY
> > > >    retransmit previously sent messages.
> > > >
> > > > 6.2  Message Corruption and Checksums
> > > >
> > > >    The UDP/IP datagrams may get corrupted in transit due to
> > > software,
> > > >    hardware or network errors. This protocol specified
> use of UDP
> > > >    checksums to enable corruption detection in addition to
> > checksums
> > > >    utilized in IP and Ethernet layers. However, checksums do
not
> > > >    guarantee corruption detection and this protocol does
> > > not provide for
> > > >    message retransmission when a corrupt message is detected.
> > > >
> > > > 6.3  Congestion Control
> > > >
> > > >    The UDP does not provide for congestion control. Some
> > > systems (hosts
> > > >    or routers) may generate ICMP source quench error, but
> > > they are not
> > > >    required to do so [8].  Any network host can discard UDP
> > > packets when
> > > >    it is overloaded. Due to lack of congestion control one
> > > or multiple
> > > >    syslog senders can maliciously or inadvertently overload
> > > the receiver
> > > >    or the network infrastructure and cause loss of syslog
> > messages.
> > > >
> > > > 6.4  Sequenced Delivery
> > > >
> > > >    The IP transport utilized by the UDP does not guarantee
that
> > the
> > > >    sequence of datagram delivery will match the order
> in which the
> > > >    datagrams have been sent. The time stamp contained
> > > within each syslog
> > > >    message may serve as some guide in establishing sequence
> > > order, but
> > > >    it will not help in cases when multiple messages
> were generated
> > > >    during the same time slot or when messages originated
> > > from different
> > > >    hosts whose clocks are not synchronized. The order of
> > > syslog message
> > > >    arrival via the this syslog transport SHOULD NOT be
> used as an
> > > >
> > > >
> > > >
> > > > Okmianski               Expires November 5, 2004
> > >    [Page 14]
> > > > > >
> > > > Internet-Draft            syslog udp transport
> > >     May 2004
> > > >
> > > >
> > > >    authoritative guide in establishing the sequence of events
on
> > the
> > > >    syslog sender hosts.
> > > >
> > > > 6.5  Sender Authentication
> > > >
> > > >    The UDP syslog transport does not strongly associate the
> > > message with
> > > >    the message sender.  The receiver of the syslog message
> > > will not be
> > > >    able to ascertain that the message was indeed sent from
> > > the reported
> > > >    sender, or if the packet was sent from another device.
> > > >
> > > >    One possible consequence of this behavior is that a
> > misconfigured
> > > >    machine may send syslog messages to a receiver
> > > representing itself as
> > > >    another machine. The administrators may not be able
> to readily
> > > >    discern that there are two or more machines representing
> > > themselves
> > > >    as the same machine.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Okmianski               Expires November 5, 2004
> > >    [Page 15]
> > > > > >
> > > > Internet-Draft            syslog udp transport
> > >     May 2004
> > > >
> > > >
> > > > 7.  Security Considerations
> > > >
> > > >    Several syslog security considerations have been discussed
in
> > > >    RFC-protocol [2] and in the original RFC 3164 [1].
> This section
> > > >    focuses on security considerations specific to the
> > > syslog transport
> > > >    over UDP.
> > > >
> > > > 7.1  Message Authenticity
> > > >
> > > >    This transport protocol does not strongly authenticate
> > > the identity
> > > >    of the message sender and does not provide any assurance
that
> > the
> > > >    message was not modified in transit. The receiver of
> the syslog
> > > >    message will not be able to ascertain that the message was
> > indeed
> > > >    sent from the reported sender, or if the packet was sent
> > > from another
> > > >    device.
> > > >
> > > > 7.2  Message Forgery
> > > >
> > > >    Syslog messages can be easily forged. An attacker may
> > > transmit syslog
> > > >    messages (either from the machine from which the messages
are
> > > >    purportedly sent or from any other machine) to a receiver.
> > > >
> > > >    In one case, an attacker may hide the true nature of an
> > > attack amidst
> > > >    many other messages.  As an example, an attacker may
> > > start generating
> > > >    forged messages indicating a problem on some machine.
> > > This may get
> > > >    the attention of the system administrators who will
> > > spend their time
> > > >    investigating the alleged problem.  During this time,
> > > the attacker
> > > >    may be able to compromise a different machine, or a
> > > different process
> > > >    on the same machine.
> > > >
> > > >    Additionally, an attacker may generate false syslog
> > > messages to give
> > > >    untrue indications of status or of events.  As an example,
an
> > > >    attacker may stop a critical process on a machine, which
> > > may generate
> > > >    a notification of exit.  The attacker may
> subsequently generate
> > a
> > > >    forged notification that the process had been restarted.
> > >  The system
> > > >    administrators may accept that misinformation and not
> > > verify that the
> > > >    process had indeed been restarted.
> > > >
> > > > 7.3  Message Observation
> > > >
> > > >    The transport protocol does not provide
> confidentiality of the
> > > >    messages in transit. If syslog messages are in clear
> > > text, this is
> > > >    how they will be transferred.  In most cases passing
> clear-text
> > > >    human-readable messages is a benefit to the administrators.
> > > >    Unfortunately, an attacker may also be able to observe the
> > > >    human-readable contents of syslog messages.  The
> > > attacker may then
> > > >    use the knowledge gained from those messages to
> > > compromise a machine
> > > >    or do other damage. It is RECOMMENDED that no sensitive
> > > information
> > > >
> > > >
> > > >
> > > > Okmianski               Expires November 5, 2004
> > >    [Page 16]
> > > > > >
> > > > Internet-Draft            syslog udp transport
> > >     May 2004
> > > >
> > > >
> > > >    is transmitted via this transport protocol or that
> > > transmission of
> > > >    such information is restricted to properly secured
networks.
> > > >
> > > > 7.4  Replaying
> > > >
> > > >    Message forgery and observation can be combined into a
> > > replay attack.
> > > >    An attacker may record a set of messages that indicate
normal
> > > >    activity of a machine.  At a later time, that attacker may
> > remove
> > > >    that machine from the network and replay the syslog
> > > messages to the
> > > >    collector with new time stamps. The administrators may
> > > find nothing
> > > >    unusual in the received messages and their receipt would
> > falsely
> > > >    indicate normal activity of the machine.
> > > >
> > > > 7.5  Unreliable Delivery
> > > >
> > > >    As was previously discussed in the Reliability
Considerations
> > > >    section, the UDP transport is not reliable and packets
> > containing
> > > >    syslog message datagrams can be lost in transit without
> > > any notice.
> > > >    There can be security consequences to the loss of one or
> > > more syslog
> > > >    messages.  Administrators may not become aware of a
> > > developing and
> > > >    potentially serious problem. Messages may also be
intercepted
> > and
> > > >    discarded by an attacker as a way to hide unauthorized
> > > activities.
> > > >
> > > > 7.6  Message Prioritization and Differentiation
> > > >
> > > >    The transport protocol described in this document does
> > > not require
> > > >    prioritization of syslog messages on the wire or when
> > > processed on
> > > >    the receiving host based on their severity.  The
> > > security implication
> > > >    of such behavior is that the syslog receiver or network
> > > devices may
> > > >    get overwhelmed with low severity messages and be forced
> > > to discard
> > > >    potentially high severity messages. High severity
> messages may
> > > >    contain indication about serious security problems, but
> > > they will not
> > > >    get a higher priority. It is difficult to make sure that
high
> > > >    severities messages get higher end-to-end delivery
priority,
> > > >    especially over an unreliable UDP transport.
> > > >
> > > >    On a case-by-case basis, device operators may find
> some way to
> > > >    associate the different severity levels with the quality
> > > of service
> > > >    identifiers.  As an example, the operators may elect to
> > > define some
> > > >    linkage between syslog messages that have a specific
> > > Priority value
> > > >    with a specific value to be used in the IPv4 Precedence
> > > field [4],
> > > >    the IPv6 Traffic Class octet [5], or the Differentiated
> > Services
> > > >    field [9].  However, even with this prioritization on
> > > the network,
> > > >    high load can lead to buffer starvation on the receiving
host
> > and
> > > >    result in dropped messages.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Okmianski               Expires November 5, 2004
> > >    [Page 17]
> > > > > >
> > > > Internet-Draft            syslog udp transport
> > >     May 2004
> > > >
> > > >
> > > > 7.7  Denial of Service
> > > >
> > > >    An attacker may overwhelm a receiver by sending more
> > > messages to it
> > > >    than can be handled by the infrastructure or the
> device itself.
> > > >    Implementers SHOULD attempt to provide features that
> > > minimize this
> > > >    threat such as only receiving syslog messages from known IP
> > > >    addresses.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Okmianski               Expires November 5, 2004
> > >    [Page 18]
> > > > > >
> > > > Internet-Draft            syslog udp transport
> > >     May 2004
> > > >
> > > >
> > > > 8.  IANA Considerations
> > > >
> > > >    IANA must reserve UDP port 514 for this transport.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Okmianski               Expires November 5, 2004
> > >    [Page 19]
> > > > > >
> > > > Internet-Draft            syslog udp transport
> > >     May 2004
> > > >
> > > >
> > > > 9.  Notice to RFC Editor
> > > >
> > > >    This is a notice to the RFC editor. This ID is submitted
> > > along with
> > > >    ID draft-ietf-syslog-protocol and they cross-reference
> > > each other.
> > > >    When RFC numbers are determined for each of these IDs,
> > > please replace
> > > >    all references to "RFC-protocol" with the RFC number of
> > > >    draft-ietf-syslog-protocol ID.  Please remove this section
> > after
> > > >    editing.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Okmianski               Expires November 5, 2004
> > >    [Page 20]
> > > > > >
> > > > Internet-Draft            syslog udp transport
> > >     May 2004
> > > >
> > > >
> > > > 10.  Authors and Working Group Chair
> > > >
> > > >    The working group can be contacted via the mailing list:
> > > >
> > > >    [email-masked]
> > > >
> > > >    The current Chair of the Working Group may be contacted at:
> > > >
> > > >    Chris Lonvick
> > > >    Cisco Systems
> > > >    Email: [email-masked]
> > > >
> > > >    The author of this draft is:
> > > >
> > > >    Anton Okmianski
> > > >    Email: [email-masked]
> > > >
> > > >    Phone: (978) 936-1612
> > > >    Fax: (978) 936-2225
> > > >
> > > >    Cisco Systems, Inc
> > > >    1414 Massachusetts Ave.
> > > >    Boxborough, MA 01719-2205
> > > >    USA
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Okmianski               Expires November 5, 2004
> > >    [Page 21]
> > > > > >
> > > > Internet-Draft            syslog udp transport
> > >     May 2004
> > > >
> > > >
> > > > 11.  Acknowledgements
> > > >
> > > >    The author wishes to thank Chris Lonvick, Rainer Gerhards,
> > David
> > > >    Harrington, Andrew Ross, Albert Mietus, Bernie Volz, and
> > > all others
> > > >    who have commented on the various versions of this
proposal.
> > > >
> > > > 12  References
> > > >
> > > >    [1]   Lonvick, C., "The BSD Syslog Protocol", RFC 3164,
> > > August 2001.
> > > >
> > > >    [2]   Gerhards, R., "The syslog Protocol", RFC
RFC-protocol.
> > > >
> > > >    [3]   Postel, J., "User Datagram Protocol", STD 6, RFC
> > > 768, August
> > > >          1980.
> > > >
> > > >    [4]   Postel, J., "Internet Protocol", STD 5, RFC 791,
> > September
> > > >          1981.
> > > >
> > > >    [5]   Deering, S. and R. Hinden, "Internet Protocol,
> > > Version 6 (IPv6)
> > > >          Specification", RFC 2460, December 1998.
> > > >
> > > >    [6]   Bradner, S., "Key words for use in RFCs to
> > > Indicate Requirement
> > > >          Levels", BCP 14, RFC 2119, March 1997.
> > > >
> > > >    [7]   Crocker, D. and P. Overell, "Augmented BNF for Syntax
> > > >          Specifications: ABNF", RFC 2234, November 1997.
> > > >
> > > >    [8]   Stevens, W., "TCP/IP Illustrated Volume 1. The
> > Protocols.",
> > > >          January 1994.
> > > >
> > > >    [9]   Nichols, K., Blake, S., Baker, F. and D. Black,
> > > "Definition of
> > > >          the Differentiated Services Field (DS Field) in
> > > the IPv4 and
> > > >          IPv6 Headers", RFC 2474, December 1998.
> > > >
> > > >    [10]  Mockapetris, P., "Domain names - implementation and
> > > >          specification", STD 13, RFC 1035, November 1987.
> > > >
> > > >    [11]  Hedrick, C., "Routing Information Protocol", RFC
1058,
> > June
> > > >          1988.
> > > >
> > > >    [12]  Droms, R., "Dynamic Host Configuration Protocol", RFC
> > 2131,
> > > >          March 1997.
> > > >
> > > >    [13]  Sollins, K., "The TFTP Protocol (Revision 2)", STD
33,
> > RFC
> > > >          1350, July 1992.
> > > >
> > > >    [14]  Braden, R., "Requirements for Internet Hosts -
> > > Communication
> > > >          Layers", STD 3, RFC 1122, October 1989.
> > > >
> > > >
> > > >
> > > > Okmianski               Expires November 5, 2004
> > >    [Page 22]
> > > > > >
> > > > Internet-Draft            syslog udp transport
> > >     May 2004
> > > >
> > > >
> > > >    [15]  Kent, C. and J. Mogul, ""Fragmentation Considered
> > Harmful,"
> > > >          Computer Communications Review, vol.17, no.5,
> > pp.390-401",
> > > >          August 1987.
> > > >
> > > >
> > > > Author's Address
> > > >
> > > >    Anton Okmianski
> > > >    Cisco Systems, Inc.
> > > >    1414 Massachusetts Ave
> > > >    Boxborough, MA  01719-2205
> > > >    USA
> > > >
> > > >    EMail: [email-masked]
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Okmianski               Expires November 5, 2004
> > >    [Page 23]
> > > > > >
> > > > Internet-Draft            syslog udp transport
> > >     May 2004
> > > >
> > > >
> > > > Appendix A.  Rational For Transport Message Size Restrictions
> > > >
> > > >    This appendix provides the rational behind the Payload size
> > > >    restrictions for this protocol.  The Payload
> > > restrictions outlined in
> > > >    the specification, essentially ensure that the transport
> > > message size
> > > >    does not exceed 512 bytes (without UDP/IP headers) for
> > > transport via
> > > >    IPv4 and does not exceed 1196 bytes for transport via IPv6.
> > These
> > > >    restrictions put an upper boundary on the UDP/IP
> > > datagram size for
> > > >    this protocol, which accomplishes two goals.
> > > >
> > > >    First, they insure interoperability between various UDP/IP
> > > >    implementations.  Even though the maximum IP datagram size
is
> > > >    specified as 65536 bytes, many UDP/IP implementations
> > > have been shown
> > > >    not to work with large datagram sizes [8].  Many
established
> > > >    UDP-based protocols restrict UDP datagram data size to
> > > 512 bytes. For
> > > >    example, DNS [10] and RIP [11] do that. The DHCPv4 [12]
> > > restricts the
> > > >    size to 512 bytes, but allows sides to agree on a
> larger value
> > > >    through the protocol. The TFTP [13] restricts the UDP
> > > data size to
> > > >    518 bytes, which is slightly larger.
> > > >
> > > >    The second reason for datagram size restrictions is that it
> > helps
> > > >    reduce the likelihood of the  IP-layer datagram
> > > fragmentation.  This
> > > >    could have potentially resulted in fragmentation on
> two levels:
> > > >    syslog transport protocol and IP layer. Since
> fragmentation has
> > > >    significant overhead for message reassembley, it is best to
> > avoid
> > > >    double fragmentation. The likelihood of IP
> fragmentation can be
> > > >    significantly reduced by sending IP datagrams in sizes
which
> > all
> > > >    hosts must be able to process.
> > > >
> > > >    The minimum MTU of a transport protocol determines the
> > > minimum size
> > > >    of packets that hosts must be able to accept.  For IPv4,
> > > the minimum
> > > >    MTU is 576 bytes [4] and for IPv6 - 1280 bytes [5].  In
> > > both cases,
> > > >    the maximum message size we chose fits within the MTU of
the
> > > >    transport in all cases except for when extremely large
> > > IP headers are
> > > >    used.  IPv4 header can range from 20 to 60 bytes in
> > > length and UDP
> > > >    header is fixed at 8 bytes. Thus, our message size
> restrictions
> > > >    ensure that in all cases except for when the IP header
> > > is 56 bytes or
> > > >    greater, the size of the packet will within the size of
> > > the transport
> > > >    MTU.
> > > >
> > > >    For IPv6, we have left the same amount of padding for
> > > UDP/IP headers
> > > >    as was conventionally done for IPv4 in DNS, RIP and
> > > DHCPv4 with an
> > > >    additional padding of extra 20 bytes to accommodate a
larger
> > IPv6
> > > >    header. This follows the methodology suggested in the IPv6
> > > >    specification for calculating upper-layer payload limits
[5].
> > > >
> > > >    Path MTU discovery can generally be used to discover the
> > > MTU of the
> > > >    link.  Unfortunately, using path MTU discovery with
> UDP is not
> > a
> > > >
> > > >
> > > >
> > > > Okmianski               Expires November 5, 2004
> > >    [Page 24]
> > > > > >
> > > > Internet-Draft            syslog udp transport
> > >     May 2004
> > > >
> > > >
> > > >    reliable option because it depends on routers providing
> > > ICMP errors
> > > >    and hosts doing retransmission, which are not done
> > consistently.
> > > >    Implementors MUST follow the size restrictions outlined
> > > above and not
> > > >    rely on path MTU discovery.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Okmianski               Expires November 5, 2004
> > >    [Page 25]
> > > > > >
> > > > Internet-Draft            syslog udp transport
> > >     May 2004
> > > >
> > > >
> > > > Intellectual Property Statement
> > > >
> > > >    The IETF takes no position regarding the validity or scope
of
> > any
> > > >    intellectual property or other rights that might be
> claimed to
> > > >    pertain to the implementation or use of the technology
> > > described in
> > > >    this document or the extent to which any license under
> > > such rights
> > > >    might or might not be available; neither does it
> > > represent that it
> > > >    has made any effort to identify any such rights.
> > > Information on the
> > > >    IETF's procedures with respect to rights in
> standards-track and
> > > >    standards-related documentation can be found in
> BCP-11. Copies
> > of
> > > >    claims of rights made available for publication and any
> > > assurances of
> > > >    licenses to be made available, or the result of an
> > > attempt made to
> > > >    obtain a general license or permission for the use of such
> > > >    proprietary rights by implementors or users of this
> > > specification can
> > > >    be obtained from the IETF Secretariat.
> > > >
> > > >    The IETF invites any interested party to bring to its
> > > attention any
> > > >    copyrights, patents or patent applications, or other
> > proprietary
> > > >    rights which may cover technology that may be required
> > > to practice
> > > >    this standard. Please address the information to the
> > > IETF Executive
> > > >    Director.
> > > >
> > > >
> > > > Full Copyright Statement
> > > >
> > > >    Copyright (C) The Internet Society (2004). All
> Rights Reserved.
> > > >
> > > >    This document and translations of it may be copied and
> > > furnished to
> > > >    others, and derivative works that comment on or
> > > otherwise explain it
> > > >    or assist in its implementation may be prepared, copied,
> > > published
> > > >    and distributed, in whole or in part, without restriction
of
> > any
> > > >    kind, provided that the above copyright notice and this
> > > paragraph are
> > > >    included on all such copies and derivative works.
> However, this
> > > >    document itself may not be modified in any way, such as
> > > by removing
> > > >    the copyright notice or references to the Internet
> > > Society or other
> > > >    Internet organizations, except as needed for the purpose of
> > > >    developing Internet standards in which case the
> procedures for
> > > >    copyrights defined in the Internet Standards process must
be
> > > >    followed, or as required to translate it into languages
> > > other than
> > > >    English.
> > > >
> > > >    The limited permissions granted above are perpetual and
> > > will not be
> > > >    revoked by the Internet Society or its successors or
> assignees.
> > > >
> > > >    This document and the information contained herein is
> > > provided on an
> > > >    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
> > > ENGINEERING
> > > >    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
> > > INCLUDING
> > > >    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
> INFORMATION
> > > >
> > > >
> > > >
> > > > Okmianski               Expires November 5, 2004
> > >    [Page 26]
> > > > > >
> > > > Internet-Draft            syslog udp transport
> > >     May 2004
> > > >
> > > >
> > > >    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES
> > OF
> > > >    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
> > > >
> > > >
> > > > Acknowledgment
> > > >
> > > >    Funding for the RFC Editor function is currently provided
by
> > the
> > > >    Internet Society.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Okmianski               Expires November 5, 2004
> > >    [Page 27]
> > > > > >
> > > >
> > >
> > > >
> > > >
> > >      [1]
> > > > TOC
> > > >
> > > >    syslog Working Group      A. Okmianski
> > > >    Internet-Draft            Cisco Systems, Inc.
> > > >    Expires: November 5, 2004 May 7, 2004
> > > >
> > > >                                  Transmission of syslog
> > > messages over
> > > > UDP
> > > >
> > > >
> > > > draft-ietf-syslog-transport-udp-01
> > > >
> > > >   Status of this Memo
> > > >
> > > >    This document is an Internet-Draft and is in full
> > > conformance with all
> > > >    provisions of Section 10 of RFC2026.
> > > >
> > > >    Internet-Drafts are working documents of the Internet
> > > Engineering Task
> > > >    Force  (IETF),  its  areas,  and  its  working groups.
> > > Note that other
> > > >    groups may also distribute working documents as
> > Internet-Drafts.
> > > >
> > > >    Internet-Drafts  are draft documents valid for a maximum
> > > of six months
> > > >    and  may  be updated, replaced, or obsoleted by other
> > > documents at any
> > > >    time. It is inappropriate to use Internet-Drafts as
> > > reference material
> > > >    or to cite them other than as "work in progress."
> > > >
> > > >    The   list   of   current   Internet-Drafts   can   be
> > > accessed   at
> > > >    [2]http://www.ietf.org/ietf/1id-abstracts.txt.
> > > >
> > > >    The  list  of  Internet-Draft  Shadow  Directories  can
> > > be accessed at
> > > >    [3]http://www.ietf.org/shadow.html.
> > > >
> > > >    This Internet-Draft will expire on November 5, 2004.
> > > >
> > > >   Copyright Notice
> > > >
> > > >    Copyright (C) The Internet Society (2004). All
> Rights Reserved.
> > > >
> > > >   Abstract
> > > >
> > > >    This  document  describes  the  transport  for the
> > > syslog message 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 using
> > > >    multiple datagrams.
> > > >
> > >
_________________________________________________________________
> > > >
> > > >   Table of Contents
> > > >
> > > >    [4]1.  Introduction
> > > >    [5]2.  Transport Protocol Overview
> > > >        [6]2.1  Definitions and Architecture
> > > >        [7]2.2  Required Transport Protocol
> > > >        [8]2.3  Encapsulation Layers
> > > >    [9]3.  Message Format
> > > >        [10]3.1  Basic Header Format
> > > >        [11]3.2  Extended Header Format
> > > >            [12]3.2.1  Message Identifier
> > > >            [13]3.2.2  Total Length
> > > >            [14]3.2.3  Fragment Offset
> > > >            [15]3.2.4  Extended Header Example
> > > >        [16]3.3  Payload
> > > >        [17]3.4  Supported Message Length
> > > >    [18]4.  UDP/IP Layer Considerations
> > > >        [19]4.1  Target Port
> > > >        [20]4.2  Source Port
> > > >        [21]4.3  Source IP Address
> > > >        [22]4.4  UDP/IP Headers
> > > >    [23]5.  Fragmentation and Reassembley
> > > >        [24]5.1  Message Fragmentation
> > > >        [25]5.2  Message Reassembley
> > > >        [26]5.3  Avoiding Fragmentation
> > > >    [27]6.  Reliability Considerations
> > > >        [28]6.1  Lost Datagrams
> > > >        [29]6.2  Message Corruption and Checksums
> > > >        [30]6.3  Congestion Control
> > > >        [31]6.4  Sequenced Delivery
> > > >        [32]6.5  Sender Authentication
> > > >    [33]7.  Security Considerations
> > > >        [34]7.1  Message Authenticity
> > > >        [35]7.2  Message Forgery
> > > >        [36]7.3  Message Observation
> > > >        [37]7.4  Replaying
> > > >        [38]7.5  Unreliable Delivery
> > > >        [39]7.6  Message Prioritization and Differentiation
> > > >        [40]7.7  Denial of Service
> > > >    [41]8.  IANA Considerations
> > > >    [42]9.  Notice to RFC Editor
> > > >    [43]10.  Authors and Working Group Chair
> > > >    [44]11.  Acknowledgements
> > > >    [45]§.  References
> > > >    [46]§  Author's Address
> > > >    [47]A.  Rational For Transport Message Size Restrictions
> > > >    [48]§  Intellectual Property and Copyright Statements
> > > >
> > >
_________________________________________________________________
> > > >
> > > >
> > >     [49]
> > > > TOC
> > > >
> > > >   1. Introduction
> > > >
> > > >    The  original  syslog  protocol has been described in an
> > > informational
> > > >    [50]RFC  3164Lonvick,  C., The BSD Syslog Protocol,
> > > August 2001.[1] as
> > > >    it  has  been  observed in existing implementations. It
> > > describes both
> > > >    the  semantics  of  syslog  message format as well as a
> > > UDP transport.
> > > >    Subsequently,  the  syslog  protocol  has  been
> > > formally defined in a
> > > >    standards  track  [51]RFC-protocolGerhards,  R.,  The
> > > syslog Protocol,
> > > >    .[2].
> > > >
> > > >    The  [52]RFC-protocolGerhards,  R.,  The  syslog
> > > Protocol,  .[2]  has
> > > >    provided  for  support  of any number of transport layer
> > > protocols for
> > > >    transmitting syslog messages and left it to subsequent
> > > RFCs to specify
> > > >    transport  protocols.  This  standards  track  RFC
> > > describes  the UDP
> > > >    transport for the syslog protocol. This transport
> > > protocol is REQUIRED
> > > >    for all syslog protocol implementations.
> > > >
> > > >    This   transport   protocol  was  designed  to  work  on
> > >  top  of  UDP
> > > >    [53][3]Postel, J., User Datagram Protocol, August 1980.
> > > over both IPv4
> > > >    [54][4]Postel,   J.,  Internet  Protocol,  September
> > > 1981.  and  IPv6
> > > >    [55][5]Deering,  S. and R. Hinden, Internet Protocol,
> > > Version 6 (IPv6)
> > > >    Specification,  December  1998.. This protocol overcomes
> > > the data size
> > > >    restrictions  of the UDP protocol by introducing message
> > > fragmentation
> > > >    feature.
> > > >
> > > >    As  we  will show in this specification, this protocol
> > > has significant
> > > >    reliability and security issues stemming from the use of
> > > UDP. However,
> > > >    this  protocol  is lightweight and extends on the
> > > existing popular use
> > > >    of  UDP  for  syslog.  Network administrators and
> > > architects should be
> > > >    aware of the shortcomings of this protocol and plan
> > accordingly.
> > > >
> > > >    The  key  words  "MUST", "MUST NOT", "REQUIRED",
> > > "SHALL", "SHALL NOT",
> > > >    "SHOULD",  "SHOULD  NOT", "RECOMMENDED", "MAY", and
> > > "OPTIONAL" in this
> > > >    document  are  to  be interpreted as described in
> > > [56]RFC 2119Bradner,
> > > >    S.,  Key  words  for use in RFCs to Indicate Requirement
> > > Levels, March
> > > >    1997.[6].  The  words  'byte'  and 'octet' are used
> > > interchangeably in
> > > >    this specification.
> > > >
> > >
_________________________________________________________________
> > > >
> > > >
> > >     [57]
> > > > TOC
> > > >
> > > >   2. Transport Protocol Overview
> > > >
> > > >     2.1 Definitions and Architecture
> > > >
> > > >    The following definitions will be used in this document:
> > > >      * An  application that can generate syslog messages
> > > will be referred
> > > >        to as a "sender";
> > > >      * An  application  that can receive syslog messages
> > > will be referred
> > > >        to as a "receiver".
> > > >
> > > >    An  application  can  function in dual capacity. For
> > > example, a syslog
> > > >    relay  may  receive and forward messages. A single
> > > system can host any
> > > >    number  of syslog senders. Only one syslog receiver can
> > > be hosted on a
> > > >    single system using the standard listening port.
> > > >
> > > >     2.2 Required Transport Protocol
> > > >
> > > >    This  document  describes  the  UDP  transport  layer
> > > protocol for the
> > > >    syslog  protocol  [58]RFC-protocolGerhards,  R.,  The
> > > syslog Protocol,
> > > >    .[2]. Every syslog sender and receiver implementation
> > > which adheres to
> > > >    the [59]RFC-protocolGerhards, R., The syslog Protocol,
> > > .[2] MUST fully
> > > >    implement   the   transport   protocol  specified  in
> > > this  document.
> > > >    Implementations  does  not have to support both IPv4 and
> > > IPv6 if it is
> > > >    designed to be used over only one of these protocols.
> > > >
> > > >     2.3 Encapsulation Layers
> > > >
> > > >    Syslog  UDP  transport  carries  syslog  messages  as
> > > generic payload
> > > >    encapsulated  with  a  syslog  transport  header, UDP
> > > header and an IP
> > > >    header.  Below  is a summary of syslog UDP/IP packet
> > > structure as used
> > > >    this transport protocol:
> > > >
> > > >                 +--------------------------------+
> > > >                 |       IPv4 or IPv6 Header      |
> > > >                 |        (20 or more bytes)      |
> > > >                 +--------------------------------+
> > > >                 |           UDP Header           |
> > > >                 |           (8 bytes)            |
> > > >                 +--------------------------------+
> > > >                 |    Syslog Transport Header     |
> > > >                 |        (5 or 32 bytes)         |
> > > >                 +--------------------------------+
> > > >                 |     Syslog Message Payload     |
> > > >                 |       (1 to 1191 bytes)        |
> > > >                 +--------------------------------+
> > > >
> > > >    Small  syslog  messages  are transmitted using one
> > > UDP/IP datagram per
> > > >    message.  However,  syslog  protocol  [60][2]Gerhards,
> > > R., The syslog
> > > >    Protocol,  .  allows messages as large as 16777216
> > > bytes, while UDP/IP
> > > >    datagram  cannot exceed a total size of 65526 bytes
> > > [61][3]Postel, J.,
> > > >    User  Datagram  Protocol,  August  1980.  and  most
> > > existing protocols
> > > >    restrict  the  size  of  UDP  data  to  much less. In
> > > order to support
> > > >    transmitting  large  messages  over  UDP/IP,  this
> > > transport protocol
> > > >    supports  fragmentation  of large syslog messages into
> > > multiple UDP/IP
> > > >    datagrams for transmission and reassembley on the receiving
> > end.
> > > >
> > > >    Each  syslog  UDP/IP  datagram  MUST contain one and
> > > only one complete
> > > >    syslog  message  or  one  fragment of a message.
> > > Transmitting multiple
> > > >    messages  or  multiple fragments of different messages
> > > in a single UDP
> > > >    datagram is not supported by this protocol.
> > > >
> > >
_________________________________________________________________
> > > >
> > > >
> > >     [62]
> > > > TOC
> > > >
> > > >   3. Message Format
> > > >
> > > >    The  syslog  transport  message  consist  of  a
> > > transport header and a
> > > >    syslog  message  payload.  The  format  of  the
> > > transport  header  is
> > > >    different  for fragmented and non-fragmented messages.
> > > Basic transport
> > > >    header  is  used  for  non-fragmented  messages and
> > > extended transport
> > > >    header is used for fragmented messages.
> > > >
> > > >    An  ASCII-based  encoding  was  chosen  for  the  syslog
> > > transport for
> > > >    consistency   with   the   [63]RFC-protocolGerhards,
> > > R.,  The  syslog
> > > >    Protocol, .[2]. Syslog transport datagrams without
> > > required UDP and IP
> > > >    headers  have  the  following  format  in
> > > [64]ABNFCrocker,  D. and P.
> > > >    Overell,  Augmented  BNF  for  Syntax  Specifications:
> > > ABNF, November
> > > >    1997.[7] notation:
> > > >
> > > >     SyslogTransportMessage = ( BasicHeader / ExtendedHeader )
> > > >                                       SP Payload
> > > >
> > > >     BasicHeader     = Version SP "0"
> > > >     Version         = %d118 1*3DIGIT   ; "v1" in this version
> > > >
> > > >     ExtendedHeader  = Version SP "1" SP MessageId
> > > >                       SP TotalLength SP FragmentOffset
> > > >
> > > >     MessageId       = 1*8DIGIT        ; 0 to 16777215
> > > >     TotalLength     = 1*8DIGIT        ; 1 to 16777216
> > > >     FragmentOffset  = 1*8DIGIT        ; 0 to 16777215
> > > >     Payload         = 1*1191OCTET
> > > >
> > > >     OCTET           = %d00-255
> > > >     DIGIT           = %d48-57
> > > >     SP              = %d32
> > > >
> > > >
> > > >     3.1 Basic Header Format
> > > >
> > > >    When  no  fragmentation  is  used  and  the  entire
> > > syslog message is
> > > >    transferred  as  a  single  UDP/IP  datagram, a basic
> > > syslog transport
> > > >    header  MUST be used. The version for this protocol is
> > > "1". It must be
> > > >    followed  by  one  space  and  a  "0" to indicate that
> > > this is a basic
> > > >    header.  Therefore,  the  only  possible value for the
> > > basic header in
> > > >    this protocol is as follows:
> > > >
> > > >    "v1 0 "
> > > >
> > > >    Example  of  a syslog message without the transport
> > > header (message is
> > > >    wrapped for display):
> > > >
> > > >    "v1 888 3 2003-10-11T22:14:15.003Z host.domain.com
> > > >    dns: configuration error"
> > > >
> > > >    Example  of  the  same  message  with the transport
> > > header (message is
> > > >    wrapped for display):
> > > >
> > > >    "v1 0 v1 888 4 2003-10-11T22:14:15.003Z host.domain.com
> > > >    dns: configuration error"
> > > >
> > > >     3.2 Extended Header Format
> > > >
> > > >    When  syslog  message  is  fragmented  by  the  sender,
> > > multiple  UDP
> > > >    datagrams  must  be  used  and  each datagram MUST
> > > contain an extended
> > > >    syslog  transport  header.  The  version for this
> > > protocol is "1". The
> > > >    version field MUST be followed by a single space and a
> > > "1" to indicate
> > > >    that  this is an extended header. Thus, an extended
> > > header MUST always
> > > >    begin  with "v1 1 ", but MUST also have additional
> > > fields which aid in
> > > >    fragmentation.
> > > >
> > > >    The  MessageId,  TotalLength and FragmentOffset fields
> > > are used solely
> > > >    for fragmentation of long messages and reassembley. They
> > > SHOULD NOT be
> > > >    used for other purposes.
> > > >
> > > >     3.2.1 Message Identifier
> > > >
> > > >    The  MessageId  field  (along  with  the  source  UDP
> > > port and the IP
> > > >    address)  is  used  to  identify  the message such that
> > > fragments of a
> > > >    single  syslog  message  can  be  reassembled  by  the
> > > receiver into a
> > > >    complete  message.  The MessageId field MUST be a
> > > numeric value in the
> > > >    range  of  0  to  16777215.  Leading  zeros MUST not be
> > > present in the
> > > >    MessageId field.
> > > >
> > > >    Each syslog sender process MUST choose a random
> > > MessageId value within
> > > >    the  supported  range  for  its  first  message.
> > > Subsequent  messages
> > > >    generated  by  the same process MUST each increment the
> > > MessageId by 1
> > > >    up  to  16777215  and  then  continue at 0. Using random
> > > value for the
> > > >    first  MessageId  helps  reduce the possibility of
> > > potential errors in
> > > >    message   reassembley.   Refer   to   discussion   about
> > >   [65]message
> > > >    reassembleyMessage Reassembley for more details.
> > > >
> > > >    All  datagrams  which  represent  parts  of  a given
> > > fragmented syslog
> > > >    message MUST have the same MessageId value.
> > > >
> > > >     3.2.2 Total Length
> > > >
> > > >    The  TotalLength  field  MUST  be a numeric value in the
> > > range of 1 to
> > > >    16777216.  It  MUST  indicate  the length of a complete
> > > syslog message
> > > >    before it was fragmented and before it was encapsulated
> > > with transport
> > > >    headers.  The  same TotalLength field value MUST be
> > > present in all UDP
> > > >    datagrams  which  represent  fragments  of  the  same
> > > syslog message.
> > > >    Leading zeros MUST not be present in the TotalLength field.
> > > >
> > > >    Note  that in IPv4 the "total length" field identifies
> > > the length of a
> > > >    single  packet.  In  this  protocol,  the TotalLength
> > > field is used to
> > > >    identify  the  total  length  of  a  complete syslog
> > > message, which is
> > > >    transmitted  using  multiple  fragments and multiple
> > > datagram packets.
> > > >    The  fragment  length is not specified in the transport
> > > header because
> > > >    it  can  be inferred from the size of the IP packet
> > > containing the UDP
> > > >    datagram.
> > > >
> > > >     3.2.3 Fragment Offset
> > > >
> > > >    The  FragmentOffset field MUST be a numeric value in the
> > > range of 0 to
> > > >    16777215. It MUST indicate the byte offset of the
> > > fragment data in the
> > > >    complete  syslog  message.  The offset index starts at 0
> > > for the first
> > > >    fragment.  For  example,  if  an 700 byte syslog message
> > > is fragmented
> > > >    into  480  and 220 byte parts, the FragmentOffset in the
> > > first message
> > > >    will  be  0 and in the second - 480. Note that fragments
> > > don't have to
> > > >    be   the  same  size.  Leading  zeros  MUST  not  be
> > > present  in  the
> > > >    FragmentOffset field.
> > > >
> > > >     3.2.4 Extended Header Example
> > > >
> > > >    The  following is an example of a syslog message without
> > > the transport
> > > >    header (message is wrapped for display):
> > > >
> > > >    "v1 888 4 2003-10-11T22:14:15.003Z host.domain.com
> > > >    dns: configuration error"
> > > >
> > > >    Suppose  this message had to be fragmented by transport
> > > layer into two
> > > >    parts  at  an  arbitrary  point. This would result in
> > > two separate UDP
> > > >    datagrams  being sent - one for each fragment. Below is
> > > the content of
> > > >    each  of  the  syslog  transport  UDP  messages  with
> > > syslog transport
> > > >    headers but without UDP/IP headers:
> > > >
> > > >    "v1 1 45612221 74 0 v1 888 4
> 2003-10-11T22:14:15.003Z host.dom"
> > > >
> > > >    "v1 1 45612221 74 42 ain.com dns: configuration error"
> > > >
> > > >    In the above example, the leading "v1" is the version of
> > > the transport
> > > >    protocol, "1" indicates that this is an extended header
> > > (fragmentation
> > > >    in  use),  "45612221" is the MessageId, "74" is the
> > > TotalLength of the
> > > >    message,  while  "0"  and  "42"  are FragmentOffset
> > > fields. Everything
> > > >    following  the  FragmentOffset  and  a  space is a the
> > > Payload of each
> > > >    respective message.
> > > >
> > > >     3.3 Payload
> > > >
> > > >    The  Payload  field  of  the syslog UPD transport
> > > message is an entire
> > > >    syslog  message  or  one fragment. The maximum Payload
> > > size depends on
> > > >    the IP protocol used and the type header that is used.
> > > >    Maximum Payload size:
> > > >
> > > >    With IPv4 and basic header:    507 bytes
> > > >    With IPv4 and extended header: 480 bytes
> > > >
> > > >    With IPv6 and basic header:    1191 bytes
> > > >    With IPv6 and extended header: 1164 bytes
> > > >
> > > >    The  Payload size restrictions above effectively mean
> > > that the largest
> > > >    syslog  message  that  can  be  sent  non-fragmented  is
> > > 507 bytes for
> > > >    transport via IPv4 and 1191 bytes for transport via IPv6.
> > > >
> > > >    For  a discussion of the relational behind the above
> > > size restrictions
> > > >    please refer to Appendix A.
> > > >
> > > >     3.4 Supported Message Length
> > > >
> > > >    The  maximum  syslog  message length supported by this
> > > protocol is the
> > > >    maximum  value  of  the  TotalLength  field,  which is
> > > 16777216 bytes.
> > > >    However, not all deployment scenarios for syslog will be
> > > on hosts with
> > > >    hardware   capable  of  supporting  the  maximum  length
> > >  of  messages
> > > >    supported by this protocol. Additionally, extremely
> > > large messages may
> > > >    not be needed in many environments. Therefore,
> > > implementations are NOT
> > > >    REQUIRED  to  support  the  maximum  message  length
> > > allowed  by this
> > > >    protocol.
> > > >
> > > >    All implementations MUST support sending and receiving
> > > syslog messages
> > > >    up  to  and including 65536 bytes in size (syslog
> > > transport and UDP/IP
> > > >    headers  are  extra).  Support  for  larger  messages
> > > is  encouraged.
> > > >    Implementors  SHOULD  clearly state the maximum
> > > supported message size
> > > >    in documentation.
> > > >
> > >
_________________________________________________________________
> > > >
> > > >
> > >     [66]
> > > > TOC
> > > >
> > > >   4. UDP/IP Layer Considerations
> > > >
> > > >     4.1 Target Port
> > > >
> > > >    Syslog  receivers MUST support accepting syslog message
> > > datagrams on a
> > > >    well-known  UDP  port  514. Syslog senders MUST support
> > > sending syslog
> > > >    message datagrams to the UDP port 514.
> > > >
> > > >     4.2 Source Port
> > > >
> > > >    Syslog  senders can use any source UDP port for
> > > transmitting messages.
> > > >    Senders MAY randomly select a source port, but MUST use
> > > the port in an
> > > >    exclusive  fashion.  No  concurrent  port  reuse  on
> > > the same host is
> > > >    allowed.
> > > >
> > > >    Each  syslog  sender  process MUST attempt to use the
> > > same source port
> > > >    for the life of the the process. If due to an error or
> > > other condition
> > > >    it  becomes  impossible  for  the  process to continue
> > > to use the same
> > > >    port, it MAY start using a new source port, but it MUST
> > > generate a new
> > > >    random  MessageId  for  the  first message after
> > > changing the port and
> > > >    then MUST continue incrementing the new MessageId value
> > > for subsequent
> > > >    messages.
> > > >
> > > >    Since  source  port is used to identify parts of a
> > > fragmented message,
> > > >    the  sender  MUST  use  the same port to send all
> > > fragments of a given
> > > >    message.  If  due to an error or other condition, the
> > > sender is unable
> > > >    to  do  that,  it MUST resend all message fragments
> > > using the new port
> > > >    and a new MessageId field value.
> > > >
> > > >     4.3 Source IP Address
> > > >
> > > >    The source IP address of the UDP datagrams is one of the
> > > data elements
> > > >    used  to  identify  parts of a fragmented message.
> > > Therefore, a syslog
> > > >    sender  MUST  attempt  to  use  the same source IP
> > > address to send all
> > > >    fragments   of   a   given   syslog  message.  If  due
> > > to  an  error,
> > > >    reconfiguration  or  other condition it is unable to do
> > > so, the sender
> > > >    MUST  resend  all fragments of the syslog message using
> > > the new source
> > > >    IP address and a new MessageId value.
> > > >
> > > >     4.4 UDP/IP Headers
> > > >
> > > >    Each  UDP/IP  datagram  sent  by  the  transport layer
> > > MUST completely
> > > >    adhere  to  the  structure specified in the UDP [67]RFC
> > > 768Postel, J.,
> > > >    User  Datagram  Protocol,  August  1980.[3]  and  either
> > >  IPv4 [68]RFC
> > > >    791Postel,  J.,  Internet Protocol, September 1981.[4]
> > > or IPv6 [69]RFC
> > > >    2640Deering,  S.  and  R.  Hinden, Internet Protocol,
> > > Version 6 (IPv6)
> > > >    Specification, December 1998.[5] depending on which
> protocol is
> >
> > > > used.
> > > >
> > > >    Use of UDP checksums was defined as optional in [70]RFC
> > > 768Postel, J.,
> > > >    User  Datagram  Protocol,  August 1980.[3]. IPv6 has
> > > subsequently made
> > > >    UDP  checksums  required  [71][5]Deering,  S.  and R.
> > > Hinden, Internet
> > > >    Protocol,  Version  6  (IPv6)  Specification, December
> > > 1998.. However,
> > > >    syslog  senders MUST utilize valid UDP checksums when
> > > sending messages
> > > >    over  either  IPv4  or IPv6. Syslog receivers MUST check
> > > for checksums
> > > >    and  discard  messages  with  incorrect  checksums.
> > > Note that this is
> > > >    typically  accomplished  by  the  UDP  layer
> > > implementation, and some
> > > >    implementations allow for checksum checks to be enabled or
> > > > disabled.
> > > >
> > > >    Enabling  use  of  checksums  serves as an extra measure
> > > of corruption
> > > >    detection  in  addition  to  checksums  performed  by
> > > IP and Ethernet
> > > >    layers.  None  of  the above checksums provide a
> > > complete guarantee of
> > > >    corruption  detection.  Utilizing checksums on multiple
> > > layers reduces
> > > >    the chance of corruption error not being detected.
> > > >
> > >
_________________________________________________________________
> > > >
> > > >
> > >     [72]
> > > > TOC
> > > >
> > > >   5. Fragmentation and Reassembley
> > > >
> > > >     5.1 Message Fragmentation
> > > >
> > > >    The  syslog  transport  layer  MUST  perform
> > > fragmentation  if syslog
> > > >    message  size  exceeds the maximum allowed Payload size.
> > > Fragmentation
> > > >    SHOULD NOT be used if message can fit into the maximum
> > > allowed Payload
> > > >    size.
> > > >
> > > >    Syslog  messages  SHOULD  be fragmented such that all
> > > but last message
> > > >    utilize  the  Payload to its maximum capacity. For
> > > example, when using
> > > >    IPv4,  a 700 byte syslog message SHOULD be fragmented
> > > into 480 and 220
> > > >    byte  parts  because  the  maximum Payload size with
> > > IPv4 and extended
> > > >    header is 480 bytes.
> > > >
> > > >    Each  message fragment MUST be sent as a separate UDP/IP
> > > datagram with
> > > >    an  extended  syslog  transport  header.  The sender
> > > MUST use the same
> > > >    MessageId  value,  source port and source IP address for
> > > all fragments
> > > >    of  a  given  message.  These  three  field together
> > > uniquely identify
> > > >    fragments belonging to a given message.
> > > >
> > > >    On a system with short-lived sender processes, it may be
> > > possible that
> > > >    fragments  with  the  same  MessageId value, source port
> > > and source IP
> > > >    address  will  get  generated  in  short  time
> > > proximity. This can be
> > > >    possible  because  a  new  process may re-use the source
> > > port that was
> > > >    freed  up  by  another  process  that  just  dies. Such
> > > behavior could
> > > >    confuse  the  receiver  if the datagrams were received
> > > out of order or
> > > >    some datagrams got lost.
> > > >
> > > >    In  order to reduce the risk of such mistaken identity
> > > errors, section
> > > >    3.2.1  specified  that each process must start with a
> > > random value for
> > > >    MessageId  field.  Given  a relatively large range of
> > > MessageId values
> > > >    and  the  unlikely event of a coincidence of having the
> > > same MessageId
> > > >    value combined with re-used source port and UPD errors,
> > > the window for
> > > >    potential  mistaken identity errors during message
> > > reassembley is very
> > > >    small  and  tolerable.  The  users  take  a greater risk
> > > by using this
> > > >    protocol due to general UDP reliability issues discussed
> > > later in this
> > > >    specification.
> > > >
> > > >     5.2 Message Reassembley
> > > >
> > > >    The reassembley process uses the source IP address from
> > > the IP header,
> > > >    the  source  port from the UDP header and the MessageId
> > > field value to
> > > >    identify  fragments  of  a  given  message.  It  then
> > > uses  data from
> > > >    TotalLength  and FragmentOffset fields to re-assemble
> > > fragments into a
> > > >    complete message.
> > > >
> > > >    Typically,  an  implementation  of  fragmentation
> > > reassembley involves
> > > >    allocating  a  buffer  for  the  message  when any
> > > fragment with a new
> > > >    combination  of  source  IP  address,  source  port  and
> > >  MessageId is
> > > >    received.  A timer is used to expire the message
> > > reassembley and clean
> > > >    the  buffer  if all fragments are not received in
> > > certain time period.
> > > >    As  each  fragment  is  received,  it is placed into the
> > > buffer at the
> > > >    appropriate  offset  and  a  check  is  performed  to
> > > determine if all
> > > >    fragments have been received using additional data
> structures.
> > > >
> > > >    The  receiver  SHOULD  make  the  timeout  interval
> > > used  for message
> > > >    reassembley  configurable  for  the administrator. The
> > > receiver SHOULD
> > > >    also be able to limit the total amount of memory used
> > > for buffers such
> > > >    that it does not run out of resources under a simple
> > > denial of service
> > > >    attack  involving  just  one message fragment with a
> > > large TotalLength
> > > >    field  value.  Degrading  the  service  under  heavy
> > > load or attack is
> > > >    better  than  crashing  and  potentially making the
> > > service completely
> > > >    unavailable.
> > > >
> > > >     5.3 Avoiding Fragmentation
> > > >
> > > >    Fragmentation   and   reassembley   of   messages
> > > incurs  substantial
> > > >    processing overhead on both the sender and the receiver
> > > hosts. It also
> > > >    increases  the risk of lost messages due to lose of just
> > > one fragment.
> > > >    It  is  RECOMMENDED  that  syslog  senders  which
> > > anticipate  sending
> > > >    messages  over this transport protocol attempt to reduce
> > > the number of
> > > >    messages  which  require fragmentation by restricting
> > > them to the size
> > > >    which does not require fragmentation.
> > > >
> > >
_________________________________________________________________
> > > >
> > > >
> > >     [73]
> > > > TOC
> > > >
> > > >   6. Reliability Considerations
> > > >
> > > >    The UDP is an unreliable low-overhead protocol. This
> > > section discusses
> > > >    reliability  issues  inherent  in  the UDP that
> > > implementers and users
> > > >    must be aware of.
> > > >
> > > >     6.1 Lost Datagrams
> > > >
> > > >    Neither  UDP  nor  syslog protocol provide any mechanism
> > > to detect and
> > > >    correct  loss  of  datagrams.  Datagrams may be lost in
> > > transit due to
> > > >    congestion,  corruption  or  any  other  intermittent
> > > network problem.
> > > >    Syslog  protocol  and IP fragmentation exacerbates the
> > > problem because
> > > >    loss  of  a  single  fragment  would  result  in  entire
> > > message being
> > > >    discarded.
> > > >
> > > >    In  some circumstances the sender may receive an ICMP
> > > error message or
> > > >    other  indication  of a transmission problem. If the
> > > sender receives a
> > > >    reasonable  indication  that  some datagram may have
> > > been lost, it MAY
> > > >    retransmit previously sent messages.
> > > >
> > > >     6.2 Message Corruption and Checksums
> > > >
> > > >    The  UDP/IP  datagrams  may  get corrupted in transit
> > > due to software,
> > > >    hardware  or  network  errors.  This  protocol
> > > specified  use  of UDP
> > > >    checksums  to  enable  corruption  detection  in
> > > addition to checksums
> > > >    utilized  in  IP  and  Ethernet  layers.  However,
> > > checksums  do  not
> > > >    guarantee  corruption detection and this protocol does
> > > not provide for
> > > >    message retransmission when a corrupt message is detected.
> > > >
> > > >     6.3 Congestion Control
> > > >
> > > >    The  UDP  does not provide for congestion control. Some
> > > systems (hosts
> > > >    or  routers)  may  generate ICMP source quench error,
> > > but they are not
> > > >    required to do so [74][8]Stevens, W., TCP/IP Illustrated
> > > Volume 1. The
> > > >    Protocols.,  January  1994..  Any network host can
> > > discard UDP packets
> > > >    when  it  is  overloaded.  Due  to  lack  of congestion
> > > control one or
> > > >    multiple  syslog senders can maliciously or
> > > inadvertently overload the
> > > >    receiver  or  the  network  infrastructure  and  cause
> > > loss of syslog
> > > >    messages.
> > > >
> > > >     6.4 Sequenced Delivery
> > > >
> > > >    The  IP  transport  utilized  by  the  UDP does not
> > > guarantee that the
> > > >    sequence  of  datagram  delivery  will  match  the
> > > order in which the
> > > >    datagrams  have been sent. The time stamp contained
> > > within each syslog
> > > >    message may serve as some guide in establishing sequence
> > > order, but it
> > > >    will  not  help  in cases when multiple messages were
> > > generated during
> > > >    the  same  time  slot or when messages originated from
> > > different hosts
> > > >    whose clocks are not synchronized. The order of syslog
> > > message arrival
> > > >    via  the  this syslog transport SHOULD NOT be used as an
> > > authoritative
> > > >    guide  in  establishing  the  sequence  of events on the
> > > syslog sender
> > > >    hosts.
> > > >
> > > >     6.5 Sender Authentication
> > > >
> > > >    The  UDP syslog transport does not strongly associate
> > > the message with
> > > >    the  message  sender.  The  receiver of the syslog
> > > message will not be
> > > >    able  to  ascertain that the message was indeed sent
> > > from the reported
> > > >    sender, or if the packet was sent from another device.
> > > >
> > > >    One  possible  consequence  of  this  behavior is that a
> > > misconfigured
> > > >    machine  may send syslog messages to a receiver
> > > representing itself as
> > > >    another machine. The administrators may not be able to
> > > readily discern
> > > >    that  there  are  two  or more machines representing
> > > themselves as the
> > > >    same machine.
> > > >
> > >
_________________________________________________________________
> > > >
> > > >
> > >     [75]
> > > > TOC
> > > >
> > > >   7. Security Considerations
> > > >
> > > >    Several   syslog   security  considerations  have  been
> > > discussed  in
> > > >    [76]RFC-protocolGerhards,  R.,  The  syslog  Protocol,
> > > .[2] and in the
> > > >    original  [77]RFC  3164Lonvick,  C.,  The  BSD Syslog
> > > Protocol, August
> > > >    2001.[1].  This section focuses on security
> > > considerations specific to
> > > >    the syslog transport over UDP.
> > > >
> > > >     7.1 Message Authenticity
> > > >
> > > >    This transport protocol does not strongly authenticate
> > > the identity of
> > > >    the message sender and does not provide any assurance
> > > that the message
> > > >    was  not  modified in transit. The receiver of the
> > > syslog message will
> > > >    not  be  able  to  ascertain that the message was indeed
> > > sent from the
> > > >    reported sender, or if the packet was sent from
> another device.
> > > >
> > > >     7.2 Message Forgery
> > > >
> > > >    Syslog  messages can be easily forged. An attacker may
> > > transmit syslog
> > > >    messages  (either  from  the  machine  from  which  the
> > > messages  are
> > > >    purportedly sent or from any other machine) to a receiver.
> > > >
> > > >    In  one case, an attacker may hide the true nature of an
> > > attack amidst
> > > >    many  other  messages. As an example, an attacker may
> > > start generating
> > > >    forged messages indicating a problem on some machine.
> > > This may get the
> > > >    attention  of  the  system  administrators  who  will
> > > spend their time
> > > >    investigating  the alleged problem. During this time,
> > > the attacker may
> > > >    be  able  to compromise a different machine, or a
> > > different process on
> > > >    the same machine.
> > > >
> > > >    Additionally,  an  attacker may generate false syslog
> > > messages to give
> > > >    untrue  indications of status or of events. As an
> > > example, an attacker
> > > >    may  stop  a  critical  process  on  a  machine,  which
> > > may generate a
> > > >    notification  of exit. The attacker may subsequently
> > > generate a forged
> > > >    notification   that   the  process  had  been
> > > restarted.  The  system
> > > >    administrators  may accept that misinformation and not
> > > verify that the
> > > >    process had indeed been restarted.
> > > >
> > > >     7.3 Message Observation
> > > >
> > > >    The  transport  protocol  does  not  provide
> > > confidentiality  of  the
> > > >    messages in transit. If syslog messages are in clear
> > > text, this is how
> > > >    they   will   be   transferred.   In  most  cases
> > > passing  clear-text
> > > >    human-readable   messages   is   a   benefit  to  the
> > > administrators.
> > > >    Unfortunately,   an   attacker   may  also  be  able  to
> > >  observe  the
> > > >    human-readable  contents of syslog messages. The
> > > attacker may then use
> > > >    the knowledge gained from those messages to compromise a
> > > machine or do
> > > >    other  damage.  It  is  RECOMMENDED  that  no sensitive
> > > information is
> > > >    transmitted  via  this transport protocol or that
> > > transmission of such
> > > >    information is restricted to properly secured networks.
> > > >
> > > >     7.4 Replaying
> > > >
> > > >    Message  forgery and observation can be combined into a
> > > replay attack.
> > > >    An attacker may record a set of messages that indicate
> > > normal activity
> > > >    of  a  machine. At a later time, that attacker may
> > > remove that machine
> > > >    from  the network and replay the syslog messages to the
> > > collector with
> > > >    new  time  stamps.  The administrators may find nothing
> > > unusual in the
> > > >    received  messages  and  their  receipt  would falsely
> > > indicate normal
> > > >    activity of the machine.
> > > >
> > > >     7.5 Unreliable Delivery
> > > >
> > > >    As was previously discussed in the Reliability
> > > Considerations section,
> > > >    the  UDP  transport  is  not  reliable  and  packets
> > > containing syslog
> > > >    message datagrams can be lost in transit without any
> > > notice. There can
> > > >    be  security  consequences to the loss of one or more
> > > syslog messages.
> > > >    Administrators  may  not  become aware of a developing
> > > and potentially
> > > >    serious  problem. Messages may also be intercepted and
> > > discarded by an
> > > >    attacker as a way to hide unauthorized activities.
> > > >
> > > >     7.6 Message Prioritization and Differentiation
> > > >
> > > >    The  transport  protocol  described  in this document
> > > does not require
> > > >    prioritization of syslog messages on the wire or when
> > > processed on the
> > > >    receiving  host  based  on their severity. The security
> > > implication of
> > > >    such  behavior  is that the syslog receiver or network
> > > devices may get
> > > >    overwhelmed  with  low  severity  messages  and  be
> > > forced to discard
> > > >    potentially high severity messages. High severity
> > > messages may contain
> > > >    indication  about  serious  security problems, but they
> > > will not get a
> > > >    higher  priority.  It  is  difficult to make sure that
> > > high severities
> > > >    messages  get  higher end-to-end delivery priority,
> > > especially over an
> > > >    unreliable UDP transport.
> > > >
> > > >    On  a  case-by-case  basis,  device  operators  may
> > > find  some way to
> > > >    associate  the  different  severity levels with the
> > > quality of service
> > > >    identifiers.  As  an  example,  the operators may elect
> > > to define some
> > > >    linkage  between  syslog  messages that have a specific
> > > Priority value
> > > >    with  a  specific  value  to  be  used  in  the  IPv4
> > > Precedence field
> > > >    [78][4]Postel,  J.,  Internet  Protocol,  September
> > > 1981.,  the  IPv6
> > > >    Traffic  Class  octet  [79][5]Deering,  S.  and  R.
> > > Hinden,  Internet
> > > >    Protocol,  Version  6  (IPv6)  Specification,  December
> > > 1998., or the
> > > >    Differentiated Services field [80][9]Nichols, K., Blake,
> > > S., Baker, F.
> > > >    and  D.  Black,  Definition  of  the Differentiated
> > > Services Field (DS
> > > >    Field)  in  the  IPv4  and IPv6 Headers, December 1998..
> > > However, even
> > > >    with  this prioritization on the network, high load can
> > > lead to buffer
> > > >    starvation on the receiving host and result in dropped
> > messages.
> > > >
> > > >     7.7 Denial of Service
> > > >
> > > >    An  attacker  may  overwhelm a receiver by sending more
> > > messages to it
> > > >    than  can  be  handled  by  the  infrastructure  or the
> > > device itself.
> > > >    Implementers  SHOULD  attempt  to  provide features that
> > > minimize this
> > > >    threat such as only receiving syslog messages from known
> > > IP addresses.
> > > >
> > >
_________________________________________________________________
> > > >
> > > >
> > >     [81]
> > > > TOC
> > > >
> > > >   8. IANA Considerations
> > > >
> > > >    IANA must reserve UDP port 514 for this transport.
> > > >
> > >
_________________________________________________________________
> > > >
> > > >
> > >     [82]
> > > > TOC
> > > >
> > > >   9. Notice to RFC Editor
> > > >
> > > >    This is a notice to the RFC editor. This ID is submitted
> > > along with ID
> > > >    draft-ietf-syslog-protocol  and  they cross-reference
> > > each other. When
> > > >    RFC  numbers  are determined for each of these IDs,
> > > please replace all
> > > >    references    to    "RFC-protocol"    with    the    RFC
> > >   number   of
> > > >    draft-ietf-syslog-protocol   ID.  Please  remove  this
> > > section  after
> > > >    editing.
> > > >
> > >
_________________________________________________________________
> > > >
> > > >
> > >     [83]
> > > > TOC
> > > >
> > > >   10. Authors and Working Group Chair
> > > >
> > > >    The working group can be contacted via the mailing list:
> > > > [email-masked]
> > > >
> > > >    The current Chair of the Working Group may be contacted
> > > at: Chris
> > > > Lonvick Cisco Systems
> > > > Email: [email-masked]
> > > >
> > > >    The author of this draft is:
> > > > Anton Okmianski
> > > > Email: [email-masked]
> > > >
> > > > Phone: (978) 936-1612
> > > > Fax: (978) 936-2225
> > > >
> > > > Cisco Systems, Inc
> > > > 1414 Massachusetts Ave.
> > > > Boxborough, MA 01719-2205
> > > > USA
> > > >
> > >
_________________________________________________________________
> > > >
> > > >
> > >     [84]
> > > > TOC
> > > >
> > > >   11. Acknowledgements
> > > >
> > > >    The  author  wishes  to  thank  Chris  Lonvick, Rainer
> > > Gerhards, David
> > > >    Harrington,  Andrew  Ross,  Albert Mietus, Bernie Volz,
> > > and all others
> > > >    who have commented on the various versions of this
proposal.
> > > >
> > >
_________________________________________________________________
> > > >
> > > >
> > >     [85]
> > > > TOC
> > > >
> > > >   12 References
> > > >
> > > >    [1] Lonvick, C., "[86]The BSD Syslog Protocol", RFC
> > > 3164, August 2001.
> > > >    [2] Gerhards, R., "[87]The syslog Protocol", RFC
> RFC-protocol.
> > > >    [3] Postel, J., "[88]User Datagram Protocol", STD 6, RFC
> > > 768, August
> > > >    1980.
> > > >    [4]  Postel,  J.,  "[89]Internet  Protocol", STD 5, RFC
> > > 791, September
> > > >    1981.
> > > >    [5] [90]Deering, S. and [91]R. Hinden, "[92]Internet
> > > Protocol, Version
> > > >    6 (IPv6) Specification", RFC 2460, December 1998
> > > ([93]HTML, [94]XML).
> > > >    [6]  [95]Bradner,  S.,  "[96]Key  words  for  use  in
> > > RFCs to Indicate
> > > >    Requirement Levels", BCP 14, RFC 2119, March 1997
> > > ([97]HTML, [98]XML).
> > > >    [7]  [99]Crocker,  D.  and  [100]P.  Overell,
> > > "[101]Augmented BNF for
> > > >    Syntax Specifications: ABNF", RFC 2234, November 1997.
> > > >    [8]  Stevens,  W.,  "TCP/IP  Illustrated  Volume  1.
> > > The Protocols.",
> > > >    January 1994.
> > > >    [9]  [102]Nichols,  K.,  [103]Blake,  S.,  [104]Baker,
> > > F. and [105]D.
> > > >    Black,  "[106]Definition  of  the  Differentiated
> > > Services  Field (DS
> > > >    Field)  in  the  IPv4  and  IPv6  Headers",  RFC  2474,
> > > December 1998
> > > >    ([107]HTML, [108]XML).
> > > >    [10]   Mockapetris,   P.,  "[109]Domain  names  -
> > > implementation  and
> > > >    specification", STD 13, RFC 1035, November 1987.
> > > >    [11]  Hedrick, C., "[110]Routing Information Protocol",
> > > RFC 1058, June
> > > >    1988.
> > > >    [12]  [111]Droms,  R., "[112]Dynamic Host Configuration
> > > Protocol", RFC
> > > >    2131, March 1997 ([113]HTML, [114]XML).
> > > >    [13]  [115]Sollins, K., "[116]The TFTP Protocol
> > > (Revision 2)", STD 33,
> > > >    RFC 1350, July 1992.
> > > >    [14]   [117]Braden,   R.,  "[118]Requirements  for
> > > Internet  Hosts  -
> > > >    Communication Layers", STD 3, RFC 1122, October 1989.
> > > >    [15]  Kent,  C.  and  J.  Mogul,  ""Fragmentation
> > > Considered Harmful,"
> > > >    Computer  Communications  Review,  vol.17,  no.5,
> > > pp.390-401", August
> > > >    1987.
> > > >
> > >
_________________________________________________________________
> > > >
> > > >
> > >    [119]
> > > > TOC
> > > >
> > > >   Author's Address
> > > >
> > > >            Anton Okmianski
> > > >            Cisco Systems, Inc.
> > > >            1414 Massachusetts Ave
> > > >            Boxborough, MA 01719-2205
> > > >            USA
> > > >    EMail:  [email-masked]
> > > >
> > >
_________________________________________________________________
> > > >
> > > >
> > >    [120]
> > > > TOC
> > > >
> > > >   Appendix A. Rational For Transport Message Size Restrictions
> > > >
> > > >    This   appendix   provides   the  rational  behind  the
> > > Payload  size
> > > >    restrictions  for  this protocol. The Payload
> > > restrictions outlined in
> > > >    the  specification, essentially ensure that the
> > > transport message size
> > > >    does  not  exceed 512 bytes (without UDP/IP headers) for
> > > transport via
> > > >    IPv4  and  does  not  exceed  1196 bytes for transport
> > > via IPv6. These
> > > >    restrictions  put  an  upper  boundary on the UDP/IP
> > > datagram size for
> > > >    this protocol, which accomplishes two goals.
> > > >
> > > >    First,   they   insure   interoperability   between
> > > various   UDP/IP
> > > >    implementations. Even though the maximum IP datagram
> > > size is specified
> > > >    as  65536  bytes,  many  UDP/IP implementations have
> > > been shown not to
> > > >    work with large datagram sizes [121][8]Stevens, W.,
> > > TCP/IP Illustrated
> > > >    Volume  1.  The  Protocols., January 1994.. Many
> > > established UDP-based
> > > >    protocols  restrict  UDP datagram data size to 512
> > > bytes. For example,
> > > >    DNS  [122][10]Mockapetris,  P.,  Domain  names  -
> > > implementation  and
> > > >    specification,  November  1987.  and RIP
> > > [123][11]Hedrick, C., Routing
> > > >    Information  Protocol,  June 1988. do that. The DHCPv4
> > > [124][12]Droms,
> > > >    R.,  Dynamic  Host  Configuration  Protocol, March 1997.
> > > restricts the
> > > >    size to 512 bytes, but allows sides to agree on a larger
> > > value through
> > > >    the  protocol.  The  TFTP  [125][13]Sollins,  K.,  The
> > > TFTP  Protocol
> > > >    (Revision  2),  July  1992.  restricts the UDP data size
> > > to 518 bytes,
> > > >    which is slightly larger.
> > > >
> > > >    The  second  reason  for  datagram  size restrictions is
> > > that it helps
> > > >    reduce  the  likelihood  of  the IP-layer datagram
> > > fragmentation. This
> > > >    could have potentially resulted in fragmentation on two
> > > levels: syslog
> > > >    transport  protocol  and IP layer. Since fragmentation
> > > has significant
> > > >    overhead   for  message  reassembley,  it  is  best  to
> > > avoid  double
> > > >    fragmentation. The likelihood of IP fragmentation can be
> > > significantly
> > > >    reduced  by sending IP datagrams in sizes which all
> > > hosts must be able
> > > >    to process.
> > > >
> > > >    The minimum MTU of a transport protocol determines the
> > > minimum size of
> > > >    packets  that  hosts must be able to accept. For IPv4,
> > > the minimum MTU
> > > >    is  576  bytes  [126][4]Postel, J., Internet Protocol,
> > > September 1981.
> > > >    and  for IPv6 - 1280 bytes [127][5]Deering, S. and R.
> > > Hinden, Internet
> > > >    Protocol,  Version  6  (IPv6)  Specification,  December
> > > 1998.. In both
> > > >    cases,  the  maximum  message size we chose fits within
> > > the MTU of the
> > > >    transport  in all cases except for when extremely large
> > > IP headers are
> > > >    used.  IPv4  header  can  range  from 20 to 60 bytes in
> > > length and UDP
> > > >    header is fixed at 8 bytes. Thus, our message size
> > > restrictions ensure
> > > >    that  in  all  cases  except  for  when  the  IP header
> > > is 56 bytes or
> > > >    greater,  the size of the packet will within the size of
> > > the transport
> > > >    MTU.
> > > >
> > > >    For  IPv6,  we have left the same amount of padding for
> > > UDP/IP headers
> > > >    as  was  conventionally  done  for IPv4 in DNS, RIP and
> > > DHCPv4 with an
> > > >    additional  padding  of  extra  20  bytes to accommodate
> > > a larger IPv6
> > > >    header.   This   follows   the   methodology  suggested
> > > in  the  IPv6
> > > >    specification    for    calculating    upper-layer
> > > payload   limits
> > > >    [128][5]Deering, S. and R. Hinden, Internet Protocol,
> > > Version 6 (IPv6)
> > > >    Specification, December 1998..
> > > >
> > > >    Path  MTU  discovery  can generally be used to discover
> > > the MTU of the
> > > >    link.  Unfortunately,  using  path  MTU  discovery  with
> > >  UDP is not a
> > > >    reliable  option  because  it depends on routers
> > > providing ICMP errors
> > > >    and  hosts  doing  retransmission,  which  are  not done
> > > consistently.
> > > >    Implementors  MUST follow the size restrictions outlined
> > > above and not
> > > >    rely on path MTU discovery.
> > > >
> > >
_________________________________________________________________
> > > >
> > > >
> > >    [129]
> > > > TOC
> > > >
> > > >   Intellectual Property Statement
> > > >
> > > >    The  IETF  takes  no  position  regarding the validity
> > > or scope of any
> > > >    intellectual property or other rights that might be
> > > claimed to pertain
> > > >    to  the  implementation  or  use  of  the technology
> > > described in this
> > > >    document or the extent to which any license under such
> > > rights might or
> > > >    might not be available; neither does it represent that
> > > it has made any
> > > >    effort  to  identify  any  such  rights.  Information
> > > on  the  IETF's
> > > >    procedures   with   respect   to   rights   in
> > > standards-track   and
> > > >    standards-related  documentation  can  be  found  in
> > > BCP-11. Copies of
> > > >    claims  of rights made available for publication and any
> > > assurances of
> > > >    licenses  to  be  made  available, or the result of an
> > > attempt made to
> > > >    obtain a general license or permission for the use of
> > > such proprietary
> > > >    rights  by implementors or users of this specification
> > > can be obtained
> > > >    from the IETF Secretariat.
> > > >
> > > >    The  IETF  invites  any interested party to bring to its
> > > attention any
> > > >    copyrights,  patents  or  patent  applications,  or
> > > other proprietary
> > > >    rights  which  may  cover  technology that may be
> > > required to practice
> > > >    this  standard.  Please  address the information to the
> > > IETF Executive
> > > >    Director.
> > > >
> > > >   Full Copyright Statement
> > > >
> > > >    Copyright (C) The Internet Society (2004). All
> Rights Reserved.
> > > >
> > > >    This  document  and  translations of it may be copied
> > > and furnished to
> > > >    others,  and  derivative works that comment on or
> > > otherwise explain it
> > > >    or assist in its implementation may be prepared, copied,
> > > published and
> > > >    distributed,  in  whole  or  in part, without
> > > restriction of any kind,
> > > >    provided  that  the  above  copyright  notice  and  this
> > > paragraph are
> > > >    included  on  all  such  copies  and  derivative  works.
> > > However, this
> > > >    document  itself  may  not be modified in any way, such
> > > as by removing
> > > >    the  copyright  notice  or references to the Internet
> > > Society or other
> > > >    Internet organizations, except as needed for the purpose
> > > of developing
> > > >    Internet standards in which case the procedures for
> > > copyrights defined
> > > >    in  the Internet Standards process must be followed, or
> > > as required to
> > > >    translate it into languages other than English.
> > > >
> > > >    The  limited  permissions  granted above are perpetual
> > > and will not be
> > > >    revoked by the Internet Society or its successors or
> assignees.
> > > >
> > > >    This  document  and the information contained herein is
> > > provided on an
> > > >    "AS  IS"  basis  and THE INTERNET SOCIETY AND THE
> > > INTERNET ENGINEERING
> > > >    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
> > > INCLUDING BUT
> > > >    NOT  LIMITED  TO  ANY  WARRANTY THAT THE USE OF THE
> > > INFORMATION HEREIN
> > > >    WILL   NOT   INFRINGE   ANY   RIGHTS  OR  ANY  IMPLIED
> > > WARRANTIES  OF
> > > >    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
> > > >
> > > >   Acknowledgment
> > > >
> > > >    Funding  for  the  RFC  Editor  function  is currently
> > > provided by the
> > > >    Internet Society.
> > > >
> > > > References
> > > >
> > > >    1.
> > >
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
> > > >    2. http://www.ietf.org/ietf/1id-abstracts.txt
> > > >    3. http://www.ietf.org/shadow.html
> > > >    4.
> > >
> >
>
file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#intro
> > > >    5.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#TransportProtocolOverview
> > > >    6.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#DefinitionsAndArchitecture
> > > >    7.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#RequiredTransportProtocol
> > > >    8.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#EncapsulationLayers
> > > >    9.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#MessageFormat
> > > >   10.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#BasicHeaderFormat
> > > >   11.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#ExtendedHeaderFormat
> > > >   12.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#Message Identifier
> > > >   13.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#TotalLength
> > > >   14.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#FragmentOffset
> > > >   15.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#ExtendedHeaderExample
> > > >   16.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#Payload
> > > >   17.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#SupportedMessageLength
> > > >   18.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#LowerLayerConsiderations
> > > >   19.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#TargetPort
> > > >   20.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#SourcePort
> > > >   21.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#SourceIPAddress
> > > >   22.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#UDPIPHeader
> > > >   23.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#FragmentationAndReassembley
> > > >   24.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#MessageFragmentation
> > > >   25.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#MessageReassembley
> > > >   26.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#AvoidingFragmentation
> > > >   27.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#reliability
> > > >   28.
> > >
> >
>
file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#loss
> > > >   29.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#corruption
> > > >   30.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#overload
> > > >   31.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#sequence
> > > >   32.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#SenderAuthentication
> > > >   33.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#security
> > > >   34.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#SecAuth
> > > >   35.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#SecForg
> > > >   36.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#SecObs
> > > >   37.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#SecReplay
> > > >   38.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#SecRelDel
> > > >   39.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#SecPri
> > > >   40.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#SecDen
> > > >   41.
> > >
> >
>
file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#iana
> > > >   42.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#rfc-editor
> > > >   43.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#authors
> > > >   44.
> > >
> >
>
file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#acks
> > > >   45.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#rfc.references1
> > > >   46.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#rfc.authors
> > > >   47.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#AppendixA
> > > >   48.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#rfc.copyright
> > > >   49.
> > >
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
> > > >   50.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#RFC3164
> > > >   51.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#RFC-protocol
> > > >   52.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#RFC-protocol
> > > >   53.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#RFC0768
> > > >   54.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#RFC0791
> > > >   55.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#RFC2460
> > > >   56.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#RFC2119
> > > >   57.
> > >
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
> > > >   58.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#RFC-protocol
> > > >   59.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#RFC-protocol
> > > >   60.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#RFC-protocol
> > > >   61.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#RFC0768
> > > >   62.
> > >
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
> > > >   63.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#RFC-protocol
> > > >   64.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#RFC2234
> > > >   65.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#MessageReassembley
> > > >   66.
> > >
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
> > > >   67.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#RFC0768
> > > >   68.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#RFC0791
> > > >   69.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#RFC2460
> > > >   70.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#RFC0768
> > > >   71.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#RFC2460
> > > >   72.
> > >
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
> > > >   73.
> > >
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
> > > >   74.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#Stevens
> > > >   75.
> > >
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
> > > >   76.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#RFC-protocol
> > > >   77.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#RFC3164
> > > >   78.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#RFC0791
> > > >   79.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#RFC2460
> > > >   80.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > > ml#RFC2474
> > > >   81.
> > >
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
> > > >   82.
> > >
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
> > > >   83.
> > >
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
> > > >   84.
> > >
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
> > > >   85.
> > >
> file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
> > > >   86. ftp://ftp.isi.edu/in-notes/rfc3164.txt
> > > >   87. ftp://ftp.isi.edu/in-notes/rfc3164.txt
> > > >   88. ftp://ftp.isi.edu/in-notes/rfc768.txt
> > > >   89. ftp://ftp.isi.edu/in-notes/rfc791.txt
> > > >   90. mailto:[email-masked]
> > > >   91. mailto:[email-masked]
> > > >   92. ftp://ftp.isi.edu/in-notes/rfc2460.txt
> > > >   93. http://xml.resource.org/public/rfc/html/rfc2460.html
> > > >   94. http://xml.resource.org/public/rfc/xml/rfc2460.xml
> > > >   95. mailto:[email-masked]
> > > >   96. ftp://ftp.isi.edu/in-notes/rfc2119.txt
> > > >   97. http://xml.resource.org/public/rfc/html/rfc2119.html
> > > >   98. http://xml.resource.org/public/rfc/xml/rfc2119.xml
> > > >   99. mailto:[email-masked]
> > > >  100. mailto:[email-masked]
> > > >  101. ftp://ftp.isi.edu/in-notes/rfc2234.txt
> > > >  102. mailto:[email-masked]
> > > >  103. mailto:[email-masked]
> > > >  104. mailto:[email-masked]
> > > >  105. mailto:[email-masked]
> > > >  106. ftp://ftp.isi.edu/in-notes/rfc2474.txt
> > > >  107. http://xml.resource.org/public/rfc/html/rfc2474.html
> > > >  108. http://xml.resource.org/public/rfc/xml/rfc2474.xml
> > > >  109. ftp://ftp.isi.edu/in-notes/rfc1035.txt
> > > >  110. ftp://ftp.isi.edu/in-notes/rfc1058.txt
> > > >  111. mailto:[email-masked]
> > > >  112. ftp://ftp.isi.edu/in-notes/rfc2131.txt
> > > >  113. http://xml.resource.org/public/rfc/html/rfc2131.html
> > > >  114. http://xml.resource.org/public/rfc/xml/rfc2131.xml
> > > >  115. mailto:[email-masked]
> > > >  116. ftp://ftp.isi.edu/in-notes/rfc1350.txt
> > > >  117. mailto:[email-masked]
> > > >  118. ftp://ftp.isi.edu/in-notes/rfc1122.txt
> > > >  119.
> > > >
> >
file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
> > > >  120.
> > > file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.ht
> > ml#toc
> > >  121.
> >
> file://localhost/usr/tmp/draft-ietf-syslog->
transport-udp-01.html#Steve
> > ns
> > >  122.
> >
> file://localhost/usr/tmp/draft-ietf-syslog->
transport-udp-01.html#RFC10
> > 35
> > >  123.
> >
> file://localhost/usr/tmp/draft-ietf-syslog->
transport-udp-01.html#RFC10
> > 58
> > >  124.
> >
> file://localhost/usr/tmp/draft-ietf-syslog->
transport-udp-01.html#RFC21
> > 31
> > >  125.
> >
> file://localhost/usr/tmp/draft-ietf-syslog->
transport-udp-01.html#RFC13
> > 50
> > >  126.
> >
> file://localhost/usr/tmp/draft-ietf-syslog->
transport-udp-01.html#RFC07
> > 91
> > >  127.
> >
> file://localhost/usr/tmp/draft-ietf-syslog->
transport-udp-01.html#RFC24
> > 60
> > >  128.
> >
> file://localhost/usr/tmp/draft-ietf-syslog->
transport-udp-01.html#RFC24
> > 60
> > >  129.
> >
file://localhost/usr/tmp/draft-ietf-syslog-transport-udp-01.html#toc
> >
> >
> > --
> > Devin Kowatch
> > [email-masked]
>
> --
> Devin Kowatch
> [email-masked]
>

------------------------------

Date: Thu, 13 May 2004 13:03:21 -0400
From: [email-masked]
Subject: I-D ACTION:draft-ietf-syslog-transport-udp-01.txt

- --NextPart

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-01.txt
	Pages		: 20
	Date		: 2004-5-12

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-transport-udp-01.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-01.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-01.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.

- --NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

- --OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-syslog-transport-udp-01.txt

- --OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-syslog-transport-udp-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

- --OtherAccess--

- --NextPart--

------------------------------

Date: Thu, 13 May 2004 18:24:16 -0400
From: "Anton Okmianski" <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-syslog-transport-udp-01.txt

Team:

This draft is essentially what you saw when I sent a preview.  It
incorporates some minor editorial updates and has one major change
which has been suggested to me by several people.

It sets the minimum required message support at 507 bytes (for IPv4)
instead of 65K.  This means that implementations that don't wish to
handle larger message sizes, don't have to implement the fragmentation
at all.  I think this solves the concerns many people voiced.  Since
fragmentation makes UDP even less reliable than it already is, it is
probably not a good idea to force people to implement it if they
decide that it is not a good model for their customers.

This way, we have baseline interoperability, and for scenarios where
large message support is needed, the administrators can use
appropriate implementations which support it.  The maximum size is
still 16MB.  I think it is important that we support (not necessarily
require) ability to transmitting syslog messages of any size over any
transport.  I am not married to the 16MB number though if people want
it lowered.

Please provide comments on the draft.

Thanks,
Anton.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Thursday, May 13, 2004 1:03 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: I-D ACTION:draft-ietf-syslog-transport-udp-01.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-01.txt
> 	Pages		: 20
> 	Date		: 2004-5-12
>
> 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-01.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-01.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-01.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.

------------------------------

Date: Fri, 21 May 2004 19:38:26 -0700 (PDT)
From: Chris Lonvick <[email-masked]>
Subject: Mailing List Moving

Hi Folks,

The employees.org maching is going away rather soon so I'm working to get
the mailing list moved over to the IETF mail server.  If all works out
well, you will be notified when you are subscribed to the new mailing
list.  If you don't hear anything soon, then please check our web page on
the IETF server to see if it lists a new mailing list and somehow you were
not automatically subscribed.
  http://www.ietf.org/html.charters/syslog-charter.html

I sincerely apologize for the disruption.  I think that we're getting
really close to finalizing syslog-protocol and syslog-transport-udp.  I
will be calling a meeting for the San Diego IETF so look for that notice
soon.

Thanks,
Chris

------------------------------

End of syslog-sec-digest V1 #306
********************************