Meeting Information

WGs info

Data / Time

Date: Thursday July 27th, 2023
Time: 9:30AM local, 18:30AM CET, July 28th 0:30AM Shanghai

Meeting Information

Chairs
o Pascal Thubert pthubert@cisco.com
(in-person chair)
o Alexander Pelov a@ackl.io (remote chair)
o Laurent Toutain (in-person delegate)
Responsible AD
o Éric Vyncke
Room: Golden Gate 7-8
Agenda: on datatracker
Meeting documents: on datatracker
Meeting material: on datatracker
Meeting link: Meetecho Link
On-Site tool: Meetecho Link
Live Minutes: CODIMD Link

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]

Associated draft: draft-barthel-schc-oam-schc-01
Presenter name: Laurent Toutain
Objective of the discussion: discuss adoption

[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]

Associated draft: draft-toutain-lpwan-access-control
Presenter name: Ivan Martinez
Objective of the discussion: presentation of updates in version -01

[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

Meeting Information

WGs info

Data / Time