Minutes IETF100: lwig
Light-Weight Implementation Guidance
||Minutes IETF100: lwig
¨j ¨j ¨j¨j¨X¨T¨[
¨U ¨U¨U¨U¨U¨U ¨j
Light-Weight Implementation Guidance Agenda at IETF-100
Wednesday Morning session Room: Olivia
Intro & Overview Co-chairs
New chair Mohit Sehti
TCP for Constrained devices
Presenter: Carles Gomez Montenegro [20min]
Carles: Presenting updates on the draft.
Mohit: The table, the code size is the tcp part only?
Carles: some are the whole protocol stack and some just the tcp, we need to fix
this. Mohit: the stars are missing data? Carles: we would have to update it.
Hannes: thanks for the work. One thing that could be added is whether multiple
concurrent tcp connectons could be interesting. Also who is responsible to
maintain the buffers. I was surprised that most implementations 8-16 bit
microcontrollers and not 32. Carles: Usefull, will try to add. Rahul: is socket
interface supported on top of tcp? Carles: usefull to be added. Ari: Very
usefull. Would be interesting to know RAM use and over constrained network
(LPWAN). Carles: No experience on that. Not aware of specific effor tin this
area. Ari: variety of algorithms for TCP. Exploring the impact and when is TCP
even possible to run. Michael Scharf: TCP should work well over very
constrained networks. It was designed in a time when 10kb network were common.
Ari: Thinking about edge of nbiot cell, less than 10kb. Suresh: If you put
everything on the LPWAN bucket there are lots of things that won't work in TCP.
Carsten: Range in which things work and range in which it doesn't. It'd be
interesting to know. Hannes: Did you check freertos and micrium use as tcp
stack? Zephyr, Mbed... it'd be good to find out if the table covers various IoT
OSs. Carles: Taking in feedback, thanks. Hannes: On the introduction it'd be
good to know about the perception of TCP heaviness, here it comes from and the
performance, sticking to the bare minimum. Carles: We will provide insights on
this. In reality many of the arguments on TCP are not valid or are issues found
in other reliable protocols. We will explain which aspects increase complexity.
Hannes. A bit like mythbusting. For example if you support many cyphersuits.
Rahal: Second that thought. Carsten: True, but there is a flip side. When you
say "Support TCP" it does not really mean that. It is also true of TLS. When
you cut down options the benefit of using a standard protocol its also cut down.
Carles: updating on details for changes on -02.
CoAP Security Overhead
Presenter: John Mattsson [15min]
John: Presenting updates. Draft analyzes overhead of DTLS1.2, TLS1.2 and OSCORE.
Hannes: Curious on why did you focus on sequence number.
John: TLS and DTLS compression depends on it.
Hannes: I'd have started with "here are various on algorithms and the length
would depend on it." John: ?
John: Continues presentation
Hannes: there is a new document that compresses the epoch number and other
fields. John: will add it to the next version. Carsten: Foresight when doing
this. We put the tls1.2 version number there, so now tls1.3 also will have that
number. Hannes: Can you explain why responses in oscore are always 11bytes in
size independent of sequence number? John: OSCORE does not send it inband. Also
it uses COSE which uses CBOR which includes numbers with small data value.
Compression. Hannes: trafficwise is good for analysis (as responses are always
the same size). John: well you can also see that from whom is sending the
John: Continues presentation
Carten: (back to the response comment). Impact of compression on visibility of
information. Hannes has valid point. Hannes: TLS1.3 has some features to make
traffic analysis more difficult. Hannes: Change title cause it gives the
impression that security ads overhead. Jaime, Ari, Hannes: Use Comparison.
Mohit: seems that there is interest. Authors should submit to lwig. Carsten:
overhead is also useful. numbers would make more snese if you separate the
information that cannot be compressed. Also there is a security cost. Ari:
Handshake was also not analyzed. John: no, not included. ACE is doing some
analysis but not public at the moment. Hannes: not very useful Ari: maybe give
a pointer when it is available. John: there is no easy to find numbers on how
large tls packets are in the handshake. Hannes: you added some work that was
not picked up and continued so it might be counter productive. Handshake is
more complex to analyzed. Carsten pointed out that most of the overhead is
caused by the sec algorythm itself. With the handshake you are comparing apples
and oranges, they have different purpose. Mohit: be concise please. Ari: should
we have a document with handshakes? John: not in this doc, in ACE will be done.
Neighbor Management Recommendations
Presenter: Rahul Jadhav [15min]
Rahul: Presenting updates on draft, decribing problems associated with neighbor
cache management in constrained multihop networks and solutions.