Re: [apps-discuss] [shim6] APPSDIR review of draft-garcia-shim6-applicability-03
Alberto García <alberto@it.uc3m.es> Tue, 06 March 2012 17:06 UTC
Return-Path: <alberto@it.uc3m.es>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C33921F8714; Tue, 6 Mar 2012 09:06:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.107
X-Spam-Level:
X-Spam-Status: No, score=-6.107 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBllJftbPFNq; Tue, 6 Mar 2012 09:06:44 -0800 (PST)
Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE2821F8763; Tue, 6 Mar 2012 09:06:39 -0800 (PST)
X-uc3m-safe: yes
Received: from BOMBO (unknown [163.117.139.62]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 4155275ABF1; Tue, 6 Mar 2012 18:06:38 +0100 (CET)
From: Alberto García <alberto@it.uc3m.es>
To: 'Carsten Bormann' <cabo@tzi.org>, 'IETF Apps Discuss' <apps-discuss@ietf.org>, draft-garcia-shim6-applicability.all@tools.ietf.org, shim6@ietf.org
References: <FDE1C2DB-48CF-42AB-91C3-266C1AAD95F9@tzi.org>
In-Reply-To: <FDE1C2DB-48CF-42AB-91C3-266C1AAD95F9@tzi.org>
Date: Tue, 06 Mar 2012 18:06:38 +0100
Message-ID: <00ac01ccfbbb$7e81e580$7b85b080$@it.uc3m.es>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AD_01CCFBC3.E04B0870"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQE8Z7u/F1paD1p9UUiMSbxgp70Ic5d4Qc7Q
Content-Language: es
X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.8.0.1017-18758.000
X-Mailman-Approved-At: Wed, 07 Mar 2012 08:12:50 -0800
Cc: 'The IESG' <iesg@ietf.org>
Subject: Re: [apps-discuss] [shim6] APPSDIR review of draft-garcia-shim6-applicability-03
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Mar 2012 17:06:51 -0000
Hi Carsten, Thank you very much for your review | -----Mensaje original----- | De: shim6-bounces@ietf.org [mailto:shim6-bounces@ietf.org] En nombre | de Carsten Bormann | Enviado el: miércoles, 29 de febrero de 2012 23:13 | Para: IETF Apps Discuss; <mailto:draft-garcia-shim6-applicability.all@tools.ietf.org> draft-garcia-shim6-applicability.all@tools.ietf.org; | <mailto:shim6@ietf.org> shim6@ietf.org | CC: The IESG | Asunto: [shim6] APPSDIR review of draft-garcia-shim6-applicability-03 | | I have been selected as the Applications Area Directorate reviewer for this | draft (for background on APPSDIR, please see | <http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate) | | Please resolve these comments along with any other Last Call comments | you may receive. Please wait for direction from your document shepherd or | AD before posting a new version of the draft. | | Gruesse, Carsten | --------------------------------- | | Document: draft-garcia-shim6-applicability-03.txt | Title: Applicability Statement for the Level 3 Multihoming Shim Protocol | (Shim6) | Reviewer: Carsten Bormann | IETF Last Call Date: 2012-02-15 | Review Date: 2012-02-29 | | ** Summary: This draft is ready for publication as an Informational | RFC with small changes, but maybe requires a better title. | | Note: I reviewed this with the expectation that the intended audience will | read this *before* looking at RFC55335535 in detail. | | ** Major Issues: | | General: | | The document provides useful discussion of considerations around the | usage of Shim6. At the end, it leaves the reader confused: What *is* the | applicability/area of application of Shim6? I assume this comment relates with the expectations created by the title, so I comment below. | Who should decide whether | Shim6 is activated for a specific connection? (There is an API in RFC 6316, | but clearly that is meant for advanced applications.) This issue was partially addressed in the 'Short-Lived Communications' subsection. However, I think the text would improve by placing this in a more prominent place, and by making a clearer statement. I have appended the following text just to the end of the '2. Deployment Scenarios' section: To allow nodes to benefit from the capabilities provided by Shim6 (discussed in Section 5) such as fault tolerance, nodes should be configured to initiate a Shim6 session with any peer node if they have multiple locators to use. Note that this configuration can be performed transparently to the applications, in the sense that applications do not need to be aware of the Shim6 functionality provided by the node; iin particular, nodes are not forced to use the Shim6 API [RFC6316] to benefit from Shim6. The Shim6 session should be created after the two nodes have been communicating for some time, i.e. using the deferred context establishment facility provided by Shim6. Otherwise, the cost of the Shim6 4-way handshake used for establishing the session may exceed the benefits provided for short- lived communications (see Section 5.1.2). More advanced node configuration may involved configuring different delays for initiating the session for different applications, for example, based on a per-port configuration. Nodes being able to use a single locator for the communication should not initiate the creation of a Shim6 context, but should participate if other node initiates it. Note that Shim6-aware applications can overrid this behavior by means of the Shim6 API [RFC6316]. By the way, I've also merged the 'Short-lived' and 'Long-lived' sections, into a single '5.1.2. Short-lived and long-lived communications', which is referred in the previous paragraph. Does this address your concern? | While the document | successfully relates Shim6 to SCTP and HIP, what about other approaches to | multi-addressing? In general, all mechanisms which handle different addresses at a higher level than the network-layer may experience unwanted interactions with Shim6. This applies to MPTCP, in addition to SCTP. Although there was a generic comment regarding to this at the end of the SCTP section, I have make this more explicit for MPTCP, by changing the SCTP section to refer to both SCTP and MPTCP. 7.3. Shim6, SCTP and MPTCP Both the SCTP [RFC4960] and MPTCP [RFC6182] protocols provide a reliable, stream-based communications channel between two hosts which provides a superset of the capabilities of TCP. One notable feature of these two protocols is that they allow the exchange of endpoint addresses between hosts, in order to recover from the failure of a particular endpoint pair, or to benefit from multipath communication in the MPTCP case, in a manner which is conceptually similar to locator selection in Shim6. SCTP and MPTCP are transport-layer protocols, higher in the protocol stack than Shim6, and hence there is no fundamental incompatibility which would prevent a Shim6-capable host from communicating using SCTP or MPTCP. However, since either SCTP or MPTCP, and Shim6 aim to exchange addressing information between hosts in order to meet the same generic goal, it is possible that their simultaneous use might result in unexpected behavior, e.g. lead to race conditions. The capabilities of these transport protocols with respect to path maintenance of a reliable, connection-oriented stream protocol are more extensive than the more general layer-3 locator agility provided by Shim6. Therefore, it is recommended that Shim6 is not used for SCTP or MPTCP sessions, and that path maintenance is provided solely by SCTP or MPTCP. There are at least two ways to enforce this behavior. One option would be to make the stack, and in particular the Shim6 sublayer, aware of the use of SCTP or MPTCP and in this case refrain from creating a Shim6 context. The other option is that the upper transport layer, informs using a Shim6-capable API like the one proposed in [RFC6316] that no Shim6 context must be created for this particular communication. In general, the issues described here may also arise for protocols which handle different addresses for two communicating nodes at a higher level than the network-layer to improve reliability, performance, congestion control, etc. | When is happy-eyeballs enough? Umm. In my opinion, the happy-eyeballs algorithm is not related to Shim6. Happy-eyeballs deals with dual-stack hosts connecting to servers. As discussed in section 3.1 Protocol Version (IPv4 vs. IPv6), Shim6 is just defined for IPv6. | When should MPTCP | be used? Now this is included in the new SCTP/MPTCP section commented before. | (The introduction to 7 then goes ahead and destroys any | remaining hope that this document provides the answers -- maybe this | should be split into "Open Issues" and the solid information about where | Shim6 is not needed.) | | The document may have started out as an applicability statement half a | decade ago, but maybe renaming it to "Considerations on the Application of | Shim6" provides a more appropriate title now. | | Again, this is meant as a comment on the expectations raised by the title | and abstract, not as an attempt to belittle the usefulness of the document's | content. | I think I see your point. For me its ok to change the title to Considerations on the Application of the Level 3 Multihoming Shim Protocol (Shim6) Ive also changed the abstract to a less ambitious This document discusses some considerations on the applicability of the Shim6 IPv6 protocol and associated support protocols and mechanisms to provide site multihoming capabilities in IPv6. Regarding to splitting section 7 into something like open issues, and do not mix, this is not evident to me. The do not mix is comprised of just two subsections (SCTP/MPTCP and HIP). Besides, the open issues part is very heterogeneous: there are things we are pretty confident that should work (e.g. SEND and Shim6), complex interactions (eg. NATs will work as long as there are no changes in the locators, which leads to a functionality which is not worse than current IPv6, although not as good as Shim6 could provide ), things that may work but they should be tested (MIP, NEMO, firewalls) I prefer the current approach in which each Shim6 and other combination is considered separately, without giving further structure to the section (structure that is difficult for me to find). | ** Minor Issues: | | (1) | I'm not so fond of the DHCP speculation in 3.3. An applicability statement | should talk about what is, not what could be. As of today, DHCP is not | applicable, and that should be clearly stated. (Work in progress can, of | course, be pointed to, but it is not clear there is much more than a problem | statement.) OK. Ive changed the section to this: 3.3. Address Generation and Configuration The security of the Shim6 protocol is based on the use of CGA and HBA addresses. CGA and HBA generation process can use the information provided by the stateless auto-configuration mechanism defined in [RFC4862] with the additional considerations presented in [RFC3972] and [RFC5535]. Stateful address auto-configuration using DHCP [RFC3315] is not currently supported, because there is no defined mechanism to convey the CGA Parameter Data Structure and other relevant information from the DHCP server to the host. An analysis of the possible interactions between DHCPv6 and Cryptographically Generated Addresses (CGAs) can be found in [I-D.ietf-csi-dhcpv6-cga-ps]. | | (2) | This sentence in 3.4 is opaque, unless it is talking about the state of | implementations (or is this another piece of DHCP speculation?): | | There is no current mechanism designed to allow an administrator to | enforce the configuration of a CGA or an HBA in a host. Ok, Ive removed it, since the comment is implicit in the previous section. | | (3) | Section 3.4, 7.2: The term "hybrid" does not occur in RFC 5535. | Adapt the terminology. OK, I adhere to RFC5535 text. Now the text says: In the case that a Shim6-capable host is using HBAs to protect its locator sets, the host will need to generate an address which is both a valid CGA and a valid HBA, as defined in [RFC5535] | | (4) | Section 5.2: | | One such solution is being developed at the MP-TCP Working Group. | | That is not the name of the WG, and referring to ephemeral IETF WGs is not | very useful in an archival document such as an RFC. It is probably most | appropriate to reference RFC 6182. Done | | More generally speaking, one would expect some more guidance when | MPTCP is appropriate and when Shim6 is appropriate. Oddly, RFC 6181 | seems to provide more information about Shim6 on this point than the | present document. Well, I think the inclusion of MPTCP along with SCTP provides much more information. Regarding to the information included in RFC6181, this information has not much to do with this application document: RFC6181 describes the security threats involving locator agility in MPTCP, which have some relation to those faced by Shim6 (thats why Shim6 is referred there). These threats are related to the design of the protocol, but not to the application of the protocol, since once they have been successfully addressed by the protocol itself, the managers deploying it do not need to care about anymore. So these issues are covered by the Shim6 specification [RFC5533], but do not need to be considered here, in the applicability considerations. | | (5) | (On a related note, avoid discussion of the Shim6 WG's charter in 7.5.) Sure. Changed to Shim6 aimed to provide a solution to | | ** Nits: | | [I-D.ietf-mif-problem-statement] is now RFC 6418. | | The document will benefit from some micro-editing, e.g. | s/different to/different from/g | s/specific of/specific to/g | s/associated to/associated with/g | s/is developed/has been developed/ | The usage of "suffer" in several places | (in particular, should "These problems are suffered by other solutions | supporting multihoming such as SCTP [RFC4960] or HIP | [RFC4423]." in section 4 not be "relevant to" instead?) | "Shim6 has no means to enforce neither host nor network forwarding..." Corrected to When a locator has been selected by a host to be used as source address for a Shim6 session, Shim6 has no means to enforce an appropriate path for that source address neither in the host nor in the network. | "does not require also" | s/should be review/should be reviewed/ | "...which security features can expect applications and users of the Shim6 | protocol." | As this is typically done by the RFC editor, I'm not providing a detailed list | here. | | Section 4: s/not being used/not be used/ | | Define "REAP" (I know, RFC5533 doesn't, either). | | Section 6: This sentence is hard to read: | "As long as the address exchanged, IP_A is the ULID..." All these nits have been corrected. Thanks again, Alberto | | _______________________________________________ | shim6 mailing list | <mailto:shim6@ietf.org> shim6@ietf.org | <https://www.ietf.org/mailman/listinfo/shim6> https://www.ietf.org/mailman/listinfo/shim6
- [apps-discuss] APPSDIR review of draft-garcia-shi… Carsten Bormann
- Re: [apps-discuss] [shim6] APPSDIR review of draf… Alberto García