RE: [Syslog] delineated datagrams

["David Harrington" <[e-mail]>]

Hi,

As you probably know by now, I like to see design reuse across IETF NM
solutions, especially across SNMP, syslog, ipfix, and netconf where
feasible.

As all the IETF NM protocols move toward similar secure transport
solutions, including moving from datagrams to streams, it would be a
good thing to use consistent aproaches to framing.

Here is what is happening in the other IETF NM protocols:

SNMPv1/v2c/v3 uses octet-counting within its BER encoded messages.
For SNMP over TCP (RFC3430):
   It is possible that the underlying TCP implementation delivers byte
   sequences that do not align with SNMP message boundaries.  A
   receiving SNMP engine MUST therefore use the length field in the
   BER-encoded SNMP message to separate multiple requests sent over a
   single TCP connection (framing).  An SNMP engine which looses
framing
   (for example due to ASN.1 parse errors) SHOULD close the TCP
   connection. 

SNMP over SSH (ISMS) does not specify how to delineate datagrams,
beyond the BER octet-counting.
(As editor of the SNMP/SSH draft, I will probably copy the text from
RFC3430.)

IPFIX uses octet-counting. See
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-22.txt
section 3.1.

The NETCONF protocol uses an RPC-based communication model.  
From
http://www.ietf.org/internet-drafts/draft-ietf-netconf-prot-12.txt:
   NETCONF peers use <rpc> and <rpc-reply> elements to provide
transport
   protocol-independent framing of NETCONF requests and responses.
There is ongoing discussion about the framing in the netconf
notification protocol, and the possibility of interleaving
notifications and request/responses within a session or channel. 

David Harrington
[e-mail] 
[e-mail]
[e-mail] 

> -----Original Message-----
> From: Chris Lonvick [mailto:[e-mail]] 
> Sent: Friday, August 04, 2006 10:14 AM
> To: Miao Fuyou
> Cc: [e-mail]; 'Tom Petch'
> Subject: RE: [Syslog] delineated datagrams
> 
> Hi,
> 
> I'd like to get this resolved and put into the next version 
> of the draft.
> 
> Many protocols use byte-counting for framing.
> Many protocols use a specific character as a delimiter.
> Do we need both?
> 
> I think that I've seen notes from Rainer, Tom Petch, and Andrew Ross

> saying that we should only use a special character for both 
> simplicity of 
> design and for interoperability with current syslog/tls 
> implementations.
> 
> Are there other opinions on this?   Please speak up now.
> 
> Thanks,
> Chris
> 
> 
> On Mon, 24 Jul 2006, Miao Fuyou wrote:
> 
> >
> > Hi, Rainer,
> >
> > Interop is a compelling reason for protocol design, so I 
> tend to agree with
> > you that it is a feature nice to have. I am wondering 
> whether we should
> > define procedures for frame delineating processing in 
> syslog-tls draft
> > because we have both octect-counter and LF in a record.
> >
> > Miao
> >
> >> -----Original Message-----
> >> From: Rainer Gerhards [mailto:[e-mail]]
> >> Sent: Friday, July 21, 2006 6:16 PM
> >> To: Miao Fuyou; Tom Petch; [e-mail]
> >> Subject: RE: [Syslog] delineated
> >> datagramswasdraft-ietf-syslog-transport-tls-01.txt
> >>
> >> Miao,
> >>
> >> I agree with your comments. However, using the LF as a record
> >> delimited would still allow us to interop with existing
> >> syslog/tls implementations. This is my major point. I think
> >> it is worth it.
> >>
> >> Rainer
> >>
> >>> -----Original Message-----
> >>> From: Miao Fuyou [mailto:[e-mail]]
> >>> Sent: Friday, July 21, 2006 12:00 PM
> >>> To: 'Tom Petch'; [e-mail]
> >>> Subject: RE: [Syslog] delineated
> >>> datagramswasdraft-ietf-syslog-transport-tls-01.txt
> >>>
> >>>
> >>> TLS uses SHA-1 or MD5 in ciphersuite for message integrity
> >>> verification. If bytes lost happens during transferring,
> >> the message
> >>> will be dropped by TLS.
> >>> That is also the cause that we need a security mechanism
> >> for Syslog.
> >>>
> >>> As for error of encoding/decoding, I believe if an 
> application does
> >>> encoding/decoding in a wrong way, you must not expect it do
> >> it right
> >>> with other mechanism, such as LF.
> >>>
> >>> Redundancy to improve robustness is  good idea, but I don't
> >> think it
> >>> applies to this case.
> >>>
> >>>> -----Original Message-----
> >>>> From: Tom Petch [mailto:[e-mail]]
> >>>> Sent: Tuesday, June 20, 2006 8:43 PM
> >>>> To: [e-mail]
> >>>> Subject: Re: [Syslog] delineated datagrams
> >>>> wasdraft-ietf-syslog-transport-tls-01.txt
> >>>>
> >>>> I wonder if others share my concern about the lack of
> >> robustness in
> >>>> the way in which datagrams are delineated in the stream
> >> protocol (a
> >>>> TCP rather than a TLS issue).
> >>>>
> >>>> The system works as long as
> >>>>  - the frame length is encoded perfectly
> >>>>  - the frame length is decoded perfectly
> >>>>  - no bytes are inserted or removed in error which is
> >> doubtless true
> >>>> in some networks, but I would prefer not to
> >>> rely on it.
> >>>>
> >>>> So, when an error occurs, can the Collector/Relay detect it?
> >>>> Can the Collector/Relay recover synch?  If not, what does the
> >>>> Collector/Relay do?
> >>>>
> >>>> There is very little redundancy in the definition of
> >> frame length,
> >>>> and syslog messages have very little structure to help the
> >>>> application, so I think that this is an issue we should
address.
> >>>>
> >>>> Tom Petch
> >>>>
> >>>> ----- Original Message -----
> >>>> From: "David B Harrington" <[e-mail]>
> >>>> To: <[e-mail]>
> >>>> Sent: Tuesday, May 09, 2006 4:26 PM
> >>>> Subject: [Syslog] draft-ietf-syslog-transport-tls-01.txt
> >>>>
> >>>>
> >>>> Hi,
> >>>>
> >>>> A new revision of the syslog/TLS draft is available.
> >>>>
> >>>
> >> 
>
http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-01
> >>>> .txt
> >>>>
> >>>> We need reviewers.
> >>>> Can we get
> >>>> 1) a person to check the grammar?
> >>>> 2) a person to check the syslog technical parts?
> >>>> 3) a person to check compatibility with the other WG documents?
> >>>> 4) a person to check the TLS technical parts?
> >>>>
> >>>> We also need general reviews of the document by multiple
people.
> >>>>
> >>>> Thanks,
> >>>> David Harrington
> >>>> co-chair, Syslog WG
> >>>> [e-mail]
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Syslog mailing list
> >>>> [e-mail]
> >>>> https://www1.ietf.org/mailman/listinfo/syslog
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Syslog mailing list
> >>>> [e-mail]
> >>>> https://www1.ietf.org/mailman/listinfo/syslog
> >>>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Syslog mailing list
> >>> [e-mail]
> >>> https://www1.ietf.org/mailman/listinfo/syslog
> >>>
> >>
> >
> >
> >
> > _______________________________________________
> > Syslog mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/syslog
> >
> 
> _______________________________________________
> Syslog mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/syslog
> 


_______________________________________________
Syslog mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/syslog