Hi Alexander 

This is interesting work and use case. 

Some comments:

"It can be used during all stages of the lifecycle of the network,
   e.g. discovery, authentication, operation. " --> Basically authentication is 
based on DTLS... is that what you mean?

Figure 3 says associated then authenticated but in the text is different 
authenticated -> associated

In semi-associated state you mention: "In that state, the Node-F broadcasts 
frames, handled by the Node-G,
   but the network cannot join the Node-F on a regular basis." What do you 
mean? The node-G cannot contact node-F? 

In section 3.3.1:

"The frames SHOULD be signed,
   so that they could be authenticated by the network." This signing process is 
before the authentication and key management. How is it possible to sign the 
frames? Any pre-shared key?

In fact, you say:

"and enough information for the Node-G to
   authenticate the message sender.  This can be achieved through a
   Confirmable CoAP message, where the user data are POSTed to a well-
   known resource defined on the Node-G.  DTLS with integrity check can
   be used, with long-lived keys negotiated by the Node-F and the
   network."

DTLS is established for protection (Confirmable CoAP message does not achieve 
authentication by itself). Again, if DTLS is used and those messages are 
authenticated, why do you need authentication phase?

In section 3.3.3:

"For example, it may provide the AAA server, which could authenticate
   the Node-F, or its EAP-Identity. " --> Assuming that an AAA infrastructure 
is used for authentication ( I think that assumption should be expressed in the 
document), typically Node G will have the AAA client and, actually, it does not 
need to know the IP address of the AAA server that authenticates the node F, 
just the next hop AAA server. On the other hand, Node G will not typically 
provide the EAP identity, are you referring to that?

In section 3.3.4 

The reference to EAP-over-CoAP is 
https://tools.ietf.org/html/draft-marin-ace-wg-coap-eap-01 and not 
[I-D.garcia-core-security] where the general problem of bootstrapping is 
explained. 

Hope this helps.

Best Regards.


El 06/07/2015, a las 17:27, Alexander Pelov <[email protected]> escribió:

> Dear all,
> 
> I'd like to bring to your attention a new document, which was submitted this 
> weekend: draft-pelov-core-cosol-00
> 
> It presents a new type of far-reaching, low-rate radio technologies (such as 
> Semtech LoRa and SigFox) and an extensible mechanism to operate these 
> networks based on CoAP.  We document the way REST can be used to manage these 
> networks.
> 
> You can find the current text at the following address: 
> https://tools.ietf.org/html/draft-pelov-core-cosol-00
> 
> We would be happy to discuss with anyone interested the contents of the draft 
> and the possible future works on it. Also, we will be glad if there is any 
> possibility to present even briefly during a session.
> 
> Best,
> Alexander
> 
> _______________________________________________
> 6tisch mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/6tisch

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: [email protected]
-------------------------------------------------------




_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch

Reply via email to