Minutes IETF117: lpwan: Thu 16:30
minutes-117-lpwan-202307271630-00

Meeting Minutes IPv6 over Low Power Wide-Area Networks (lpwan) WG
Date and time 2023-07-27 16:30
Title Minutes IETF117: lpwan: Thu 16:30
State Active
Other versions markdown
Last updated 2023-08-03

minutes-117-lpwan-202307271630-00

Meeting Information

WGs info

Data / Time

Meeting Information

WG Meeting Agenda

[9:30AM] Administrivia [20min]

  • Presenter: Alexander Pelov
  • Note-Well, Scribes, Agenda Bashing
  • Announcing RFC 9441 / 9442
  • Completing transition to SCHC
  • WG / drafts Status / adoption of SCHCoPPP
  • IP protocol Number and Ethertype (INTAREA)

[9:50AM] OAM reborn [10min]

[10:00AM] Updating RFC 8824 (new work) [15min]

  • Associated draft: draft-tiloca-lpwan-8824-update
  • Presenter name: Marco Tiloca
  • Objective of the discussion: presentation of updates in version -01;
    confirm the switching to a bis document

[10:15AM] SCHC Access Control [10min]

[10:25AM] SCHC Packet Information [15min]

  • Associated draft: draft-ietf-schc-architecture-00
  • Presenter name: Pascal Thubert
  • Objective of the discussion: Discuss the abstract data model of
    session identification in packets

[10:40AM] Session Initiation and Rule exchange (new work) [15min]

  • Associated draft: None yet
  • Presenter name: Sergio Aguilar Romero / Pascal Thubert
  • Objective of the discussion: Discuss abstract exchange for session
    setup and Rule instantiation

WG Meeting Minutes

[9:30AM] Administrivia [20min]

  • Presenter: Alexander Pelov
  • Note-Well, Scribes, Agenda Bashing
  • Announcing RFC 9441 / 9442
  • Completing transition to SCHC
  • WG / drafts Status / adoption of SCHCoPPP

  • IP protocol Number and Ethertype (INTAREA)

  • Pascal: Note-Well, new features to read and agree

  • Agenda:

    • Pascal presents the Agenda of the day.
    • New topics: Ethertype, AOM reborn from lpwan, Updating RFC8824,
      Acces Control, Architecture
    • Architecture difference with lpwan, and how to stablish a
      session and identify the resources and what information to
      negotiate and which header
    • Hackacton feedback

  • LPWAN:

    • The last 2 RFCs have been published RFC9441 and 9442
    • We have move the rest of the features to SCHC WG
    • Closing LPWAN WG
    • Eric Vyncke: LPWAN will be closed today or tomorrow
    • Make reinscription to the SCHC WG, it is not automatic

  • SCHC:

    • Adopting new document: SCHC over PPP
    • Convergence document, split into convergence profile
    • Streaming mode, not changes
    • Need a logo: need to ask Ana
    • 2 adoptions: PPP and architecture
    • Milestone to discuss now is the SCHC header with a separate
      document
    • SCHC adopted in IEC and Lorawan Standards
    • Laurent: TS10 for LoRAWAN Standard that adopts SCHC over LoRaWAN
      with RFC 9011

[9:50AM] OAM reborn [10min]

  • Presenter name: Laurent Toutain

  • Laurent

    • Mainly how to compress ICMP messages

    • Add different features to handle it:

      • Proxies
      • ICMP message generation at the core level
      • New CDA and MO to compress ICMP messages Echo Request/reply,
        already implemeted in OpenSCHC and working well

    • Eric: what about sending SCHC-specific error codes? be more
      descriptive

    • LT: good question, generate new ICMP code (new code can indicate
      that the device is a LPWAN device, and that is not wanted)
    • Eric: New type not only error codes: e.g. ICMP error code
      indicating time out
    • LT: 2MO : match-rule, match-rev-rule
    • LT: 2CDA : send-compressed, send-rev-compressed
    • PT: Are there cases where the ICMP message goes from dev to app?
    • LT: Good idea, not present in the architecture, maybe not good
      from the security point of view.
    • LT: not included for now but we can discuss it.
    • AM: When you use the proxy, you say that the device is an LPWAN
      device, what will happen if the device is not contrained?
    • LT: you can just use the compression and not use the proxies,
      the actions are not mandatory.
    • AM: add this to the draft, cause we get the feeling in the
      document that is must be with a proxy.
    • EV: adding error codes or even ICMP types can be done but it'll
      be a bit difficult and could be both more useful for OAM but
      also cause unexpected message in some legacy implementation.
    • PT: OAM is not only about rechability but also quality of the
      link (assert the capabilities of a device)?, it's an open
      question. Add capabilities, and make statistics to see the
      status of the network
    • EV: We need to do links to other groups, OPSAWG (e.g., IPFIX),
      IPPM, ...
    • DB: Carry on to the ML

    • PT: Security section is very important to consider the possible
      attacks

    • Robert Moskowitz (from ML): Too long abtract that can be
      problematic with IESG

[10:00AM] Updating RFC 8824 (new work) [15min]

  • Presenter name: Marco Tiloca
  • MT:
  • RM: Is it possible that an outer rule says that there is a inner
    rule, then when you proccess the outer rule you can handdle the
    inner compression.
  • MT: Both rules compress different things

  • RM: That's not the point the this is what if a rule compresses
    another one?, just an open question.

  • MT: Open point to discuss considering as bis or update to RFC8824.
    Objections to transform it to a bis document?

    • No objections

  • MT: More options will be defined in the future, so how to cover all
    and not do new versions.

    • Use the yang data model to add the new options
    • And cover in this document how to analyse and compress any
      option.

  • PT: Is it OK to start a bis document?

    • 15 hands up out of 15 participants
    • We'll confirm on the mailing list as usual but (to Marco),
      please prepare for a bis.

  • DB: There is a proposal from Quentin for handling new options
    wothout the need of having to update the Data Model each time a new
    option appears.

[10:15AM] SCHC Access Control [10min]

  • Presenter name: Ivan Martinez
  • Update version
  • Define terminology to agree in all the documents
  • PT: We need to discuss and it is reponsible of architecture document
  • PT: Architecture is the reference and we need to be sure that
    everything is there, go to the ML to add and discuss what is missing
  • Questions
    • PT: How is comparing your work to the milestones, it has several
      components that are spread in some of these objectives, but the
      security analysis perhaps need to make part of the architecture.
    • IM: yes it was only the introduction to the management
    • PT: Two milestones, how do you install the Rules in the devices
      (provisioning) and the setting of the session to be agreed that
      we are using the correct Set of Rules. If this is a separate
      document refering to your document ?
    • LT: We want to describe the use of the different combinations
      and the attacks that may happen
    • PT: make a document just the data model and how it is use and
      the second is the provisioning
    • LT: We have to understand how to protect a Rule, and how it can
      be attacked
    • PT: do you want to separate this in 2 documents?
    • LT: yes, we can. This document was an input for discussion
    • QL: slide combination: Consider setting the value to something
      that does not exist?
    • QL: How to add a new FID?
    • AM: Create a new Rule
    • LT: This only the case with CoAP for some fields as Uri Path
    • PT: Useful?
      • 13 raise, 1 not raise hands out of 14
      • ML will confirm

[10:25AM] SCHC Packet Information [15min]

  • Presenter name: Pascal Thubert
  • Moving from LPWAN architecture to SCHC architecture, there are more
    things to see
  • Session context. New extension header are UDP ports
  • If can be compressed to zero for the LPWANs
  • Everything that the session needs to know
  • 3 possibilities and what do we want to see there

Open MIC
RM: Are we complicating here or not? We need guidelines
PT: the discussion is how we encapsulate the this and not how we are
building that
PT: is like a general canvas to compress any packet, this could be
zero,
BM: we need Options and actions to the protocol
PT: The architecture needs to add all these points
PT: to be compliant, you can use this format even if it zero
LT: we do smthg with IPSEC in the hackaton, it is very flexible
PT: depending on your Rules could be there or not, only default is Next
header (mandatory)
EV: Session ID is an opaque value (any value) End to end.
PT: yes
EV: you cannot change the packet in the fly, there is not any new
extension value definition
PT: we could have a destination option header
KM: extension hdr. SCHC ext hdr with other ext hedr, SCHC is the 1st
one
PT: No you are free to place it whereever you want. Destination option
header you could have two of them
PT: everything before SCHC is not compressed
PT: a Hop by hop is not compressed. Session is EtE
KM: Default Rules. Are part of the architecture? or configuration
specific?
PT: we need to discuss and agree. Scope of knowledge for these Rules.
PT: Discussion what is SCHC context?
- Rule Set + Amendments (management) + rule data
- Instantiated then I can add timers and states
PT: structure the data

  • Which model, do we take one or the three we need SCHC protocol
    number
    • Go to the ML

[10:40AM] Session Initiation and Rule exchange (new work) [15min]

  • Presenter name: Sergio Aguilar Romero / Pascal Thubert

[10:45AM] diet ESP [10min]

  • Presenter name: Daniel Migault
  • Presented in IPSEC WG

[xxxx] AOB [QS]