Minutes for 6LO at IETF-92
minutes-92-6lo-1

6lo WG meeting - IETF 92, Dallas, USA
1520-1720 CDT 2015-03-24
Room: International
---------------------------------------
Thanks to Dominique Barthel for the minutes

[15.24] Introduction and  draft status                                         
Chakrabarti/Montenegro
  * Samita introduces Gabriel (co-chair) and James (secretary)
  * Agenda bashing; blue sheets; scribe; Jabber scribe (James)
  * RPL compression shifted in the agenda (Michael)
  * draft status: GHC and Zwave went to RFC:
draft-ietf-6lo-ghc-03 ==>  http://tools.ietf.org/html/rfc7400
draft-ietf-6lo-lowpanz-05 ==> http://tools.ietf.org/html/rfc7428

  * reminder of discussion session on security on Thursday evening, 7pm-8pm
  * reminder to submit your requirements for RFC6775 updates

[15.28] Transmission of IPv6 Packets over Near Field Communication             
Yong-Geun Hong
  <draft-ietf-6lo-nfc-00>
  Update on WG comments since IETF91
  * first time as a WG document (adopted at IETF91)
  * Updates since IETF91:
      - SLAC. 6-bit IID pre-pended with 0's.
      - multicast address mapping: 16-bit compressed address is 0x3F prepended
      with 0's
  * goes over use cases (personal connected devices)
  * implementation status. Should be done by end of year.
  * next steps : Header Compression, Fragmentation/Reassembly. Re-organize doc
  wrt IPv6 addressing, will implement HC and FAR.

[15.37] Transmission of IPv6 over MS/TP Networks                               
Kerry Lynn
  <draft-ietf-6lo-lobac-01>
  Update and Request for WGLC
  * proposal is 5 years old.
  * BACnet international standard, used in buildings, contention-less L2
  * larger frames introduced in BACnet, finalized last July. Larger CRC,
  * RFC6282 header compression. 7 bit addresses at L2, used for SLAC. Could use
  privacy addresses
    if needed.
  * Think this doc ready for WGLC.
  * Carsten: do you still have uncompressed mode? Kerry: yes, cost of keeping
  it is zero. * Carsten: learned in 6LoPWAN that options still cost (testing,
  code size). From interop testing, seen * Alex Petrescu: recommends no header
  compression at all. * Samita: does the audience have recommendation? * NOTE: 
  right before the meeting, this draft received the BACnet MS/TP Frame Type
  Number issued by ASHRAE, something the authors had been waiting for

[15.48] Enabling Security/Privacy addressing on 6LoWPAN technologies           
Dave Thaler
  <draft-thaler-6lo-privacy-addrs-00>
  Draft Presentation
  * see RFC6973 for problem introduction. See RFC4941 and RFC7217 for two
  solutions * in this draft, describe three approaches with increasing
  difficulty/benefit
    - use IEEE identifier based address. Problem is correlation over time.
    Could mitigate by using
      multiple addresses over time.
    - use short address. Not enough entropy to mitigate threats. Can do a few
    tweaks. Solve the threats by security - use non-IEEE-id-based address.
    Relies on using substitutable behavior in RFC6282. Context "prefix" is the
    full 128 bits. it's a big change but solves the issues.
  * Subir Das: first proposal, one has two addresses overlapping in time.
  Change while an L2 connection is going on? Problem may not exist. Dave: if
  connections are short, correct, problem may not exist. * René Struik:  if
  more than 40 bits in L2, can mitigate everything but security.
     Dave: this typically requires 59 or more bits
  * Robert Craigie: will probably do MAC address randomization anyway. Solution
  3 looks really complex. * Kerry: in third case, do you assume that you can
  pass a full address to fill the cache? Dave: does not make assumption, could
  compress external addresses * Pascal: ... CID could go hop by hop or direct
  to LBR, covers both cases you described. * Robert: ... will end up doing
  solution 1 anyway, solution 2 probably as well. * Gabriel: seems like 3 is
  not desired.

[16.10] RFC6775 Update requirements for 6lowpan-ND                             
Pascal Thubert
  <draft-thubert-6lo-rfc6775-update-reqs>
  WG discussion on RFC 6775 update requirement completeness
  * stable document. Comments?
  * Carsten: most of the requirements in here aren't.
  * Gabriel: not to publish as an RFC, instead, this could go on a wiki page
  for you to comment * Gabriel: objective is to come up with a list of
  requirements for changes in 6775. * Pascal: removed most of text, most
  requirements come from 6TiSCH, referenced properly. * Samita: have decided
  this is not going to IESG. Still keep it to track the requirements from other
  groups.
    Help needed to keep track of these requirements. Raise hands if you can
    contribute. [Carsten, Robert, ...]

    Goal is by next IETF meeting, analyse the requirements....

[16.16] Lightweight and Secure ND for Low-power and Networks             
Thubert/Sarikaya
  <draft-sarikaya-6lo-cga-nd-02>
  Follow-up WG Discussion on the update
  * major change following discussion at last IETF meeting.
  * only need to make sure that only the node that first registered the address
  can own it. * assumes "Efficient ID" goes through, need IDS from that. * CGA
  Uid stored in 6LR and 6LBR * Samita: do you need CGA sent in discovery?
  Pascal: if rogue can enter the network, SeND is needed to avoiding
    stealing the address.
  * Michael R: in industrial envt, probably no node can enter the premise that
  is not authorized. On home networks whatever you bought that day enters. The
  most sensitive system to this problem will implement solution first. * Pascal
  (resumes) 3 questions to the group. * Alex P: CGA uses public key? yes. Too
  heavy for this kind of device?
 * Gabriel: discussion on the mailing list.

[16.27] RPL compression mechanism Discussion from Roll Interim                 
Michael Richardson
  <draft-thubert-6lo-rpl-nhc-02>
  <draft-thubert-6lo-routing-dispatch-03>
  WG discussion on choosing a solution between the above two solutions and
  their implications * ROLL interim meeting to discuss compression. IP-in-IP
  encapsulation needed in many cases. * come up with a better NHC, that would
  compress RFC6553 (the hop by hop option). Also for 6554 (Routing Header 3,
  for source routing in the non-storing LLNs). * shows various incremental
  solutions for compression. * a proposal is to apply a global approach. Move
  RH3 in the front, allows to route fragments. Use dispatch byte. * question to
  other groups who do mesh-under if ok to re-using their values. Assumes
  packets will not co-exist on same network. * Ralph: moving RH3 ahead is doing
  mesh-under, replicating RH in fragments. * Ralph: think seriously about the
  re-use of header mappings. * Pat Kenney: mesh-under and route-over are not
  quite exclusive. Secondly, 802.10 does routing, would love to be added to
  liaisons. * Pascal: remember that every byte counts. ISA100 experience.
  Compression on outer IP is much better with the DISPATCH approach than with
  IPHC. * Robert Craigie: mesh header can be used to carry L3 addresses, not
  just used for mesh-under. * Michael: anybody feels NHC solution can be made
  better? if yes, say so. If not, we'll carry on with the dispatch solution. *
  Carsten: dispatch solution looks better, more flexible. Can we fix the
  re-allocation problem? * Michael: are you saying we should reclaim the unused
  space in the dispatch header? Carsten: yes. * Samita: how much of 6282 would
  be modified? Pascal: 6282 parser not replaced, new code for routing only. *
  Robert: mesh header can probably be easily replaced by something on the new
  model. But it's been in an RFC for years, we don't know who's using it. *
  Gabriel: not just on the principle. Operational issue. When proposal is
  fleshed out, liaisons can get feeedback from other communities. * Pascal: at
  IETF91, 3 solutions discussed. Greedy, NHC++ needed escape as well. With this
  solution, we compress much better. Recommend to focus on solution 3
  (DISPATCH) even if ESC has to be used. Perhaps drop NHC++ * Michael: audience
  does not look upset by this statement. * Carsten shows a slide of his own:
  ROLL storing mode. Reportedly not implemented in any non-academic
  implementation. BIER, bloom filters. Good argument to keep some flexibility
  in the dispatch space, could help there too.

[16.59] ETSI  Plugfest for 6lo implementations                                 
Miguel Angel Reina Ortega
  * remote presentation. About 6lo plugfest, and incidentally an intro to CTI.
  * among other things, CTI organized pugtest events, under EU funding.
  * describes plugtest conditions. Confidentiality, anonymity of results.
  * Samita: can you say what you need from WG?
  * planning for IETF94 Oct30th-Nov1st. Basic 6lo functionality.
  * will need technical support from members. Form a group of experts for test
  specification development. * Michael R: Prague? Miguel: there is a 6Tisch
  plugtest already planned for Prague. Maybe also 2nd 6TiSCH at IETF94 * Thomas
  W: scope of the 6lo event? Samita: not yet, will be defined by the group of
  few experts. * Gabriel: who would be interested in joining the group? in
  participating? * Miguel: can build on top of 6LoWPAN test specification. *
  Tim Winters: willing to help.
 * Toerless also interested
  * Gabriel: send info to the list

New Drafts Introduction
[  .  ] IP Multicast Technologies for state synchronization in RPL Networks    
Carsten Bormann
   <draft-bergmann-bier-ccast>
   * Presented briefly during previous discussion

[17.11] An Extension to MLE for HIP DEX                                        
Yoshi Ohba
 <draft-ohba-mle-hip-dex-00>
   * compares HIPDEX and MLE. Combination can satisfy reqs for key management
   and link establishment. Using HIP-DEX for key management for MLE * proposes
   to carry HIP DEX msg in MLE msg. * describes key update mechanism. * Subir
   Das: Zigbee NAN  is waiting for this.

[17.14] Security Bootstrapping over IEEE 802.15.4 in Selective order           
Sandeep Kumar
  <draft-kumar-6lo-selective-bootstrap>
  Description of a bootstrapping mechanism for IEEE 802.15.4 based 6lowpan
  networks * many drafts out there on deployment. This one from a user point of
  view. * technician should be allowed to go to commission node in most
  convenient order, not "onion style". * proposal to have network in
  semi-secure state during installation phase. * DTLS with diff credentials as
  the secure channel

[17.18] Analysis of IOT Bootstrapping mechanisms                               
Ana Hedanping
   <draft-he-6lo-analysis-iot-sbootstrapping>
   * lists 6 drafts, as well as Zigbee IP SEP, which propose different
   mechanisms. * compares different credential materials: certificated, raw
   public key, pre-shared key, thread group product installed code * Robert:
   corrections to this comparison table; will send to the list. * describes
   features of a good solution. * issues to be addressed: * Gabriel: these are
   good questions, keep them for the security discussion.

[17.25] Meeting ends