6lo WG Agenda - IETF 96, Berlin, Germany 10:00-12:30 Local Time MONDAY, July 18, 2016 Potsdam III Chairs: Samita Chakrabarti, Gabriel Montenegro Secretary: James Woodyatt Responsible AD: Suresh Krishnan Technical Advisor: Ralph Droms Minute takers: Zach Shelby, Dominique Barthel Jabber scribe: James woodyatt Chairs: Note Well Chairs: Update on WG draft status since IETF95 • Two drafts in IESG processing Suresh: dect-ule awaiting AD review • Three drafts past LC • Three other WG drafts Chairs: Liaison from IEC/JTC-1, IAB has recommended pursuing an informal relationship draft-gomez-6lo-bluemesh-01 (Carles Gomez) • Objective is not to request new work from BT SIG. • Restriction with the use of multicast in BTLE: actually n-way unicast. Problem mitigated by remembering subscribers to "multicast". • Additional security considerations added, including routing protocol attacks using RFC7416 as a guide • Tentatively asking for WG adoption • Samita: who has read the draft? 3-4 hands. Is BT SIG aware of this work? yes. Do people in the room think this is intereting, please humm? significant humm. • Don Sturek: How do you deal with prefix delegation, which requires multicast in RFC6775? o Carles: We don't cover this feature in the draft yet • Ari Kerδnen: relation beteen this and work at BT SIG? o Carles: not a member of BT SIG. This extends RFC7668--They might be using other mechanisms, our position is that we can enable mesh by adding very little to the current RFC; won't harm anything the're doing. o Ari: recommend to clarify this with BT-SIG. o Dave Thaler: this WG should work on IP-over-foo o Suresh: Talked to BT SIG, said they don't work on IP. Can send mail to BT SIG again to check. o Gabriel: Do you think we can do WG adoption in parallel to talking to BT SIG? o Suresh: Yes and be ready to drop it. o Dave: Doesn't see a reason to delay WG adoption while figuring out the BT SIG angle • Samita: More people to read the draft before we ask for adoption. draft-ietf-6lo-6lobac (Kerry Lynn) • Kerry provides background on this work.It is an wired alternative of IEEE802.15.4 • two implementations, Plugtest in Yokohama, Wireshark dissector, 3 thorough draft reviews. • Samita: will submit to IESG draft-ietf-6lo-privacy-considerations (Dave Thaler) • Goal: Guide for IP-over-foo specification writers o Whenever possible IP-over-foo should not limit what protocols run on top o • Should be designed to not assume a firewall is in place (sure a fw can be used to mitigate some privacy issues) • describes changes made following draft review, as well as proposed changes not retained and why. • Dave asks for contributions for better phrasing of a particular sentence, explains motivating considerations. o Gabriel: could the text provide the motivating considerations as well? o Kerry: don't think this is an issue. If short addresses are assigned by controller in a non-stable network, they won't be carried across networks by the node. And if network stable, tracking is not an issue eather. Kerry's review has been taken care of o Address scanning not relevant to link local addresses, only to routable addressses o Distinguish between on-link and off-link o Reduce emphasis on "46 bits" which was the example for links > 8 years •But location tracking might be an issue-- need enough bits to mitigate this LL addresses changing over time • On-link: have to change link-layer address too • Off-link: useful if LL addrs can leak in higher layer protocols • known to happen from observation, by accident, a lot, with, e.g., smtp, sip, dns, etc • Important to NOT assume they won't leak, but it may be less common Kerry: Agree this might be a whole, but just like buffer overflow problems, it is a matter of education • Dave: about the use of DHCPv6 for temporary addresses. o Ralph Droms: RFC3315bis is in progress, this potential application would be interesting for the authors o Dave: This is to advise draft authors as to what issues to consider, not provide technical solutions o Suresh: xxx draft. Dave: checked this one, does not pertain to this. o Juan-Carlos Zuniga: consider work at 6man and IEEE802 about changing MAC-addresses for privacy o Tim Winters: RFC3315bis currently says it is not recommended to renew temporary addresses o o Samita: regarding IEEE recent changes, is there a document? Dave: referred to it in -00 version Chairs: Document will go to WGLC after the meeting. draft-ietf-6lo-dispatch-iana-registry (Samita) • Changes since IETF95 include new Shepherd (Brian Haberman) and the draft addressed shepherd's comments o New title to reflect the content Not just define codepoints but also provide guidelines about the allocation of dispatch bytes. o Clarifies that the document updated RFC4944 and RFC6282 o Updated draft ready this week, then going for IESG submission • comments? none draft-ietf-6lo-paging-dispatch (Pascal) status of doc • James Woodyatt: currently writing the shepherd writeup; not yet completed • Suresh: just get it done, doesn't need to be perfect. questions? none draft-ietf-6lo-backbone-router (Pascal) 3 parts in doc including update of 6775 Two implementations tested this week at ETSI plugtest. Interop tested in Berlin (ETSI) on Fri-Sat •One open source (openWRT) •One Vendor (Cisco) •Tested with openWSN as client This draft is thick. Extract 6775 update and make it a separate draft? Gabriel: question to Juan-Carlos? what is the status wrt to IEEE? Pascal: regarding the broadcast JCZ: will provide recommendations, and document in interim. This is not blocking. Good idea to put out this document for other communities (such as IEEE) aware of this work Questions? Samita: another presentation later on proposed split. Pascal: this doc is really 3 in 1. Suggestion to the group to split in 3 documents • Update to 6775, registration • Informational on BBR • Prescriptive stuff Samita: Make your suggestion on the mailing list for discussion. draft-ietf-6lo-nfc (Younghwan Choi) Point to point comm at link layer. Discusses updates following review. • Participated in two ETSI plugtest with two implementations Requested review by NFC forum, but not a member and no official IETF-NFCforum liaison, so still waiting for comments. If anything received, will consider for updating this draft. Asking for WG LC anyway. Gabriel: Better explain results of tests at ETSI plugtest? Yong-Geun Hong: test setup issues more than protocol implementation issues. 10 out 12 test cases passed. Samita: Before WG LC, we need 1 or 2 reviewers for this draft. Raise your hand? Dave Thaler volunteers. Gabriel: would like to have NFC Forum feedback. draft-hong-6lo-use-cases (Yong-Geun Hong) • Changed the title, added a use case and editorial changes in this version • This document describes 7 link layer technologies, 5 use cases. • Remaining issues include o Adding new use cases for MS/TP, 6tisch, LPWAN etc. • Comments? Ready for WG adoption? • Samita: Any objections to adopting this document? o Quite a few people had read the document o Will take adoption call to the mailing list draft-rashid-6lo-iid-assignment (Rashid Sangi) This draft discusses how to designate 6LBR to assign IIDs for failed DAD. Currently, DAD cycle is repeated until the conceived IID isn't declared unique. To remove the overhead of repeated DAD cycle, this document enables 6LBR to suggest an IID (to 6LN) for failed DAD. It improves the overall network performance by avoiding repeated DAD cycle. To attain higher degree of privacy, IID can be periodical changed and designating 6LBR ensures the uniqueness of IID in a proactive manner. • Draft proposes the use of 6LBRs to assign unique IIDs, e.g. in case a locally-generated address turns out ot be a duplicate • Questions/comments? • Kerry Lynn: How does this compare to e.g. DHCP? o Rashid: There are some reasons RFC7217 can't be used with DHCP o Lorenzo Colitti: I don't understand how this is supposed to work. So, if the EUI-64 fails due to DAD, then someone else produces an RFC7217 o Rashid: Yes o Lorenzo: Why is RFC7217 better at avoiding collisions? Who has the secret key? o Rashid: The 6LBR o Lorenzo: Doesn't that mean the same secret key would be used for all nodes, thus the same IID? o Rashid: But the DAD counter would be increased o Lorenzo: Why not just have the nodes create a random IID? o Samita: Work with Lorenzo to improve the draft. There is a problem space. Invite comments form 6775 co-authors. o Gabriel: depending on collision probability, this maybe more or less important to have. Adds complexity. Document if problem is real • draft-mglt-6lo-diet-esp-requirements and draft-mglt-6lo-diet-esp (Daniel Migault) • DTLS does not address all problems. IPsec/ESP could fill some IoT needs. • DTLS allows observer to see IP addresses, ports, traffic pattern. • With IPsec, secure domains and secure communication between domains. • Owner can change destination within domain, balance/scale traffic. • ESP works for any key exchange protocol. • Diet-ESP is ESP and ROHC. • one implementation on Contiki. Hopefully another one soon on RIOT. • IPSECME former chairs recommended to bring this work to 6lo. • asking for interest in 6lo for this work? • Samita: who has read? 5-6 hands. Think interest for this group? 3. • Gabriel: doubts about interest, and even more about relevance to this group. There might be security issues that we nay not be able to detect or discuss here. • Daniel: would anyway be discussed in security area anyway. • Suresh: will figure out how the work gets done. Need to determine motivation for the work first. • Kerry Lynn: ? • Juan-Carlos Z: interesting problem. Related to compression and fitting in the constrained world. Would like to host this work here and have it reviewed by security experts. • Brian Weis: Interested in the low-overhead, think it should go forward regardless in which WG • Samita: Thinks problem space is interesting. Imagine thousands of iot gateways connecting to second level gateway. No network security solution with compression at this time. ETSI/IETF 6lo Plugtest Report (Yeong-Geun Hong) The tests were performed by ETSI and held in conjunction with 6tisch plugfest. Unfortunately Miguel Ortega Reina, the ETSI test co-ordinator had to leave before the 6lo session, so Young-Geun has been requested to present on behalf of Miguel. Plugtests were held at IETF between 15-17 July. There were 10-12 participants in the 6tisch/6lo joint plugfest, but only a few vendors tested 6lo only. 6lo tests per: http://rawgit.com/6lo/test-descriptions/master/6lo.html 6lo NFC: More 80% of interoporability as tested between two implementations. Test setup issues. Need more reliable packet sniffing mechanism. draft-thubert-6lo-rfc6775-update-00 (Pascal) Extended ARO option moved in rfc6775_update Add TID field to support registration mobility Same as efficient ND Proxy registration enabled by rfc6775_update 6LBR may register on behalf of 6LN in mesh environment Registering the target as opposed to source address New in 6lo ND: work on uniqueness using link model so Link Local is point to point • can be validated (DAD) by 6LR directly • No need to go to 6LBR Global addresses are unique • Validated by 6LBR (DAR / DAC) • 6LBR (s) maintain subnet wide DAD • Multiple 6LBR coordination by backbone router • Zach: why this work? Pascal: solving chicken-egg problem with 6LR. Need a readily-usable address to talk to the 6LR, on-link. Then go to 6LBR for globally-unique address. • Zach: had this discussion before. Link changes all the time. Pascal: each node pair is a link, this proposes to be able to use a different link-local address to talk to each neighbor. • Don Sturek: like 6BBR draft. Hope this ... Pascal: this link-local doesn't need DAD. we regularly see DAD being disallowed. I like BBR stuff, and hope it does not bring DAD into the solution as we don't want it • Eric Nordmark: does DAD mean 4861? This checks for uniqueness but does not imply multicast. Don: ok, addresses my question. • Carsten: . Pascal: at a given point in time, 6LN only talks to one 6LR. A second 6LR may deny the first link-local address, node will use another one. • Carsten: in 6LoWPAN, 16-bit address obtained from LBR. Pascal: from PAN coordinator. • Pascal: a 6LN may be using different link-local addresses to talk to different 6LR. May be unlikely to occur if link-local is built in a way that is likely to be globally unique, but doesn't have to. • Carsten: this looks complex .. • Emmanuel Baccelli: ... draft in WG LC in INT area, this one would need to refer to it. Pascal: discuss it on the mailing list. • Samita: more discussion needed. Make sure backward compatibility, and no major issue. Low-Power Wide Area Networks (LPWAN) BOF Alex Pelov BOF meeting this afternoon. New radio technologies (Sigfox, LoRa, NB-IoT, ...) Non-WG-forming BOF at Buenos-Aires. Unique constraints introduced by these technologies. Lots of interest and discussions. Today reps of Sigfox, LoRa, NB-IoT, IEEE will introduce their L2 technology and present the challenges that need to be solved. Come and provide your inputs. 12:21 end of meeting. Gabriel: your notes welcome to contribute to the minutes. No comments offered on Jabber.