From nobody Fri Feb 2 04:41:27 2018 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5391201F8; Fri, 2 Feb 2018 04:41:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Gonzalo Camarillo To: X-Test-IDTracker: no X-IETF-IDTracker: 6.71.0 Auto-Submitted: auto-generated Precedence: bulk Cc: hipsec@ietf.org, iesg-secretary@ietf.org, hip-chairs@ietf.org, gonzalo.camarillo@ericsson.com, Gonzalo Camarillo Message-ID: <151757528551.25747.12795374532585653990.idtracker@ietfa.amsl.com> Date: Fri, 02 Feb 2018 04:41:25 -0800 Archived-At: Subject: [Hipsec] Publication has been requested for draft-ietf-hip-native-nat-traversal-27 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 12:41:25 -0000 Gonzalo Camarillo has requested publication of draft-ietf-hip-native-nat-traversal-27 as Proposed Standard on behalf of the HIP working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/ From nobody Wed Feb 7 04:30:34 2018 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D843B12DA09; Wed, 7 Feb 2018 04:30:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Gonzalo Camarillo To: X-Test-IDTracker: no X-IETF-IDTracker: 6.72.0 Auto-Submitted: auto-generated Precedence: bulk Cc: hipsec@ietf.org, iesg-secretary@ietf.org, hip-chairs@ietf.org, gonzalo.camarillo@ericsson.com, Gonzalo Camarillo Message-ID: <151800662382.4740.2871357807479817263.idtracker@ietfa.amsl.com> Date: Wed, 07 Feb 2018 04:30:23 -0800 Archived-At: Subject: [Hipsec] Publication has been requested for draft-ietf-hip-dex-06 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 12:30:24 -0000 Gonzalo Camarillo has requested publication of draft-ietf-hip-dex-06 as Proposed Standard on behalf of the HIP working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-hip-dex/ From nobody Thu Feb 8 01:17:59 2018 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 37AC012D874; Thu, 8 Feb 2018 01:17:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Gonzalo Camarillo To: X-Test-IDTracker: no X-IETF-IDTracker: 6.72.0 Auto-Submitted: auto-generated Precedence: bulk Cc: hipsec@ietf.org, iesg-secretary@ietf.org, hip-chairs@ietf.org, gonzalo.camarillo@ericsson.com, Gonzalo Camarillo Message-ID: <151808147021.17016.14337765617920453091.idtracker@ietfa.amsl.com> Date: Thu, 08 Feb 2018 01:17:50 -0800 Archived-At: Subject: [Hipsec] Publication has been requested for draft-ietf-hip-rfc4423-bis-18 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 09:17:50 -0000 Gonzalo Camarillo has requested publication of draft-ietf-hip-rfc4423-bis-18 as Informational on behalf of the HIP working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-hip-rfc4423-bis/ From nobody Mon Feb 12 06:17:12 2018 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4501270FC; Mon, 12 Feb 2018 06:17:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.72.1 Auto-Submitted: auto-generated Precedence: bulk CC: hipsec@ietf.org, gonzalo.camarillo@ericsson.com, hip-chairs@ietf.org, Gonzalo Camarillo , draft-ietf-hip-dex@ietf.org, terry.manderson@icann.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <151844503114.6038.5530404591936997870.idtracker@ietfa.amsl.com> Date: Mon, 12 Feb 2018 06:17:11 -0800 Archived-At: Subject: [Hipsec] Last Call: (HIP Diet EXchange (DEX)) to Proposed Standard X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Feb 2018 14:17:11 -0000 The IESG has received a request from the Host Identity Protocol WG (hip) to consider the following document: - 'HIP Diet EXchange (DEX)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-02-26. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies the Host Identity Protocol Diet EXchange (HIP DEX), a variant of the Host Identity Protocol Version 2 (HIPv2). The HIP DEX protocol design aims at reducing the overhead of the employed cryptographic primitives by omitting public-key signatures and hash functions. In doing so, the main goal is to still deliver similar security properties to HIPv2. The HIP DEX protocol is primarily designed for computation or memory- constrained sensor/actuator devices. Like HIPv2, it is expected to be used together with a suitable security protocol such as the Encapsulated Security Payload (ESP) for the protection of upper layer protocol data. In addition, HIP DEX can also be used as a keying mechanism for security primitives at the MAC layer, e.g., for IEEE 802.15.4 networks. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-hip-dex/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-hip-dex/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: draft-moskowitz-hip-dex: HIP Diet EXchange (DEX) (None - ) draft-moskowitz-hip-rg-dex: HIP Diet EXchange (DEX) (None - ) From nobody Mon Feb 12 06:18:26 2018 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F291A12AAB6; Mon, 12 Feb 2018 06:18:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.72.1 Auto-Submitted: auto-generated Precedence: bulk CC: hipsec@ietf.org, gonzalo.camarillo@ericsson.com, hip-chairs@ietf.org, draft-ietf-hip-native-nat-traversal@ietf.org, Gonzalo Camarillo , terry.manderson@icann.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <151844510499.6058.13030103472975342030.idtracker@ietfa.amsl.com> Date: Mon, 12 Feb 2018 06:18:24 -0800 Archived-At: Subject: [Hipsec] Last Call: (Native NAT Traversal Mode for the Host Identity Protocol) to Proposed Standard X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Feb 2018 14:18:25 -0000 The IESG has received a request from the Host Identity Protocol WG (hip) to consider the following document: - 'Native NAT Traversal Mode for the Host Identity Protocol' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-02-26. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies a new Network Address Translator (NAT) traversal mode for the Host Identity Protocol (HIP). The new mode is based on the Interactive Connectivity Establishment (ICE) methodology and UDP encapsulation of data and signaling traffic. The main difference from the previously specified modes is the use of HIP messages for all NAT traversal procedures. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Feb 12 06:19:47 2018 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 72B77126C2F; Mon, 12 Feb 2018 06:19:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.72.1 Auto-Submitted: auto-generated Precedence: bulk CC: hipsec@ietf.org, gonzalo.camarillo@ericsson.com, hip-chairs@ietf.org, Gonzalo Camarillo , terry.manderson@icann.org, draft-ietf-hip-rfc4423-bis@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <151844518146.6121.15930424656447754205.idtracker@ietfa.amsl.com> Date: Mon, 12 Feb 2018 06:19:41 -0800 Archived-At: Subject: [Hipsec] Last Call: (Host Identity Protocol Architecture) to Informational RFC X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Feb 2018 14:19:41 -0000 The IESG has received a request from the Host Identity Protocol WG (hip) to consider the following document: - 'Host Identity Protocol Architecture' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-02-26. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memo describes a new namespace, the Host Identity namespace, and a new protocol layer, the Host Identity Protocol, between the internetworking and transport layers. Herein are presented the basics of the current namespaces, their strengths and weaknesses, and how a new namespace will add completeness to them. The roles of this new namespace in the protocols are defined. This document obsoletes RFC 4423 and addresses the concerns raised by the IESG, particularly that of crypto agility. It incorporates lessons learned from the implementations of RFC 5201 and goes further to explain how HIP works as a secure signaling channel. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-hip-rfc4423-bis/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-hip-rfc4423-bis/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Feb 13 13:54:42 2018 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94CD612D951 for ; Tue, 13 Feb 2018 13:54:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.863 X-Spam-Level: X-Spam-Status: No, score=-0.863 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 dzVlrCvdJB-y for ; Tue, 13 Feb 2018 13:54:38 -0800 (PST) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94F9D12711B for ; Tue, 13 Feb 2018 13:54:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 36A9062205 for ; Tue, 13 Feb 2018 16:54:36 -0500 (EST) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id uDNrvMbmSjcu for ; Tue, 13 Feb 2018 16:54:32 -0500 (EST) Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 2DC1362204 for ; Tue, 13 Feb 2018 16:54:32 -0500 (EST) To: hipsec@ietf.org From: Robert Moskowitz Message-ID: <7d240152-de81-ca7d-73e8-d3417ff1c514@htt-consult.com> Date: Tue, 13 Feb 2018 16:54:23 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [Hipsec] CGA IPR history X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Feb 2018 21:54:41 -0000 Can someone help me with the history of the IPR filings on CGA? There are a number of IPR filings in CGA itself, RFC3972. But nothing on ORCHID. How did ORCHID avoid the IPR issues related to CGA? This recently came up in a conversation with new work on cryptographic addressing. Thanks for any refresher history as my search foo is weak. Bob From nobody Sat Feb 17 21:33:44 2018 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 616081243F3; Sat, 17 Feb 2018 21:33:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joel Halpern To: Cc: draft-ietf-hip-rfc4423-bis.all@ietf.org, hipsec@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151893202236.27832.16542073394919248181@ietfa.amsl.com> Date: Sat, 17 Feb 2018 21:33:42 -0800 Archived-At: Subject: [Hipsec] Genart last call review of draft-ietf-hip-rfc4423-bis-18 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 05:33:42 -0000 Reviewer: Joel Halpern Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-hip-rfc4423-bis-18 Reviewer: Joel Halpern Review Date: 2018-02-17 IETF LC End Date: 2018-02-26 IESG Telechat date: Not scheduled for a telechat Summary: This document is ready for publication as an Informational RFCs. The following comments may be useful for the authors to consider. Major issues: N/A Minor issues: In the table in section 2.2 (Terms specific to this and other HIP documents) the Host Identity Hash is defined as "The cryptographic hash used in creating the Host Identity Tag from the Host Identity." I am pretty sure the last word should be Identifier, not Identity,, which matches the meanings and the usage in the following term. In section 4.1 second paragraph, it seems odd to refer to the public-private key pair as the structure of the abstract Host Identity. Given that the earlier text refers to the Public key as the Host Identifier, I am not sure how you want to refer to the public/private key pair. But I do not think it "is" the structure of the Host Identity. In the section 4.4 discussion of locally scoped identifier (LSI), it appears that applications need to be modified to use this. Reading between the lines of the stack architecture, the actual advantage of using HIP with LSIs is that the application changes can be restricted to whatever indication is to be used that the stack is to use HIP, rather than changing the places that use sockaddrs, etc. But this is not clearly stated here. In section 5.1 paragraph 3, the text talks about a connecting client not specifying a responder identifier (HIP Opportunistic mode) in order to enable load balancing. I think the text would be helped by an example of how an initiator might know to do this, rather than just not using HIP. Also, it would be good if the text was explicit as to whether or not there was a way to support load balancing / multi servers without either using a shared identity or sacrificing security by using Opportunistic HIP. Given that section 5 is titled "New Stack Architecture", I think it would be helpful if the section were explicit as to where the HIP logic lives relative to the IP and UDP/TCP portions of the host stack. This would help the reader have the right model for interpreting section 6.2 and 8.1. Nits/editorial comments: Section 4.2 third sentence "It is possible to for ..." should be "It is possible for ..." From nobody Thu Feb 22 18:01:49 2018 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E4475126DD9; Thu, 22 Feb 2018 18:01:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: David Waltermire To: Cc: hipsec@ietf.org, draft-ietf-hip-dex.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151935130185.22539.7608018209255295739@ietfa.amsl.com> Date: Thu, 22 Feb 2018 18:01:41 -0800 Archived-At: Subject: [Hipsec] Secdir last call review of draft-ietf-hip-dex-06 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 02:01:42 -0000 Reviewer: David Waltermire Review result: Has Issues I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Ready with issues. In general this document is clearly-written and well-organized. It was a fun read overall. I have the following concerns with the draft: ----------------------------------------------------------- Section 2.1: You should use text from RFC8174 to indicate that lowercase versions of the keywords are not normative. Something like the following would work: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Section 4.1.3.1: "it can be long-lived with no need for rekeying" Small is open to interpretation. It would be useful to include some guidance on the expected amount of data to be exchanged before rekeying would be needed, or why this is a practical impossibility. Section 5.3.2 and 5.3.3: In the paragraph on TRANSPORT_FORMAT_LIST, it would be good to document the specific ESP parameter value to be used from: https://www.iana.org/assignments/hip-parameters/hip-parameters.xml#transport-modes. This will remove any ambiguity. Section 6.6: In items #5 and #6, what is "an acceptable time span"? Some guidance here would be helpful. I believe this is discussed earlier in the draft. Perhaps a reference back may provide some clarity? Section 6.9: In #1, under what circumstances would the NOTIFY packet not be dropped silently? Why is this not a MUST? Some explanation would be useful here. In general, many of the SHOULDs in the section 6 subsections, could use further justification. Section 8: What is "a reasonable delta time"? Some guidance here would be useful. Section 9 (Security Considerations): "The puzzle mechanism using CMAC may need further study regarding the level of difficulty." Study of what? Is the concern here that the impact on constrained devices at a higher level of difficulty is not well understood? Or is this concern around identifying best practices around raising the difficulty under specific conditions? A sentence or two on this would be helpful for the reader to better understand the issue. I don't see a mention of the non-protected Host Identity issue from section 1.1 here. With regards to the 4th bullet, the text in section 3 should be referenced regarding HIT collisions. (nit)-> Referencing back to the relevant sections for the other bullets may also be useful. >From section 5.3.1, I don't see a mention of the issues around dealing with I1 storms addressed here. Section 10: It can be useful for IANA to reference the specific registry by name and URL in the IANA considerations. It can also be useful to include the actual table in the IANA considerations section. These are embedded in section 5 in the current document. Suggest moving these tables to the IANA consideration section. I found the following nits in the draft: ------------------------------------------------- Section 1.1: In the text "any signaling that indicates such anonymity should be ignored" it would be useful to provide an example of such signaling. /may carry data payload/may carry a data payload/ The packets are referred to as 1st, 2nd, 3rd, and 4th here, and as I1, R1, I2, and R2 in section 4. Consider use a consistent naming approach throughout this document to improve clarity. Section 1.2: Section 8 is not included in this summary. Suggest adding a sentence about it. (nit) Section 10 is not linked as well. Section 2: /Terms and Definitions/Terms, Notation, and Definitions/ Section 3: "other methods are used to map the data packets to the corresponding HIs" What are these other methods? What if ESP is not used and the SPI is not an option? Section 4.1.2.3: In the diagram, I think there is a missing arrow between I2-SENT and R2-SENT. Please double check. Also, this diagram is far from simple. Maybe name this section "HIP State Diagram"? Section 4.1.3.2: "Even though this input" Please clarify the "this" indefinite article. Section 4.1.4: /This will limit state/Using non-volatile storage will limit state/ This section should reference section 6.11, since some of the content is duplicated there. Section 5.2.3: /It is defined in/The HOST_ID parameter is defined in/ Section 5.2.5: /at least 64 bit/at least 64 bits/ Update the reference "#I and the puzzle solution #J (see [RFC7401])" to point to section 4.1.2 in RFC7401. Section 5.3.2: The discussion of difficulty K touches on a local policy issue that is discussed in section 7. It could be useful to reference section 7 from here. Update "(see [RFC7401])" to point to section 4.1.2 in RFC7401. /based on which it chose the ECDH/based on which the Responder chose the ECDH/ Regards, David Waltermire From nobody Fri Feb 23 00:23:11 2018 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9301200C1; Fri, 23 Feb 2018 00:23:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Qin Wu To: Cc: hipsec@ietf.org, draft-ietf-hip-dex.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151937418915.22547.2306442974033264477@ietfa.amsl.com> Date: Fri, 23 Feb 2018 00:23:09 -0800 Archived-At: Subject: [Hipsec] Opsdir last call review of draft-ietf-hip-dex-06 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 08:23:09 -0000 Reviewer: Qin Wu Review result: Ready Summary: This document defines the Host Identity Protocol Diet EXchange (HIP DEX) protocol for constrained devices. The draft is well written. I believe it is ready for publication. Major issue: None Minor issue: Editorial 1.It is not clear how fine-grained policy control defined in IKEv2 is different from policy control defined in HIP DEX protocol? In the draft, local policies are mentioned many times, however it is not clear what local policy for HIP DEX Protocol looks like? Is it possbile to carry policy control parameters(e.g., ACL parameter) in the HIP DEX protocol message? Would it be great to provide example to clarify this. 2. Is Nonce I same as radom value #I? 3. Is puzzle difficulty K same as #K used in the HIP R1 described in section 7? 4. Is puzzle difficulty K same as low-order #K bits of the RHASH? If the answer is yes, please make the term and symbol used in the draft consistent. From nobody Mon Feb 26 03:56:23 2018 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A592B12D77C for ; Mon, 26 Feb 2018 03:56:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 cdv2XwtoUDHX for ; Mon, 26 Feb 2018 03:56:20 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A4E712D779 for ; Mon, 26 Feb 2018 03:56:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519646169; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=wbXMDcMzSk0FElWc6m0mGtQFFJk77xnOD/XXQEziWWk=; b=NpLifBz85ONJqmFReKJ7ersxKOxY0jXAvurch6BCweYNrSphMoJHhn8aa6MOuwPL e9iIr92DznVMFb92kXJ7uw0hlR72W0ciTFHyFl3ZI7AwoNK/4iK0vJw8EXMTABqT OBJ0mAIXQ9b+7k/B2DbefMsW5MiHuuudteJ0V0Q2MWc=; X-AuditID: c1b4fb3a-728f89c0000067b4-66-5a93f5d9e7cb Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id D4.4A.26548.9D5F39A5; Mon, 26 Feb 2018 12:56:09 +0100 (CET) Received: from [131.160.51.186] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.92) with Microsoft SMTP Server id 14.3.352.0; Mon, 26 Feb 2018 12:56:08 +0100 To: Joel Halpern , CC: , , References: <151893202236.27832.16542073394919248181@ietfa.amsl.com> From: Miika Komu Organization: Ericsson AB Message-ID: <51f4f14e-12ac-646e-2dc2-13adbd8390f9@ericsson.com> Date: Mon, 26 Feb 2018 13:56:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <151893202236.27832.16542073394919248181@ietfa.amsl.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUyM2J7lO7Nr5OjDNYvkLc4d+IYq8XVV59Z LKYumsxs8WzjfBaLj6feMDmweixZ8pPJ49yU74wBTFFcNimpOZllqUX6dglcGW3XiwvOOlV8 PdfL1MDYb9TFyMkhIWAi8XH7b9YuRi4OIYHDjBIfN51lg3DWMEpsnf6CEaRKWMBVYu2RRnYQ W0TASqK3vYkVxGYWCJY4NusLC4gtJOAisWjeBbA4m4CWxKo715lBbH4BSYkNDbvBbF4Be4kP Lw+CzWERUJWYtqILrF5UIEKic+V8FogaQYmTM58A2RwcnEB7F6/mhFhlITFz/nlGCFtc4taT +UwQtrzE9rdzmEHKhQRUJC4eC57AKDQLyaBZSLpnIemehaR7ASPLKkbR4tTi4tx0IyO91KLM 5OLi/Dy9vNSSTYzAwD+45bfVDsaDzx0PMQpwMCrx8H57MTlKiDWxrLgy9xCjBAezkgjvysVA Id6UxMqq1KL8+KLSnNTiQ4zSHCxK4rxOaRZRQgLpiSWp2ampBalFMFkmDk6pBsb4xvN7fqfH 7o/t3Gyz4aLXsXbNtEsTK91nz9397/y+OeK7pAo95t+dGf91q3f2pdWvryyOKLnW+/96wNcz V8x2fs1o15buXMsxMWf2iqivGgvT+AoU8zxPPnym+UyeY1JvwVuRqX2meqejn3nUGVY+cg3y 2JNWM3nq2+oJTKUTVNl86/dZ/gpWYinOSDTUYi4qTgQAmA+VCHgCAAA= Archived-At: Subject: Re: [Hipsec] Genart last call review of draft-ietf-hip-rfc4423-bis-18 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 11:56:22 -0000 Hi Joel, thanks for the nice review! My suggested changes for HIP architecture document are below (in "diff" format). On 02/18/2018 07:33 AM, Joel Halpern wrote: > Reviewer: Joel Halpern > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-hip-rfc4423-bis-18 > Reviewer: Joel Halpern > Review Date: 2018-02-17 > IETF LC End Date: 2018-02-26 > IESG Telechat date: Not scheduled for a telechat > > Summary: This document is ready for publication as an Informational RFCs. > The following comments may be useful for the authors to consider. > > Major issues: N/A > > Minor issues: > In the table in section 2.2 (Terms specific to this and other HIP > documents) the Host Identity Hash is defined as "The cryptographic hash > used in creating the Host Identity Tag from the Host Identity." I am > pretty sure the last word should be Identifier, not Identity,, which > matches the meanings and the usage in the following term. agreed. Suggested change: Host Identity Hash The cryptographic hash used - in creating the Host Identity Tag from the Host Identity. + in creating the Host Identity Tag from the Host Identifier. (I will move the definition of Host Identifier earlier so that the terms appear in chronological order) > In section 4.1 second paragraph, it seems odd to refer to the > public-private key pair as the structure of the abstract Host Identity. > Given that the earlier text refers to the Public key as the Host > Identifier, I am not sure how you want to refer to the public/private key > pair. But I do not think it "is" the structure of the Host Identity. Agree. Suggested rephrasing: - The only completely defined structure of the Host Identity - is that of a public/private key pair. In this case, the Host - Identity is referred to by its public component, the public + An identity is based on public-private key cryptography in HIP. + The Host Identity is referred to by its public component, the public key. > In the section 4.4 discussion of locally scoped identifier (LSI), it > appears that applications need to be modified to use this. Reading between > the lines of the stack architecture, the actual advantage of using HIP with > LSIs is that the application changes can be restricted to whatever > indication is to be used that the stack is to use HIP, rather than changing > the places that use sockaddrs, etc. But this is not clearly stated here. yes, you are correct. I would suggest the following changes to make this more clear: A Host Identity Tag is a 128-bit representation for a Host - Identity. It is created from an HIH, - an IPv6 prefix [RFC7343] and a hash identifier. + Identity. Due to its size, it is suitable to be used in the existing sockets API in + the place of IPv6 addresses (e.g. in sockaddr_in6 structure, sin6_addr member) without modifying applications. + It is created from an HIH, an IPv6 prefix [RFC7343] + and a hash identifier. ...and the following: An LSI is a 32-bit localized representation for a Host - Identity. The purpose of an LSI is to facilitate using Host + Identity. Due to its size, it is suitable to be used in the existing sockets API in + the place of IPv4 addresses (e.g. in sockaddr_in structure, sin_addr member) without modifying applications. + The purpose of an LSI is to facilitate using Host Identities in existing APIs for IPv4-based - applications. Besides facilitating HIP-based connectivity for + applications. + LSIs are never transmitted on the wire; when an application + sends data using a pair of LSIs, the HIP layer (or sockets + handler) translates the LSIs to the corresponding HITs, and + vice versa for receiving of data. + Besides facilitating HIP-based connectivity for legacy IPv4 applications, the LSIs are beneficial in two other scenarios [RFC6538]. @@ -712,6 +721,14 @@ to facilitate backward compatibility with existing networking APIs and stacks. > In section 5.1 paragraph 3, the text talks about a connecting client not > specifying a responder identifier (HIP Opportunistic mode) in order to > enable load balancing. I think the text would be helped by an example of > how an initiator might know to do this, rather than just not using HIP. > Also, it would be good if the text was explicit as to whether or not there > was a way to support load balancing / multi servers without either using a > shared identity or sacrificing security by using Opportunistic HIP. agreed, the description of this was quite short. Would the following clarify your concerns? + At the server side, utilizing DNS is a better alternative than a + shared Host Identity to implement load balancing. A single FQDN entry can be configured + to refer to multiple Host Identities. Each of the FQDN entries + can be associated with the related locators, or a single + shared locator in the case the servers are using the same HIP rendezvous server + or HIP relay server. + Instead of duplicating identities, HIP opportunistic mode can be employed, where the initiator leaves out the identifier of the responder when initiating the key exchange and learns @@ -731,14 +766,21 @@ it upon the completion of the exchange. The tradeoffs are related to lowered security guarantees, but a benefit of the approach is to avoid publishing of Host Identifiers in any - directories [komu-leap]. The approach could also be used - for load balancing purposes at the HIP layer because the - identity of the responder can be decided dynamically during - the key exchange. Thus, the approach has - the potential to be used as a HIP-layer "anycast", either - directly between two hosts or indirectly through the - rendezvous service [komu-diss]. + directories [komu-leap]. Since many public + servers already employ DNS as their directory, opportunistic mode + may be more suitable for, e.g, peer-to-peer connectivity. + HIP opportunistic mode could be utilized in association + with HIP rendezvous servers or HIP relay servers + [komu-diss]. In such a scenario, the Initiator sends + an I1 message with a wildcard destination HIT to the locator of a HIP + rendezvous/relay server. When the receiving rendezvous/relay server is + serving multiple registered Responders, the server can choose + the ultimate destination HIT, thus acting as a HIP based load + balancer. However, this approach is still experimental and + requires further investigation. + (I can also remove the last paragraph if it is still unclear) > Given that section 5 is titled "New Stack Architecture", I think it would > be helpful if the section were explicit as to where the HIP logic lives > relative to the IP and UDP/TCP portions of the host stack. This would help > the reader have the right model for interpreting section 6.2 and 8.1. I would suggest to add a new paragraph in the end of the section to clarify this: + HIP layer is logically located at layer 3.5, between the + transport and network layers, in the networking stack. It acts + as shim layer for transport data utilizing LSIs or HITs, but + leaves other data intact. HIP layer translates between the two + forms of HIP identifiers originating from the transport layer + into routable IPv4/IPv6 addresses for the network layer, and + vice versa for the reverse direction. > Nits/editorial comments: > Section 4.2 third sentence "It is possible to for ..." should be "It is > possible for ..." Good catch, will fix this too. Joel, should I go ahead and submit a new version (bis-19) of the document? From nobody Mon Feb 26 05:21:18 2018 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 24A3C12702E; Mon, 26 Feb 2018 05:21:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Roni Even To: Cc: hipsec@ietf.org, ietf@ietf.org, draft-ietf-hip-native-nat-traversal.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151965127608.31482.7946240138786040730@ietfa.amsl.com> Date: Mon, 26 Feb 2018 05:21:16 -0800 Archived-At: Subject: [Hipsec] Genart last call review of draft-ietf-hip-native-nat-traversal-27 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 13:21:16 -0000 Reviewer: Roni Even Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-hip-native-nat-traversal-?? Reviewer: Roni Even Review Date: 2018-02-26 IETF LC End Date: 2018-02-26 IESG Telechat date: Not scheduled for a telechat Summary: The document is almost ready for publication as a standard track RFC Major issues: Minor issues: 1. in section 4.2 "Gathering of candidates MAY also be performed by other means than described in this section. For example, the candidates could be gathered as specified in Section 4.2 of [RFC5770] if STUN servers are available, or if the host has just a single interface and no STUN orData Relay Server are available." I did not see this a different ways since section 3 says "The hosts use either Control Relay Servers or Data Relay Servers (or other infrastructure including STUN or TURN servers) for gathering the candidates." so STUN is mentioned also here. 2. In section 4.6.2 "The connectivity check messages MUST be paced by the Ta value negotiated during the base exchange as described in Section 4.4. If neither one of the hosts announced a minimum pacing value, a value of 20 ms SHOULD be used." in section 4.4 the default value is 50 ms? 3. in section 5.4 what about "ICE-STUN-UDP 2" ; I assume it is not relevant but this is also the IANA registeration 4. In section 5.5 "The TRANSACTION_PACING is a new parameter" it is not new it is in RFC5770 5. In section 5.10 "SERVER_REFLEXIVE_CANDIDATE_ALLOCATION_FAILED 63" is the only new one. this also relates to section 7 that says that all error values in section 5.10 are new while the rest are in RFC5770. Also there is no mention in section 7 of which registry is used for the error values. Nits/editorial comments: 1. Expand SPI and LSI when first appear in the document 2. in section 2 "the base of an candidate" should be "a candidate" 3. In section 3 "so it is the Initiator may also have registered to a Control and/or Data Relay Server" maybe "so the Initiator may also need to register to a Control and/or Data Relay Server" 4. In section 4.2 "However, it is RECOMMENDED that a Data Relay Client registers a new server reflexive candidate for each its peer for the reasons described" maybe "for each of its..." 5. In section 4.2 I could not parse the sentence "where Ta is the value used for Ta is the value used for the" 6. in section 4.6 "as defined in section in 6.7 in [RFC7401]:" change to "as defined in section 6.7 in [RFC7401]:" From nobody Mon Feb 26 06:40:03 2018 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84AF81242F5; Mon, 26 Feb 2018 06:40:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: 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, HTML_MESSAGE=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 (1024-bit key) header.d=joelhalpern.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 DZ3d9n3IYPyu; Mon, 26 Feb 2018 06:39:58 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D875120725; Mon, 26 Feb 2018 06:39:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id D988B240469; Mon, 26 Feb 2018 06:39:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1519655997; bh=1WbyyQ9yOnBkhMabiXstxJMsfAdio4gNKf/kARbsFA4=; h=Date:Subject:In-Reply-To:From:To:Cc:From; b=TfchX7e2IeflbNYPP8i5CFVxBkFdSX1p4KgJsUV7a+mqpWbjOHqSyeDT8uNEBhOAz jheAM7hKnpahmCzyfHJKGhAsHJDgOz4qcDqmddWp/GEK+yoypczEb2AbmpgN8Kv0Bi Eo/SPVrM/bZBSmhsmJ1mHlk2TciHcIx21JF/K7UM= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [172.20.100.97] (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id A672D2405C0; Mon, 26 Feb 2018 06:39:56 -0800 (PST) SavedFromEmail: jmh.direct@joelhalpern.com Date: Mon, 26 Feb 2018 09:39:53 -0500 In-Reply-To: <51f4f14e-12ac-646e-2dc2-13adbd8390f9@ericsson.com> Importance: normal From: "jmh.direct" To: Miika Komu , Joel Halpern , gen-art@ietf.org Cc: draft-ietf-hip-rfc4423-bis.all@ietf.org, hipsec@ietf.org, ietf@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_10905280141180150" Message-Id: <20180226143958.2D875120725@ietfa.amsl.com> Archived-At: Subject: Re: [Hipsec] Genart last call review of draft-ietf-hip-rfc4423-bis-18 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 14:40:00 -0000 ----_com.samsung.android.email_10905280141180150 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 VGhlc2UgY2hhbmdlcyB2ZXJ5IG5pY2VseSBhZGRyZXNzIG15IGNvbmNlcm5zLmIgWW91IHNob3Vs ZCBjaGVjayB3aXRoIHlvdXIgY2hhaXIsYW5kIEFEIGJlZm9yZSBzdWJtaXR0aW5nIGEscmV2aXNp b24uClRoYW5rIHlvdSxKb2VsCgoKU2VudCB2aWEgdGhlIFNhbXN1bmcgR2FsYXh5IFPCriA2LCBh biBBVCZUIDRHIExURSBzbWFydHBob25lCi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0t LS1Gcm9tOiBNaWlrYSBLb211IDxtaWlrYS5rb211QGVyaWNzc29uLmNvbT4gRGF0ZTogMi8yNi8x OCAgMDY6NTYgIChHTVQtMDU6MDApIFRvOiBKb2VsIEhhbHBlcm4gPGptaEBqb2VsaGFscGVybi5j b20+LCBnZW4tYXJ0QGlldGYub3JnIENjOiBkcmFmdC1pZXRmLWhpcC1yZmM0NDIzLWJpcy5hbGxA aWV0Zi5vcmcsIGhpcHNlY0BpZXRmLm9yZywgaWV0ZkBpZXRmLm9yZyBTdWJqZWN0OiBSZTogR2Vu YXJ0IGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1oaXAtcmZjNDQyMy1iaXMtMTggCkhp IEpvZWwsCgp0aGFua3MgZm9yIHRoZSBuaWNlIHJldmlldyEgTXkgc3VnZ2VzdGVkIGNoYW5nZXMg Zm9yIEhJUCBhcmNoaXRlY3R1cmUgCmRvY3VtZW50IGFyZSBiZWxvdyAoaW4gImRpZmYiIGZvcm1h dCkuCgpPbiAwMi8xOC8yMDE4IDA3OjMzIEFNLCBKb2VsIEhhbHBlcm4gd3JvdGU6Cj4gUmV2aWV3 ZXI6IEpvZWwgSGFscGVybgo+IFJldmlldyByZXN1bHQ6IFJlYWR5IHdpdGggTml0cwo+IAo+IEkg YW0gdGhlIGFzc2lnbmVkIEdlbi1BUlQgcmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQuIFRoZSBHZW5l cmFsIEFyZWEKPiBSZXZpZXcgVGVhbSAoR2VuLUFSVCkgcmV2aWV3cyBhbGwgSUVURiBkb2N1bWVu dHMgYmVpbmcgcHJvY2Vzc2VkCj4gYnkgdGhlIElFU0cgZm9yIHRoZSBJRVRGIENoYWlyLsKgIFBs ZWFzZSB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0Cj4gbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxs IGNvbW1lbnRzLgo+IAo+IEZvciBtb3JlIGluZm9ybWF0aW9uLCBwbGVhc2Ugc2VlIHRoZSBGQVEg YXQKPiAKPiA8aHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvZ2VuL3dpa2kvR2VuQXJ0ZmFxPi4K PiAKPiBEb2N1bWVudDogZHJhZnQtaWV0Zi1oaXAtcmZjNDQyMy1iaXMtMTgKPiBSZXZpZXdlcjog Sm9lbCBIYWxwZXJuCj4gUmV2aWV3IERhdGU6IDIwMTgtMDItMTcKPiBJRVRGIExDIEVuZCBEYXRl OiAyMDE4LTAyLTI2Cj4gSUVTRyBUZWxlY2hhdCBkYXRlOiBOb3Qgc2NoZWR1bGVkIGZvciBhIHRl bGVjaGF0Cj4gCj4gU3VtbWFyeTogVGhpcyBkb2N1bWVudCBpcyByZWFkeSBmb3IgcHVibGljYXRp b24gYXMgYW4gSW5mb3JtYXRpb25hbCBSRkNzLgo+wqDCoMKgwqDCoMKgIFRoZSBmb2xsb3dpbmcg Y29tbWVudHMgbWF5IGJlIHVzZWZ1bCBmb3IgdGhlIGF1dGhvcnMgdG8gY29uc2lkZXIuCj4gCj4g TWFqb3IgaXNzdWVzOiBOL0EKPiAKPiBNaW5vciBpc3N1ZXM6Cj7CoMKgwqDCoMKgIEluIHRoZSB0 YWJsZSBpbiBzZWN0aW9uIDIuMiAoVGVybXMgc3BlY2lmaWMgdG8gdGhpcyBhbmQgb3RoZXIgSElQ Cj7CoMKgwqDCoMKgIGRvY3VtZW50cykgdGhlIEhvc3QgSWRlbnRpdHkgSGFzaCBpcyBkZWZpbmVk IGFzICJUaGUgY3J5cHRvZ3JhcGhpYyBoYXNoCj7CoMKgwqDCoMKgIHVzZWQgaW4gY3JlYXRpbmcg dGhlIEhvc3QgSWRlbnRpdHkgVGFnIGZyb20gdGhlIEhvc3QgSWRlbnRpdHkuIsKgIEkgYW0KPsKg wqDCoMKgwqAgcHJldHR5IHN1cmUgdGhlIGxhc3Qgd29yZCBzaG91bGQgYmUgSWRlbnRpZmllciwg bm90IElkZW50aXR5LCwgd2hpY2gKPsKgwqDCoMKgwqAgbWF0Y2hlcyB0aGUgbWVhbmluZ3MgYW5k IHRoZSB1c2FnZSBpbiB0aGUgZm9sbG93aW5nIHRlcm0uCgphZ3JlZWQuIFN1Z2dlc3RlZCBjaGFu Z2U6CgrCoMKgwqDCoMKgwqDCoCBIb3N0IElkZW50aXR5IEhhc2jCoCBUaGUgY3J5cHRvZ3JhcGhp YyBoYXNoIHVzZWQKLcKgwqDCoMKgwqAgaW4gY3JlYXRpbmcgdGhlIEhvc3QgSWRlbnRpdHkgVGFn IGZyb20gdGhlIEhvc3QgSWRlbnRpdHkuCivCoMKgwqDCoMKgIGluIGNyZWF0aW5nIHRoZSBIb3N0 IElkZW50aXR5IFRhZyBmcm9tIHRoZSBIb3N0IElkZW50aWZpZXIuCsKgIChJIHdpbGwgbW92ZSB0 aGUgZGVmaW5pdGlvbiBvZiBIb3N0IElkZW50aWZpZXIgZWFybGllciBzbyB0aGF0IHRoZSAKdGVy bXMgYXBwZWFyIGluIGNocm9ub2xvZ2ljYWwgb3JkZXIpCgo+wqDCoMKgwqDCoCBJbiBzZWN0aW9u IDQuMSBzZWNvbmQgcGFyYWdyYXBoLCBpdCBzZWVtcyBvZGQgdG8gcmVmZXIgdG8gdGhlCj7CoMKg wqDCoMKgIHB1YmxpYy1wcml2YXRlIGtleSBwYWlyIGFzIHRoZSBzdHJ1Y3R1cmUgb2YgdGhlIGFi c3RyYWN0IEhvc3QgSWRlbnRpdHkuCj7CoMKgwqDCoMKgIEdpdmVuIHRoYXQgdGhlIGVhcmxpZXIg dGV4dCByZWZlcnMgdG8gdGhlIFB1YmxpYyBrZXkgYXMgdGhlIEhvc3QKPsKgwqDCoMKgwqAgSWRl bnRpZmllciwgSSBhbSBub3Qgc3VyZSBob3cgeW91IHdhbnQgdG8gcmVmZXIgdG8gdGhlIHB1Ymxp Yy9wcml2YXRlIGtleQo+wqDCoMKgwqDCoCBwYWlyLsKgIEJ1dCBJIGRvIG5vdCB0aGluayBpdCAi aXMiIHRoZSBzdHJ1Y3R1cmUgb2YgdGhlIEhvc3QgSWRlbnRpdHkuCgpBZ3JlZS4gU3VnZ2VzdGVk IHJlcGhyYXNpbmc6CgotwqDCoMKgIFRoZSBvbmx5IGNvbXBsZXRlbHkgZGVmaW5lZCBzdHJ1Y3R1 cmUgb2YgdGhlIEhvc3QgSWRlbnRpdHkKLcKgwqDCoMKgwqDCoMKgIGlzIHRoYXQgb2YgYSBwdWJs aWMvcHJpdmF0ZSBrZXkgcGFpci7CoCBJbiB0aGlzIGNhc2UsIHRoZSBIb3N0Ci3CoMKgwqDCoMKg wqDCoCBJZGVudGl0eSBpcyByZWZlcnJlZCB0byBieSBpdHMgcHVibGljIGNvbXBvbmVudCwgdGhl IHB1YmxpYworwqDCoMKgIEFuIGlkZW50aXR5IGlzIGJhc2VkIG9uIHB1YmxpYy1wcml2YXRlIGtl eSBjcnlwdG9ncmFwaHkgaW4gSElQLgorwqDCoMKgwqDCoMKgwqAgVGhlIEhvc3QgSWRlbnRpdHkg aXMgcmVmZXJyZWQgdG8gYnkgaXRzIHB1YmxpYyBjb21wb25lbnQsIHRoZSAKcHVibGljCsKgwqDC oMKgwqDCoMKgwqDCoCBrZXkuCgo+wqDCoMKgwqDCoCBJbiB0aGUgc2VjdGlvbiA0LjQgZGlzY3Vz c2lvbiBvZiBsb2NhbGx5IHNjb3BlZCBpZGVudGlmaWVyIChMU0kpLCBpdAo+wqDCoMKgwqDCoCBh cHBlYXJzIHRoYXQgYXBwbGljYXRpb25zIG5lZWQgdG8gYmUgbW9kaWZpZWQgdG8gdXNlIHRoaXMu wqAgUmVhZGluZyBiZXR3ZWVuCj7CoMKgwqDCoMKgIHRoZSBsaW5lcyBvZiB0aGUgc3RhY2sgYXJj aGl0ZWN0dXJlLCB0aGUgYWN0dWFsIGFkdmFudGFnZSBvZiB1c2luZyBISVAgd2l0aAo+wqDCoMKg wqDCoCBMU0lzIGlzIHRoYXQgdGhlIGFwcGxpY2F0aW9uIGNoYW5nZXMgY2FuIGJlIHJlc3RyaWN0 ZWQgdG8gd2hhdGV2ZXIKPsKgwqDCoMKgwqAgaW5kaWNhdGlvbiBpcyB0byBiZSB1c2VkIHRoYXQg dGhlIHN0YWNrIGlzIHRvIHVzZSBISVAsIHJhdGhlciB0aGFuIGNoYW5naW5nCj7CoMKgwqDCoMKg IHRoZSBwbGFjZXMgdGhhdCB1c2Ugc29ja2FkZHJzLCBldGMuwqAgQnV0IHRoaXMgaXMgbm90IGNs ZWFybHkgc3RhdGVkIGhlcmUuCgp5ZXMsIHlvdSBhcmUgY29ycmVjdC4gSSB3b3VsZCBzdWdnZXN0 IHRoZSBmb2xsb3dpbmcgY2hhbmdlcyB0byBtYWtlIHRoaXMgCm1vcmUgY2xlYXI6CgrCoMKgwqDC oMKgIEEgSG9zdCBJZGVudGl0eSBUYWcgaXMgYSAxMjgtYml0IHJlcHJlc2VudGF0aW9uIGZvciBh IEhvc3QKLcKgwqDCoMKgwqDCoMKgIElkZW50aXR5LsKgIEl0IGlzIGNyZWF0ZWQgZnJvbSBhbiBI SUgsCi3CoMKgwqDCoMKgwqDCoCBhbiBJUHY2IHByZWZpeCBbUkZDNzM0M10gYW5kIGEgaGFzaCBp ZGVudGlmaWVyLgorwqDCoMKgIElkZW50aXR5LiBEdWUgdG8gaXRzIHNpemUsIGl0IGlzIHN1aXRh YmxlIHRvIGJlIHVzZWQgaW4gdGhlIApleGlzdGluZyBzb2NrZXRzIEFQSSBpbgorwqDCoMKgIHRo ZSBwbGFjZSBvZiBJUHY2IGFkZHJlc3NlcyAoZS5nLiBpbiBzb2NrYWRkcl9pbjYgc3RydWN0dXJl LCAKc2luNl9hZGRyIG1lbWJlcikgd2l0aG91dCBtb2RpZnlpbmcgYXBwbGljYXRpb25zLgorwqDC oMKgwqDCoMKgwqAgSXQgaXMgY3JlYXRlZCBmcm9tIGFuIEhJSCwgYW4gSVB2NiBwcmVmaXggW1JG QzczNDNdCivCoMKgwqAgYW5kIGEgaGFzaCBpZGVudGlmaWVyLgoKLi4uYW5kIHRoZSBmb2xsb3dp bmc6CgrCoMKgwqDCoMKgIEFuIExTSSBpcyBhIDMyLWJpdCBsb2NhbGl6ZWQgcmVwcmVzZW50YXRp b24gZm9yIGEgSG9zdAotwqDCoMKgIElkZW50aXR5LiBUaGUgcHVycG9zZSBvZiBhbiBMU0kgaXMg dG8gZmFjaWxpdGF0ZSB1c2luZyBIb3N0CivCoMKgwqAgSWRlbnRpdHkuIER1ZSB0byBpdHMgc2l6 ZSwgaXQgaXMgc3VpdGFibGUgdG8gYmUgdXNlZCBpbiB0aGUgCmV4aXN0aW5nIHNvY2tldHMgQVBJ IGluCivCoMKgwqAgdGhlIHBsYWNlIG9mIElQdjQgYWRkcmVzc2VzIChlLmcuIGluIHNvY2thZGRy X2luIHN0cnVjdHVyZSwgCnNpbl9hZGRyIG1lbWJlcikgd2l0aG91dCBtb2RpZnlpbmcgYXBwbGlj YXRpb25zLgorwqDCoMKgwqDCoMKgwqAgVGhlIHB1cnBvc2Ugb2YgYW4gTFNJIGlzIHRvIGZhY2ls aXRhdGUgdXNpbmcgSG9zdArCoMKgwqDCoMKgIElkZW50aXRpZXMgaW4gZXhpc3RpbmcgQVBJcyBm b3IgSVB2NC1iYXNlZAotwqDCoMKgIGFwcGxpY2F0aW9ucy4gQmVzaWRlcyBmYWNpbGl0YXRpbmcg SElQLWJhc2VkIGNvbm5lY3Rpdml0eSBmb3IKK8KgwqDCoCBhcHBsaWNhdGlvbnMuCivCoMKgwqDC oMKgwqDCoCBMU0lzIGFyZSBuZXZlciB0cmFuc21pdHRlZCBvbiB0aGUgd2lyZTsgd2hlbiBhbiBh cHBsaWNhdGlvbgorwqDCoMKgwqDCoMKgwqAgc2VuZHMgZGF0YSB1c2luZyBhIHBhaXIgb2YgTFNJ cywgdGhlIEhJUCBsYXllciAob3Igc29ja2V0cworwqDCoMKgwqDCoMKgwqAgaGFuZGxlcikgdHJh bnNsYXRlcyB0aGUgTFNJcyB0byB0aGUgY29ycmVzcG9uZGluZyBISVRzLCBhbmQKK8KgwqDCoMKg wqDCoMKgIHZpY2UgdmVyc2EgZm9yIHJlY2VpdmluZyBvZiBkYXRhLgorwqDCoMKgwqDCoMKgwqAg QmVzaWRlcyBmYWNpbGl0YXRpbmcgSElQLWJhc2VkIGNvbm5lY3Rpdml0eSBmb3IKwqDCoMKgwqDC oCBsZWdhY3kgSVB2NCBhcHBsaWNhdGlvbnMsIHRoZSBMU0lzIGFyZSBiZW5lZmljaWFsIGluIHR3 byBvdGhlcgrCoMKgwqDCoMKgIHNjZW5hcmlvcyBbUkZDNjUzOF0uCgpAQCAtNzEyLDYgKzcyMSwx NCBAQArCoMKgwqDCoMKgIHRvIGZhY2lsaXRhdGUgYmFja3dhcmQgY29tcGF0aWJpbGl0eSB3aXRo IGV4aXN0aW5nIG5ldHdvcmtpbmcKwqDCoMKgwqDCoCBBUElzIGFuZCBzdGFja3MuPC90PgoKPsKg wqDCoMKgwqAgSW4gc2VjdGlvbiA1LjEgcGFyYWdyYXBoIDMsIHRoZSB0ZXh0IHRhbGtzIGFib3V0 IGEgY29ubmVjdGluZyBjbGllbnQgbm90Cj7CoMKgwqDCoMKgIHNwZWNpZnlpbmcgYSByZXNwb25k ZXIgaWRlbnRpZmllciAoSElQIE9wcG9ydHVuaXN0aWMgbW9kZSkgaW4gb3JkZXIgdG8KPsKgwqDC oMKgwqAgZW5hYmxlIGxvYWQgYmFsYW5jaW5nLsKgIEkgdGhpbmsgdGhlIHRleHQgd291bGQgYmUg aGVscGVkIGJ5IGFuIGV4YW1wbGUgb2YKPsKgwqDCoMKgwqAgaG93IGFuIGluaXRpYXRvciBtaWdo dCBrbm93IHRvIGRvIHRoaXMsIHJhdGhlciB0aGFuIGp1c3Qgbm90IHVzaW5nIEhJUC4KPsKgwqDC oMKgwqAgQWxzbywgaXQgd291bGQgYmUgZ29vZCBpZiB0aGUgdGV4dCB3YXMgZXhwbGljaXQgYXMg dG8gd2hldGhlciBvciBub3QgdGhlcmUKPsKgwqDCoMKgwqAgd2FzIGEgd2F5IHRvIHN1cHBvcnQg bG9hZCBiYWxhbmNpbmcgLyBtdWx0aSBzZXJ2ZXJzIHdpdGhvdXQgZWl0aGVyIHVzaW5nIGEKPsKg wqDCoMKgwqAgc2hhcmVkIGlkZW50aXR5IG9yIHNhY3JpZmljaW5nIHNlY3VyaXR5IGJ5IHVzaW5n IE9wcG9ydHVuaXN0aWMgSElQLgoKYWdyZWVkLCB0aGUgZGVzY3JpcHRpb24gb2YgdGhpcyB3YXMg cXVpdGUgc2hvcnQuIFdvdWxkIHRoZSBmb2xsb3dpbmcgCmNsYXJpZnkgeW91ciBjb25jZXJucz8K CivCoMKgwqAgQXQgdGhlIHNlcnZlciBzaWRlLCB1dGlsaXppbmcgRE5TIGlzIGEgYmV0dGVyIGFs dGVybmF0aXZlIHRoYW4gYQorwqDCoMKgIHNoYXJlZCBIb3N0IElkZW50aXR5IHRvIGltcGxlbWVu dCBsb2FkIGJhbGFuY2luZy7CoCBBIHNpbmdsZSBGUUROIAplbnRyeSBjYW4gYmUgY29uZmlndXJl ZAorwqDCoMKgIHRvIHJlZmVyIHRvIG11bHRpcGxlIEhvc3QgSWRlbnRpdGllcy4gRWFjaCBvZiB0 aGUgRlFETiBlbnRyaWVzCivCoMKgwqAgY2FuIGJlIGFzc29jaWF0ZWQgd2l0aCB0aGUgcmVsYXRl ZCBsb2NhdG9ycywgb3IgYSBzaW5nbGUKK8KgwqDCoCBzaGFyZWQgbG9jYXRvciBpbiB0aGUgY2Fz ZSB0aGUgc2VydmVycyBhcmUgdXNpbmcgdGhlIHNhbWUgSElQIApyZW5kZXp2b3VzIHNlcnZlcgor wqDCoMKgIG9yIEhJUCByZWxheSBzZXJ2ZXIuCisKwqDCoMKgwqDCoMKgwqDCoMKgIEluc3RlYWQg b2YgZHVwbGljYXRpbmcgaWRlbnRpdGllcywgSElQIG9wcG9ydHVuaXN0aWMgbW9kZQrCoMKgwqDC oMKgwqDCoMKgwqAgY2FuIGJlIGVtcGxveWVkLCB3aGVyZSB0aGUgaW5pdGlhdG9yIGxlYXZlcyBv dXQgdGhlIGlkZW50aWZpZXIKwqDCoMKgwqDCoMKgwqDCoMKgIG9mIHRoZSByZXNwb25kZXIgd2hl biBpbml0aWF0aW5nIHRoZSBrZXkgZXhjaGFuZ2UgYW5kIGxlYXJucwpAQCAtNzMxLDE0ICs3NjYs MjEgQEAKwqDCoMKgwqDCoMKgwqDCoMKgIGl0IHVwb24gdGhlIGNvbXBsZXRpb24gb2YgdGhlIGV4 Y2hhbmdlLiBUaGUgdHJhZGVvZmZzIGFyZQrCoMKgwqDCoMKgwqDCoMKgwqAgcmVsYXRlZCB0byBs b3dlcmVkIHNlY3VyaXR5IGd1YXJhbnRlZXMsIGJ1dCBhIGJlbmVmaXQgb2YgdGhlCsKgwqDCoMKg wqDCoMKgwqDCoCBhcHByb2FjaCBpcyB0byBhdm9pZCBwdWJsaXNoaW5nIG9mIEhvc3QgSWRlbnRp ZmllcnMgaW4gYW55Ci3CoMKgwqDCoMKgwqDCoCBkaXJlY3RvcmllcyBba29tdS1sZWFwXS7CoCBU aGUgYXBwcm9hY2ggY291bGQgYWxzbyBiZSB1c2VkCi3CoMKgwqDCoMKgwqDCoCBmb3IgbG9hZCBi YWxhbmNpbmcgcHVycG9zZXMgYXQgdGhlIEhJUCBsYXllciBiZWNhdXNlIHRoZQotwqDCoMKgwqDC oMKgwqAgaWRlbnRpdHkgb2YgdGhlIHJlc3BvbmRlciBjYW4gYmUgZGVjaWRlZCBkeW5hbWljYWxs eSBkdXJpbmcKLcKgwqDCoMKgwqDCoMKgIHRoZSBrZXkgZXhjaGFuZ2UuIFRodXMsIHRoZSBhcHBy b2FjaCBoYXMKLcKgwqDCoMKgwqDCoMKgIHRoZSBwb3RlbnRpYWwgdG8gYmUgdXNlZCBhcyBhIEhJ UC1sYXllciAiYW55Y2FzdCIsIGVpdGhlcgotwqDCoMKgwqDCoMKgwqAgZGlyZWN0bHkgYmV0d2Vl biB0d28gaG9zdHMgb3IgaW5kaXJlY3RseSB0aHJvdWdoIHRoZQotwqDCoMKgwqDCoMKgwqAgcmVu ZGV6dm91cyBzZXJ2aWNlIFtrb211LWRpc3NdLgorwqDCoMKgwqDCoMKgwqAgZGlyZWN0b3JpZXMg W2tvbXUtbGVhcF0uIFNpbmNlIG1hbnkgcHVibGljCivCoMKgwqDCoMKgwqDCoCBzZXJ2ZXJzIGFs cmVhZHkgZW1wbG95IEROUyBhcyB0aGVpciBkaXJlY3RvcnksIG9wcG9ydHVuaXN0aWMgbW9kZQor wqDCoMKgwqDCoMKgwqAgbWF5IGJlIG1vcmUgc3VpdGFibGUgZm9yLCBlLmcsIHBlZXItdG8tcGVl ciBjb25uZWN0aXZpdHkuCgorwqDCoMKgIEhJUCBvcHBvcnR1bmlzdGljIG1vZGUgY291bGQgYmUg dXRpbGl6ZWQgaW4gYXNzb2NpYXRpb24KK8KgwqDCoCB3aXRoIEhJUCByZW5kZXp2b3VzIHNlcnZl cnMgb3IgSElQIHJlbGF5IHNlcnZlcnMKK8KgwqDCoCBba29tdS1kaXNzXS4gSW4gc3VjaCBhIHNj ZW5hcmlvLCB0aGUgSW5pdGlhdG9yIHNlbmRzCivCoMKgwqAgYW4gSTEgbWVzc2FnZSB3aXRoIGEg d2lsZGNhcmQgZGVzdGluYXRpb24gSElUIHRvIHRoZSBsb2NhdG9yIG9mIGEgSElQCivCoMKgwqAg cmVuZGV6dm91cy9yZWxheSBzZXJ2ZXIuIFdoZW4gdGhlIHJlY2VpdmluZyByZW5kZXp2b3VzL3Jl bGF5IHNlcnZlciBpcworwqDCoMKgIHNlcnZpbmcgbXVsdGlwbGUgcmVnaXN0ZXJlZCBSZXNwb25k ZXJzLCB0aGUgc2VydmVyIGNhbiBjaG9vc2UKK8KgwqDCoCB0aGUgdWx0aW1hdGUgZGVzdGluYXRp b24gSElULCB0aHVzIGFjdGluZyBhcyBhIEhJUCBiYXNlZCBsb2FkCivCoMKgwqAgYmFsYW5jZXIu IEhvd2V2ZXIsIHRoaXMgYXBwcm9hY2ggaXMgc3RpbGwgZXhwZXJpbWVudGFsIGFuZAorwqDCoMKg IHJlcXVpcmVzIGZ1cnRoZXIgaW52ZXN0aWdhdGlvbi4KKwoKKEkgY2FuIGFsc28gcmVtb3ZlIHRo ZSBsYXN0IHBhcmFncmFwaCBpZiBpdCBpcyBzdGlsbCB1bmNsZWFyKQoKPsKgwqDCoMKgwqAgR2l2 ZW4gdGhhdCBzZWN0aW9uIDUgaXMgdGl0bGVkICJOZXcgU3RhY2sgQXJjaGl0ZWN0dXJlIiwgSSB0 aGluayBpdCB3b3VsZAo+wqDCoMKgwqDCoCBiZSBoZWxwZnVsIGlmIHRoZSBzZWN0aW9uIHdlcmUg ZXhwbGljaXQgYXMgdG8gd2hlcmUgdGhlIEhJUCBsb2dpYyBsaXZlcwo+wqDCoMKgwqDCoCByZWxh dGl2ZSB0byB0aGUgSVAgYW5kIFVEUC9UQ1AgcG9ydGlvbnMgb2YgdGhlIGhvc3Qgc3RhY2suwqAg VGhpcyB3b3VsZCBoZWxwCj7CoMKgwqDCoMKgIHRoZSByZWFkZXIgaGF2ZSB0aGUgcmlnaHQgbW9k ZWwgZm9yIGludGVycHJldGluZyBzZWN0aW9uIDYuMiBhbmQgOC4xLgoKSSB3b3VsZCBzdWdnZXN0 IHRvIGFkZCBhIG5ldyBwYXJhZ3JhcGggaW4gdGhlIGVuZCBvZiB0aGUgc2VjdGlvbiB0byAKY2xh cmlmeSB0aGlzOgoKK8KgwqDCoCBISVAgbGF5ZXIgaXMgbG9naWNhbGx5IGxvY2F0ZWQgYXQgbGF5 ZXIgMy41LCBiZXR3ZWVuIHRoZQorwqDCoMKgIHRyYW5zcG9ydCBhbmQgbmV0d29yayBsYXllcnMs IGluIHRoZSBuZXR3b3JraW5nIHN0YWNrLiBJdCBhY3RzCivCoMKgwqAgYXMgc2hpbSBsYXllciBm b3IgdHJhbnNwb3J0IGRhdGEgdXRpbGl6aW5nIExTSXMgb3IgSElUcywgYnV0CivCoMKgwqAgbGVh dmVzIG90aGVyIGRhdGEgaW50YWN0LiBISVAgbGF5ZXIgdHJhbnNsYXRlcyBiZXR3ZWVuIHRoZSB0 d28KK8KgwqDCoCBmb3JtcyBvZiBISVAgaWRlbnRpZmllcnMgb3JpZ2luYXRpbmcgZnJvbSB0aGUg dHJhbnNwb3J0IGxheWVyCivCoMKgwqAgaW50byByb3V0YWJsZSBJUHY0L0lQdjYgYWRkcmVzc2Vz IGZvciB0aGUgbmV0d29yayBsYXllciwgYW5kCivCoMKgwqAgdmljZSB2ZXJzYSBmb3IgdGhlIHJl dmVyc2UgZGlyZWN0aW9uLgoKPiBOaXRzL2VkaXRvcmlhbCBjb21tZW50czoKPsKgwqDCoMKgwqAg U2VjdGlvbiA0LjIgdGhpcmQgc2VudGVuY2UgIkl0IGlzIHBvc3NpYmxlIHRvIGZvciAuLi4iIHNo b3VsZCBiZSAiSXQgaXMKPsKgwqDCoMKgwqAgcG9zc2libGUgZm9yIC4uLiIKCkdvb2QgY2F0Y2gs IHdpbGwgZml4IHRoaXMgdG9vLgoKSm9lbCwgc2hvdWxkIEkgZ28gYWhlYWQgYW5kIHN1Ym1pdCBh IG5ldyB2ZXJzaW9uIChiaXMtMTkpIG9mIHRoZSBkb2N1bWVudD8K ----_com.samsung.android.email_10905280141180150 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2PlRoZXNlIGNoYW5nZXMgdmVy eSBuaWNlbHkgYWRkcmVzcyBteSBjb25jZXJucy5iIFlvdSBzaG91bGQgY2hlY2sgd2l0aCB5b3Vy IGNoYWlyLGFuZCBBRCBiZWZvcmUgc3VibWl0dGluZyBhLHJldmlzaW9uLjwvZGl2PjxkaXY+PGJy PjwvZGl2PjxkaXY+VGhhbmsgeW91LDwvZGl2PjxkaXY+Sm9lbDwvZGl2PjxkaXY+PGJyPjwvZGl2 PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXYgaWQ9ImNvbXBvc2VyX3NpZ25hdHVy ZSI+PGRpdiBzdHlsZT0iZm9udC1zaXplOjg1JTtjb2xvcjojNTc1NzU3IiBkaXI9ImF1dG8iPlNl bnQgdmlhIHRoZSBTYW1zdW5nIEdhbGF4eSBTwq4gNiwgYW4gQVQmYW1wO1QgNEcgTFRFIHNtYXJ0 cGhvbmU8L2Rpdj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LXNpemU6MTAw JTtjb2xvcjojMDAwMDAwIj48IS0tIG9yaWdpbmFsTWVzc2FnZSAtLT48ZGl2Pi0tLS0tLS0tIE9y aWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS08L2Rpdj48ZGl2PkZyb206IE1paWthIEtvbXUgJmx0O21p aWthLmtvbXVAZXJpY3Nzb24uY29tJmd0OyA8L2Rpdj48ZGl2PkRhdGU6IDIvMjYvMTggIDA2OjU2 ICAoR01ULTA1OjAwKSA8L2Rpdj48ZGl2PlRvOiBKb2VsIEhhbHBlcm4gJmx0O2ptaEBqb2VsaGFs cGVybi5jb20mZ3Q7LCBnZW4tYXJ0QGlldGYub3JnIDwvZGl2PjxkaXY+Q2M6IGRyYWZ0LWlldGYt aGlwLXJmYzQ0MjMtYmlzLmFsbEBpZXRmLm9yZywgaGlwc2VjQGlldGYub3JnLCBpZXRmQGlldGYu b3JnIDwvZGl2PjxkaXY+U3ViamVjdDogUmU6IEdlbmFydCBsYXN0IGNhbGwgcmV2aWV3IG9mIGRy YWZ0LWlldGYtaGlwLXJmYzQ0MjMtYmlzLTE4IDwvZGl2PjxkaXY+PGJyPjwvZGl2PjwvZGl2Pkhp IEpvZWwsPGJyPjxicj50aGFua3MgZm9yIHRoZSBuaWNlIHJldmlldyEgTXkgc3VnZ2VzdGVkIGNo YW5nZXMgZm9yIEhJUCBhcmNoaXRlY3R1cmUgPGJyPmRvY3VtZW50IGFyZSBiZWxvdyAoaW4gImRp ZmYiIGZvcm1hdCkuPGJyPjxicj5PbiAwMi8xOC8yMDE4IDA3OjMzIEFNLCBKb2VsIEhhbHBlcm4g d3JvdGU6PGJyPiZndDsgUmV2aWV3ZXI6IEpvZWwgSGFscGVybjxicj4mZ3Q7IFJldmlldyByZXN1 bHQ6IFJlYWR5IHdpdGggTml0czxicj4mZ3Q7IDxicj4mZ3Q7IEkgYW0gdGhlIGFzc2lnbmVkIEdl bi1BUlQgcmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQuIFRoZSBHZW5lcmFsIEFyZWE8YnI+Jmd0OyBS ZXZpZXcgVGVhbSAoR2VuLUFSVCkgcmV2aWV3cyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJv Y2Vzc2VkPGJyPiZndDsgYnkgdGhlIElFU0cgZm9yIHRoZSBJRVRGIENoYWlyLiZuYnNwOyBQbGVh c2UgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdDxicj4mZ3Q7IGxpa2UgYW55IG90aGVyIGxhc3Qg Y2FsbCBjb21tZW50cy48YnI+Jmd0OyA8YnI+Jmd0OyBGb3IgbW9yZSBpbmZvcm1hdGlvbiwgcGxl YXNlIHNlZSB0aGUgRkFRIGF0PGJyPiZndDsgPGJyPiZndDsgJmx0O2h0dHBzOi8vdHJhYy5pZXRm Lm9yZy90cmFjL2dlbi93aWtpL0dlbkFydGZhcSZndDsuPGJyPiZndDsgPGJyPiZndDsgRG9jdW1l bnQ6IGRyYWZ0LWlldGYtaGlwLXJmYzQ0MjMtYmlzLTE4PGJyPiZndDsgUmV2aWV3ZXI6IEpvZWwg SGFscGVybjxicj4mZ3Q7IFJldmlldyBEYXRlOiAyMDE4LTAyLTE3PGJyPiZndDsgSUVURiBMQyBF bmQgRGF0ZTogMjAxOC0wMi0yNjxicj4mZ3Q7IElFU0cgVGVsZWNoYXQgZGF0ZTogTm90IHNjaGVk dWxlZCBmb3IgYSB0ZWxlY2hhdDxicj4mZ3Q7IDxicj4mZ3Q7IFN1bW1hcnk6IFRoaXMgZG9jdW1l bnQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9uIGFzIGFuIEluZm9ybWF0aW9uYWwgUkZDcy48YnI+ Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGUgZm9sbG93aW5nIGNv bW1lbnRzIG1heSBiZSB1c2VmdWwgZm9yIHRoZSBhdXRob3JzIHRvIGNvbnNpZGVyLjxicj4mZ3Q7 IDxicj4mZ3Q7IE1ham9yIGlzc3VlczogTi9BPGJyPiZndDsgPGJyPiZndDsgTWlub3IgaXNzdWVz Ojxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEluIHRoZSB0YWJsZSBpbiBz ZWN0aW9uIDIuMiAoVGVybXMgc3BlY2lmaWMgdG8gdGhpcyBhbmQgb3RoZXIgSElQPGJyPiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZG9jdW1lbnRzKSB0aGUgSG9zdCBJZGVudGl0 eSBIYXNoIGlzIGRlZmluZWQgYXMgIlRoZSBjcnlwdG9ncmFwaGljIGhhc2g8YnI+Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB1c2VkIGluIGNyZWF0aW5nIHRoZSBIb3N0IElkZW50 aXR5IFRhZyBmcm9tIHRoZSBIb3N0IElkZW50aXR5LiImbmJzcDsgSSBhbTxicj4mZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHByZXR0eSBzdXJlIHRoZSBsYXN0IHdvcmQgc2hvdWxk IGJlIElkZW50aWZpZXIsIG5vdCBJZGVudGl0eSwsIHdoaWNoPGJyPiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgbWF0Y2hlcyB0aGUgbWVhbmluZ3MgYW5kIHRoZSB1c2FnZSBpbiB0 aGUgZm9sbG93aW5nIHRlcm0uPGJyPjxicj5hZ3JlZWQuIFN1Z2dlc3RlZCBjaGFuZ2U6PGJyPjxi cj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSG9zdCBJZGVudGl0 eSBIYXNoJm5ic3A7IFRoZSBjcnlwdG9ncmFwaGljIGhhc2ggdXNlZDxicj4tJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluIGNyZWF0aW5nIHRoZSBIb3N0IElkZW50aXR5IFRhZyBmcm9t IHRoZSBIb3N0IElkZW50aXR5Ljxicj4rJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlu IGNyZWF0aW5nIHRoZSBIb3N0IElkZW50aXR5IFRhZyBmcm9tIHRoZSBIb3N0IElkZW50aWZpZXIu PGJyPiZuYnNwOyAoSSB3aWxsIG1vdmUgdGhlIGRlZmluaXRpb24gb2YgSG9zdCBJZGVudGlmaWVy IGVhcmxpZXIgc28gdGhhdCB0aGUgPGJyPnRlcm1zIGFwcGVhciBpbiBjaHJvbm9sb2dpY2FsIG9y ZGVyKTxicj48YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJbiBzZWN0aW9u IDQuMSBzZWNvbmQgcGFyYWdyYXBoLCBpdCBzZWVtcyBvZGQgdG8gcmVmZXIgdG8gdGhlPGJyPiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcHVibGljLXByaXZhdGUga2V5IHBhaXIg YXMgdGhlIHN0cnVjdHVyZSBvZiB0aGUgYWJzdHJhY3QgSG9zdCBJZGVudGl0eS48YnI+Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBHaXZlbiB0aGF0IHRoZSBlYXJsaWVyIHRleHQg cmVmZXJzIHRvIHRoZSBQdWJsaWMga2V5IGFzIHRoZSBIb3N0PGJyPiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgSWRlbnRpZmllciwgSSBhbSBub3Qgc3VyZSBob3cgeW91IHdhbnQg dG8gcmVmZXIgdG8gdGhlIHB1YmxpYy9wcml2YXRlIGtleTxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHBhaXIuJm5ic3A7IEJ1dCBJIGRvIG5vdCB0aGluayBpdCAiaXMiIHRo ZSBzdHJ1Y3R1cmUgb2YgdGhlIEhvc3QgSWRlbnRpdHkuPGJyPjxicj5BZ3JlZS4gU3VnZ2VzdGVk IHJlcGhyYXNpbmc6PGJyPjxicj4tJm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZSBvbmx5IGNvbXBsZXRl bHkgZGVmaW5lZCBzdHJ1Y3R1cmUgb2YgdGhlIEhvc3QgSWRlbnRpdHk8YnI+LSZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpcyB0aGF0IG9mIGEgcHVibGljL3ByaXZh dGUga2V5IHBhaXIuJm5ic3A7IEluIHRoaXMgY2FzZSwgdGhlIEhvc3Q8YnI+LSZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJZGVudGl0eSBpcyByZWZlcnJlZCB0byBi eSBpdHMgcHVibGljIGNvbXBvbmVudCwgdGhlIHB1YmxpYzxicj4rJm5ic3A7Jm5ic3A7Jm5ic3A7 IEFuIGlkZW50aXR5IGlzIGJhc2VkIG9uIHB1YmxpYy1wcml2YXRlIGtleSBjcnlwdG9ncmFwaHkg aW4gSElQLjxicj4rJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRo ZSBIb3N0IElkZW50aXR5IGlzIHJlZmVycmVkIHRvIGJ5IGl0cyBwdWJsaWMgY29tcG9uZW50LCB0 aGUgPGJyPnB1YmxpYzxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsga2V5Ljxicj48YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBJbiB0aGUgc2VjdGlvbiA0LjQgZGlzY3Vzc2lvbiBvZiBsb2NhbGx5IHNjb3BlZCBpZGVu dGlmaWVyIChMU0kpLCBpdDxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFw cGVhcnMgdGhhdCBhcHBsaWNhdGlvbnMgbmVlZCB0byBiZSBtb2RpZmllZCB0byB1c2UgdGhpcy4m bmJzcDsgUmVhZGluZyBiZXR3ZWVuPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgdGhlIGxpbmVzIG9mIHRoZSBzdGFjayBhcmNoaXRlY3R1cmUsIHRoZSBhY3R1YWwgYWR2YW50 YWdlIG9mIHVzaW5nIEhJUCB3aXRoPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgTFNJcyBpcyB0aGF0IHRoZSBhcHBsaWNhdGlvbiBjaGFuZ2VzIGNhbiBiZSByZXN0cmljdGVk IHRvIHdoYXRldmVyPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW5kaWNh dGlvbiBpcyB0byBiZSB1c2VkIHRoYXQgdGhlIHN0YWNrIGlzIHRvIHVzZSBISVAsIHJhdGhlciB0 aGFuIGNoYW5naW5nPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlIHBs YWNlcyB0aGF0IHVzZSBzb2NrYWRkcnMsIGV0Yy4mbmJzcDsgQnV0IHRoaXMgaXMgbm90IGNsZWFy bHkgc3RhdGVkIGhlcmUuPGJyPjxicj55ZXMsIHlvdSBhcmUgY29ycmVjdC4gSSB3b3VsZCBzdWdn ZXN0IHRoZSBmb2xsb3dpbmcgY2hhbmdlcyB0byBtYWtlIHRoaXMgPGJyPm1vcmUgY2xlYXI6PGJy Pjxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQSBIb3N0IElkZW50aXR5IFRhZyBp cyBhIDEyOC1iaXQgcmVwcmVzZW50YXRpb24gZm9yIGEgSG9zdDxicj4tJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElkZW50aXR5LiZuYnNwOyBJdCBpcyBjcmVhdGVk IGZyb20gYW4gSElILDxicj4tJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGFuIElQdjYgcHJlZml4IFtSRkM3MzQzXSBhbmQgYSBoYXNoIGlkZW50aWZpZXIuPGJyPism bmJzcDsmbmJzcDsmbmJzcDsgSWRlbnRpdHkuIER1ZSB0byBpdHMgc2l6ZSwgaXQgaXMgc3VpdGFi bGUgdG8gYmUgdXNlZCBpbiB0aGUgPGJyPmV4aXN0aW5nIHNvY2tldHMgQVBJIGluPGJyPismbmJz cDsmbmJzcDsmbmJzcDsgdGhlIHBsYWNlIG9mIElQdjYgYWRkcmVzc2VzIChlLmcuIGluIHNvY2th ZGRyX2luNiBzdHJ1Y3R1cmUsIDxicj5zaW42X2FkZHIgbWVtYmVyKSB3aXRob3V0IG1vZGlmeWlu ZyBhcHBsaWNhdGlvbnMuPGJyPismbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgSXQgaXMgY3JlYXRlZCBmcm9tIGFuIEhJSCwgYW4gSVB2NiBwcmVmaXggW1JGQzczNDNd PGJyPismbmJzcDsmbmJzcDsmbmJzcDsgYW5kIGEgaGFzaCBpZGVudGlmaWVyLjxicj48YnI+Li4u YW5kIHRoZSBmb2xsb3dpbmc6PGJyPjxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg QW4gTFNJIGlzIGEgMzItYml0IGxvY2FsaXplZCByZXByZXNlbnRhdGlvbiBmb3IgYSBIb3N0PGJy Pi0mbmJzcDsmbmJzcDsmbmJzcDsgSWRlbnRpdHkuIFRoZSBwdXJwb3NlIG9mIGFuIExTSSBpcyB0 byBmYWNpbGl0YXRlIHVzaW5nIEhvc3Q8YnI+KyZuYnNwOyZuYnNwOyZuYnNwOyBJZGVudGl0eS4g RHVlIHRvIGl0cyBzaXplLCBpdCBpcyBzdWl0YWJsZSB0byBiZSB1c2VkIGluIHRoZSA8YnI+ZXhp c3Rpbmcgc29ja2V0cyBBUEkgaW48YnI+KyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgcGxhY2Ugb2Yg SVB2NCBhZGRyZXNzZXMgKGUuZy4gaW4gc29ja2FkZHJfaW4gc3RydWN0dXJlLCA8YnI+c2luX2Fk ZHIgbWVtYmVyKSB3aXRob3V0IG1vZGlmeWluZyBhcHBsaWNhdGlvbnMuPGJyPismbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlIHB1cnBvc2Ugb2YgYW4gTFNJIGlz IHRvIGZhY2lsaXRhdGUgdXNpbmcgSG9zdDxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgSWRlbnRpdGllcyBpbiBleGlzdGluZyBBUElzIGZvciBJUHY0LWJhc2VkPGJyPi0mbmJzcDsm bmJzcDsmbmJzcDsgYXBwbGljYXRpb25zLiBCZXNpZGVzIGZhY2lsaXRhdGluZyBISVAtYmFzZWQg Y29ubmVjdGl2aXR5IGZvcjxicj4rJm5ic3A7Jm5ic3A7Jm5ic3A7IGFwcGxpY2F0aW9ucy48YnI+ KyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBMU0lzIGFyZSBuZXZl ciB0cmFuc21pdHRlZCBvbiB0aGUgd2lyZTsgd2hlbiBhbiBhcHBsaWNhdGlvbjxicj4rJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNlbmRzIGRhdGEgdXNpbmcgYSBw YWlyIG9mIExTSXMsIHRoZSBISVAgbGF5ZXIgKG9yIHNvY2tldHM8YnI+KyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBoYW5kbGVyKSB0cmFuc2xhdGVzIHRoZSBMU0lz IHRvIHRoZSBjb3JyZXNwb25kaW5nIEhJVHMsIGFuZDxicj4rJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHZpY2UgdmVyc2EgZm9yIHJlY2VpdmluZyBvZiBkYXRhLjxi cj4rJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEJlc2lkZXMgZmFj aWxpdGF0aW5nIEhJUC1iYXNlZCBjb25uZWN0aXZpdHkgZm9yPGJyPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBsZWdhY3kgSVB2NCBhcHBsaWNhdGlvbnMsIHRoZSBMU0lzIGFyZSBiZW5l ZmljaWFsIGluIHR3byBvdGhlcjxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2Nl bmFyaW9zIFtSRkM2NTM4XS48YnI+PGJyPkBAIC03MTIsNiArNzIxLDE0IEBAPGJyPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0byBmYWNpbGl0YXRlIGJhY2t3YXJkIGNvbXBhdGliaWxp dHkgd2l0aCBleGlzdGluZyBuZXR3b3JraW5nPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBBUElzIGFuZCBzdGFja3MuJmx0Oy90Jmd0Ozxicj48YnI+Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBJbiBzZWN0aW9uIDUuMSBwYXJhZ3JhcGggMywgdGhlIHRleHQgdGFs a3MgYWJvdXQgYSBjb25uZWN0aW5nIGNsaWVudCBub3Q8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBzcGVjaWZ5aW5nIGEgcmVzcG9uZGVyIGlkZW50aWZpZXIgKEhJUCBPcHBv cnR1bmlzdGljIG1vZGUpIGluIG9yZGVyIHRvPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgZW5hYmxlIGxvYWQgYmFsYW5jaW5nLiZuYnNwOyBJIHRoaW5rIHRoZSB0ZXh0IHdv dWxkIGJlIGhlbHBlZCBieSBhbiBleGFtcGxlIG9mPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgaG93IGFuIGluaXRpYXRvciBtaWdodCBrbm93IHRvIGRvIHRoaXMsIHJhdGhl ciB0aGFuIGp1c3Qgbm90IHVzaW5nIEhJUC48YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBBbHNvLCBpdCB3b3VsZCBiZSBnb29kIGlmIHRoZSB0ZXh0IHdhcyBleHBsaWNpdCBh cyB0byB3aGV0aGVyIG9yIG5vdCB0aGVyZTxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHdhcyBhIHdheSB0byBzdXBwb3J0IGxvYWQgYmFsYW5jaW5nIC8gbXVsdGkgc2VydmVy cyB3aXRob3V0IGVpdGhlciB1c2luZyBhPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgc2hhcmVkIGlkZW50aXR5IG9yIHNhY3JpZmljaW5nIHNlY3VyaXR5IGJ5IHVzaW5nIE9w cG9ydHVuaXN0aWMgSElQLjxicj48YnI+YWdyZWVkLCB0aGUgZGVzY3JpcHRpb24gb2YgdGhpcyB3 YXMgcXVpdGUgc2hvcnQuIFdvdWxkIHRoZSBmb2xsb3dpbmcgPGJyPmNsYXJpZnkgeW91ciBjb25j ZXJucz88YnI+PGJyPismbmJzcDsmbmJzcDsmbmJzcDsgQXQgdGhlIHNlcnZlciBzaWRlLCB1dGls aXppbmcgRE5TIGlzIGEgYmV0dGVyIGFsdGVybmF0aXZlIHRoYW4gYTxicj4rJm5ic3A7Jm5ic3A7 Jm5ic3A7IHNoYXJlZCBIb3N0IElkZW50aXR5IHRvIGltcGxlbWVudCBsb2FkIGJhbGFuY2luZy4m bmJzcDsgQSBzaW5nbGUgRlFETiA8YnI+ZW50cnkgY2FuIGJlIGNvbmZpZ3VyZWQ8YnI+KyZuYnNw OyZuYnNwOyZuYnNwOyB0byByZWZlciB0byBtdWx0aXBsZSBIb3N0IElkZW50aXRpZXMuIEVhY2gg b2YgdGhlIEZRRE4gZW50cmllczxicj4rJm5ic3A7Jm5ic3A7Jm5ic3A7IGNhbiBiZSBhc3NvY2lh dGVkIHdpdGggdGhlIHJlbGF0ZWQgbG9jYXRvcnMsIG9yIGEgc2luZ2xlPGJyPismbmJzcDsmbmJz cDsmbmJzcDsgc2hhcmVkIGxvY2F0b3IgaW4gdGhlIGNhc2UgdGhlIHNlcnZlcnMgYXJlIHVzaW5n IHRoZSBzYW1lIEhJUCA8YnI+cmVuZGV6dm91cyBzZXJ2ZXI8YnI+KyZuYnNwOyZuYnNwOyZuYnNw OyBvciBISVAgcmVsYXkgc2VydmVyLjxicj4rPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJbnN0ZWFkIG9mIGR1cGxpY2F0aW5nIGlkZW50 aXRpZXMsIEhJUCBvcHBvcnR1bmlzdGljIG1vZGU8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNhbiBiZSBlbXBsb3llZCwgd2hlcmUgdGhl IGluaXRpYXRvciBsZWF2ZXMgb3V0IHRoZSBpZGVudGlmaWVyPGJyPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBvZiB0aGUgcmVzcG9uZGVyIHdo ZW4gaW5pdGlhdGluZyB0aGUga2V5IGV4Y2hhbmdlIGFuZCBsZWFybnM8YnI+QEAgLTczMSwxNCAr NzY2LDIxIEBAPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBpdCB1cG9uIHRoZSBjb21wbGV0aW9uIG9mIHRoZSBleGNoYW5nZS4gVGhlIHRy YWRlb2ZmcyBhcmU8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHJlbGF0ZWQgdG8gbG93ZXJlZCBzZWN1cml0eSBndWFyYW50ZWVzLCBidXQg YSBiZW5lZml0IG9mIHRoZTxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgYXBwcm9hY2ggaXMgdG8gYXZvaWQgcHVibGlzaGluZyBvZiBIb3N0 IElkZW50aWZpZXJzIGluIGFueTxicj4tJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGRpcmVjdG9yaWVzIFtrb211LWxlYXBdLiZuYnNwOyBUaGUgYXBwcm9hY2ggY291 bGQgYWxzbyBiZSB1c2VkPGJyPi0mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgZm9yIGxvYWQgYmFsYW5jaW5nIHB1cnBvc2VzIGF0IHRoZSBISVAgbGF5ZXIgYmVjYXVz ZSB0aGU8YnI+LSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpZGVu dGl0eSBvZiB0aGUgcmVzcG9uZGVyIGNhbiBiZSBkZWNpZGVkIGR5bmFtaWNhbGx5IGR1cmluZzxi cj4tJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSBrZXkgZXhj aGFuZ2UuIFRodXMsIHRoZSBhcHByb2FjaCBoYXM8YnI+LSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgcG90ZW50aWFsIHRvIGJlIHVzZWQgYXMgYSBISVAtbGF5 ZXIgImFueWNhc3QiLCBlaXRoZXI8YnI+LSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBkaXJlY3RseSBiZXR3ZWVuIHR3byBob3N0cyBvciBpbmRpcmVjdGx5IHRocm91 Z2ggdGhlPGJyPi0mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVu ZGV6dm91cyBzZXJ2aWNlIFtrb211LWRpc3NdLjxicj4rJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRpcmVjdG9yaWVzIFtrb211LWxlYXBdLiBTaW5jZSBtYW55IHB1 YmxpYzxicj4rJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNlcnZl cnMgYWxyZWFkeSBlbXBsb3kgRE5TIGFzIHRoZWlyIGRpcmVjdG9yeSwgb3Bwb3J0dW5pc3RpYyBt b2RlPGJyPismbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbWF5IGJl IG1vcmUgc3VpdGFibGUgZm9yLCBlLmcsIHBlZXItdG8tcGVlciBjb25uZWN0aXZpdHkuPGJyPjxi cj4rJm5ic3A7Jm5ic3A7Jm5ic3A7IEhJUCBvcHBvcnR1bmlzdGljIG1vZGUgY291bGQgYmUgdXRp bGl6ZWQgaW4gYXNzb2NpYXRpb248YnI+KyZuYnNwOyZuYnNwOyZuYnNwOyB3aXRoIEhJUCByZW5k ZXp2b3VzIHNlcnZlcnMgb3IgSElQIHJlbGF5IHNlcnZlcnM8YnI+KyZuYnNwOyZuYnNwOyZuYnNw OyBba29tdS1kaXNzXS4gSW4gc3VjaCBhIHNjZW5hcmlvLCB0aGUgSW5pdGlhdG9yIHNlbmRzPGJy PismbmJzcDsmbmJzcDsmbmJzcDsgYW4gSTEgbWVzc2FnZSB3aXRoIGEgd2lsZGNhcmQgZGVzdGlu YXRpb24gSElUIHRvIHRoZSBsb2NhdG9yIG9mIGEgSElQPGJyPismbmJzcDsmbmJzcDsmbmJzcDsg cmVuZGV6dm91cy9yZWxheSBzZXJ2ZXIuIFdoZW4gdGhlIHJlY2VpdmluZyByZW5kZXp2b3VzL3Jl bGF5IHNlcnZlciBpczxicj4rJm5ic3A7Jm5ic3A7Jm5ic3A7IHNlcnZpbmcgbXVsdGlwbGUgcmVn aXN0ZXJlZCBSZXNwb25kZXJzLCB0aGUgc2VydmVyIGNhbiBjaG9vc2U8YnI+KyZuYnNwOyZuYnNw OyZuYnNwOyB0aGUgdWx0aW1hdGUgZGVzdGluYXRpb24gSElULCB0aHVzIGFjdGluZyBhcyBhIEhJ UCBiYXNlZCBsb2FkPGJyPismbmJzcDsmbmJzcDsmbmJzcDsgYmFsYW5jZXIuIEhvd2V2ZXIsIHRo aXMgYXBwcm9hY2ggaXMgc3RpbGwgZXhwZXJpbWVudGFsIGFuZDxicj4rJm5ic3A7Jm5ic3A7Jm5i c3A7IHJlcXVpcmVzIGZ1cnRoZXIgaW52ZXN0aWdhdGlvbi48YnI+Kzxicj48YnI+KEkgY2FuIGFs c28gcmVtb3ZlIHRoZSBsYXN0IHBhcmFncmFwaCBpZiBpdCBpcyBzdGlsbCB1bmNsZWFyKTxicj48 YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBHaXZlbiB0aGF0IHNlY3Rpb24g NSBpcyB0aXRsZWQgIk5ldyBTdGFjayBBcmNoaXRlY3R1cmUiLCBJIHRoaW5rIGl0IHdvdWxkPGJy PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYmUgaGVscGZ1bCBpZiB0aGUgc2Vj dGlvbiB3ZXJlIGV4cGxpY2l0IGFzIHRvIHdoZXJlIHRoZSBISVAgbG9naWMgbGl2ZXM8YnI+Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZWxhdGl2ZSB0byB0aGUgSVAgYW5kIFVE UC9UQ1AgcG9ydGlvbnMgb2YgdGhlIGhvc3Qgc3RhY2suJm5ic3A7IFRoaXMgd291bGQgaGVscDxi cj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSByZWFkZXIgaGF2ZSB0aGUg cmlnaHQgbW9kZWwgZm9yIGludGVycHJldGluZyBzZWN0aW9uIDYuMiBhbmQgOC4xLjxicj48YnI+ SSB3b3VsZCBzdWdnZXN0IHRvIGFkZCBhIG5ldyBwYXJhZ3JhcGggaW4gdGhlIGVuZCBvZiB0aGUg c2VjdGlvbiB0byA8YnI+Y2xhcmlmeSB0aGlzOjxicj48YnI+KyZuYnNwOyZuYnNwOyZuYnNwOyBI SVAgbGF5ZXIgaXMgbG9naWNhbGx5IGxvY2F0ZWQgYXQgbGF5ZXIgMy41LCBiZXR3ZWVuIHRoZTxi cj4rJm5ic3A7Jm5ic3A7Jm5ic3A7IHRyYW5zcG9ydCBhbmQgbmV0d29yayBsYXllcnMsIGluIHRo ZSBuZXR3b3JraW5nIHN0YWNrLiBJdCBhY3RzPGJyPismbmJzcDsmbmJzcDsmbmJzcDsgYXMgc2hp bSBsYXllciBmb3IgdHJhbnNwb3J0IGRhdGEgdXRpbGl6aW5nIExTSXMgb3IgSElUcywgYnV0PGJy PismbmJzcDsmbmJzcDsmbmJzcDsgbGVhdmVzIG90aGVyIGRhdGEgaW50YWN0LiBISVAgbGF5ZXIg dHJhbnNsYXRlcyBiZXR3ZWVuIHRoZSB0d288YnI+KyZuYnNwOyZuYnNwOyZuYnNwOyBmb3JtcyBv ZiBISVAgaWRlbnRpZmllcnMgb3JpZ2luYXRpbmcgZnJvbSB0aGUgdHJhbnNwb3J0IGxheWVyPGJy PismbmJzcDsmbmJzcDsmbmJzcDsgaW50byByb3V0YWJsZSBJUHY0L0lQdjYgYWRkcmVzc2VzIGZv ciB0aGUgbmV0d29yayBsYXllciwgYW5kPGJyPismbmJzcDsmbmJzcDsmbmJzcDsgdmljZSB2ZXJz YSBmb3IgdGhlIHJldmVyc2UgZGlyZWN0aW9uLjxicj48YnI+Jmd0OyBOaXRzL2VkaXRvcmlhbCBj b21tZW50czo8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTZWN0aW9uIDQu MiB0aGlyZCBzZW50ZW5jZSAiSXQgaXMgcG9zc2libGUgdG8gZm9yIC4uLiIgc2hvdWxkIGJlICJJ dCBpczxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBvc3NpYmxlIGZvciAu Li4iPGJyPjxicj5Hb29kIGNhdGNoLCB3aWxsIGZpeCB0aGlzIHRvby48YnI+PGJyPkpvZWwsIHNo b3VsZCBJIGdvIGFoZWFkIGFuZCBzdWJtaXQgYSBuZXcgdmVyc2lvbiAoYmlzLTE5KSBvZiB0aGUg ZG9jdW1lbnQ/PGJyPjwvYm9keT48L2h0bWw+ ----_com.samsung.android.email_10905280141180150-- From nobody Tue Feb 27 00:38:09 2018 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BD65B1200B9; Tue, 27 Feb 2018 00:38:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tianran Zhou To: Cc: hipsec@ietf.org, ietf@ietf.org, draft-ietf-hip-native-nat-traversal.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151972068371.29322.12949981324078586743@ietfa.amsl.com> Date: Tue, 27 Feb 2018 00:38:03 -0800 Archived-At: Subject: [Hipsec] Opsdir last call review of draft-ietf-hip-native-nat-traversal-27 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 08:38:04 -0000 Reviewer: Tianran Zhou Review result: Ready I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. I did not see any special operational or network management related issue. This document is clear to me and is ready for publication. Cheers, Tianran From nobody Tue Feb 27 03:13:05 2018 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF73129C59; Tue, 27 Feb 2018 03:12:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: hipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151972997646.29211.8215154662540113651@ietfa.amsl.com> Date: Tue, 27 Feb 2018 03:12:56 -0800 Archived-At: Subject: [Hipsec] I-D Action: draft-ietf-hip-rfc4423-bis-19.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 11:12:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol WG of the IETF. Title : Host Identity Protocol Architecture Authors : Robert Moskowitz Miika Komu Filename : draft-ietf-hip-rfc4423-bis-19.txt Pages : 43 Date : 2018-02-27 Abstract: This memo describes a new namespace, the Host Identity namespace, and a new protocol layer, the Host Identity Protocol, between the internetworking and transport layers. Herein are presented the basics of the current namespaces, their strengths and weaknesses, and how a new namespace will add completeness to them. The roles of this new namespace in the protocols are defined. This document obsoletes RFC 4423 and addresses the concerns raised by the IESG, particularly that of crypto agility. It incorporates lessons learned from the implementations of RFC 5201 and goes further to explain how HIP works as a secure signaling channel. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc4423-bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-hip-rfc4423-bis-19 https://datatracker.ietf.org/doc/html/draft-ietf-hip-rfc4423-bis-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-rfc4423-bis-19 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Feb 27 03:18:38 2018 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA0341270B4 for ; Tue, 27 Feb 2018 03:18:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 Qv3mgGGZV5qx for ; Tue, 27 Feb 2018 03:18:31 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 030091273B1 for ; Tue, 27 Feb 2018 03:18:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519730307; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=lL4fwM8RvFSu5HHsbpRYpgTt8WioSgm8a+hrO+hSinU=; b=QHCvHDf4Z/IFRrJkrljQtx+Jnq8rAnKHpVvl3qnaQdi1gj/FOl9NqMP+VMBEPko9 PWeG3EPqrUNoqLKsmsjIuLtR2J3gY4BQCIB2Ef/dS+ULqRjPLw2B/687pkj3+JPI kUCkOt3nGJX4ytAAvr5+e63ZAOskmUSS1q03UudjMn4=; X-AuditID: c1b4fb25-083ff70000002d5f-b3-5a953e834163 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id C3.C2.11615.38E359A5; Tue, 27 Feb 2018 12:18:27 +0100 (CET) Received: from [131.160.51.186] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.89) with Microsoft SMTP Server id 14.3.352.0; Tue, 27 Feb 2018 12:18:27 +0100 To: jmh.direct , Joel Halpern , CC: , , References: <34.48.17338.F3C149A5@sessmg11.ericsson.net> From: Miika Komu Organization: Ericsson AB Message-ID: <30a11644-ebb9-54e8-2d2e-465a0f35852c@ericsson.com> Date: Tue, 27 Feb 2018 13:18:26 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <34.48.17338.F3C149A5@sessmg11.ericsson.net> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM2J7uG6z3dQog22tMhbnThxjtbj66jOL xdRFk5ktnm2cz2KxbdF6ZouPp94wObB5LFnyk8nj3JTvjAFMUVw2Kak5mWWpRfp2CVwZU4/N Yyw4n1pxqH8LcwPj2ZAuRk4OCQETiYlXepi6GLk4hAQOM0p8eXKADcJZwyixdO4URpAqYQFX ibVHGtlBbBGBVIlFWyeBxZkFgiWOzfrCAmILCVhIrNixAMxmE9CSWHXnOjOIzS8gKbGhYTeY zStgL7H1+FOwGhYBVYlJ+xeC2aICERKdK+ezQNQISpyc+QTM5hSwlPi1ZyEbxC4LiZnzz0Pt FZe49WQ+E4StLbFs4Wug+RxAN6hIXDwWPIFRaBaSSbOQdM9C0j0LSfcCRpZVjKLFqcVJuelG xnqpRZnJxcX5eXp5qSWbGIFxcHDLb9UdjJffOB5iFOBgVOLhjdaeGiXEmlhWXJl7iFGCg1lJ hHfl4slRQrwpiZVVqUX58UWlOanFhxilOViUxHnnCLdHCQmkJ5akZqemFqQWwWSZODilGhit Fi6xTehdYHpCYttNrW6W+8tjrvdkWwp+4uDo4a8561aW8frCOQn+XYwp/PEJubXqu3U7p86q kn/0IjQpbUdoEb/+sWylptuvVQwXB35+4v/h9mFf3qbfVYsrZ/+8dDbhQY2Wx6TejodyO06I +36ZaM5yXv2oCOu+xvm6skzzdt1+ZSXlt12JpTgj0VCLuag4EQBbtwmsfwIAAA== Archived-At: Subject: Re: [Hipsec] Genart last call review of draft-ietf-hip-rfc4423-bis-18 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 11:18:33 -0000 Hi Joel, done! The new version with your suggested changes and diff are here: https://www.ietf.org/internet-drafts/draft-ietf-hip-rfc4423-bis-19.txt https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-hip-rfc4423-bis-19 P.S. I took the liberty to fix a small typo from the text: drop HIP-base connectivity -> drop HIP-based connectivity On 02/26/2018 04:39 PM, jmh.direct wrote: > These changes very nicely address my concerns.b You should check with=20 > your chair,and AD before submitting a,revision. >=20 > Thank you, > Joel >=20 >=20 >=20 > Sent via the Samsung Galaxy S=C2=AE 6, an AT&T 4G LTE smartphone >=20 > -------- Original message -------- > From: Miika Komu > Date: 2/26/18 06:56 (GMT-05:00) > To: Joel Halpern , gen-art@ietf.org > Cc: draft-ietf-hip-rfc4423-bis.all@ietf.org, hipsec@ietf.org, ietf@ietf= =2Eorg > Subject: Re: Genart last call review of draft-ietf-hip-rfc4423-bis-18 >=20 > Hi Joel, >=20 > thanks for the nice review! My suggested changes for HIP architecture > document are below (in "diff" format). >=20 > On 02/18/2018 07:33 AM, Joel Halpern wrote: > > Reviewer: Joel Halpern > > Review result: Ready with Nits > > > > I am the assigned Gen-ART reviewer for this draft. The General Area > > Review Team (Gen-ART) reviews all IETF documents being processed > > by the IESG for the IETF Chair.=C2=A0 Please treat these comments ju= st > > like any other last call comments. > > > > For more information, please see the FAQ at > > > > . > > > > Document: draft-ietf-hip-rfc4423-bis-18 > > Reviewer: Joel Halpern > > Review Date: 2018-02-17 > > IETF LC End Date: 2018-02-26 > > IESG Telechat date: Not scheduled for a telechat > > > > Summary: This document is ready for publication as an Informational = RFCs. > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The following comments may be us= eful for the authors to consider. > > > > Major issues: N/A > > > > Minor issues: > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 In the table in section 2.2 (Terms spe= cific to this and other HIP > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 documents) the Host Identity Hash is d= efined as "The=20 > cryptographic hash > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 used in creating the Host Identity Tag= from the Host Identity." =20 > I am > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 pretty sure the last word should be Id= entifier, not Identity,, which > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 matches the meanings and the usage in = the following term. >=20 > agreed. Suggested change: >=20 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Host Identity Hash=C2=A0 Th= e cryptographic hash used > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 in creating the Host Identity Tag from = the Host Identity. > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 in creating the Host Identity Tag from = the Host Identifier. > =C2=A0 (I will move the definition of Host Identifier earlier so that = the > terms appear in chronological order) >=20 > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 In section 4.1 second paragraph, it se= ems odd to refer to the > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 public-private key pair as the structu= re of the abstract Host=20 > Identity. > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Given that the earlier text refers to = the Public key as the Host > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Identifier, I am not sure how you want= to refer to the=20 > public/private key > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 pair.=C2=A0 But I do not think it "is"= the structure of the Host=20 > Identity. >=20 > Agree. Suggested rephrasing: >=20 > -=C2=A0=C2=A0=C2=A0 The only completely defined structure of the Host I= dentity > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 is that of a public/private= key pair.=C2=A0 In this case, the Host > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Identity is referred to by = its public component, the public > +=C2=A0=C2=A0=C2=A0 An identity is based on public-private key cryptogr= aphy in HIP. > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The Host Identity is referr= ed to by its public component, the > public > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 key. >=20 > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 In the section 4.4 discussion of local= ly scoped identifier (LSI), it > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 appears that applications need to be m= odified to use this. =20 > Reading between > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the lines of the stack architecture, t= he actual advantage of=20 > using HIP with > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 LSIs is that the application changes c= an be restricted to whatever > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 indication is to be used that the stac= k is to use HIP, rather=20 > than changing > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the places that use sockaddrs, etc.=C2= =A0 But this is not clearly=20 > stated here. >=20 > yes, you are correct. I would suggest the following changes to make thi= s > more clear: >=20 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A Host Identity Tag is a 128-bit repres= entation for a Host > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Identity.=C2=A0 It is creat= ed from an HIH, > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 an IPv6 prefix [RFC7343] an= d a hash identifier. > +=C2=A0=C2=A0=C2=A0 Identity. Due to its size, it is suitable to be use= d in the > existing sockets API in > +=C2=A0=C2=A0=C2=A0 the place of IPv6 addresses (e.g. in sockaddr_in6 s= tructure, > sin6_addr member) without modifying applications. > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 It is created from an HIH, = an IPv6 prefix [RFC7343] > +=C2=A0=C2=A0=C2=A0 and a hash identifier. >=20 > ...and the following: >=20 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 An LSI is a 32-bit localized representa= tion for a Host > -=C2=A0=C2=A0=C2=A0 Identity. The purpose of an LSI is to facilitate us= ing Host > +=C2=A0=C2=A0=C2=A0 Identity. Due to its size, it is suitable to be use= d in the > existing sockets API in > +=C2=A0=C2=A0=C2=A0 the place of IPv4 addresses (e.g. in sockaddr_in st= ructure, > sin_addr member) without modifying applications. > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The purpose of an LSI is to= facilitate using Host > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Identities in existing APIs for IPv4-ba= sed > -=C2=A0=C2=A0=C2=A0 applications. Besides facilitating HIP-based connec= tivity for > +=C2=A0=C2=A0=C2=A0 applications. > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 LSIs are never transmitted = on the wire; when an application > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sends data using a pair of = LSIs, the HIP layer (or sockets > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 handler) translates the LSI= s to the corresponding HITs, and > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 vice versa for receiving of= data. > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Besides facilitating HIP-ba= sed connectivity for > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 legacy IPv4 applications, the LSIs are = beneficial in two other > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 scenarios [RFC6538]. >=20 > @@ -712,6 +721,14 @@ > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 to facilitate backward compatibility wi= th existing networking > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 APIs and stacks. >=20 > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 In section 5.1 paragraph 3, the text t= alks about a connecting=20 > client not > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 specifying a responder identifier (HIP= Opportunistic mode) in=20 > order to > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 enable load balancing.=C2=A0 I think t= he text would be helped by an=20 > example of > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 how an initiator might know to do this= , rather than just not=20 > using HIP. > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Also, it would be good if the text was= explicit as to whether or=20 > not there > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 was a way to support load balancing / = multi servers without=20 > either using a > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 shared identity or sacrificing securit= y by using Opportunistic HIP. >=20 > agreed, the description of this was quite short. Would the following > clarify your concerns? >=20 > +=C2=A0=C2=A0=C2=A0 At the server side, utilizing DNS is a better alter= native than a > +=C2=A0=C2=A0=C2=A0 shared Host Identity to implement load balancing.=C2= =A0 A single FQDN > entry can be configured > +=C2=A0=C2=A0=C2=A0 to refer to multiple Host Identities. Each of the F= QDN entries > +=C2=A0=C2=A0=C2=A0 can be associated with the related locators, or a s= ingle > +=C2=A0=C2=A0=C2=A0 shared locator in the case the servers are using th= e same HIP > rendezvous server > +=C2=A0=C2=A0=C2=A0 or HIP relay server. > + > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Instead of dupl= icating identities, HIP opportunistic mode > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 can be employed= , where the initiator leaves out the identifier > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 of the responde= r when initiating the key exchange and learns > @@ -731,14 +766,21 @@ > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 it upon the com= pletion of the exchange. The tradeoffs are > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 related to lowe= red security guarantees, but a benefit of the > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 approach is to = avoid publishing of Host Identifiers in any > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 directories [komu-leap].=C2= =A0 The approach could also be used > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 for load balancing purposes= at the HIP layer because the > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 identity of the responder c= an be decided dynamically during > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the key exchange. Thus, the= approach has > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the potential to be used as= a HIP-layer "anycast", either > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 directly between two hosts = or indirectly through the > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 rendezvous service [komu-di= ss]. > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 directories [komu-leap]. Si= nce many public > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 servers already employ DNS = as their directory, opportunistic mode > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 may be more suitable for, e= =2Eg, peer-to-peer connectivity. >=20 > +=C2=A0=C2=A0=C2=A0 HIP opportunistic mode could be utilized in associa= tion > +=C2=A0=C2=A0=C2=A0 with HIP rendezvous servers or HIP relay servers > +=C2=A0=C2=A0=C2=A0 [komu-diss]. In such a scenario, the Initiator send= s > +=C2=A0=C2=A0=C2=A0 an I1 message with a wildcard destination HIT to th= e locator of a HIP > +=C2=A0=C2=A0=C2=A0 rendezvous/relay server. When the receiving rendezv= ous/relay server is > +=C2=A0=C2=A0=C2=A0 serving multiple registered Responders, the server = can choose > +=C2=A0=C2=A0=C2=A0 the ultimate destination HIT, thus acting as a HIP = based load > +=C2=A0=C2=A0=C2=A0 balancer. However, this approach is still experimen= tal and > +=C2=A0=C2=A0=C2=A0 requires further investigation. > + >=20 > (I can also remove the last paragraph if it is still unclear) >=20 > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Given that section 5 is titled "New St= ack Architecture", I think=20 > it would > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 be helpful if the section were explici= t as to where the HIP=20 > logic lives > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 relative to the IP and UDP/TCP portion= s of the host stack.=C2=A0 This=20 > would help > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the reader have the right model for in= terpreting section 6.2 and=20 > 8.1. >=20 > I would suggest to add a new paragraph in the end of the section to > clarify this: >=20 > +=C2=A0=C2=A0=C2=A0 HIP layer is logically located at layer 3.5, betwee= n the > +=C2=A0=C2=A0=C2=A0 transport and network layers, in the networking sta= ck. It acts > +=C2=A0=C2=A0=C2=A0 as shim layer for transport data utilizing LSIs or = HITs, but > +=C2=A0=C2=A0=C2=A0 leaves other data intact. HIP layer translates betw= een the two > +=C2=A0=C2=A0=C2=A0 forms of HIP identifiers originating from the trans= port layer > +=C2=A0=C2=A0=C2=A0 into routable IPv4/IPv6 addresses for the network l= ayer, and > +=C2=A0=C2=A0=C2=A0 vice versa for the reverse direction. >=20 > > Nits/editorial comments: > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Section 4.2 third sentence "It is poss= ible to for ..." should be=20 > "It is > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 possible for ..." >=20 > Good catch, will fix this too. >=20 > Joel, should I go ahead and submit a new version (bis-19) of the docume= nt? From nobody Tue Feb 27 07:06:58 2018 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0897012D963; Tue, 27 Feb 2018 07:06:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Sean Turner To: Cc: draft-ietf-hip-rfc4423-bis.all@ietf.org, hipsec@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151974401093.28581.6727583492292312298@ietfa.amsl.com> Date: Tue, 27 Feb 2018 07:06:51 -0800 Archived-At: Subject: [Hipsec] Secdir last call review of draft-ietf-hip-rfc4423-bis-19 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 15:06:51 -0000 Reviewer: Sean Turner Review result: Has Nits This is a bis draft of the HIP (Host Identity Protocol) Architecture and because of that I focused on what’s changed (i.e., I reviewed the diffs from https://www.ietf.org/rfcdiff?url1=rfc4423&url2=draft-ietf-hip-rfc4423-bis-18). It’s still HIP but with a slightly expanded scope; it’s still Informational. 1. s4: The one place where I’ll step out from not looking at the old is a similar-ish recommendation that was in the RF4423: In this document, the non-cryptographic forms of HI and HIP are presented to complete the theory of HI, but they should not be implemented as they could produce worse denial-of-service attacks than the Internet has without Host Identity. Should the should not be a SHOULD NOT? 2. (none security) s4.4: Is the paragraph about IPv4 vs IPv6 vs LSI really necessary? I.e., is this yet another thing that folks are going to use to not transition to IPv6? 3. s11.2: Isn’t an additional drawback the need to have a HIP-aware firewall? From nobody Wed Feb 28 07:34:09 2018 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C21B12DA03 for ; Wed, 28 Feb 2018 07:34:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 4Ai3dTqNMjYI for ; Wed, 28 Feb 2018 07:34:05 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09DC712D94B for ; Wed, 28 Feb 2018 07:34:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519832042; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=umqc2P2jMbmmF4SvTtMDbEfoqs/3IzA9/Z80YzCIYGU=; b=Lsa9Q+NpCOoZQ2rEaCiCIAdSU0qD4oM+Awjn8vEiFhvxmsZHzYReO4s9sVEmPwlG AFj9vdH6rkBthUurv1IfgRKBEBCIzAkDyVt+e16FeTr3wXuSb3/aw8v7AOCd5aI3 JUJw7qvNUl3nx+hdaCgcyeKkbrJmRYT9QPW6My44H+w=; X-AuditID: c1b4fb2d-4b1ff70000005540-9b-5a96cbea732a Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id A8.77.21824.AEBC69A5; Wed, 28 Feb 2018 16:34:02 +0100 (CET) Received: from [131.160.51.186] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.74) with Microsoft SMTP Server id 14.3.352.0; Wed, 28 Feb 2018 16:34:02 +0100 To: Sean Turner , CC: , , References: <151974401093.28581.6727583492292312298@ietfa.amsl.com> From: Miika Komu Organization: Ericsson AB Message-ID: <61df7006-3ce9-2929-b58d-af500fa40ea8@ericsson.com> Date: Wed, 28 Feb 2018 17:34:02 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <151974401093.28581.6727583492292312298@ietfa.amsl.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM2K7h+6r09OiDE5ftLI4d+IYq8XURZOZ LZ5tnM9icWVVI7PFh4UPWRxYPZYs+cnkcfAgYwBTFJdNSmpOZllqkb5dAlfGhE8XmAp+yFY8 XjCXvYHxnngXIyeHhICJxJqPk1m6GLk4hAQOM0o8PnWOCSQhJLCGUeLQE6AEB4ewgKvEianZ IGERAWOJx30zwUqYBYIljs36wgJR7iyxeuZ0sDibgJbEqjvXmUFsfgFJiQ0Nu8FsXgF7ia0d z8DqWQRUJX50/WYDsUUFIiQ6V85ngagRlDg5E2Itp4CLxJJNBhCrLCRmzj/PCGGLS9x6Mh/q BG2JZQtfM4OUCwmoSFw8FjyBUWgWkkGzkHTPQtI9C0n3AkaWVYyixanFxbnpRsZ6qUWZycXF +Xl6eaklmxiBQX9wy2/dHYyrXzseYhTgYFTi4dXfMS1KiDWxrLgy9xCjBAezkgjv6e1AId6U xMqq1KL8+KLSnNTiQ4zSHCxK4rwnPXmjhATSE0tSs1NTC1KLYLJMHJxSDYydxt2z1qwrOSW9 ZMGy/NLW+RMnr9vSGRv6dInXhlqL48VTdW50bFJlPTfLiT9++VLNM6rtu/9pd7+XK6nzjp3n ZF9nWll1/vGlRy079CdKtXnOOHn3mde5SYmuDGFdGzymq+hdTfEtbHJ19/2REHCMq7qW77hJ GmOg9I7/HjPELuy6/zCf202JpTgj0VCLuag4EQA49RhQdgIAAA== Archived-At: Subject: Re: [Hipsec] Secdir last call review of draft-ietf-hip-rfc4423-bis-19 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 15:34:07 -0000 Hi Sean, On 02/27/2018 05:06 PM, Sean Turner wrote: > Reviewer: Sean Turner > Review result: Has Nits >=20 > This is a bis draft of the HIP (Host Identity Protocol) Architecture an= d > because of that I focused on what=E2=80=99s changed (i.e., I reviewed t= he diffs from > https://www.ietf.org/rfcdiff?url1=3Drfc4423&url2=3Ddraft-ietf-hip-rfc44= 23-bis-18). > It=E2=80=99s still HIP but with a slightly expanded scope; it=E2=80=99s= still Informational. >=20 > 1. s4: The one place where I=E2=80=99ll step out from not looking at th= e old is a > similar-ish recommendation that was in the RF4423: >=20 > In this document, the non-cryptographic forms of HI and HIP are > presented to complete the theory of HI, but they should not be > implemented as they could produce worse denial-of-service attacks > than the Internet has without Host Identity. >=20 > Should the should not be a SHOULD NOT? I can change this for sure but the whole document is written without the = capitalized terms due to its informal nature... actually, this sentence=20 is a bit moot since non-cryptographic forms of HI are only referenced in = the text. I would suggest rephrasing this as follows: "In this document, some non-cryptographic forms of HI and HIP are referenced, but cryptographic forms should be preferred because they are = more secure than their non-cryptographic counterparts." Would that work for you? > 2. (none security) s4.4: Is the paragraph about IPv4 vs IPv6 vs LSI rea= lly > necessary? I.e., is this yet another thing that folks are going to use= to not > transition to IPv6? I think the draft should discuss IPv4 compatibility because it is part=20 of architecture design. Btw, do you mean this paragraph or something else? The interoperability mechanism should not be used to avoid transition to IPv6; the authors firmly believe in IPv6 adoption and encourage developers to port existing IPv4-only applications to use IPv6. However, some proprietary, closed-source, IPv4-only applications may never see the daylight of IPv6, and the LSI mechanism is suitable for extending the lifetime of= such applications even in IPv6-only networks. IMHO, the LSIs should be supported mainly for the sake of proprietary,=20 legacy applications which should be supported for backwards=20 compatibility. The next paragraph also mentions a limitation of the LSIs:= The main disadvantage of an LSI is its local scope. Applications may violate layering principles and pass LSIs to each other in application-layer protocols. Let me know if you would like change or emphasize something? > 3. s11.2: Isn=E2=80=99t an additional drawback the need to have a HIP-a= ware firewall? Good point. It's both a benefit and drawback from the viewpoint of=20 firewalls. s11.1 mentions: [...] First, the use of HITs can potentially halve the size of access control lists because separate rules for IPv4 are not needed [komu-diss]. Second, HIT-based configuration rules in HIP-aware middleboxes remain static and independent of topology changes, thus simplifying administrative efforts particularly for mobile environments. As a drawback, I could add something like this to s11.2: In the current Internet, firewalls are commonly used to control access=20 to various services and devices. Since HIP introduces a new namespace,=20 it is expected that also the HIP namespace would be filtered for=20 unwanted connectivity. While this can be achieved with existing tools=20 directly in the end-hosts, filtering at the middleboxes requires=20 modifications to existing firewall software or new middleboxes [RFC6538].= How does this sound? From nobody Wed Feb 28 12:18:35 2018 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 834B012426E; Wed, 28 Feb 2018 12:18:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 tlbYVEBQ4hwZ; Wed, 28 Feb 2018 12:18:24 -0800 (PST) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38F70120227; Wed, 28 Feb 2018 12:18:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id D02116224C; Wed, 28 Feb 2018 15:18:22 -0500 (EST) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id V--KsPSpBdYQ; Wed, 28 Feb 2018 15:18:18 -0500 (EST) Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id D2E8362244; Wed, 28 Feb 2018 15:18:16 -0500 (EST) To: Joel Halpern , gen-art@ietf.org Cc: draft-ietf-hip-rfc4423-bis.all@ietf.org, hipsec@ietf.org, ietf@ietf.org References: <151893202236.27832.16542073394919248181@ietfa.amsl.com> From: Robert Moskowitz Message-ID: <5f1465c2-5ab8-eab5-651e-f8e704e1a0c6@htt-consult.com> Date: Wed, 28 Feb 2018 15:18:09 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <151893202236.27832.16542073394919248181@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Hipsec] Genart last call review of draft-ietf-hip-rfc4423-bis-18 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 20:18:27 -0000 Mail folder problems. I will be catching up with all of this starting Friday (Purim tonight and tomorrow). Bob On 02/18/2018 12:33 AM, Joel Halpern wrote: > Reviewer: Joel Halpern > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-hip-rfc4423-bis-18 > Reviewer: Joel Halpern > Review Date: 2018-02-17 > IETF LC End Date: 2018-02-26 > IESG Telechat date: Not scheduled for a telechat > > Summary: This document is ready for publication as an Informational RFCs. > The following comments may be useful for the authors to consider. > > Major issues: N/A > > Minor issues: > In the table in section 2.2 (Terms specific to this and other HIP > documents) the Host Identity Hash is defined as "The cryptographic hash > used in creating the Host Identity Tag from the Host Identity." I am > pretty sure the last word should be Identifier, not Identity,, which > matches the meanings and the usage in the following term. > > In section 4.1 second paragraph, it seems odd to refer to the > public-private key pair as the structure of the abstract Host Identity. > Given that the earlier text refers to the Public key as the Host > Identifier, I am not sure how you want to refer to the public/private key > pair. But I do not think it "is" the structure of the Host Identity. > > In the section 4.4 discussion of locally scoped identifier (LSI), it > appears that applications need to be modified to use this. Reading between > the lines of the stack architecture, the actual advantage of using HIP with > LSIs is that the application changes can be restricted to whatever > indication is to be used that the stack is to use HIP, rather than changing > the places that use sockaddrs, etc. But this is not clearly stated here. > > In section 5.1 paragraph 3, the text talks about a connecting client not > specifying a responder identifier (HIP Opportunistic mode) in order to > enable load balancing. I think the text would be helped by an example of > how an initiator might know to do this, rather than just not using HIP. > Also, it would be good if the text was explicit as to whether or not there > was a way to support load balancing / multi servers without either using a > shared identity or sacrificing security by using Opportunistic HIP. > > Given that section 5 is titled "New Stack Architecture", I think it would > be helpful if the section were explicit as to where the HIP logic lives > relative to the IP and UDP/TCP portions of the host stack. This would help > the reader have the right model for interpreting section 6.2 and 8.1. > > Nits/editorial comments: > Section 4.2 third sentence "It is possible to for ..." should be "It is > possible for ..." > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec >