[Anima] IPIP in draft-ietf-anima-bootstrapping-keyinfra-07

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 04 July 2017 05:32 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 30EDB124D68 for <anima@ietfa.amsl.com>; Mon, 3 Jul 2017 22:32:11 -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 4tWf5xArg86c for <anima@ietfa.amsl.com>; Mon, 3 Jul 2017 22:32:09 -0700 (PDT)
Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::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 ED2351200C5 for <anima@ietf.org>; Mon, 3 Jul 2017 22:32:08 -0700 (PDT)
Received: by mail-pg0-x232.google.com with SMTP id j186so104654440pge.2 for <anima@ietf.org>; Mon, 03 Jul 2017 22:32:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:organization:to:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=B0wmXtDkyQ0EpJIvFtYXNG4yxyHeI9OKoFJCubL0KVs=; b=fTGG/p2O0ntb230pFxwI/XIHuleU4SQ+XmovOb6cb1lSXpOb1yeURHfMYKwg38y2bV b247diU7IiUr3QdSWbKQu9/AT/DeYdk/cupbS+NY2pJcncx5pbZpsu4H9OULGgDf3YmF BaSqbaCx5YmJSHcS7F25gT9Xjy16bJCWswE7Sr8xqxJk5eNXGZUtlKcEG2Xm/SRSddEN rQHHVJ4r57+7mcO23q6SvIHARhBJM/AtDTHiCFwwTdtcYIfzZ6y0tNtNIolXnZRwWIhE I3prQVIZIkgrIQHfDMuPKPWKjRHS88I1h4FyQMzO/DDAUIHt7V2EXoUO16n06/Xuqkhi YNYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:organization:to:subject:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=B0wmXtDkyQ0EpJIvFtYXNG4yxyHeI9OKoFJCubL0KVs=; b=Ofgka+lY6DL75Sy5+iEP1RI43a+QA8N8C2v8eSQEW+L8zJBipluVHLDesWrnWgA3S7 4JueU6IOn5u4u5BINll/zVOOC3jSzWa7JI68GSGNaqtUwB6x+yk2afI7EhYa3SSwyLHo vcpGcBZ0ms/zgQooRE2CD+2RdaWC9lm4ZCq0DovCu/FaWzopXlq++hrzQLMs81e3EVnI m0+KDlheoTw+THSiqEHxbMtAvxNQqWPXT6zEPJg9ZkvwRLzrtACSqkHeUR05sJ2V33fG 1ys+V4mm2rfEaUamqkwjX/K0+KC7M/uvdnLSIO8VdA2hXEdREJVYn9tpMLPJxirvjoFX FTfA==
X-Gm-Message-State: AIVw112rkqj26JFmdmawMrMXWdpBnBjvuQ6g+2zssXCKSNXKPl1EyCpq 1qByNnr+L4F//ep1
X-Received: by 10.84.241.4 with SMTP id a4mr14590101pll.160.1499146328368; Mon, 03 Jul 2017 22:32:08 -0700 (PDT)
Received: from ?IPv6:2406:e007:4f03:1:28cc:dc4c:9703:6781? ([2406:e007:4f03:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id o8sm32172683pgn.52.2017.07.03.22.32.06 for <anima@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Jul 2017 22:32:07 -0700 (PDT)
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
To: Anima WG <anima@ietf.org>
Message-ID: <a933b9fc-bc89-f86d-c87a-ac6d5c453724@gmail.com>
Date: Tue, 04 Jul 2017 17:32:06 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/HLzdV63-vJwJCuMS5r7T1v68hXE>
Subject: [Anima] IPIP in draft-ietf-anima-bootstrapping-keyinfra-07
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: Tue, 04 Jul 2017 05:32:11 -0000

Hi,

I am still trying to figure out what you really want to say in sections 3.1.1. Proxy Discovery Protocol Details and 3.1.2. Registrar Discovery Protocol Details.

1. Why doesn't section 3.1.1 mention IP-in-IP (protocol 41)? Surely the pledge needs to know about it?

2. The description is wrong anyway; see https://tools.ietf.org/html/draft-carpenter-anima-ani-objectives-02#section-2.3 for something that can work.

3. In section 3.1.2, as I already pointed out, the proposal is really a misuse of the GRASP discovery response message. Not a problem, we simply replace it with a synchronization response; see https://tools.ietf.org/html/draft-carpenter-anima-ani-objectives-02#section-2.2. 
But regardless of that, I am confused by the example locators:
    locator1  = [O_IPv6_LOCATOR, fd45:1345::6789, 6,  443]
    locator2  = [O_IPv6_LOCATOR, fd45:1345::6789, 17, 5683]
    locator3  = [O_IPv6_LOCATOR, fe80::1234, 41, nil]

The first two are OK. The ports announced by the proxy to the pledges may be different. If the registrar sends  [O_IPv6_LOCATOR, fd45:1345::6789, 6,  443], the proxy might announce [O_IPv6_LOCATOR, fe80::4321, 6, 9999] - the proxy's link-local address and a different port chosen by the proxy.

But the third locator sent by the Registrar indicates a meaningless link-local address, because it could come from many hops away. At first I thought this was a confusion with the previous (proxy-to-pledge) case, where all addresses must be link-local. But no: this text is just confused, I think:

   A protocol of 41 indicates that packets may be IPIP proxy'ed.  In the
   case of that IPIP proxying is used, then the provided link-local
   address MUST be advertised on the local link using proxy neighbour
   discovery.  The Join Proxy MAY limit forwarded traffic to the
   protocol (6 and 17) and port numbers indicated by locator1 and
   locator2.  The address to which the IPIP traffic should be sent is
   the initiator address (an ACP address of the Registrar), not the
   address given in the locator.

A link local address provided by the Registrar is completely invalid except on the relevant link connected directly to the Registrar. So it definitely must not be given to anybody off that link. At the moment I have no idea how the IP-in-IP is supposed to work. Appendix C doesn't help much. Apart from anything else, it mentions a non-existent GRASP message type. I can sort of see what you want to do, but it isn't a codable spec at the moment.

Maybe you can provide a complete example of the packet flow, where the pledge has link-local address Lp, the proxy has link-local address Lx and ACP address Ax, and the registrar has ACP address Ar. And to make my concern clear, the registrar has the link-local address Lp, by chance the same as the pledge, although on a different LAN.

Regards
   Brian