Re: [Anima-bootstrap] peer and domain [was BRSKI State Machine]

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 20 October 2016 00:03 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: anima-bootstrap@ietfa.amsl.com
Delivered-To: anima-bootstrap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E57F129496 for <anima-bootstrap@ietfa.amsl.com>; Wed, 19 Oct 2016 17:03:42 -0700 (PDT)
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 JJtkqbhv-PxK for <anima-bootstrap@ietfa.amsl.com>; Wed, 19 Oct 2016 17:03:40 -0700 (PDT)
Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (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 5601A129490 for <anima-bootstrap@ietf.org>; Wed, 19 Oct 2016 17:03:39 -0700 (PDT)
Received: by mail-pf0-x22e.google.com with SMTP id s8so24313732pfj.2 for <anima-bootstrap@ietf.org>; Wed, 19 Oct 2016 17:03:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=KLFI+aTvnN+dTdMqzfFAILf+kYgrxeinMA7yYfySvhg=; b=E3LOv1VoJpddBNNAUCddBBfRCrvpXl3JWfKhGIH1eByBft4hiCXEdlqRBpvp8GsuNa /uEpre82ER31D60nXTAGErsjm5cw0tsNn6Yq3b07Q9vv2ZlvXMzt1e/pxhZeWsOWgqKD 7BmlNRoMA+uk9WNfMv7vZWlHg537YvPwTfx+KJMREurRBGyX07LAIN/f/QywbT1p+jn0 6ACd8+P5PeCbCDSsSQkf8K/TrdqLF0xQHFtdePoASSRDKVXJsE3fA24afoOQAYd8MhlP bmmEsQg0jKDQtNbL3p3rRWVUWp1C1jlvzbZLD2JOXK7IYgTWRxpYTJN2W1ugv1DtekVD KBcg==
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:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=KLFI+aTvnN+dTdMqzfFAILf+kYgrxeinMA7yYfySvhg=; b=GmOQUWM6CkTXkmpdyzK17xE4UmHnezEwOwlEN1t+lThcpLfKBBOtTuI3xk3CRVi7rc GdfbPIiWTeIWFxpAiLYWb5nmBnKj0P3hJcmUG/bxKtSTi2NORCSkrAc8Us4p/p4BMB1o srcMS4gJNFPt8kdzlGnNS/SFQk4jAQ2GaIKMBOjygaZTxjTu8X4/9estoQUZZ00ffSqN jOhnZbwgr1vY/Eo6+QcLY34ocmzVyEJDmmhj1ZWE4te9cMx1arepi2fqh+F9IkWmd5FV n6zBKh/tx6mIwy9WYjWeYbIE81nDary+eZxQN7LeUMxaTLgUh+FLQV0a6+SDkS3MYogF Xbzw==
X-Gm-Message-State: AA6/9RlfdygH7NARYG+MxyCEtJjsMWEHzOapkRd2EuQv81gwuwP0JTOuInaCbCjARCGfSg==
X-Received: by 10.98.131.71 with SMTP id h68mr15918527pfe.166.1476921818557; Wed, 19 Oct 2016 17:03:38 -0700 (PDT)
Received: from [192.168.178.23] ([118.148.125.82]) by smtp.gmail.com with ESMTPSA id q7sm66307594pfq.80.2016.10.19.17.03.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Oct 2016 17:03:37 -0700 (PDT)
To: "Max Pritikin (pritikin)" <pritikin@cisco.com>
References: <c41c231f3906477f97f1641617de025e@XCH-RCD-006.cisco.com> <6E2BF711-B34F-40E3-9543-CEB3A9BD89DC@cisco.com> <71f23615-511f-e087-dc32-a041c295de9c@gmail.com> <0EEC961F-D08D-4E35-8736-5CA7515090A2@cisco.com> <56fba332c2744d0aa5ab48189722e175@XCH-RCD-006.cisco.com> <b03f7712-269f-50bb-1dec-18d02d430340@gmail.com> <1E52CF54-52F5-40A8-98A2-1DD3BE030CC7@cisco.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <a60e82ad-3b03-fc3f-3471-5f32bf8d1398@gmail.com>
Date: Thu, 20 Oct 2016 13:03:40 +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: <1E52CF54-52F5-40A8-98A2-1DD3BE030CC7@cisco.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima-bootstrap/3L0VopjTNbn2wz5k_dqn9DtH0dw>
Cc: "anima-bootstrap@ietf.org" <anima-bootstrap@ietf.org>, "Michael Behringer \(mbehring\)" <mbehring@cisco.com>
Subject: Re: [Anima-bootstrap] peer and domain [was BRSKI State Machine]
X-BeenThere: anima-bootstrap@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list for the bootstrap design team of the ANIMA WG <anima-bootstrap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima-bootstrap>, <mailto:anima-bootstrap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima-bootstrap/>
List-Post: <mailto:anima-bootstrap@ietf.org>
List-Help: <mailto:anima-bootstrap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima-bootstrap>, <mailto:anima-bootstrap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Oct 2016 00:03:42 -0000

On 20/10/2016 09:05, Max Pritikin (pritikin) wrote:
> 
>> On Oct 19, 2016, at 1:42 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>>
>> Picking out a couple points:
>>
>>> Right now we really specify the same thing in both BRSKI and ACP drafts.
>>
>> It's a bit worse, because in practice GRASP has to do a lot of the same
>> stuff.
> 
> Isn’t this a result of not clearly defining the dependencies? If GRASP clearly depended on the ACP then some of this redundancy would go away? 

That's true, but the requirements that we're working off include being able to
operate with no ACP. If we change that, we lock GRASP in. I don't think that's
desirable.

> 
> For example, if GRASP s3.3.1 required the ACP instead of only indicating that the ACP “SHOULD” exist then a dependence on the adjacency table from ACP-03 s5.1.2 would be clear. Ref:
> 	https://tools.ietf.org/html/draft-ietf-anima-grasp-07#section-3.3.1
> 	https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-03#section-5.1.2
> 	and the core adjacency table discussion in:
> 	https://tools.ietf.org/html/draft-ietf-anima-reference-model-02#section-5
> 
> The BRSKI doc can’t reference ACP so instead I’ll update the list of adjacencies discussion to reference only the anima-reference-model (informational).

I think that's wise. We should probably add a similar reference to the adjacency
table in the GRASP spec. I've just put some text in my working copy. Basically:

if ACP is up:
    get interface & address info from the adjacency table
else:
    dig it out from the operating system yourself

   Brian

> 
> - max
> 
>> I won't trouble you with details, but the first sections of GRASP
>> initialisation carry these comments:
>>
>> # Initialise global variables
>> # Is there an ACP?
>> # What's my address?
>> # What interfaces do I have?
>> # Create sockets to send LL multicasts
>> # Initialise TCP sockets to receive unicast Discovery responses
>> # Start relay if needed
>>
>> So, although it doesn't deal with adjacencies as such, if it could
>> simply grap the adjacency table from the ACP, all of the above would
>> be much more straightforward. However, that may have things backwards.
>> If the first thing a GRASP node did after initialisation was something
>> like flood(objective("AN_ACP")) and then listen for incoming floods from
>> neighbors, it could quickly learn its potential ACP adjacencies.
>>
>> So, perhaps ACP formation is a special case ASA that runs always, in insecure
>> link-local mode, to maintain adjacencies and support the creation of
>> secure ACP tunnels.
>>
>> I could write demo code for the adjacency learning, but I'd need some help
>> on the domain ID.
>>
>>> make a separate (short) draft for autonomic adjacency discovery, and the adjacency table.
>>
>> If it's needed we can write it up. Then either embed it arbitrarily in one
>> of the other documents, or discuss it with the WG.
>>
>> Regards
>>   Brian
>>
>> On 19/10/2016 20:21, Michael Behringer (mbehring) wrote:
>>>>> What exactly is the "peer" in the above text? I tend to assume it's the
>>>> proxy.
>>>>> In that case it seems to me that the discovery process (whether it's
>>>>> mDNS or GRASP) will discover all available proxies regardless of
>>>>> domain. And then try them in some order of preference TBD.
>>>>
>>>> Agreed. From the perspective of a Pledge new device anything discovered is
>>>> a “proxy” or perhaps a registrar but it doesn’t yet know the domain(s).
>>>
>>> Mostly agree; two small edits: I would say " From the perspective of a Pledge anything discovered is a *potential* “proxy”."
>>>
>>> I would not mention the registrar, since we decided that if a device happens to be a registrar, it should still behave like a proxy, to keep the behaviour of the pledge as simple as possible. 
>>>
>>> (I'm sure we agree - these are just editorial comments)
>>>
>>>>> Also, all of this needs to work in the absence of an ACP and therefore
>>>>> of the ACP's adjacency table. That applies to GRASP too, because in
>>>>> order to perform its various link-local actions, it needs to know
>>>>> which interfaces it has and which link-local addresses it has. And it
>>>>> learns of its link-local neighbors as a result of discovery. So while
>>>>> I fully appreciate the value of the adjacency table, we need to be functional
>>>> without it.
>>>>
>>>> Michael things of discovered proxies as adjacencies for the table. I think of
>>>> them as a “list of discovered proxies”. The concepts are similar and Michael is
>>>> correct that the current sentence could be clearer.
>>>
>>> Seen from BRSKI, you are right. 
>>>
>>> My main comment really is: Adjacency discovery, as well as the adjacency table, is really independent of both BRSKI and ACP. It is a feature of an *autonomic node*. When an autonomic node is in factory default, it will use the adjacency table to invoke bootstrap; when it is in a domain, it will use the same table to create an ACP connection. So the adjacency discovery and the table are really separate from BRSKI and ACP. 
>>>
>>> Because of this, I've said for a while the really "correct" thing to do would be to make a separate (short) draft for autonomic adjacency discovery, and the adjacency table. This would be a really nice place to describe the general behaviour of an autonomic node. 
>>>
>>> Right now we really specify the same thing in both BRSKI and ACP drafts. First of all, I think we should be VERY clear that we don't want *two* mechanisms to discover a proxy or an ACP neighbour. We want a single protocol to do this. (I think we agree up to here). 
>>>
>>> The chairs have been pushing hard against another draft, for purely practical reasons, and I understand that, and can live with it. 
>>>
>>> But let's be clear that this should really be the same protocol, it should be specified in one place only, and the other refers to that. (Again, I think we agree on that). 
>>>
>>> Here's what's going to happen in phase 2 of ANIMA: 
>>> - We'll want Intent to say things like "trust autonomic devices in domain x for the sole purpose of auto-negotiating BGP security". 
>>> - or "if a node in sp.net sees one in customer.sp.net, it should create a 'unidirectional' ACP"
>>> - Therefore, a node now needs to scan its adjacency table, see where there are nodes of domain x. 
>>> - for such nodes, we'll establish another form of security association, we will NOT include them in the general ACP. 
>>> - so there will be another way to handle nodes in the table that we've ignored so far. 
>>> - This will result in another draft. 
>>> - Now, without the adjacency discovery draft, we need now to point to another "use case" draft, e.g., BRSKI for the details of adjacency discovery, and what to do in which case. 
>>>
>>> To me, we are turning cause and action the wrong way round. 
>>>
>>> Michael
>>>
>>>
>>>> - max
>>>>
>>>>>
>>>>> Rgds
>>>>>   Brian
>>>>>
>>>>>
>>>
>>
>