Telechat Review of draft-ietf-anima-grasp-11
review-ietf-anima-grasp-11-tsvart-telechat-stiemerling-2017-05-23-00
review-ietf-anima-grasp-11-tsvart-telechat-stiemerling-2017-05-23-00
Hi all, Please find below my review of draft-ietf-anima-grasp-11. The comments below are about -11 of the draft, as I did work on this version and did unfortunately not have time to go through -12. I've reviewed this document as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. When done at the time of IETF Last Call, the authors should consider this review together with any other last-call comments they receive. Please always CC tsv-art@… if you reply to or forward this review. Summary: This draft has serious issues, described in the review, and needs to be rethought. General comments: * The title is partially misleading as this document is setting requirements for the protocol and is additionally defining the protocol. This is made obvious in the abstract, but nonetheless, the title is misleading * Document structure: I am not sure why the requirements are listed in Section 2. The are never ever used in the document to motivate any design decision or reference to. So what is the purpose of having these requirements here? Couldn’t and shouldn’t they be listed in a separate document? * Security: There is no security proposed or discussed for GRASP in this document. There are solely statements about generic security, such as in Section 1 „a secure and strongly authenticated environment“ or Section 3.5.2.1. "Messages MUST be authenticated and encryption MUST be implemented“. So how must they be authenticated and encrypted and why? What is the standard set of protocols to be used for this and what is the minimal set of crypto algorithms to be implemented to make this work? ************************************************************ This document is always using the escape hatch when it comes to security in any respect! ************************************************************ * Usage of UDP: This document is not discussing any of the aspects in RFC 8085. Every usage of UDP is required by IETF consensus to review RFC 8085 and to address at least the applicable subset of issues listed in RFC 8085 (or the predecessor RFC 5405). * Starting with UDP and switching to TCP for the data transfer looks like the right do. However, UDP should be really only used to discover other devices, but not piggy back further protocol mechanics. However, this document is not really specific on how to make use of TCP, for instance, how long are TCP connections kept open or closed down after a protocol exchange (persistent vs temporary connections). What happens if a TCP connection is shutdown by one end or is forcefully closed, e.g., by a reset? * There is no versioning support in GRASP. Why are we still developing protocols that do not have versioning support in it? * IPv4/IPv6 simultaneous use: I believe the email describing the -12 update of the draft says that IPv4 and IPv6 should not be mixed, so I can skip over this. Detailed comments: * Section 2.1: These are not protocol requirements but system requirements. It would be really good to separate them in the list of requirements. * Section 2.1, Requirement D2: What is this requirements saying? Is it „it should just work whatever?“ * Section 2.1, Requirement D7: What is the rest of the network in the first bullet point? All anima devices or every single element of the network? * Section 2.2, Requirement SN7: I am not sure if any of these points in this requirement related to any part of the GRAPS protocol. If so, you can for sure add forward references or backward references in the protocol specification. * Section 2.3, T1 & T2 are good, but how is this fulfilled by the protocol? * Section 3.2, end of page 12, „appropriate global-scope address“: so GRASP is not intended to run networks that use private RFC 1918 addresses? * Section 3.2, head of page 13: the discussion about interfaces. I am not sure that calling GRASP interfaces just interfaces helps. Why not calling interfaces interfaces and GRASP interfaces if the are used? or active interfaces, etc? * Section 3.3: This section is again bringing up a number of requirements. Wrong place in the document? * Section 3.3, page 14: the unsolicited flooding mode sounds really bad. Has this aspect looked at in terms of how many GRAPS nodes are expected to live on in a single link-local multicast domain (hoping that non link-local multicast is excluded per se). * Section 3.3: last bullet on page 14 and first bullet on page 15: what is this saying other than it is complicated? Aren’t there any tangible details to this? * Section 3.4: " An instance of GRASP is expected to run as a separate core module, providing an API (such as [I-D.liu-anima-grasp-api]) to interface to various ASAs. These ASAs may operate without special privilege, unless they need it for other reasons (such as configuring IP addresses or manipulating routing tables).“ This is implementation specific and does not belong in a protocol specification. * Section 3.5.1, page 17: „virtualized over the ACP“ — what does this mean and how it is done? * Section 3.5.1, page 17: „If there is no ACP, one“ there are two options listed for this case, but which is used when? * Section 3.5.1, page 17: „strong authentication“ — what is strong authentication and what needs to be supported by a minimal, but interoperable implementation? This is extremely underspecified. * Section 3.5.1, page 17: "Network interfaces could be at different security levels,“ what is a security level in the context of this document and specifically here. * Section 3.5.1, page 17: "discovery messages MUST be secured, with one exception mentioned in“ — how secured? This is extremely underspecified. * Section 3.5.2 s/GRAPS subject/GRAPS are subject/ * Section 3.5.2.1., page 17: "As mentioned in Section 3.3“ this isn’t mentioned in this place or I cannot correlate it. * Section 3.5.2.1., page 17 " implemented. TLS [RFC5246] and DTLS [RFC6347] based on a Public Key Infrastructure (PKI) [RFC5280] are RECOMMENDED for this purpose. Further details are out of scope for this document.“ How bad is this that TLS and DTLS are RECOMMENDED but the usage is not specified? * Section 3.5.2.2: Are there any measures in the protocol to ensure that datagrams have really been sent on the same link? I haven’t seen any measures. * Section 3.5.2.3.: " by TLS. A separate instance of GRASP is used, with its own copy of all GRASP data structures. This instance is nicknamed SONN - Secure Only Neighbor Negotiation.“ I am not sure why this document is trying to mandate how implementers are organizing their implementation and how instances are named? * Section 3.5.2.3, page 19, end of bullet list: "Further details are out of scope for this document.“ What further details? Is the WG not sure what the missing details are? * Section 3.5.3.: "They MUST NOT be fragmented, and therefore MUST NOT exceed the link MTU size.“ How should the protocol ensure that such datagrams are not fragmented and do not exceed the MTU? * Section 3.5.3.: " Use of an unreliable transport protocol is therefore NOT RECOMMENDED.“ — very good guidance — thank you! :-) * Section 3.5.3., end of page 19: * Section 3.5.4.4: "Since the relay device is unaware of the timeout set by the original initiator it SHOULD set a timeout at least equal to GRASP_DEF_TIMEOUT milliseconds.“ The timeout set by the initiator seems to be important, so why is this value not communicated by the initiator within GRASP? * Section 3.5.5: It is unclear to me if the messages here are expected to be sent over TCP or nor? This is not clear. * Section 3.5.5, page 24 and also Section 3.5.6.1: " request is sent (see Section 3.8.6). If no reply message of any kind is received within a reasonable timeout, the negotiation request MAY be repeated, with a newly generated Session ID (Section 3.7). An exponential backoff SHOULD be used for subsequent repetitions.“ What is a reasonable time out? And why is this need if TCP is used? TCP provides reliable data transfer… * Section 3.5.5, page 24: " about different objectives. Thus, GRASP is expected to be used in a multi-threaded mode. Certain negotiation objectives may have restrictions on multi-threading, for example to avoid over-allocating resources. „ Again, talking about the implementation. This is not a protocol specification, isn’t it? * Section 3.5.6.2 (and other places in the document): What is the GRASP core? * Section 3.5.6.2, page 26: „ the result is zero. Also, it MUST limit the total rate at which it relays Flood Synchronization messages to a reasonable value, in order to mitigate possible denial of service attacks. It MUST cache the „ What is a reasonable value? * Message encoding: What is the encoding to be supported for "reason = text ;optional error message“ Is there are any minimal standard to be supported, such as 7 bit ASCII or UTF-8 or whatever? Best regards, Martin Stiemerling