[Anima] ACP -10 [was Re: I-D Action: draft-ietf-anima-autonomic-control-plane-08.txt]

Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 20 September 2017 02:46 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBE12132D45; Tue, 19 Sep 2017 19:46:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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_NONE=-0.0001, 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 IG6i284AmBfg; Tue, 19 Sep 2017 19:46:26 -0700 (PDT)
Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (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 7EC8F120724; Tue, 19 Sep 2017 19:46:26 -0700 (PDT)
Received: by mail-pg0-x22d.google.com with SMTP id j16so927559pga.1; Tue, 19 Sep 2017 19:46:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=BzuPykqNQetbQgYixJX4986OVJ5YLtYu3r7m1u6DyDk=; b=ixkpb+iqsgf1KBO/QyS1GRpckZBYcn7n8YRan7b8oWcF8i01CrEdIRBKEi2qQWVAi/ KWCi3X9DOo++a3jOZiZEeKY+jJ5psr+9sgHfsyQSPh4KkF2H1zy5LIjFdqedJcjjPecY Z/PZloO84U8N0OaleisuCawGLr2RRioli+kK933SoeBkvHsyqujkWx6G01kHgj/euBil rrK4xAfQ9W8+GxzNutQCWeMuAoBadpgdE7JkGEVw9g24rlF/3ioTd6hp7j2Xn99JVqB/ C9j14d0IeNHEUfI2G297k0ZxHoRsqb4qL2SH4LSJLvejLf8u9m/OK6PcCSVVF2Bt5Zoo nn/w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=BzuPykqNQetbQgYixJX4986OVJ5YLtYu3r7m1u6DyDk=; b=VtQ/V7SSdCgYhkzAyP81hxcjrxAJ0bqnl/hy+4G9lwuilp/HKEer3audBWgguoth0W vQMB6owabr22kdImKPm9u6XNqYCXLsZDu/+yK+tr0OZ84vWLfn2VCFwLeTfzD7SP8joI g1oRJm6hO7ZTqxlYAy2a9KHgf3wkAgEiIOwwVvek4FggG/nCKU7GQpzXD/VtgnFj+aT+ j/jX8352a9yeNHtRHjTmKCmlwRV0NPIwbEZQH0ocHBbFfiVg8LVf64wgnivU3BGhQCsn RAOuAvUKb9LjWZWXO9dmIKJwIc8ILBcU4gpqDXeEWOT6uZAYYSsgTqfsGvaCOGoTpTNG s6eA==
X-Gm-Message-State: AHPjjUgtSpUtS7uK/Z7bHbO0Mf6muZd40gGJNcE16t/jxgiqwdSedick fKP1kAOguz8n5pa7bdxXAJLfAQ==
X-Google-Smtp-Source: AOwi7QBDQjsTEjjjeGqh+pIvB+uDOaLivMJR/HQ0VxhtQs4aLbVWrh+Su+iAWSToNzTFMwyQYgiXCQ==
X-Received: by 10.84.201.6 with SMTP id u6mr584690pld.289.1505875585697; Tue, 19 Sep 2017 19:46:25 -0700 (PDT)
Received: from ?IPv6:2406:e007:57a7:1:28cc:dc4c:9703:6781? ([2406:e007:57a7:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id a25sm7225635pfg.111.2017.09.19.19.46.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Sep 2017 19:46:24 -0700 (PDT)
To: Toerless Eckert <tte@cs.fau.de>
Cc: draft-ietf-anima-autonomic-control-plane@ietf.org, anima@ietf.org
References: <150044138257.25233.12391471568614147773@ietfa.amsl.com> <f5e84812-c2fa-cc16-4105-20f7791110f4@gmail.com> <20170918060429.GC31832@faui40p.informatik.uni-erlangen.de>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <7e70c270-6cf6-58b9-2ce4-d811f9cd1c87@gmail.com>
Date: Wed, 20 Sep 2017 14:46:25 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <20170918060429.GC31832@faui40p.informatik.uni-erlangen.de>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/OWPEVJQ54SnXtyO0lYiF4PLOBxs>
Subject: [Anima] ACP -10 [was Re: I-D Action: draft-ietf-anima-autonomic-control-plane-08.txt]
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Sep 2017 02:46:29 -0000

Hi Toerless,

Slight change of subject header to bring us up to date.

Thanks for all the work. I think the -10 version is much better.

No comments on the -08 to -09 revisions.

On -09 to -10 revisions:

...
>>>    5.  Inside the ACP VRF, each node sets up a virtual (loopback)
>>>        interface with its ULA IPv6 address.
>>
>> I think we have cases where a node has multiple ULAs.
> 
> Right now, an ACP would have exacty one Certificate derived ULA
> and 0 or more configured ones for autonomic-connect interfaces in case
> the operator wants to use the manual addressing sub-scheme on the autonomic
> connect interface.
> 
> What other cases are you thinking of ?

I forget but I think Michael R had a case for this. Or possibly Michael B.

...

>>>    anima.acp+<acp-address>{+<rsub>{+<extensions>}}@<domain>
>>
>> What notation is that? Is {} supposed to be an optional item?
>> If so, why not use [] as in ABNF, and cite ABNF.
> 
> acp-10: Done. Please check again. Got a lot more complex by using ABNF, but maybe more precise.

Looks OK to me, except for some surviving {} in  {+<extensions>}}

...

On the question of duplicate description of the "AN_join_registrar" objective:

> b), c) BRSKI only specifies zero touch bootstrap, but not certificate maintenance/renewal.
> 
> ACP should be modular, eg: we should be able to combine it with any initial bootstrap
> (BRSKI of course preferred and only BRSKI+ANIMA+GRASP = ANI, but netconf-zero-touch or
> other would be possible option if so desired). So we need zero-touch certificate
> (renewal, revocation) specification in ACP doc> 
> Cert renewal in ACP spec is using EST (RFC7030). Use of GRASP is specified in ACP draft
> is solely to support this EST renewal. Without GRASP to find EST-Server, we can not
> support EST-Server redundancy: YOu can specify a URL for reneal in the certificate,
> but if that URL goes down, you're lost. Without ACP/GRASP you would have had to setup some
> form of anycast domain-name or ip-address in the URL - or worse yet list multiple registrar.
> 
> The GRASP objective in BRSKI is BRSKI-TLS and is discovered by bootstrap proxies, the
> GRASP objective in ACP is EST-TLS and is discovered by encrolled ACP members for their
> own Cert renewal. Big difference.

Understood, but we can't have two standards track documents claiming to define
the same objective. If it's *different* from the one in BRSKI it needs a
different name. If it's the *same* one and you are extending its semantics,
you have to say that, and BRSKI becomes a normative reference.

The latest BRSKI draft calls it "AN_registrar" but I assume it is intended to
be the same thing. Anyway I suggest that the ACP authors and the BRSKI authors
agree on what you want. I'm very happy to help with the GRASP details but only
when it's clear what you want.
> c) Initially i thought too that RSKI would be a superset of everything that we'd need
> for certificate maintenance, but thats not the goal of BRSKI. It is only meant o specify
> initial bootstrap, but not cert renewal or the like.
> 
> a) I think to remember that MichaelR was pretty positive on the mike in Prague about
> the inclusion of EST in ACP spec for renewal. But i am sure he will chime in. 
> 
> The confusing bits may be how to use GRASP. Here is what current ACP and BRSKI text
> would lead to:
> 
> - ACP registrar without BRSKI: registrar == EST-server
>   registrar announces AN_join_registrar with only EST-TLS objective value
> 
> - ACP registrar with BRSKI: registrar == EST-server + BRSKI spec
>   registrar announces AN_join_registrar with both EST-TLS and EST-BRSKI objective values

I agree, it should work.

> 
>>>    The loop-count MUST be sete to 255.  When an ACP node
>>>    receives the M_FLOOD, it will have been reduced by the number of hops
>>>    from the EST server.
>>
>> I don't like that. The role of the loop count is loop prevention,
>> so it should be set to a reasonable upper bound on the "radius"
>> of the network. GRASP has two measures for loop detection, this
>> one and detection of duplicate session IDs, but that was
>> intentional redundancy.]
> 
> Sure, and if we set loop-count to a well-known value such as 255 then
> we do use it in the same way as IP uses TTL: Just as a way of last defense.
> Primary method is loop-free routing protocols (IP) or duplicate session ID (GRASP).
> 
> [50% rant:]
> Every new technology seems to think that TTL is a great tool, only then to
> figure out later that its only a good protection of last resort. IP unicast
> did this, and today, nobody really uses any TTL other than 255 or 1.
> IP multicast regurgitated TTL values for "TTL scoping" and it took almost
> 10 years to get rid of it, we depreciated that, and since ~2000 IP multicast
> also only uses 255 or 1 since then. IMHO: Same learning curve is necessary for GRASP.
> Maybe we will come up with good use cases for 1 < TTL < 255 still, but i doubt
> it. Unless you have very specific variations of eg: ACP for networks with
> well-knon smaller max-TTL, i do not see it.
> [/rant]
> 
> But you do not need to buy into this logic of mine. I just want to put you in the
> bind for an ability in GRASP to discover the closest instance of an objective.
> Thats i think something you agreed GRASP will support a long time ago.
> 
> If you do not like to use the fixed TTL value of 255 as a mechanism to help
> support the "closest objective announcer" mechanism, then i need to specify
> a more complex way to discover the closest objective announcer:
> 
> - objective-values for AN_join_registrar would need to be extended to be a structure like:
> 
>   objective-value = [ sender-ttl, method-list [, future-extensions]* ]
>   method-list = [ method ]*1
>   methd = BRSKI-TLS | EST-TLS | ...
>   sender-ttl = NUM
> 
>   (pretty sure i didn't get the CBOR template not right, but i am sure you get the idea)

Not only do I get the idea, I tested it out many months ago; actually after the
discussions in Berlin, I think. In my Pythonic world it was very easy, but it is
indeed a bit more complicated than the 255-N method.

> 
> That way, the recipient can compare sender-ttl with the TTL of the received objective
> and threeby figue out which one is closest.
> 
> I fine either way. I just tried to go for the most simple, logical option.

Right, so the question for the WG (are you all listening?) is whether we
want to defend the value of the loop count in limiting propagation of multicast
messages. (Remember that it has another role in negotiation sessions, where
it really is a loop-prevention counter.)

I will note that in testing on looped topologies I have seen looped multicasts
dropped because of the session ID; theoretically that is sufficient, and the
loop count is logically redundant.

Otherwise, me happy.

Thanks again for all the work,

    Brian