Subject: [core] help needed: IETF 81 minutes!

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 13 Sep 2011 12:02:26 -0600

<hat type='AD'/>

The CORE WG has yet to submit minutes for its sessions at IETF 81.
Minutes are not optional and need to be submitted by the end of the day
tomorrow (September 14).

Who volunteered to scribe the sessions? Did you send your notes to the
WG chairs? Can you please send them to the list so that we can try to
create official minutes?

Thanks!

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Zach Shelby <[email-masked]>
Date: Tue, 13 Sep 2011 21:36:55 +0300

Peter,

Here are the two sets of notes from Quebec that I got via Cullen. The first is from Ed Beroset and the second from Thomas Fossati (thanks!). 

CoRE notes part 1:

Note well well noted, blue sheets distributed.
Volunteers for note taking.
1. Link format.  
Last call was January.  Chairs to do writeup. 
2. CoAP:
Reminder of changes made.  
One open issue regarding Content-Type Negotiation.  Do we support single or muliple Accept requests?  What about error return?  We decide to keep it elective, and if multiple types are requested and none are implemented, a server that supports Content-Type Negotiation returns an error code.  Servers that don't support Content-Type Negotiation will simply return content in the single format they do support.
Security section:
let the pre-shared key mode stay as is, 
Have an interim meeting; maybe Sept. to nail down cert provisioning story.  Prefer not to have it during Sept 18 IEEE 802 meeting in Okinawa (Bob Moskowitz).  Pero (spelling?) will write a proposal before September.  Bob Moskowitz suggests the use of raw public keys in ACLs rather than x.509 certificates.  Bob Moskowitz will write up a proposal for doing that.  

"TLS working group should take up a raw public key mode." (hum - unanimous agreement).

Blockwise Transfers in CoAP:
needs rewrite, better names for BLOCK1, BLOCK2 and clarify that Request Entity Too Large could mean truncated message.  (Shelby will open ticket on the latter.)

Observe:
Same version as in Prague.  Text on reordering detection needs rewrite for clarity.  Observe relationship used to contain a duration negotiation, but simplification caused us to drop that.  Requesting observation relationship to a sleepy server can be difficult.

Proxy Implementation Advice:
Request for group to provide examples for TLS+Proxy to CoAP.  Request to group to read and comment on mailing list.

Sleepy nodes:
Shelby to clarify retransmission rules.  Arkko says that observe needs to be fixed for low power networks.  

Always Online requirements:
presentation given.

CoRE notes part 2:

> :: doc submission to IESG proposal by fluffy ::
> 
> :: resource directory shelby ::
> personal draft start specifying interfaces of resource directory
> roughly comes from SENSEI EU project migrated to CoRE
> in hack fests used as a commodity to locate resources in a simple way
> architecturally 
> 
> enpoints make their web links available to others by registering to an RD
> clients lookup in the RD for resources given ct= and other attributes
> the draft only wants to specify the (REST) interface of the RD, not how it is implemented internally
> 
> 1) discover RD via .well-known
> 2) register POSTing resources to a "root" pathname given by the RD during discovery
> 3) update by PUTing the up ...
> 4) validation [see slides]
> 5) deletion [see slides]
> 6) lookup [see slides]
> 
> two new link format are defined
> 1) ins= for distinguish different res with the same rt=
> 2) exp for allow the RD to export the request you have registered
> 
> issues
> terminology is a mess
> how to differentiate between multiple RDs in discovery
> how to tell the RD about the host
> 
> hannes > trying to give meaning to the nice Architecture picture in the presentation
> shelby > just want to propose a basic mechanism for registration and lookup, no overspecification
> 
> :: discovery mapping by lynn :: 
> -01
> refers to core charter, how to map existing technologies 
> use cases
> 	support alt methods for discovery in mixed envs (e.g. http and coap clients coexisting)
> 	support hierarchical discovery in massively populated envs
> 	use:
> 		DNS-SD for coarse grained discovery
> 		link-format for fine grained discovery
> 
> 	DNS-SD uses SRV records to get service instance name (host:port, the server at the transport layer); then use TXT record to add pairs "path=entry-point" (the resource at the application layer)
> 	mapping link-format to DNS-SD
> 		ins= -> {Instance}
> 		rt= -> {Service}
> 		<uri> -> TXT.path=...
> alex > concern about overloading the TXT record, have you looked after alt solutions ?
> fluffy > we are reusing DNS-SD, so nothing has been invented here
> 	slide with example of link-format to DNS-SD mapping
> 		coap query to the well-known at the all-multicast-hosts address for core "exp"ortable resources
> 		get a response back, do reverse DNS on the responder address and create a DNS record ... [see slides]
> 
> 
> :: groupconn by akbar ::
> -06
> * basic mcast concepts definition
> 	- assume multicple receiver nodes in a group
> 	- sender sends a single message with content to the group address
> 	- actual message distribution (can be mcast, series of mcasts, serial unicast, ...)
> * reqs for group comm [see slide "Requirements for Group Comm ([1-4]/4) for details]
> 	- reliability 
> 	- efficiency
> 	- low latency
> 	- synchrony 
> 	- ordering
> 	- security
> 	- flexibility
> 	- robust group management
> 	- network layer independence
> 	- minimal spec overhead
> 	- minimal impl overhead
> 	- mixed IP backbone/LLN topology support
> * potential approaches
> 	- IP multicast
> 	- overlay mcast
> 	- application layer group management (a la mailing list)
> 
> * recommendations
> 	- adopt IP mcast as baseline solution (not a trivial task, but does not require changes in the IP mcast suite)
> ACTION: send to the homenet group the mcast requirements
> 	- MLD-like optimizations, e.g. subset
> akbar > what next ?
> fluffy > not ready to take any decision
> lynn > does the core draft needs on the method side support groupwise communication ?
> shelby > congestion control needs to be expanded, the rest of the spec seems to be IP multicast ready
> 
> :: timeout options ::
> POST/PUT issue {slide 1}
> GET issue {slide 2}
> => add the size option to solve the highlighted issues
> 	- GET: server return the size of the resource without giving back the payload
> 	- POST/PUT: ...
> open issues on proposal (going on in the ml):
> 	* elective or critical ?
> 	* block[12] design 
> fluffy > [after humming] ok, carry on with the document 
> request-timeout option to specify timeout in the request
> open issues on proposal (going on in the ml):
> 	milli or mib secs for timeout spec ?
> 	difference between request and connection timeout
> fluffy > comments ?
> shelby > not convinced that we need this, but not an horrible idea. get real-world experience to have a proof it is not broken before adopting it as wg item
> fluffy > thanks for being the first in the history of this wg to close your presentation on time
> 
> 
> :: naming and discovery of groups by vanderstok ::
> how to represent in the DNS-SD inherently hierarchical/groupable devices by defining the hierarchy in the SRV name space...
> shelby > issue with forcing all the res in the group to use the same path
> vds > we didn't
> shelby > use proxy to resolv the conflict
> ... > where is the DNS and who is administrating it ?
> lynn > delegate the IT guys the administration in some "secure" way
> 
> shelby > I think the idea of forcing the sensors in the group to have the same path should be carefully considered. An alternative way is to have a proxy in between.
> Peter > Put the proxy in between will cause delay. 
> Ed > Where the DNS server is? Who is administrative it in that scenario?
> Kerry > In commercial applications, you can delegate DNS resource. 
> Anders > For large buildings you will have administrative DNS server. 
> Kerry > It is also possible to add DNS records in existing DNS.
> 
> 
> :: EAP-based key establishment  by ohba ::
> goal: provide KE mech for
> 	- DTLS-PSK 
> 	- PSKmode for IKEv2
> use cases:
> 	- non integrated with network access auth
> 	- integrated with network access auth
> architecture picture { see slide }
> 	basically you need two functional entities AA (auth agent) and AS (auth server) [maybe hosted in the same network device] to handle the KE protocol and credential feeding on endpoints
> 
> configured parameters at the end of a successful KE process:
> 	- identity of client and server
> 	- PSK to use in DTLS of IKEv2 to setup SAs
> support for change of service provider (recommissioning): with the use of service provider-independent authentication credentials that may be pre-provisioned to the UE
> (e.g. manufacturer provisioned credential).
> ... > recommends thinking about different mech that reduces the number of messages used for KE (12 or so)
> 
> :: deploying security by arkko ::
> 
> for multiple reasons (# of objects, no user interface, ...) provisioning is the fundamental issue 
> another issue is the layering one: LL security is not enough in non isolated contextes, ...
> concepts:
> 	* secure identities: hash(public_key), like in HIP
> 	* provisioning: each object has a secure identity that is communicated to the server
> 	* layer choice
> 	* proto formats
> how  identities are used:
> 	messages are sent with data, signature, public_key of the sender, secure_id
> ohba > no mutual auth in this sec model
> arkko > it is modeled after my current setup, which doesn't look for server identity
> hannes > there's probably no security solution that satisfies everyone.  we should probably make a bigger picture rather than provide single-shot solutions
> arkko > mine is a minimalistic approach that aims at using the minimal amount of resources possible for doing what i need...
> ekr > ...
> oscar > DTLS is more efficient from a memory and message size
> arkko > provisioning is not cheap in DTLS
> bob > use 2D barcode to do the provisioning 
> Yoshihiro > his identity is the client device identity. Consider the mutual authentication, how this can be done?
> Hannes > he different trust model leads to different solutions. This is the application layer solution. I am wondering how this can form a big picture for different trust models in terms of standardization. 
> arkko > We are proposing architecture that provides a practical, minimal-configuration approach to smart object security. 

On Sep 13, 2011, at 9:02 PM, Peter Saint-Andre wrote:

> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 13 Sep 2011 14:06:32 -0600

Thanks, those are very comprehensive. If the chairs don't reappear in
the next 24 hours, I can send these notes to the Secretariat.

On 9/13/11 12:36 PM, Zach Shelby wrote:
> Peter,
> 
> Here are the two sets of notes from Quebec that I got via Cullen. The
> first is from Ed Beroset and the second from Thomas Fossati
> (thanks!).

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 13 Sep 2011 15:59:25 -0600

FYI, Cullen has submitted the minutes although because of a website
glitch they might now show up until tomorrow.