|
»
« Return to Thread: Issue 14 - Unreliable Delivery
Re: Issue 14 - Unreliable Delivery
by David Harrington
::
Rate this Message:
Hi,
I think that text looks good, except I think you lost the last word. I
assume the last sentence was meant to end with "loss".
You also might want to mention syslog-sign by name, not just RFC#
dbh
> -----Original Message-----
> From: syslog-bounces@...
> [mailto:syslog-bounces@...] On Behalf Of Joseph Salowey
> (jsalowey)
> Sent: Monday, June 21, 2010 12:48 AM
> To: Chris Lonvick (clonvick); syslog@...
> Subject: Re: [Syslog] Issue 14 - Unreliable Delivery
>
>
>
> > -----Original Message-----
> > From: syslog-bounces@... [mailto:syslog-bounces@...] On
> Behalf
> > Of Chris Lonvick (clonvick)
> > Sent: Friday, June 18, 2010 8:42 PM
> > To: syslog@...
> > Subject: [Syslog] Issue 14 - Unreliable Delivery
> >
> > SECDIR Reviewer comments:
> >
> > One difference between the security considerations for syslog over
> > DTLS and those for syslog over TLS (unnoted in the current
Security
> > Considerations section) is that DTLS does not provide
> retransmission.
> > If an attacker can cause a packet to be dropped (especially one
> > carrying significant information about an attack), the transport
> > receiver may not consider this a significant event and so
> the syslog
> > server may be completely unaware of the occurrence. This contrasts
> > with syslog over TLS where a dropped packet would be retransmitted
> > until acknowledged or until the TLS connection goes down
> (indicating
> > to the transport sender and receiver and perhaps to the
> syslog client
> > and server that a significant event has occurred). Maybe it
> would be a
> > good idea to recommend that the transport receiver notice
> gaps in the
> > DTLS sequence numbers and notify the syslog server. Still,
> this is not
> > as good from a security standpoint as syslog over TLS since noneof
> > the client code will be aware that the dropped message was not
> > received. At least, there should be a discussion of this
> issue in the
> > Security Considerations section of this document.
> >
> > My comments back to the reviewer and the IESG:
> > ===vvv===
> > It's discussed in section 5.4 (Unreliable Delivery - in the
> Security
> > Considerations section) in RFC 5426 and throughout Section 3.1
> > (Loss-Insensitive Messaging) in RFC 4347. I'm thinking
> that it would
> be
> > good to note this in Section 4 (Using DTLS to Secure Syslog) inthe
> draft.
> >
> > Overall, the community is comfortable with the loss of
> information
> as
> > they've been using syslog/udp for many years and know the problems
> with
> > that. RFC 5424 also notes that implementers who wish a lossless
> stream
> > should be using tls/tcp as their transport. From that,
> it's probably
> best
> > to reference RFC 5848 (referenced as draft-ietf-syslog-sign in the
> draft)
> > which can also provide an indication of loss of messages. "
> > ===^^^^===
> >
> > ACTION: I'd like to get some discussion going on this. Do people
> think
> > that this is good?
> >
> [Joe] I think it would be good to add a security consideration. How
> about:
>
> "9.x Message Loss
>
> The transports described in this document are unreliable. It
> is possible for messages to be lost or removed by an attacker
> without the knowledge of the receiver. [RFC 5424] notes that
> implementers who wish a lossless stream should be using
> tls/tcp as their transport. In addition, the use of [RFC
> 5848] can also provide an indication of message. "
>
>
> > Thanks,
> > Chris
> > _______________________________________________
> > Syslog mailing list
> > Syslog@...
> > https://www.ietf.org/mailman/listinfo/syslog
> _______________________________________________
> Syslog mailing list
> Syslog@...
> https://www.ietf.org/mailman/listinfo/syslog
_______________________________________________
Syslog mailing list
Syslog@...
https://www.ietf.org/mailman/listinfo/syslog
I think that text looks good, except I think you lost the last word. I
assume the last sentence was meant to end with "loss".
You also might want to mention syslog-sign by name, not just RFC#
dbh
> -----Original Message-----
> From: syslog-bounces@...
> [mailto:syslog-bounces@...] On Behalf Of Joseph Salowey
> (jsalowey)
> Sent: Monday, June 21, 2010 12:48 AM
> To: Chris Lonvick (clonvick); syslog@...
> Subject: Re: [Syslog] Issue 14 - Unreliable Delivery
>
>
>
> > -----Original Message-----
> > From: syslog-bounces@... [mailto:syslog-bounces@...] On
> Behalf
> > Of Chris Lonvick (clonvick)
> > Sent: Friday, June 18, 2010 8:42 PM
> > To: syslog@...
> > Subject: [Syslog] Issue 14 - Unreliable Delivery
> >
> > SECDIR Reviewer comments:
> >
> > One difference between the security considerations for syslog over
> > DTLS and those for syslog over TLS (unnoted in the current
Security
> > Considerations section) is that DTLS does not provide
> retransmission.
> > If an attacker can cause a packet to be dropped (especially one
> > carrying significant information about an attack), the transport
> > receiver may not consider this a significant event and so
> the syslog
> > server may be completely unaware of the occurrence. This contrasts
> > with syslog over TLS where a dropped packet would be retransmitted
> > until acknowledged or until the TLS connection goes down
> (indicating
> > to the transport sender and receiver and perhaps to the
> syslog client
> > and server that a significant event has occurred). Maybe it
> would be a
> > good idea to recommend that the transport receiver notice
> gaps in the
> > DTLS sequence numbers and notify the syslog server. Still,
> this is not
> > as good from a security standpoint as syslog over TLS since none
> > the client code will be aware that the dropped message was not
> > received. At least, there should be a discussion of this
> issue in the
> > Security Considerations section of this document.
> >
> > My comments back to the reviewer and the IESG:
> > ===vvv===
> > It's discussed in section 5.4 (Unreliable Delivery - in the
> Security
> > Considerations section) in RFC 5426 and throughout Section 3.1
> > (Loss-Insensitive Messaging) in RFC 4347. I'm thinking
> that it would
> be
> > good to note this in Section 4 (Using DTLS to Secure Syslog) in
> draft.
> >
> > Overall, the community is comfortable with the loss of
> information
> as
> > they've been using syslog/udp for many years and know the problems
> with
> > that. RFC 5424 also notes that implementers who wish a lossless
> stream
> > should be using tls/tcp as their transport. From that,
> it's probably
> best
> > to reference RFC 5848 (referenced as draft-ietf-syslog-sign in the
> draft)
> > which can also provide an indication of loss of messages. "
> > ===^^^^===
> >
> > ACTION: I'd like to get some discussion going on this. Do people
> think
> > that this is good?
> >
> [Joe] I think it would be good to add a security consideration. How
> about:
>
> "9.x Message Loss
>
> The transports described in this document are unreliable. It
> is possible for messages to be lost or removed by an attacker
> without the knowledge of the receiver. [RFC 5424] notes that
> implementers who wish a lossless stream should be using
> tls/tcp as their transport. In addition, the use of [RFC
> 5848] can also provide an indication of message. "
>
>
> > Thanks,
> > Chris
> > _______________________________________________
> > Syslog mailing list
> > Syslog@...
> > https://www.ietf.org/mailman/listinfo/syslog
> _______________________________________________
> Syslog mailing list
> Syslog@...
> https://www.ietf.org/mailman/listinfo/syslog
_______________________________________________
Syslog mailing list
Syslog@...
https://www.ietf.org/mailman/listinfo/syslog
« Return to Thread: Issue 14 - Unreliable Delivery
| Free embeddable forum powered by Nabble | Forum Help |
