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

Toerless Eckert <tte+ietf@cs.fau.de> Thu, 03 November 2016 22:11 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: anima-signaling@ietfa.amsl.com
Delivered-To: anima-signaling@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id EDE4A129888; Thu, 3 Nov 2016 15:11:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.696
X-Spam-Status: No, score=-5.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id c61SFI2zZ-qp; Thu, 3 Nov 2016 15:10:59 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D00412986E; Thu, 3 Nov 2016 15:10:56 -0700 (PDT)
Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de []) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id CFEC158C4AF; Thu, 3 Nov 2016 23:10:54 +0100 (CET)
Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id B277BB0AD20; Thu, 3 Nov 2016 23:10:54 +0100 (CET)
Date: Thu, 3 Nov 2016 23:10:54 +0100
From: Toerless Eckert <tte+ietf@cs.fau.de>
To: brian.e.carpenter@gmail.com, draft-ietf-anima-grasp@ietf.org, anima-signaling@ietf.org
Message-ID: <20161103221054.GC6498@faui40p.informatik.uni-erlangen.de>
References: <20161031221855.GA1970@faui40p.informatik.uni-erlangen.de> <18011.1478097279@obiwan.sandelman.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <18011.1478097279@obiwan.sandelman.ca>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima-signaling/KyPI7tvxuAt-ehxHZ4yiEMB-qeg>
Subject: [Anima-signaling] draft-ietf-anima-grasp-08: DULL comments discovery be performed over TCP?)
X-BeenThere: anima-signaling@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list for the signaling design team of the ANIMA WG <anima-signaling.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima-signaling>, <mailto:anima-signaling-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima-signaling/>
List-Post: <mailto:anima-signaling@ietf.org>
List-Help: <mailto:anima-signaling-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima-signaling>, <mailto:anima-signaling-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Nov 2016 22:11:02 -0000


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).

     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.


     A responder MUST silently discard any message referring to a GRASP
     Objective that is not directly part of the bootstrap creation
     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.