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

[Brian E Carpenter <[e-mail]>]

Hi,

It took me a while to look carefully at the message below, sorry.

I believe it's fundamentally correct and also pretty much editorial and/or
clarification, so the draft slides on GRASP status that I sent to Bing do not
mention these points at all. I'm sure we'll need another rev of the draft after
Seoul, so they can be added in then.

I think the implementation remarks at the end perhaps belong in wherever we
end up formally defining the GRASP objectives for the ANI itself. They all
make sense but can be enforced outside the GRASP kernel.

Regards
   Brian

On 04/11/2016 11:10, Toerless Eckert wrote:
> 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
>