Re: [Iot-onboarding] draft-garciamorchon-t2trg-automated-iot-security-00

["Garcia-Morchon O, Oscar" <[e-mail]>]

Hi,

I read the t2trg automated iot security document.
      draft-garciamorchon-t2trg-automated-iot-security-00
    I read -00, as I guess I started reading before the -01 came out.
    I looked at the diff just now, and I suspect that it's an improvement.

>> Yes. We removed unnecessary details and we tried to highlight the motivation and architecture view. We also tried to show how (a very first version of) such a system can be built.

    I liked the abstract concepts of the PACS and PAVA.

>> Thank you.

    I think it might be important to understand that there isn't a MUD
    "protocol", just a file format.  MUD pointers are carried in a variety of
    other protocols until DHCP, LLDP, BRSKI and even QR codes.

>> Good point. This should be better explained in the document.

    I'm not sure what to do with this document.
    I don't think it defines a protocol that we can implement, but rather a
    conceptual architecture that might guide future protocol work.  It feels like
    it could be a roadmap document for some WG which does not currently exist.

>> Version -01 was written with the goal of describing the problem space and solution direction. It indeed only describes a high-level architecture. We only describe "next steps" in Section 6 where we give some (first) details about how the "high-level architecture" in Section 4 can be instantiated.

    I am not sure that the assessments proposed are feasible in current CPE
    devices that are deployed in homes; but I suppose that the cloud might come
    to the rescue.  However, in order for this to be widely useful the inputs and
    outputs needs to be well defined, and there needs to be a standard format
    for the audit trail of decisions made.   I am reminded of the spamassassin
    explanation of why something is or isn't spam.

>> Yes, if we want to perform any type of (risk/privacy) assessment after deployment, contents and formats need standardization.
>> Here, there will be technical solutions that will be able to cover many use cases, but they will be also (more) complex.  Some solutions require (much) less work and can easily help to improve the security level in IoT systems.

On 20/11/2018, 17:23, "Michael Richardson" <[e-mail]> wrote:


    I read the t2trg automated iot security document.
      draft-garciamorchon-t2trg-automated-iot-security-00
    I read -00, as I guess I started reading before the -01 came out.
    I looked at the diff just now, and I suspect that it's an improvement.

    I liked the abstract concepts of the PACS and PAVA.
    I think it might be important to understand that there isn't a MUD
    "protocol", just a file format.  MUD pointers are carried in a variety of
    other protocols until DHCP, LLDP, BRSKI and even QR codes.

    I'm not sure what to do with this document.
    I don't think it defines a protocol that we can implement, but rather a
    conceptual architecture that might guide future protocol work.  It feels like
    it could be a roadmap document for some WG which does not currently exist.

    I am not sure that the assessments proposed are feasible in current CPE
    devices that are deployed in homes; but I suppose that the cloud might come
    to the rescue.  However, in order for this to be widely useful the inputs and
    outputs needs to be well defined, and there needs to be a standard format
    for the audit trail of decisions made.   I am reminded of the spamassassin
    explanation of why something is or isn't spam.

    --
    Michael Richardson <[e-mail]>, Sandelman Software Works
     -= IPv6 IoT consulting =-






________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.