[Anima-signaling] draft-ietf-anima-grasp-08: DULL comments discovery be performed over TCP?)

[Toerless Eckert <[e-mail]>]

Brian:

Suggestions for 3.5.2

1. I think SONN is not necessary best described as "limited security",
   but "constrained functionality". Therefore i would suggest
   to use "Constrained functionality Instances" as the title.
   imited Security such as DULL is also well in scope of 
   "Constrained functionality".

2. The initial text for DULL says:

   "2) During initialisation, before a node has joined the applicable trust infrastructure, [I-D.ietf-anima-bootstrapping-keyinfra], it is
      impossible to secure messages."
   
   This was i think suggested by the anima-bootstrap team before it
   decided that it wants mDNS. At that time i thought we would also
   use one objective for both BRSKY and ACP, therefore ACP was never
   mentioned in this text. Which now hits us.

   I would suggest changing the text so that:

   a) it will allow ACP discovery to use DULL GRASP.
   b) it will allow any other services with similar requirements to
      use DULLG GRAP
   c) the text can continue stay unchanged whether or not BRSKY
      will use DULL GRASP.
      
Suggested text:

  2) Services may need to perform neighbor discovery without 
     being able to use pre-existing security associations.
     This includes discovery of candidate ACP neighbors 
     [I-D.ietf-anima-autonomic-control-plane], discovery of bootstrap
     proxies [I-D.ietf-anima-bootstrapping-keyinfra] or for (example)
     services in networks only using GRASP without being fully autonomic
     (eg: no ACP).

     [unmodified:]
     Such usage MUST be limited to link-local operations and MUST be
     confined to a separate insecure instance of GRASP with its own copy
     of all GRASP data structures.  This instance is nicknamed DULL -
     Discovery Unsolicited Link Local.

     ...

     [modify:]
     A responder MUST silently discard any message referring to a GRASP
     Objective that is not directly part of the bootstrap creation
     process.
     [to:]
     A responder MUST silently discard and ignore any message referring to
     a GRASP Objective that is not directly part of the service(e) 
     that require this insecure discovery.

Also, to optimize / minimize signaling, i'd love to see change:
  A responder MAY send a Discovery Response message
  A responder SHOULD NOT send a Discovery Response message

FInally: i have some decades of pain optimizing this type
of fast & lightweight discovery - IGMP/MLD/PIM, so i have a lot
of opinions on the details. Let me summarize them below, and
you decide if/which of these might be useful to add (with rewording as
you like) to the GRASP spec:

     - "Announcements" in the following means LL-multicast of 1 or more
       packets needed to cover all the necessary insecure LL objectives
       that need to be announced. IMHO those "Announcements" are best
       all Flood-Synchroniation messages (Discovery messages would
       require another round of exchanges).

     - Announcements are send periodic. Good default is 30 seconds.

       Periodic announcements really only needed when connections are
       established that do not affect link-state on the neighbors
       (eg: inside a LAN, between switches etc..).

     - On link-up, announcments are sent repeated N-times to allow
       fast discovery in the presence of loss probability. N=2 is a good
       default. The periodic timer is then reset.

     - On reception of Announcements from a previously unknown 
       neighbor, we also send N-time repeated Announcements and reset
       our periodic timer.
     
     - Announcements should allow for a "Generation-ID" feature for
       each objective that indicates that the objective was restarted
       without memory of prior state. This means that any followup
       action for that objective (eg: building a connection to the
       objetive, BRSKY, ACP,..) need to be restarted. Upon change of
       Generation-ID, we also send N-time repeated Announcements and
       reset periodic timer.
     
     - To deal with link-up-flaps and other issues, there should be an
       exponential backup sending triggered announcements since
       the lasst triggered announcements (1,2,3,8,16).
     
     - Platforms often indicate link-up before packets can actually
       be send. Trigered announcements do need to send accordingly
       delayed to avoid these platform issues.


Cheers
    Toerless