Issue 10 - Jari Arrko DISCUSS
Discuss:
This is an excellent document and I was ready to post a Yes vote
on the ballot. However, there is one detail. The document says:
When mapping onto different
transports, DTLS has different record size limitations. The
application implementer SHOULD determine the maximum record size
allowed by DTLS protocol running over the transport in use. The
message size SHOULD NOT exceed the DTLS maximum record size
limitation of 2^14 bytes. To be consistent with RFC 5425, in
establishing a baseline for interoperability, this specification
requires that a transport receiver MUST be able to process messages
with a length up to and including 2048 octets. Transport receivers
SHOULD be able to process messages with lengths up to and including
8192 octets.
This guidance seems quite weak in terms of avoiding excessive
fragmentation. Or am I misunderstanding how DTLS records map to
UDP packets? I am assuming its a 1-1 mapping, but maybe I'm
mistaken.
In any case, the document should say something about tuning applications
and configurations to avoid excessively long packets due to
inefficiencies and other problems that fragmentation may cause.
^^^^
Sean proposes:
vvv
As this I-D is about two transports and they do somethings
differently, I suggest we point to both sets of considerations.
How about a multi-pronged approach:
#1) Specifically mention UDP/DCCP message size/length text in 5.1.
WRT DCCP and tuning, RFC 4340 (DCCP) says "A DCCP application
interface SHOULD let the application discover DCCP's current" maximum
packet size. So I'm not sure we should go stronger (i.e., make it a
MUST). In the text below, RFC 5426 is syslog over UDP:
OLD:
When mapping onto different
transports, DTLS has different record size limitations. The
application implementer SHOULD determine the maximum record size
allowed by DTLS protocol running over the transport in use. The
message size SHOULD NOT exceed the DTLS maximum record size
limitation of 214 bytes. ...
NEW
When mapping onto different transports, DTLS has different record
size limitations. For UDP, see section 3.2 of [RFC5426]. For
DCCP, the application implementer SHOULD determine the maximum
record size allowed by DTLS protocol running over DCCP, as
specified in [RFC4340]. The message size SHOULD NOT exceed the
DTLS maximum record size limitation of 214 bytes. ...
#2) Add new text in Section 5.1 that points to the syslog message
fragmentation implementation guidance:
See section A.2 of [RFC5424] for implementation guidance on message
length, including fragmentation.
^^^
Sean's proposed resolution:
Jari's points about message size/length/fragmentation in Section
5.4.1:
OLD:
DTLS can run over multiple transports. Implementations of this
specification MUST support DTLS over UDP and SHOULD support DTLS
over DCCP [RFC5238]. Transports, such as UDP or DCCP do not
provide session multiplexing and session-demultiplexing. In such
cases, the application implementer provides this functionality by
mapping a unique combination of the remote address, remote port
number, local address and local port number to a session.
NEW:
When mapping onto different transports, DTLS has different record
size limitations. For UDP, see section 3.2 of [RFC5426]. For
DCCP, the application implementer SHOULD determine the maximum
record size allowed by DTLS protocol running over DCCP, as
specified in [RFC4340]. Regardless of the transport, the message
size SHOULD NOT exceed the DTLS maximum record size limitation of
214 bytes. To be consistent with RFC 5425, in establishing a
baseline for interoperability, this specification requires that a
transport receiver MUST be able to process messages with a length
up to and including 2048 octets. Transport receivers SHOULD be able
to process messages with lengths up to and including 8192 octets.
See section A.2 of [RFC5424] for implementation guidance on message
length, including fragmentation.
ACTION: Authors to review and discuss on list before committing to a
plan.
_______________________________________________
Syslog mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/syslog
