[Anima-signaling] 2 day last call on SONN constrained instance

Brian E Carpenter <brian.e.carpenter@gmail.com> Mon, 12 December 2016 19:08 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: anima-signaling@ietfa.amsl.com
Delivered-To: anima-signaling@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8689B129704 for <anima-signaling@ietfa.amsl.com>; Mon, 12 Dec 2016 11:08:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fsu1q-bDX6OF for <anima-signaling@ietfa.amsl.com>; Mon, 12 Dec 2016 11:08:39 -0800 (PST)
Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A79CF1296C7 for <anima-signaling@ietf.org>; Mon, 12 Dec 2016 11:08:39 -0800 (PST)
Received: by mail-pf0-x232.google.com with SMTP id 189so13956489pfz.3 for <anima-signaling@ietf.org>; Mon, 12 Dec 2016 11:08:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=ChvcVWweEdFYLfoeFNftJE4StRsG43ab54j/+VWBbBY=; b=aAiXzUlZ/+KDDosOGSmGjIX40qRVtK6cVeqFp80DLRtq+cyvXCTz3T+rjb3yMkHM1O wV3a5wvreQtOd5PosaZCukzSe2X9Jn1pHV8FR0E2ZOqhVSoYQkm+LTqo+NYSdWNdqp2k /jbeDGjMrD5XWtoMGezR69SwiJ1Mv5+nyL/E5y7pczwjAhzuoOxcVyW/870RVUOmtjsq rJHLSkSp1/IPH7xFIJBjqLqMtTHWnhxyptDzK+1KsxYS+RRhBXf1kfblQqE5X1Deuryo CpPLOfpxb1ZRzYNAV8d/qX9zr10n+dzCS6v7qagbOAKC62rrDXGS/lSBpE3IFZkgBpt2 BtmA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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=ChvcVWweEdFYLfoeFNftJE4StRsG43ab54j/+VWBbBY=; b=SLL4fckK5KEA7FNs75w12GKs0StiIaopr04LVGk2GFEBmKr8YGJIgUKwKXV5t/Ea3V whiNEjOoBPkbzFXr0JAN5cxSiB7yay+LlGx12Nde+NRr3nfX0fdXTsISIqF+g3w4IgCT 2MjtODi/ENFbKVsVyoJHz9f3z8TUShyO283VGKtnDwLa4tt+CL4W799B6O9fThyNXrEO n8o9pglabLkd6Fr3wzArCtHkhDuWNzLykjgL+eloeq8XNWYmMryivkv0la61s4RW5Ujb WAMv5S2SDn7sjm4pGSbRQjL3aOPYbFMoKdmajrUyvdWhjeIyOMDx9QV7yeUYFH9Ve1QW wXRw==
X-Gm-Message-State: AKaTC03x6FANRlnU/Q2yuxgQudEcX3e2AV1MIPIQi1kYM13XXFLQ5/UbqJz3hzu/SqlY5w==
X-Received: by 10.99.170.79 with SMTP id x15mr169082222pgo.14.1481569718976; Mon, 12 Dec 2016 11:08:38 -0800 (PST)
Received: from ?IPv6:2406:e007:6fd6:1:28cc:dc4c:9703:6781? ([2406:e007:6fd6:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id x90sm77290713pfk.73.2016.12.12.11.08.37 for <anima-signaling@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Dec 2016 11:08:38 -0800 (PST)
To: Anima signaling DT <anima-signaling@ietf.org>
References: <d394fc61-edb7-eb3c-85fb-cd7c10fb2927@gmail.com> <2658.1480552478@obiwan.sandelman.ca> <d76de5d2-cf9f-09ef-653f-098d4c0a3ca0@gmail.com> <243c1ad6-47c4-9b19-1606-551a24fb0d8d@gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <b51e454e-da3f-64a9-8317-47ebffdb3791@gmail.com>
Date: Tue, 13 Dec 2016 08:08:39 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <243c1ad6-47c4-9b19-1606-551a24fb0d8d@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima-signaling/Vuxjr6guTb-Sgfo7Ioz4jDoqOMY>
Subject: [Anima-signaling] 2 day last call on SONN constrained instance
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: Mon, 12 Dec 2016 19:08:41 -0000

Hi,

We need to move ahead with the GRASP draft. Therefore, I have reworked the
text in a way that doesn't remove the SONN description but does not make
it a requirement either. Please comment on the new version of the whole
section that follows. I'm going to take silence as consent 48 hours from now.

Regards
   Brian

3.5.2.  Constrained Instances

   This section describes some examples of cases where additional
   instances of GRASP subject to certain constraints are appropriate.

3.5.2.1.  No ACP

   As mentioned in Section 3.3, some GRASP operations might be performed
   across an administrative domain boundary by mutual agreement, without
   the benefit of an ACP.  Such operations MUST be confined to a
   separate instance of GRASP with its own copy of all GRASP data
   structures.  Messages MUST be authenticated and SHOULD be encrypted.
   TLS [RFC5246] and DTLS [RFC6347] based on a Public Key Infrastructure
   (PKI) [RFC5280] are RECOMMENDED for this purpose.  Further details
   are out of scope for this document.

3.5.2.2.  Discovery Unsolicited Link-Local

   Some services may need to use insecure GRASP discovery, response and
   flood messages without being able to use pre-existing security
   associations.  Such operations being intrinsically insecure, they
   need to be confined to link-local use to minimise the risk of
   malicious actions.  Possible examples include discovery of candidate
   ACP neighbors [I-D.ietf-anima-autonomic-control-plane], discovery of
   bootstrap proxies [I-D.ietf-anima-bootstrapping-keyinfra] or perhaps
   initialisation services in networks using GRASP without being fully
   autonomic (e.g., 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.

   The detailed rules for the DULL instance of GRASP are as follows:

   o  An initiator MUST only send Discovery or Flood Synchronization
      link-local multicast messages with a loop count of 1.  A responder
      SHOULD NOT send a Discovery Response message unless it cannot be
      avoided.  Other GRASP message types MUST NOT be sent.

   o  A responder MUST silently discard any message whose loop count is
      not 1.

   o  A responder MUST silently discard any message referring to a GRASP
      Objective that is not directly part of a service that requires
      this insecure mode.

   o  A responder MUST NOT relay any multicast messages.

   o  A Discovery Response MUST indicate a link-local address.

   o  A Discovery Response MUST NOT include a Divert option.

   o  A node MUST silently discard any message whose source address is
      not link-local.

   GRASP traffic SHOULD be minimized by using only Flood Synchronization
   to announce objectives and their associated locators, rather than by
   using Discovery and Response.  Further details are out of scope for
   this document

3.5.2.3.  Secure Only Neighbor Negotiation

   Some services might use insecure on-link operations as in DULL, but
   also use unicast synchronization or negotiation operations protected
   by TLS.  A separate instance of GRASP is used, with its own copy of
   all GRASP data structures.  This instance is nicknamed SONN - Secure
   Only Neighbor Negotiation.

   The detailed rules for the SONN instance of GRASP are as follows:

   o  Any type of GRASP message MAY be sent.

   o  An initiator MUST send any Discovery or Flood Synchronization
      link-local multicast messages with a loop count of 1.

   o  A responder MUST silently discard any Discovery or Flood
      Synchronization message whose loop count is not 1.

   o  A responder MUST silently discard any message referring to a GRASP
      Objective that is not directly part of the service concerned.

   o  A responder MUST NOT relay any multicast messages.

   o  A Discovery Response MUST indicate a link-local address.

   o  A Discovery Response MUST NOT include a Divert option.

   o  A node MUST silently discard any message whose source address is
      not link-local.

   Further details, including TLS and PKI usage, are out of scope for
   this document.

--