[Anima-signaling] Remove SONN constrained instance?

Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 07 December 2016 03:57 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 9A67D129643 for <anima-signaling@ietfa.amsl.com>; Tue, 6 Dec 2016 19:57:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id RGLieY2J63cT for <anima-signaling@ietfa.amsl.com>; Tue, 6 Dec 2016 19:57:53 -0800 (PST)
Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (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 D3CDD129604 for <anima-signaling@ietf.org>; Tue, 6 Dec 2016 19:57:53 -0800 (PST)
Received: by mail-pf0-x22a.google.com with SMTP id c4so74438829pfb.1 for <anima-signaling@ietf.org>; Tue, 06 Dec 2016 19:57:53 -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=7ULtaYz6HIHxVhK4o55QDj7xW6AlJdAMAN+su1JHuQE=; b=efpf2RFkny7KHf+UbPYZP/ShaAAMYvlhHPr4xmH6hB/0JN2tb5PSm51zSGA3J9BpMs w8/ltefyZyapbL9klHvsxEujdKG8tin1ocz2DskeXWGgL783eRq2lXz+ueO1QsQq1ski BgABKjbBEUaD44S6yfGvUE2ZPff54GK7aO0YPKmttGLYPQplKu26FTb3gXE9SBZhSdBz fzGWZZHnHcTe9o5N9+utHcNe012OfJr1Q/x7kpTeuVTWMtF1dvG3vQCZunktKCJRv8TP Wiy5vpN8t/pNCT8FF8joUgco7J4zmSseIsZbqZddGG1u38glDzTIyV9Z8Bh6lTudG6is v0eQ==
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=7ULtaYz6HIHxVhK4o55QDj7xW6AlJdAMAN+su1JHuQE=; b=U+Sz+l7LA2Mg/7G/gSwijruH7AtKvV3vAMxgALQQGZTOQcx8yMxs+tJyEQ4ORlPL4r Z9W9EdErl3FrgPeTlR4nB/MjyuDWIhtEWu9YQFN4aCm17A5iheptoIZAPcSwex3mOksM r6OIVN4j23TrAeJf7Ci4ecoMDTqz4GSPPqwiQej49SUiIdriGKRBrb+Uiu6BAiIFWInI cSyemOYFEN20aYj6cLmJ5UVAHCqMMF32PhS3OZ5INB+Qhw95K+2bwI/ANWh8S1cDt9Tb 0XRGur7SfXVk8xbbMv4FCHuOcoNQD7S17sMsSPpCq75fLg8f8i8N/JNINu+qe/L3MNXV qqUw==
X-Gm-Message-State: AKaTC03stqtqyV4F8DyW6X+q32ddLcKZp15z3QmhvY16kYKGYNfb4UBPqqCo2sRMko/Pxw==
X-Received: by with SMTP id b5mr143213574ple.49.1481083073217; Tue, 06 Dec 2016 19:57:53 -0800 (PST)
Received: from ?IPv6:2406:e007:4ba7:1:28cc:dc4c:9703:6781? ([2406:e007:4ba7:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id m19sm38033423pfi.24.2016. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Dec 2016 19:57:52 -0800 (PST)
To: Michael Richardson <mcr+ietf@sandelman.ca>, 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>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <243c1ad6-47c4-9b19-1606-551a24fb0d8d@gmail.com>
Date: Wed, 7 Dec 2016 16:57:53 +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: <d76de5d2-cf9f-09ef-653f-098d4c0a3ca0@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima-signaling/SIJYHohvKxntBXljpLCIKqMMlxQ>
Subject: [Anima-signaling] Remove 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: Wed, 07 Dec 2016 03:57:55 -0000

OK, I've been working on the other issues that I'm aware of
(including adding the dry-run flag - easy - and changing Flood
to associate a locator with each objective - very easy in the draft,
quite a lot of work in the prototype). So unless Michael's re-review
comes up with more, SONN is now the only open issue.

I looked at the text again just now and it's a fairly simple question:
If ACP formation can just use Flood as an announcment for ACP neighbors
to find each other and start IKEv2, I agree that we don't need SONN.

I'm also not at all clear how SONN would work. The text says it
will use TLS but I'm unclear where the certs would come from.

But you ACP folks have to chime in. Please. I'd really like us to
put a new version out to the WG very soon, otherwise we get into the


On 01/12/2016 15:33, Brian E Carpenter wrote:
> On 01/12/2016 13:34, Michael Richardson wrote:
>> Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>>     > 61.  Is the SONN constrained instance really needed?
>>     > My personal inclination is to say "yes" to #59, #61 and #62.
> (BTW, I meant #60 there.)
>>     > We really need Michael R & Toerless to reach an agreement about #61.
>> I think that I said we didn't need it.
> You did. But Toerless proposed it, so we need his opinion.
>> That all we need is to become aware of the neighbours (which insecure DULL
>> can do with M_FLOOD), and that all the security is best done by IKEv2.
>> (And IKEv2, even if MacSEC is negotiated rather than IPsec)
>> The ACP-04 document imagines a protocol that isn't IKEv2 using some
>> unspecified encapsulation over (d)TLS transporting IP packets, and negotiated
>> using GRASP.  This hardly has any existing specification (one in tsvwg right
>> now), and has no hardware support anywhere.  It's not our place in this WG
>> to create new security protocols.
> Yes, all I would expect to see negotiated over GRASP would be *which* security
> mechanism to use; that's what is assumed in
> https://tools.ietf.org/html/draft-carpenter-anima-ani-objectives-00#section-3.2
> I have no skin in the game though; I'm quite happy with
> https://tools.ietf.org/html/draft-carpenter-anima-ani-objectives-00#section-3.1
> Toerless?
> Rgds
>    Brian