[saag] RFC 3552bis Suggested Text/Structure

[Michael StJohns <[e-mail]>]

This is in response to Stephen's message of 18 October.

In addition to traditional security considerations sections which focus 
on threats *to* the protocol, it's becoming obvious (especially with IOT 
style devices becoming prevalent)  that we also need to be thinking 
about threats *from* the protocol to the IETF.  So here goes:


Outline:

- Threats to the Internet from protocol choices in this document

   -- Stateless Query Response protocols (e.g., UDP-based protocols)

       UDP based protocols such as ECHO and DNS have the potential to be 
used as Denial of Service amplifiers.....

   -- Data source protocols without adequate rate and congestion 
detection mechanisms

      Protocols where a client can trigger a server to send data without 
throttling  [based on network congestion or other useful techniques] 
have the potential to be used as DOS sources and amplifiers...

   -- Cyber-physical protocols without adequate authentication, 
authorization and confidentiality

       --- Confidentiality

            Sensor data without adequate protection including but not 
limited to environmental measurements and audio and video surveillance 
has both privacy and safety and health considerations.  There may also 
be implicit  real-world (i.e. marketable) value in the data being 
transmitted that needs to be protected.

       --- Authentication & Authorization

            Sensor data without adequate protection on closed-loop 
feedback systems (e.g., temperature measures used to control heating 
systems) can result in triggered real-world actions that may be have 
safety and health considerations.  Specifically, if sourced sensor data 
cannot be verified as authentic (originated by a trusted source, 
unchanged in transmission), making process decisions on such  data is 
problematic.

            Actuator control without adequate protection (e.g., 
decontamination lighting systems, security and locking systems, 
industrial control systems, etc) may have safety and health 
considerations and could result in injury or loss of life.  This is also 
tied to Authorization - the actuator needs both an identity and a 
privilege to be authenticated prior to actuation.

   -- IOT - general

       --- Quantity has a quality all of its own

       IOT systems have the potential to deploy one or more orders of 
magnitude of internet connected entities than current 
applications/services.  Does a protocol designed for use among cluster 
of 1K, 10K or 100K+ systems have sufficient protections to prevent 
wholesale attacks against the system (e.g. does compromise of one or a 
few devices compromise most or all of the devices?).

      Botnets are well understood at DDOS enablers.  Are there other  
new forms of attack coming with IOT scale Botnets?  Can threats from 
distributed intelligence based systems be mitigated against in protocol 
designs for IOT devices?  Are there approaches the backbone can use to 
mitigate?


    --- Near zero cost security

         IOT systems seem to have special sensitivity for any additional 
costs due to the desire to churn out very cheap devices.  Issues with 
software reuse (one bad stack in 30 different designs for example), 
software replacement (is a $5 device really designed for *real* 
management), and lack of a related human (contrast with routers, 
switches, servers, laptops etc which generally have a human that 
"manages" them vs an IOT device that might be thrown out of a plane or 
scattered in a city) have already crept in.  What mitigations can we 
supply that are both cheap and effective?  Are there protocol techniques 
that are especially applicable?  Do we try not to publish protocols 
which can't be made "secure enough"?

    --- Clocks, we don't need no stinking clocks

         IOT systems, related to many of the items above, may not have a 
good sense of real-time.  Do the security techniques propose adequately 
compensate for insecure or missing time?  For sensor systems, are 
anti-replay mechanisms sufficient for the system design goals?


     ___________________

The above is somewhat stream of consciousness - not all of these bullet 
points can be reduced to practice in a security requirements section, 
and there *will* be others that pop up. But this is at least a start for 
a new section for 3552Bis.


Mike