headers
Chris Lonvick | 5 Jul 2007 16:45
Picon
Favicon

IESG Discusses and Comments

Hi Folks,

David and I have been trying to address the open DISCUSSes on 
-syslog-protocol and -syslog-transport-udp.
https://datatracker.ietf.org/idtracker/ballot/1800/

As an aside: Sam has reviewed -syslog-transport-tls and has asked for some 
modifications.  Miao and Yuzhi are working on those and we expect to get 
that back to the WG for review soon.  Until then, we're pushing forward 
with -protocol and -udp.

I've identified 4 Discuss topics:
- Source Address
- UDP Length
- UDP Checksum
- Congestion Control

For the first three I believe we have some resolution.  The WG needs to 
verify this.  There still seems to be an open issue with the last one.
When I send these out, please comment.

There are also many Comments from the IESG.  Some have resulted in some 
moderate changes, mostly editorial, in the documents.  Others I havn't 
addressed as those are not critical to progressing these documents.

Thanks,
Chris

_______________________________________________
Syslog mailing list
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Lonvick | 5 Jul 2007 16:46
Picon
Favicon

Discuss - Source Address


Discuss - Source Address

Lars:
draft-ietf-syslog-protocol-21, Section 5., paragraph 2:
>    If a syslog application is running on a machine
>    that has both statically and dynamically assigned addresses, then
>    that value SHOULD be from the statically assigned addresses.  As an
>    alternative, the syslog application MAY use the IP address of the
>    interface that is used to send the message.

   DISCUSS: So if a machine has only a dynamic address, it should instead
   use 127.0.0.1 in syslog messages, because that's statically assigned?
   That doesn't seem to make sense. Also, in practice, it will be
   difficult for the syslog sender to determine which addresses are
   statically or dynamically assigned (think MobileIP or even HIP).

Proposed Resolution:

The author and the chairs recommend removing this paragraph.  Any 
objection this this?

_______________________________________________
Syslog mailing list
Syslog <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
Permalink | Reply | 0 comments |
headers
Chris Lonvick | 5 Jul 2007 16:47
Picon
Favicon

Discuss - UDP Length


Discuss - UDP Length

Lars:

draft-ietf-syslog-transport-udp-09, Section 65535, paragraph 0:
>    This transport mapping supports transmission of syslog messages up to
>    65535 octets in size.  This limit stems from the maximum supported
>    UDP payload of 65535 octets specified in the RFC 768 [1].

   DISCUSS: The RFC768 length field includes the UDP header, so the
   permitted payload size is 65535 minus the UDP header (and for IPv4,
   minus the IP header, because IPv4 has a 16-bit length field that also
   includes the header length.)

Proposed Resolution: Change the paragraph to

     This transport mapping supports transmission of syslog messages up to
     65535 octets minus the UDP header length.  This limit stems from the
     maximum supported UDP size of 65535 octets specified in the RFC 768
     [1].  For IPv4, the maximum payload size is 65535 octets minus the UDP
     header and minus the IP header because IPv4 has a 16-bit length field
     that also includes the header length.

_______________________________________________
Syslog mailing list
Syslog <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Lonvick | 5 Jul 2007 16:56
Picon
Favicon

Discuss - UDP Checksum


Discuss - UDP Checksum

===
Magnus:
Discuss [2007-06-19]:
UDP transport:

Section 3.6:

    It is RECOMMENDED that syslog senders use valid UDP checksums when
    sending messages over IPv4 and IPv6.

    It is RECOMMENDED that syslog receivers check the checksums whenever
    they are present (i.e. the UDP header checksum field value is not 0)
    and discard messages with incorrect checksums.  Note that this is
    typically accomplished by the UDP layer implementation, and some UDP
    implementations allow for checksum validation to be enabled or
    disabled.

Why isn't these MUST? For IPv6 it is an MUST and for IPv4 does there exist 
a single reason not to use the UDP checksum?
===
Lars:
draft-ietf-syslog-transport-udp-09, Section 3.6., paragraph 2:
>    It is RECOMMENDED that syslog senders use valid UDP checksums when
>    sending messages over IPv4 and IPv6.

   Agree with Tim's DISCUSS - this language weakens the MUST for IPv6.
===
(Continue reading)

Permalink | Reply | 501 comments |
headers
Chris Lonvick | 5 Jul 2007 16:58
Picon
Favicon

Discuss - Congestion Control


Discuss - Congestion Control

Magnus: But what I think is needed here is some clear and normative 
requirement on how to avoid and limit congestion. First of all I would 
like to see a restriction on the applicability of this transport to within 
a controlled environment unless the rate is capped to a level that is TCP 
friendly or the full path is provisioned to handle the traffic. There 
should also be
a discussion on how one rate limits SYSLOG traffic.

Magnus: If any higher rates of packets are to be sent over best effort 
networks then a feedback mechanism is needed. That would probably need to 
include forward path UDP packetization layer with sequence number to 
enable loss detection. Complemented with feedback traffic to enable rate 
control of outgoing traffic. That could also resolve the PMTUD issue.

Lars:
draft-ietf-syslog-protocol-21, Section 8.5., paragraph 2: >    It may be 
desirable to use a transport with guaranteed delivery to
>    mitigate congestion.
   Reliable delivery and congestion control are orthogonal features. A
   reliable transport will not necessarily have congestion control, and
   vice versa.

Lars:
draft-ietf-syslog-protocol-21, Section 8.5., paragraph 3:
>    It may also be desirable to include rate-limiting features in syslog
>    originators and relays.  This can reduce potential congestion
>    problems when message bursts happen.
(Continue reading)

Permalink | Reply | 501 comments |
headers
Eliot Lear | 5 Jul 2007 19:21
Picon
Favicon

Re: Discuss - Congestion Control

Chris, Magnus,
> Response from Magnus:
> This mostly addresses my concerns. I still think there is one major 
> issue around this with congestion control. And that is
> some description on how to rate-limit your traffic. Either in UDP to 
> some pre-configured threshold and in the case of TLS
> over TCP the rate actually available. There can occur situations where 
> the amount of generated data will be larger than
> what can be transfered. How does one resolve this? I think it probably 
> needs to be more text in syslog-protocol spec about this. How to use 
> scope and prio to determine which messages to throw away or queue up 
> (within limits).
>

Most sources of potentially voluminous syslog messages have a rate limit 
mechanism already in as much as they will aggregate messages (the old 
"Last message repeated N times" thing).  I propose that we add some 
wording along the lines of the following in syslog-udp:

    syslog generator implementors must be mindful of the downstream
    resources their messages will consume, both from a network and
    server standpoint.  A single syslog source that has the capability
    to produce a flood of messages should aggregate and rate limit them
    in some appropriate fashion.  An event count combined with rate
    limiting has been used very successfully in the past.

How about that?

_______________________________________________
Syslog mailing list
(Continue reading)

Permalink | Reply | 501 comments |
headers
Juergen Schoenwaelder | 5 Jul 2007 19:25
Picon
Favicon

Re: Discuss - UDP Checksum

On Thu, Jul 05, 2007 at 07:56:39AM -0700, Chris Lonvick wrote:

> We used to recommend discard only for case B (when it is present and
> wrong) like this:
>
> "It is RECOMMENDED that syslog receivers check the checksums whenever
>    they are present (i.e. the UDP header checksum field value is not 0)
>    and discard messages with incorrect checksums. "
>
> I suggest we say something stronger in line with a MUST:
>
>    syslog senders MUST use UDP checksums when sending messages over IPv4.
>    syslog senders MUST use UDP checksums when sending messages over IPv6.
>
>    syslog receivers MUST check the checksums and MUST discard messages
>    with missing or incorrect checksums.  Note that this is typically
>    accomplished by the UDP layer implementation, and some UDP
>    implementations allow for checksum validation to be enabled or
>    disabled.

Stupid question: Why is UDP checksumming discussed at all in the
SYSLOG UDP transport mapping? People implementing syslog hardly have
control over the UDP layer (and for sure not exclusively) and so if at
all it only makes sense to me to have operational guidelines that UDP
checksums are a good idea - but then again this would not be very much
SYSLOG specific - so why discuss this at all in this document?

Do we from now on want to have every UDP transport document state that
UDP checksums are a good idea?
(Continue reading)

Permalink | Reply | 502 comments |
headers
Chris Lonvick | 5 Jul 2007 20:29
Picon
Favicon

Re: Discuss - UDP Checksum

Hi Juergen,

Good question.  ..and not something that we'll be able to answer in our 
WG.  I'll bring it up in the ietf <at> ietf list.

Thanks,
Chris

On Thu, 5 Jul 2007, Juergen Schoenwaelder wrote:

> On Thu, Jul 05, 2007 at 07:56:39AM -0700, Chris Lonvick wrote:
>
>> We used to recommend discard only for case B (when it is present and
>> wrong) like this:
>>
>> "It is RECOMMENDED that syslog receivers check the checksums whenever
>>    they are present (i.e. the UDP header checksum field value is not 0)
>>    and discard messages with incorrect checksums. "
>>
>> I suggest we say something stronger in line with a MUST:
>>
>>    syslog senders MUST use UDP checksums when sending messages over IPv4.
>>    syslog senders MUST use UDP checksums when sending messages over IPv6.
>>
>>    syslog receivers MUST check the checksums and MUST discard messages
>>    with missing or incorrect checksums.  Note that this is typically
>>    accomplished by the UDP layer implementation, and some UDP
>>    implementations allow for checksum validation to be enabled or
>>    disabled.
>
(Continue reading)

Permalink | Reply | 7 comments |
headers
Chris Lonvick | 5 Jul 2007 20:51
Picon
Favicon

Re: Discuss - UDP Checksum

Hi,

On the other hand...
ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-tsvwg-udp-guidelines-01.txt
"UDP Usage Guidelines for Application Designers" (Lars Eggert is 
co-author).

Section 3.4 is "Checksum Guidelines".  It appears that there is enough 
question about this that specific guidance should be given in RFCs.

Which brings us back to our original question.  Is the proposed language 
below what the WG wants?

A quick (and not thorough) check of RFCs which have "UDP" in their titles
shows that RFC 3948, "UDP Encapsulation of IPsec ESP Packets ", pub. Jan
2005, does have specific guidance on the UDP checksum.  To wit:
===
       The UDP header is a standard [RFC0768] header, where

    o  the Source Port and Destination Port MUST be the same as that used
       by IKE traffic,
    o  the IPv4 UDP Checksum SHOULD be transmitted as a zero value, and
    o  receivers MUST NOT depend on the UDP checksum being a zero value.
===

I'd like to hear from people who have current syslog/udp code.  What works 
for you?

Thanks,
Chris
(Continue reading)

Permalink | Reply | 6 comments |
headers
Juergen Schoenwaelder | 5 Jul 2007 21:23
Picon
Favicon

Re: Discuss - UDP Checksum

On Thu, Jul 05, 2007 at 11:51:13AM -0700, Chris Lonvick wrote:

> Which brings us back to our original question.  Is the proposed language 
> below what the WG wants?

As an implementor, I have a problem with the statement

  syslog senders MUST use UDP checksums when sending messages over IPv4

since on several platforms, I simply can't ensure this when I write a
portable SYSLOG implementation. So I can either claim my code to be
RFC compliant while in a real deployment it might not behave
conforming to the RFC (depending on the kernel settings for example),
or I tell the truth that I can never guarantee compliant behaviour of
my implementation.

So if we need to have language at all, what about

  syslog senders MUST NOT disable UDP checksums

This is something I can implement much more easily since the default
seems to be enabled on those platforms I am familiar with. ;-) 

Or alternatively go back to SHOULD

  syslog senders SHOULD use UDP checksums when sending messages over IPv4

with the likely non-obvious interpretation that you should enable /
not disable checksums in your code but if the kernel bites you, you
are still fine.
(Continue reading)

Permalink | Reply | 5 comments |

Gmane