[Anima-signaling] On Joel's and Charlie's comments on draft-ietf-anima-grasp-10
Brian E Carpenter <brian.e.carpenter@gmail.com> Sun, 05 March 2017 02:40 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 62804129415 for <anima-signaling@ietfa.amsl.com>; Sat, 4 Mar 2017 18:40:12 -0800 (PST)
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 XIWoD4QFo4H1 for <anima-signaling@ietfa.amsl.com>; Sat, 4 Mar 2017 18:40:11 -0800 (PST)
Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::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 E5AFE12940E for <anima-signaling@ietf.org>; Sat, 4 Mar 2017 18:40:10 -0800 (PST)
Received: by mail-pg0-x22a.google.com with SMTP id b129so55579643pgc.2 for <anima-signaling@ietf.org>; Sat, 04 Mar 2017 18:40:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:organization:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=jKFFF13yLoPaH8xcVfGgTP/0NvnBzX9w2wdX7bGPO9g=; b=YXGbBfQ47rD7RnLY8BSHHPVjD4Ds67MezI+bK0TVHpYGRZ9NHkp+wXkLyhZRgknMD3 YuGfp0R8dfHAb07IIXktXO1DeICUet7GimvDuI+lwZAMNUXEC987rSv7uyRy0qfkE45c r8kjl9DsC42B/1hRg43k+MKqPwQG6YC7/1KqtJln9U6bW9fpOIrqrtXi2of3xqhzXbTM NEOo/VmqMxfhff2XhY11sGyOrbaAGcXWfrMnzdsdmPyde58+xN08bILJzhn/gEZwjV+w g9NKpBPNdLuIUeQjWnE4gG6d7JODnclVuDiiB1bbnNVrjtWWvZAgKNRy9jvG0bmUxXvp IiQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:organization:message-id:date :user-agent:mime-version:content-transfer-encoding; bh=jKFFF13yLoPaH8xcVfGgTP/0NvnBzX9w2wdX7bGPO9g=; b=aDVLck/9JhNP40mpkOdFA8bHrgs9coVrTbpDcvXGmrBdon4AQmgJy6D6iIog1hQGKO eVcAZOERPU3NC7e8dgnTRlqQMwK3Kqgn6SVZT+pQYao7ANg0U88OjvqJ/jq+YCh05A4b kF/UGFkCHzuBw/5t6ERLYhMexb/aO/AShx1ZOCSkXleSf6CQbiVP45EJIxEndAVkUIR1 JWiK4GqBUEHx0M3ahNlFU909Rf8Tr1C5jN7mfyORUjL+vhc7Wzzrk36jvSdNOscAHoTH Xeav1ciOpttTlyBqrntFFIqZ1cHOlIjcMgNZzSPUGQ1Nwt4gJ9al2FdyDL7s6nwAme2a x9eg==
X-Gm-Message-State: AMke39mGvl3ztbytQ1UksBVnJuHvUuHAK34DmYvkeIEwLC7ksUzvRBQAXXlUCzTqUMmJFw==
X-Received: by 10.84.230.129 with SMTP id e1mr15674161plk.66.1488681610404; Sat, 04 Mar 2017 18:40:10 -0800 (PST)
Received: from ?IPv6:2406:e007:7204:1:28cc:dc4c:9703:6781? ([2406:e007:7204:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id y67sm31337534pfa.96.2017.03.04.18.40.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 Mar 2017 18:40:09 -0800 (PST)
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
To: Anima signaling DT <anima-signaling@ietf.org>, Charlie Perkins <charles.perkins@earthlink.net>, "Joel M. Halpern" <jmh@joelhalpern.com>
Organization: University of Auckland
Message-ID: <777c00b6-3a91-bf6a-6f36-07c0bed2c63b@gmail.com>
Date: Sun, 05 Mar 2017 15:40:06 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima-signaling/LHuuyBp4f56qxSeNNvGlyLxfJos>
Subject: [Anima-signaling] On Joel's and Charlie's comments on draft-ietf-anima-grasp-10
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: Sun, 05 Mar 2017 02:40:12 -0000
I believe that the -10A draft also resolves the following points that are a bit more than nits and simple clarifications. But I don't think I need to raise them as issues for the whole WG at the present time: - Characterization of routing protocols [Joel Halpern] "Section 2.2 states that routing protocols mainly consider link up/down and that "all nodes need a consistent view of the network topology". the first seems an over-generalization, ... The following sentence about information not normally used also seems to be at odds with current practice." Proposed resolution: Update this text accordingly. - Text on circular dependencies [Joel Halpern] "Bullet 1 under SN7 in section 2.2 talks about the potential for circular dependence, and then says that this protocol will not provide any assistance for that... If a single negotiation causes two dependent negotiations, this would seem to have the potential to cause a work explosion." Correct, this is an issue with ASA design. But distributed negotiation algorithms and distributed consensus algorithms are a field of study in their own right. Proposed resolution: We should be more explicit that this is a complex issue that is simply not handled by the GRASP layer and that must be considered by ASA designers. All the following issues are from Charlie: - Text on multiple instances in section 3.2 and 3.3 " An autonomic node will normally run a single instance of GRASP, used by multiple ASAs. However, scenarios where multiple instances of GRASP run in a single node, perhaps with different security properties, are not excluded. In this case, each instance MUST listen independently for GRASP link-local multicasts in order for discovery and flooding to work correctly. CEP: Better: should specify that each instance is activated by reception of a single link-local multicast." Every instance needs to receive all GRASP multicasts, so the original statement is correct. However, it does no harm to add that all must be woken by each multicast. (It's automatic as long as you set SOL_SOCKET,SO_REUSEADDR in each process before IPPROTO_IPV6,IPV6_JOIN_GROUP.) "Even better: specify that each instance should have its own IP address, and all addresses belong to the same link-local multicast group." The sender of the multicast has no prior knowledge of the separate instances. As far as Flood and Discover goes, they are all treated the same, so they can all listen on a single address. " o It is normally expected that a single main instance of GRASP will exist in an autonomic node, and that the protocol engine and each ASA will run as independent asynchronous processes. However, separate GRASP instances may exist for security-related reasons (Section 3.5.2). CEP: Why does the number of instances of GRASP matter for this document??" Because the secure bootstrap document will rely on this feature. Proposed resolution: Clarify the text, and remove some repetition.. - LL multicast security "3.5.1. Required External Security Mechanism The protocol SHOULD always run within a secure Autonomic Control Plane (ACP) [I-D.ietf-anima-autonomic-control-plane]. The ACP is assumed to carry all messages securely, including link-local multicast if possible. CEP: The clauses of the preceding sentence seem contradictory." The ACP designers have assured us that with the ACP implemented as a VFR instance, LL multicast will be secured. But indeed this will not apply to the insecure GRASP instances mentioned in the following section. Proposed resolution: s/if possible/when it is virtualized over the ACP/ - Relay interfaces "3.5.4.4. Discovery Relaying A GRASP instance with multiple link-layer interfaces (typically running in a router) MUST support discovery on all interfaces. We refer to this as a 'relaying instance'. CEP: This seems to be a mistake. Why shouldn't a device be allowed to have non-participating interfaces?" Correct, a *device* could have non-participating interfaces. So we are referring to interfaces used by the GRASP instance, not the device as a whole. Proposed resolution: State that by 'interfaces' we mean those in use for GRASP, not all physical interfaces. That applies generally, not just here. - Discovery replies "The relayed discovery message MUST have the same Session ID as the incoming discovery message and MUST be tagged with the IP address of its original initiator (see Section 3.8.4). Note that this initiator address is only used to allow for disambiguation of the Session ID and is never used to address Response packets. CEP: But, section 3.8.5. Discovery Response Message has: > It is sent to the sender of the Discovery message via TCP at the port > used to send the Discovery message (as explained in Section 3.8.4). Wouldn't this allow the Response to be sent to the initiator?" The text is unclear. Relaying a discovery breaks the chain; the relay is acting as a proxy, when I think about it. So the relayed discovery message is sourced from an {address,port} that is specific to the relay. It might even be a link-local address, if for some reason there is no global unicast address in place. Proposed resolution: Clarify the text (that will also cover Charlie's other comments on the same subsection). - Flood relays "3.5.6.1. Flooding ... A GRASP device with multiple link-layer interfaces (typically a router) MUST support synchronization flooding on all interfaces. If it receives a multicast Flood Synchronization message on a given interface, it MUST relay it by re-issuing a Flood Synchronization message on its other interfaces. The relayed message MUST have the same Session ID as the incoming message and MUST be tagged with the IP address of its original initiator. CEP: I am pretty sure this is a mistake." [Clarification: this refers to the phrase 'all interfaces', to be fixed as above.] Proposed resolution: see "3.5.4.4. Discovery Relaying" above. "3.8.13. No Operation Message In fragmentary CDDL, a No Operation message follows the pattern: noop-message = [M_NOOP] This message MAY be sent by an implementation that for practical reasons needs to activate a socket. It MUST be silently ignored by a recipient. CEP: ?? what does it mean to "activate" a socket? Is there something about how long a socket may remain open but not used?" Not that I know of. But I discovered that to find out the port number assigned to a socket, you pretty much have to perform sendto() and getsockname(), so the ability to send a no-op during initialisation seemed reasonable. I could have just sent a zero, but a well-defined message seemed better. Proposed resolution: s/activate/initialize/ - Addressing realms "3.9.5. Locator Options ... Note: It is assumed that all locators are in scope throughout the GRASP domain. GRASP is not intended to work across disjoint addressing or naming realms. CEP: It's hard to imagine the practical effect of making this statement." This is where we point someone who says "NAT breaks my GRASP". Proposed resolution: No change. - Loop-count "The 'loop-count' field is used for terminating negotiation as described in Section 3.8.7. It is also used for terminating discovery as described in Section 3.5.4, and for terminating flooding as described in Section 3.5.6.1. CEP: It would be much more intuitive to put "loop-count" in the message format." >From the protocol designer's view, perhaps. But the application programmer should think in terms of objectives, and the natural place for the ASA to set or read the loop count is in the objective. Proposed resolution: No change. - Null objective value "3.10.3. General Considerations for Objective Options ... If there is no initial value, the bits in the value field SHOULD all be set to indicate a meaningless value, unless this is inappropriate for the specific negotiation objective. CEP: Maybe better to require such objective descriptions to mandate a particular O_INVALID_VALUE, whenever needed." Actually it seems that we should simply specify CBOR's 'null' value ('None' for Python addicts). No need to reinvent the wheel. Proposed resolution: specify 'null'. - Dry run flaw? "CEP: Dry Run has a significant flaw. Namely, it appears to be stateless, so that subsequent simulation steps would not be acting in the stateful environment that a true negotiation (or true simulation) would be." Whether it's stateless is an implementation issue in the ASAs that support it. That does indeed require discussion, but probably in another draft: draft-carpenter-anima-asa-guidelines Proposed resolution: add a health warning here, discuss the issue elsewhere. (ends)
- [Anima-signaling] On Joel's and Charlie's comment… Brian E Carpenter