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

                         6lo WG  - IETF 95, Buenos Aires, Argentina
                         17:30-19:30 Local Time  Thursday, April 7, 2016
                         Room:  Pacifico A

                         Chairs: Samita Chakrabarti, Gabriel Montenegro

                         Responsible AD: Brian Haberman, Suresh
                         Krishnan(incoming) Technical Advisor: Ralph Droms
                         ----------------------------------------------

Minute takers: Dominique Barthel, Rashid Sangi
Jabber Scribe: Alexander Pelov

Thanks to our minute takers Dominique and Rashid and Alexander for being Jabber
scribe. That really helped.

Meeting Minutes:

Draft Status:

    4 WGLC completed, two of which need minor updates

    5 documents have been adopted. draft-ietf-roll-routing-dispatch-00 has been
    moved to ROLL.

Drafts that need WG attention:

    -privacy-considerations. The comments on the mailing list need to be
    resolved.

    -draft-droms-6lo-ethertype-request

    -draft-kivinen-802-15-ie-00

Next the presenations started. There were 12 presentations.

Ralph Droms -draft-droms-ehtertype-request

RFC4944 doesn't have a prootcol switch, several has requested it. This document
will enable IETF to go to IEEE and ask for an Ethertype.

Several round of discussions took place on mailing list, text reworded to say
applies to anything that uses RFC4944.

[Carsten] can we run 6lo over Ethernet? Because of padding, for e.g.. ?
Ralph: nothing to do with this draft. We want an ethertype.

[Samita] Zigbee NAN wants to use it.

Show of hands on who thinks WG should work on this? ~15 hands. Opposed? none.

Chairs mentioned that the draft would be going on adoption call soon after IETF.

[17:46] Tero Kivinen draft-kivinen-802-15-ie-00.txt

It is not directly related to 6lo, but IEEE 802.15.4 has defined Information
Elements in frames. Complements the actual payload.

IEEE will only give one code, want to see that we sub-type it and we understand
we'll only get one.

No question.

[17:48] Kerry Lynn -6lobac (remote)

BACnet international standard for building automation. Does have IP transport
so far.

First proposed at 6man in 2011.

2 implementations at plugtest in Yokohama, a dissector exists for Wireshark.

It has got two detailed reviews.

Security section remains unreviewed, will discuss it here.

The author believes lots of privacy problems usually associated with IoT do not
apply here.

Keep SLA generated out of MAC address for compression efficiency of link-local
addresses.

Waiting for Carsten's comments and then shepherd's writeup to go to iesg

[17:55] Yeung-Geong Hong - draft-ietf-6lo-nfc-03

three NFC modes, here using the p2p mode.

Last draft includes security considerations.

NFC uses 6-bit MAC address. However, very short-lived links mitigates security
risks. The 6-bit address is generated for each connection.

Plugtest at Yokohama between 2 implementations.

Will participate in NFC Forum June 2016.

Will be at ETSI plugtest in Berlin.

Will wait for a couple of review and then it will be ready for WGLC.

[Samita]: short range and short-lived connexion. What about link layer security
mechanism? [YG Hong]: none.

[Samita]: In the future, need for security mechanism at 6LoWPAN layer? [YG
Hong]: will discuss and report.

[Samita]: Looking for volunteers to read and comment the draft? Pascal Thubert
and Alex Pelov.

[Gabriel]: who wrote the 2 implementatins? [YG Hong]: one by myself, second one
by a small company in Korea

[18:02] Samita -draft-ietf-6lo-dispatch-iana-registry

completed WGLC, received comments.

Samita provides a little background on the ITU-T use of dispatch codes 1-31 for
G3.

Since IETF94: few clarifications (non-LoWPAN, ESC before efragm...)

No question
The draft will be ready for IESG submission following shepherd's (Jonathan Hui)
writeup.

[18:06] Pascal Thubert -draft-ietf-6lo-paging-dispatch

It extends the encoding space of 6LoWPAN by using pages.
Now the draft is split into two : 1) paging dispatch (remains in 6lo)
2) Routing Dispatch (moved to ROLL as it applies to Routing )

Both draft went to last call.

No active ticket.

It's a short read, very simple. Read and comment on ROLL maiing list.

Only user so far is 6loRH, which uses 1/3 of the space of page  #1

Last revision updated IANA request section.

[Gabriel]: please read and comment, even if only to say "yes".

[Gabriel, Samita] : Anything to say about the Routing Header document? Only
make sure
 it uses the right dispatch page and code.

[18:10]  Shahid Raza - draft-raza-6lo-ipsec-04

About compression of IPsec headers. First version dates back to IETF80.

designed for 6LoWPAN networks only, does not require change to IPSec.

Comparison to other IPSec compression proposal/possibilities.

Comments from IETF94:

    - AH almost never used, why bother? added paragraph on benefit of using AH
    for IoT.
      Reviews and comments welcome.

    - usage of one of free NHC ID-bits.

    - make the second EID reserve bit extensible, use only one for this draft.
    Done

    - use of CCM? This draft does not recommend any specific cypher suite.
    doesn't
      prevent CCM from being used either.

[Pascal Thubert]: which code would perform the IPSec work? Cannot compress
upper-layer protocol header
 if hidden. Shahid: we don't expect any change on the encrypted side ...

[Hannes Tsch]: interest in the WG to work on this in the first place?

[Gabriel] show of hands if interested in seeing this going forward? 5.
          Who thinks this should not go forward? 4.

[Hannes]: would love to hear from those who support this, why. You also worked
on DTLS,
          provides the same kind of security. Creates fragmentation.

[Shahid]; we've had this discussion for years, even before the DICE WG was
formed. IPSec
          can do things DTLS can't do. Programmers shouln't need to worry.

[Carsten, Core co-chair]: CoAP decided to go for DTLS. Useful to have ESP in
this space, but
          chicken-egg problem. Carsten is in favor of completing the work to
          have this tool in our tool kit.

[Tero]: Not sure compressing IPSec if very useful. 15.9 uses IKEv2 to generate
end-to-end keys from the
        node to the cloud server. There is a use for IPSec, but benefit of
        compressing it not clear.

[ on Jabber]:

[Michael Richardson on Jabber]: this should be defered

[Hannes]: conclusion at IETF before closing DICE WG is that it (what?) would
not be done.
           Same for key management in 15.4, not helping people by giving them
           to many possibilities.

[Pascal]: Agree with Hannes, don't want to fragment the market.

[Gabriel]: A lot of passion on this topic, no clear conclusion

[Suresh]: Bring it to the mailing list

Shahid happy to repy to Hannes comments.

[18:35] Pascal Thubert - draft-ietf-6lo-backbone-router-03

work dates back to 2008!

Adopted by 6lo in Jan.

planned for ETSI Interop in Berlin

ND was defined at the time Ethernet .. bridging. 802.11 introduced association
to router.

This draft does just that. It's a layer 3 access point.

This solves most of the reqs in -rfc6775-update-reqs

Extends ARO option, could go into 6775 updates.

The suggestions from chairs are to split the draft into backbone router proxy
and 6lowpan-ND updates.

Come to Berlin with your implementation for interop.

No question

[18:40] Pascal Thubert -draft-sarikaya-6lo-ap-nd-02

Address Protected Neighbour Discovery

what SEcure ND does is to make sure that no subsequent node can claim the IP
address of a previously joined node. Registrar associates IP address and ID of
the device. Could associate other info, too (name, ...). Creates a trusted
anchor.

It Would be used as Unique ID in the ARO option.

A numer of protocols were looking for ways of identifying devices. MAC address
doesn't work.

ISA100.11a uses IPv6 address as ID. Can be spoofed. This trusted anchor is the
solution.

[Hannes Tsch]: often this identity and identifier discussion is confusing. Need
to say what it's going to be used for. To run auth protocol at the server? In
some other case,
 ... For the most use cases, it doesn't matter what the identifier actually is.
 Just to use it in the auth protocol.

[Pascal]: protocol to challenge a device to prove it is the same one that
previously registered

[Hannes] this is regular SEND.

[Pascal] talking about IP layer, here. Not assuming this will bubble-up to
upper layers?

[Eric Nordmark] what this does is prove same node ... Currently done by
presenting EUI64. This makes it secure.

[Hannes] if this is true, ok.

[Hannes] if want to reuse it at other layers, start getting worried, just limit
it to protect an address.

[Subir Das] This is not addressing the compromised node problem, right? Pascal:
no.

Pascal resumes slide presentation. Added comparison with SEND. Discussion on
the mailing list.

Question: Do people see that address spoofing may occur in Iot?

L2 is the first layer of Security, codepoint in this discussion

[Micahel Richardson on Jabber] the value of this is that it protects against
misconfiguration of IP address....

[Pascal] great point, thanks

[MR]: it's a typo when you set up the new NMS node...Service Management

Pascal goes through sequence of message diagram.

[MR on Jabber] no, I'm saying the operator made a typo when the *operator*
configured the static IP
 on some new node in their NOC. That's the typical case that this kind of thing
 protects from. maybe someone in the room can explain this, but really it's not
 that important.

Pascal goes through sequence of message diagram.

CGA-lite crypto

prev draft: Backbone router uses ARO over the backbone.

Pacal describes case where 6LR configured to check proof by itself. Then
forwards registration to 6LBR.
 Save the burden of sending the few kb of ... to the 6LBR

Describes cases of collision of state (e.g. attack).

[Samita] How many people have read the draft?

3or 4 read this draft,

work on?  Yes - 2 people

[Samita] useful?

[Mohit] Useful at microphone. Mohit also reviewed the document.

[Gabriel] anybody thinks this is not interesting?

[Carsten] Should think how this integrates in the whole picture. This thinking
should be done then
          go back to this work

[Subir Das] your thinking where this would be useful?

[Pascal] Network where you can't trust all devices that joins the network. A
compromised
 device/ attacker can claim IP address of legitimate device and divert flow
 going to it.

[Pascal] prevents the attacker from black-holing another (legitimate) node.

the use case dont provide complete garanty

[Carsten] classically assume that nodes joining the networks are friendly.

[19:08] YG Hong -6lo-use-cases draft-hong-6lo-use-cases-01

6lo Use Cases: History and status

Goals: describe usage of 6LoWPAN-like mechanism on top of various L2
technolgoies.

     Plugtest Yokohama implementation, IPv6 on L2,

     News 6lo RFCs, design patterns? let us know if you are interested on this.

     NFC, secure transport by using NFC, Smart Home, BLE, DECT-ULE, LTE

     Example NFC: 6lo use case parameters: dominants one, in secure transfer by
     using NFC in healthcare services:

         Deployment/Bootstrapping, Topology, etc.

    Status of collaboration with JTC1/WG 10, on-going standard projects under
    WG 10, ISO/IEC TR on IoT Use Case

    Difference between two SDOs, Etc

    Ask to the chairs to analyze in the WG. Ralph Droms, IAB liaison ... will
    take care contacting JTC.

    Conclusions: In morning got possitve feedback, comparison table, valuable
    to develop the 6lo use cases document.

    Discussion points:

    how to describe 6lo requirements, the common and the specific ones, I would
    like to have your opinion on this.

    Last point: How to develop this document

[Pascal] renaming the doc would be a good idea. Decide if it's for of use by us
or by people outside of IETF.
 The latter would be immensely useful. The former, not sure.
Dominic: Is it similar intention to define the use case as other WG provide or
what is the detailed intent? Samita: To provide more details of the use cases.
Example, detailed requirements/expectations from security etc. Gabriel:
Detailed deployment considerations and we may go for even changing the names.
Establishing a Wiki page. Pascal: People from outside should refer to get
detailed information beyond the description mentioned in the charter.
Presenter: Personal intention, Samita: Tabular description for comparison of
characteristics in terms of applications on different L2 technologies.
Presentor: MS/TP details would be added in next version. Samita: Decsion for
adoption would be done later Pascal: similar documents exist but the deployment
parspective should be addressed here. Samita: Deploying related information if
anyone working, should kindly provide.

Samita: Anyone deploying 6lowpan network today may provide useful comments

[19:19] Carsten: 1st 6lo Plugfest, Yokohama, Report

This one was different, because we had 6lo in different technologies, we could
not test each other.

some of the technologies made changes and running own implementation.

Focus on three technologies, 6lobac, nfc, 6lowpan, 9 companies, couple did not
have implementation, just to observe the process.

Results: Got half of the tessts done, the test cases are tcp based, many
constrains because of that.

Interoperabiity, looks pretty good,

Lesson learned: need interoperability test cases for non-trivial MAC layers

Need physical support: For arrangement NFC module for testing

Isolation material necessary,

Next time? 6lowpan, and NFC have additional implementations, would be good to
do this again, additional

6tisch people have interop events very often, it is very nice.

Define which techonology to address.  6lowpan people and 6tisch in the same
room would be good.

suggest to do 6lo interop every second IETF: Berlin then Chicago.

[M Richardson on Jabber]

but, we have that list, and so that basic notice is great: Personally, it works
better to do this stuff before IETF,
               rather than after. I'm exhausted after IETFs.

Kerry Lynn seconds.

[19:28] end of meeting