Paul Wouters has entered the following ballot position for draft-ietf-6lo-use-cases-14: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6lo-use-cases/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Like Roman, I am a bit concerned about the security aspects. As this is a use cases document, I've limited my issues to comments. But it would have to be satisfied in any further specification RFCs. Security and Encryption: Though 6LoWPAN basic specifications do not address security at the network layer, the assumption is that L2 security must be present. While I do understand that some L2 security is possible, eg via pairing, there is still a gap for some technologies - eg NFC where I wouldn't know which payment terminal I really connect to. End-to-end communication is expected to be secured by means of common mechanisms, such as IPsec, TLS/DTLS or object security [RFC8613]. EDHOC (draft-ietf-lake-edhoc) could also be a good match Note that while the common mechanism is a good start, it only presents the use of a technology. Those technologies have requirements that might not be usable in the context of 6lo (eg when there is no internet connection to verify X.509 certificates (OCSP or CRLs) or DNS identifiers). _______________________________________________ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
