¨j ¨j ¨j¨j¨X¨T¨[ ¨U ¨U¨U¨U¨U¨U ¨j ¨m¨T¨a¨^¨m¨a¨m¨^¨T¨a Light-Weight Implementation Guidance Agenda at IETF-100 Jabber: xmpp:lwig@jabber.ietf.org Etherpad: http://etherpad.tools.ietf.org:9000/p/notes-ietf-100-lwig Chairs: Mohit Sehti Zhen Cao 11:00-12:00 Wednesday Morning session Room: Olivia ----------------------------------------- Minute Takers: Jaime Jimenez Intro & Overview Co-chairs New chair Mohit Sehti TCP for Constrained devices Presenter: Carles Gomez Montenegro [20min] https://tools.ietf.org/html/draft-gomez-lwig-tcp-constrained-node-networks https://datatracker.ietf.org/meeting/100/materials/slides-100-lwig-1-tcp-for-constrained/ 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] https://www.ietf.org/internet-drafts/draft-mattsson-core-security-overhead-02.txt https://datatracker.ietf.org/meeting/100/materials/slides-100-lwig-2-coap-security-overhead/ 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 packets. 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] https://tools.ietf.org/html/draft-jadhav-lwig-nbr-mgmt-policy-01 https://datatracker.ietf.org/meeting/100/materials/slides-100-lwig-3-lwig-neighbor-management-recommendation/ Rahul: Presenting updates on draft, decribing problems associated with neighbor cache management in constrained multihop networks and solutions. No questions.