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

Brian E Carpenter <> Thu, 10 November 2016 03:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E0E5512984C; Wed, 9 Nov 2016 19:32:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FNiea889b9lO; Wed, 9 Nov 2016 19:32:23 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E9A1E12997D; Wed, 9 Nov 2016 19:32:21 -0800 (PST)
Received: by with SMTP id 189so138203136pfz.3; Wed, 09 Nov 2016 19:32:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=3zlBiypOgjJbwFDH7387AKMXb6Mvsd/Ef7/hYPZWehg=; b=tdS6HUPflPvaHSUoVJvs/SoJilBNmyag9PnuYJfwmhAY8V8nFtuN9Pah2fspYk1lLV ljBFRdaje79ury+GiSfZZ1JoiIy60LvFlhTHp2X2iz21B88DMAipzbiEt9MCD+tLxqjt OoCh8nr6WP3X4XHvlbY7w3fhFgzMwt2TO5jRk8s2hCjxcx2WgBdlvzfJ0anEH3B7fSZz yIY7SFvTdiOLAbUEkFtc804Y1avj+gzJ9LlD5umgxMb3UMRAuSsp/IcJFuqKbAdXIYMB TVq1mNKx7dFdXR4RopWD+pskU1HHkkPjbVnGfHE4GqdQj2M9E0NFGC2bDudI3ux83KBZ j3Xg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=3zlBiypOgjJbwFDH7387AKMXb6Mvsd/Ef7/hYPZWehg=; b=d6WcO+6pEeifcHG929+S7VwoICOalFnM/jwVvhul5bCXUQu3O5e/ZecyRruoQPJ9XG qmPXX9tyPrIfcPGrxS35Q40D0fDj7c28SNpHTx4g4fgy7Trdoz9pQhp5dXT3aVR7sw2+ G+FXuHP9mahIvqm35I2/b+1GkC2EVltkFK39qP8d7wmneK3KZK79yeXQb6AZkkbYAjGk /syPV2mkxvHzXoY8s+QHRfQdn5XwQCnX01Itv0VYRkuAMagkDHel7n7JnJsUiE5uw5d+ aVScbqbXqLXVobwDz+owlV/lNeBzFe1LC/hpBcnsHo0awT0ZYmec0dEOu/HV67QSN1AM NE3Q==
X-Gm-Message-State: ABUngvffb3dPwvqcIYAeobH05rw5brlEytNfktneM/aCfjh4eonfOpJVdscEQAJQAXM28g==
X-Received: by with SMTP id u191mr20157835pgd.28.1478748741515; Wed, 09 Nov 2016 19:32:21 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id g10sm2514595pac.14.2016. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Nov 2016 19:32:20 -0800 (PST)
To: Toerless Eckert <>,,
References: <> <> <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Thu, 10 Nov 2016 16:32:20 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Anima-signaling] draft-ietf-anima-grasp-08: DULL comments discovery be performed over TCP?)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list for the signaling design team of the ANIMA WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 10 Nov 2016 03:32:25 -0000


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.


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