From nobody Thu Sep 8 13:16:52 2016 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 F2EDF12B124 for ; Thu, 8 Sep 2016 13:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.709 X-Spam-Level: X-Spam-Status: No, score=-5.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] 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 MZKp8a5fIo_s for ; Thu, 8 Sep 2016 13:16:49 -0700 (PDT) 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 42CDB12B117 for ; Thu, 8 Sep 2016 13:16:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 3196A62131 for ; Thu, 8 Sep 2016 16:16:44 -0400 (EDT) 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 kDiHBfg03lOw for ; Thu, 8 Sep 2016 16:16:30 -0400 (EDT) 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 86DB262130 for ; Thu, 8 Sep 2016 16:16:30 -0400 (EDT) To: HIP From: Robert Moskowitz Message-ID: Date: Thu, 8 Sep 2016 16:16:20 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Hipsec] Using Next Header with IPv6 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 08 Sep 2016 20:16:51 -0000 This is more to implementors or people that understand network stacks... We provided in 7401 a Next Header field as all good IPv6 payloads are suppose to do. But we really have not used it in front of 'real' IPv6 payloads like ESP, TCP, UDP, or IPnIP. Or have we and I have just missed it? Anyway this is for faster mobility; looking at 5206-bis and IF the payload is small enough to fit in a HIP UPDATE, to send the Mobility UPDATE along with the actual first data from the moving host. This question is primarily 'will the stack handle this'? That is, HIP gets to payload first. If validates the UPDATE, changes the necessary bindings the either: pushes a revised frame without the HIP UPDATE back into the IP interface or sends the Next Header off to where it belongs. I am not a person that has dealt with the insides of the OS(s) to know how this would be done or if it is really practical. Oh, and what is the length of the basic HIP UPDATE in 5206-bis? I can do my best calculation in a bit, but if someone has it... thanks Bob From nobody Thu Sep 8 18:48:51 2016 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 2F17712B12A; Thu, 8 Sep 2016 18:48:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.32.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147338572618.21878.3636998794156685645.idtracker@ietfa.amsl.com> Date: Thu, 08 Sep 2016 18:48:46 -0700 Archived-At: Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-multihoming-11.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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, 09 Sep 2016 01:48:46 -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 of the IETF. Title : Host Multihoming with the Host Identity Protocol Authors : Thomas R. Henderson Christian Vogt Jari Arkko Filename : draft-ietf-hip-multihoming-11.txt Pages : 23 Date : 2016-09-08 Abstract: This document defines host multihoming extensions to the Host Identity Protocol (HIP), by leveraging protocol components defined for host mobility. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-multihoming/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-hip-multihoming-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-multihoming-11 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 Fri Sep 9 09:28:33 2016 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 0A72112B1CC; Fri, 9 Sep 2016 09:28:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.32.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147343850800.15187.1682698482634871776.idtracker@ietfa.amsl.com> Date: Fri, 09 Sep 2016 09:28:28 -0700 Archived-At: Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-rfc5206-bis-13.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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, 09 Sep 2016 16:28:28 -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 of the IETF. Title : Host Mobility with the Host Identity Protocol Authors : Thomas R. Henderson Christian Vogt Jari Arkko Filename : draft-ietf-hip-rfc5206-bis-13.txt Pages : 34 Date : 2016-09-09 Abstract: This document defines a mobility extension to the Host Identity Protocol (HIP). Specifically, this document defines a "LOCATOR_SET" parameter for HIP messages that allows for a HIP host to notify peers about alternate addresses at which it may be reached. This document also defines how the parameter can be used to preserve communications across a change to the IP address used by one or both peer hosts. The same LOCATOR_SET parameter can also be used to support end-host multihoming, but the procedures are out of scope for this document and are specified elsewhere. This document obsoletes RFC 5206. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5206-bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-hip-rfc5206-bis-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-rfc5206-bis-13 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 Fri Sep 9 15:43:08 2016 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 CFF8212B27A for ; Fri, 9 Sep 2016 15:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] 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 usrLdoXzpoiW for ; Fri, 9 Sep 2016 15:43:05 -0700 (PDT) Received: from mxout21.s.uw.edu (mxout21.s.uw.edu [140.142.32.139]) (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 BCF3812B258 for ; Fri, 9 Sep 2016 15:43:05 -0700 (PDT) Received: from hymn01.u.washington.edu (hymn01.u.washington.edu [140.142.9.110]) by mxout21.s.uw.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u89Mg4Cc022791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 9 Sep 2016 15:42:05 -0700 Received: from hymn01.u.washington.edu (localhost [127.0.0.1]) by hymn01.u.washington.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u89Mg0Hb031346 for ; Fri, 9 Sep 2016 15:42:00 -0700 Received: from localhost (Unknown UID 21258@localhost) by hymn01.u.washington.edu (8.14.4+UW14.03/8.14.4+Submit-local) with ESMTP id u89Mg0Ig031341 for ; Fri, 9 Sep 2016 15:42:00 -0700 X-Auth-Received: from [73.140.18.44] by hymn01.u.washington.edu via HTTP; Fri, 09 Sep 2016 15:42:00 PDT Date: Fri, 9 Sep 2016 15:42:00 -0700 (PDT) From: Tom Henderson To: HIP Message-ID: User-Agent: Web Alpine 2.01 (LRH 1302 2010-07-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8BIT X-PMX-Version: 6.2.1.2493963, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.9.9.223616 X-PMX-Server: mxout21.s.uw.edu X-Uwash-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODYTEXTP_SIZE_400_LESS 0, BODY_SIZE_1000_LESS 0, BODY_SIZE_100_199 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, NO_CTA_URI_FOUND 0, NO_URI_FOUND 0, NO_URI_HTTPS 0, SMALL_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_FROM 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_START 0, __TO_MALFORMED_2 0, __TO_NAME 0, __TO_NAME_DIFF_FROM_ACC 0, __TO_REAL_NAMES 0, __USER_AGENT 0' Archived-At: Subject: [Hipsec] updates to RFC5206 and multihoming drafts X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 09 Sep 2016 22:43:07 -0000 Readers of the list probably saw some updates of these drafts in the past day. These updates are to address various last call review comments; nothing technically substantive. - Tom From nobody Fri Sep 9 15:44:10 2016 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 50D4F12B27B for ; Fri, 9 Sep 2016 15:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] 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 y_mlQSwGXkza for ; Fri, 9 Sep 2016 15:44:06 -0700 (PDT) Received: from mxout22.s.uw.edu (mxout22.s.uw.edu [128.95.242.222]) (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 BF9BA12B269 for ; Fri, 9 Sep 2016 15:44:06 -0700 (PDT) Received: from hymn01.u.washington.edu (hymn01.u.washington.edu [140.142.9.110]) by mxout22.s.uw.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u89MeM9b013084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Sep 2016 15:40:22 -0700 Received: from hymn01.u.washington.edu (localhost [127.0.0.1]) by hymn01.u.washington.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u89MeHUC028191; Fri, 9 Sep 2016 15:40:17 -0700 Received: from localhost (Unknown UID 21258@localhost) by hymn01.u.washington.edu (8.14.4+UW14.03/8.14.4+Submit-local) with ESMTP id u89MeHSM028182; Fri, 9 Sep 2016 15:40:17 -0700 X-Auth-Received: from [73.140.18.44] by hymn01.u.washington.edu via HTTP; Fri, 09 Sep 2016 15:40:17 PDT Date: Fri, 9 Sep 2016 15:40:17 -0700 (PDT) From: Tom Henderson To: Robert Moskowitz Message-ID: User-Agent: Web Alpine 2.01 (LRH 1302 2010-07-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8BIT X-PMX-Version: 6.2.1.2493963, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.9.9.223616 X-PMX-Server: mxout22.s.uw.edu X-Uwash-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1900_1999 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, LEGITIMATE_NEGATE 0, LEGITIMATE_SIGNS 0, MSG_THREAD 0, MULTIPLE_REAL_RCPTS 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_CC_HDR 0, __HAS_FROM 0, __HAS_MSGID 0, __HTTPS_URI 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MULTIPLE_URI_TEXT 0, __PHISH_PHRASE1_B 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __TO_NAME 0, __TO_NAME_DIFF_FROM_ACC 0, __TO_REAL_NAMES 0, __URI_IN_BODY 0, __URI_NS , __URI_WITH_PATH 0, __USER_AGENT 0' Archived-At: Cc: hipsec@ietf.org Subject: Re: [Hipsec] Using Next Header with IPv6 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 09 Sep 2016 22:44:08 -0000 On 09/08/2016 01:16 PM, Robert Moskowitz wrote: > This is more to implementors or people that understand network stacks... > > We provided in 7401 a Next Header field as all good IPv6 payloads are > suppose to do. But we really have not used it in front of 'real' IPv6 > payloads like ESP, TCP, UDP, or IPnIP. Or have we and I have just > missed it? The HICCUPS RFC describes a use of it. https://tools.ietf.org/html/rfc6078 > > Anyway this is for faster mobility; looking at 5206-bis and IF the > payload is small enough to fit in a HIP UPDATE, to send the Mobility > UPDATE along with the actual first data from the moving host. > > This question is primarily 'will the stack handle this'? That is, HIP > gets to payload first. If validates the UPDATE, changes the necessary > bindings the either: > > pushes a revised frame without the HIP UPDATE back into the IP > interface > or sends the Next Header off to where it belongs. > > I am not a person that has dealt with the insides of the OS(s) to know > how this would be done or if it is really practical. The data plane for HIP-supported sessions can be implemented in userspace or kernel (reusing kernel IPsec handling). If purely userspace (all packets are shunted to userspace) it seems like it would not be terribly difficult to do. If kernel space handling such as Linux XFRM, I'm guessing that a stack modification would be needed. > > Oh, and what is the length of the basic HIP UPDATE in 5206-bis? I can > do my best calculation in a bit, but if someone has it... HIP header 40 bytes ESP_INFO 16 bytes LOCATOR_SET (minimal) ~32 bytes SEQ parameter 8 bytes so on the order of 96 bytes; more if more than one locator involved > > thanks > > Bob > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec From nobody Mon Sep 12 00:03:20 2016 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 A3459128E19 for ; Sun, 11 Sep 2016 13:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KnHH2hSo4194 for ; Sun, 11 Sep 2016 13:06:53 -0700 (PDT) Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE7A512B0EC for ; Sun, 11 Sep 2016 13:06:52 -0700 (PDT) Received: by mail-yb0-x22b.google.com with SMTP id d69so8676534ybf.2 for ; Sun, 11 Sep 2016 13:06:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7LOHKt6m90tkdZknkFwacA1+1wjT0Tq1+VtTikPAnkY=; b=OpGmjcE5fU2WxXQEcOb9ZV3WkFB90RTqUs6ThiuyiB6fDE68JnMETo194YJGWI7zqL 6XfwaZ9dNigtMNHxkMjiYQDB4/B1xK9+93cBY7S4EcueJJzpxjB4hlr6xBfeSeOFF2Cb sRnLjZw9fbfjABkSKG0njRognLNReHBE+1ftnV2hCxQk8iCKzvt6P1LsBg9/XX7BdAy4 X8hSqF4WFD3rKaSrCcqZUStElemGJK5rfYaL9Db/UioUWN46uFnIuVcUOp6J6VgQCKke qvZmIab24srbw/GVeQDwTuwi8w6niIgkzKKd0EIzd8/Ih91/CO0R4VZ4AiuYwHncKFT1 wUBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7LOHKt6m90tkdZknkFwacA1+1wjT0Tq1+VtTikPAnkY=; b=YI+llRow/V3wPsnWKM7IRuPGHb+3e9IfA64RQnwXuIvt0Xkk59GE3BzooDMU0Vd/yO LYCMPBHuyLUSeRu75OMRu3Kod/s1964MSIWL4c32jdM5yswA6UwFLHOvSObjjFdeMBj2 iUGLGhaVHn3w9/lu01C/h6h80bEEm5stLbRIJ6PHfDopIA8ET3atJCdR+1MSPBuSzvbN 5geWLk+foFTnw2NXlzKVV96yeItQa9FtGIxySWvf3xOJyVhudM/LrGW3ME8DYXBGfU5k EKuCM+5kaW8dUvtBSi+gjfD0gDP7TdaTyc+U8r2U2WVv6qIZcTHABogNqQ1AhDxGGCAl w4Sw== X-Gm-Message-State: AE9vXwNJsHqZXD0+BjsMrPTBM8zmyZaO+MJUlpTdXNr2ainjlpu915hxFeY3mDBmi2JzYUUpO//UPZ71bEFZ9Q== X-Received: by 10.37.110.136 with SMTP id j130mr14625220ybc.139.1473624412115; Sun, 11 Sep 2016 13:06:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.240.69 with HTTP; Sun, 11 Sep 2016 13:06:51 -0700 (PDT) In-Reply-To: <5756C81D.3080601@ericsson.com> References: <20160321203627.12199.62928.idtracker@ietfa.amsl.com> <56F98E90.10601@ericsson.com> <5756C81D.3080601@ericsson.com> From: =?UTF-8?B?UmVuw6kgSHVtbWVu?= Date: Sun, 11 Sep 2016 22:06:51 +0200 Message-ID: To: Miika Komu Content-Type: multipart/alternative; boundary=001a1148a9d29df789053c40eb47 Archived-At: X-Mailman-Approved-At: Mon, 12 Sep 2016 00:03:18 -0700 Cc: hipsec@ietf.org Subject: Re: [Hipsec] A review of draft-ietf-hip-dex-02.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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: Sun, 11 Sep 2016 20:06:55 -0000 --001a1148a9d29df789053c40eb47 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello Miika, going through your email again, I saw a total of four suggestions. Three of them refer to imprecisions in the text of RFC 7401 (which I copy/pasted for HIP DEX). There, I understood that consistency with RFC 7401 has a higher priority than only fixing your comments for HIP DEX, but keeping the text as is for RFC 7401. This means, I will not modify the text in the HIP DEX draft. Is this also your intention? The last remaining issue is related to the UPDATE message and the rekeying procedure (Section 6.10.). Here, I added the following paragraph for clarification purposes: [RFC7402] specifies the rekeying of an existing HIP SA using the UPDATE message. This rekeying procedure can also be used with HIP DEX. However, where rekeying involves a new Diffie-Hellman key exchange, HIP DEX peers MUST establish a new connection in order to create a new Pair-wise Key SA due to the use of static ECDH key-pairs with HIP DEX. Does this fix your issue? BR Ren=C3=A9 On Tue, Jun 7, 2016 at 3:11 PM, Miika Komu wrote: > Hi, > > On 06/03/2016 02:20 PM, Ren=C3=A9 Hummen wrote: > >> This is part 3 of 3. >> > > I am fine with your fixes. Some comments below. > > On Mon, Mar 28, 2016 at 10:05 PM, Miika Komu > > wrote: >> > > [...] > >> > 6.2.1. CMAC Calculation >> > >> > [...] >> > >> > >> > 5. Set Checksum and Header Length fields in the HIP header to >> > original values. Note that the Checksum and Length fields >> > contain incorrect values after this step. >> >> I guess also the values following HIP_MAC should be restored since >> they were wiped in the step 2. >> >> >> I also found this description a bit imprecise, but it is taken from >> RFC7401. Step 2 already hints at the fact that parameters following >> HIP_MAC may still be of interest: >> "Remove the HIP_MAC parameter, as well as all other parameters >> that follow it with greater Type value, saving the contents if >> they will be needed later." >> >> The question is whether we want to fix the description for HIP DEX or to >> keep things as they are for consistency reasons. In the former case, I >> would prefer to completely rewrite the verification procedure to work on >> the received packet without removing any parameters. However, we should >> then probably also post an errata to RFC7401. If there are no stong >> opinions about that, I would go for the latter option. >> > > Latter option works for me too. > > > The CKDF-Extract function is the following operation: >> > >> > CKDF-Extract(I, IKM, info) -> PRK >> >> What does the arrow operator signify? I thought that it produces PRK= , >> but PRK is actually defined below. >> >> >> The arrow is part of a basic mathematical function definition. So yes, >> PRK is the output (domain), but we still need to give it a proper name. >> I changed the artwork to clearly point out the inputs and outputs. >> > > Thanks, it is now better. > > Please check this section again in the updated version and get back to >> me if the above changes do not sufficiently help your understanding. >> > > It is good now, thanks! > > > L length of output keying material in octets >> > (<=3D 255*RHASH_len/8) >> > | denotes the concatenation >> > >> > The output keying material OKM is calculated as follows: >> > >> > N =3D ceil(L/RHASH_len/8) >> > T =3D T(1) | T(2) | T(3) | ... | T(N) >> > OKM =3D first L octets of T >> > >> > where >> > >> > T(0) =3D empty string (zero length) >> > T(1) =3D CMAC(PRK, T(0) | info | 0x01) >> > T(2) =3D CMAC(PRK, T(1) | info | 0x02) >> > T(3) =3D CMAC(PRK, T(2) | info | 0x03) >> > ... >> >> The Expand was a bit more clear, but still didn't understand how to >> get to the >> Expanded key material due the arrow notation. >> >> >> Ok, let's clarify this as several comments are related to the arrow >> notation. For the function definition we use the mathematical arrow >> notation (same as RFC 5869) and for the actual opertation we use the >> equals sign (same as RFC 5869). In the end, they denote the same thing: >> "assign X to Y". >> > > Ok, this is what I guessed too. > > > (where the constant concatenated to the end of each T(n) is a >> > single octet.) >> >> Is there a max value? >> >> >> I am not sure what you mean here. If you refer to the N in T(N) then it >> is defined above as N =3D ceil(L/RHASH_len/8). >> > > Yes, I asked about the maximum value for N (which depends on L), but neve= r > mind. > > > 8. The R1 packet may have the A-bit set - in this case, the syst= em >> > MAY choose to refuse it by dropping the R1 packet and returning >> > to state UNASSOCIATED. The system SHOULD consider dropping the >> > R1 packet only if it used a NULL HIT in the I1 packet. >> >> I didn't understand the logic in the last sentence. >> >> >> Someone must have had a reason for this recommendation, but that someone >> wasn't me. This is text from RFC7401. Any suggestions how to proceed? >> > > Fix similarly as the other RFC7401 issue in the beginning of this email. > > > 6.7. Processing Incoming I2 Packets >> > >> > [...] >> > >> > 5. If the system's state machine is in the I2-SENT state, the >> > system MUST make a comparison between its local and sender's >> > HITs (similarly as in Section 6.3). If the local HIT is smaller >> > than the sender's HIT, it should drop the I2 packet, use the >> > peer Diffie-Hellman key, ENCRYPTED_KEY keying material and nonce >> > #I from the R1 packet received earlier, and get the local >> > Diffie-Hellman key, ENCRYPTED_KEY keying material, and nonce #J >> > from the I2 packet sent to the peer earlier. Otherwise, the >> > system should process the received I2 packet and drop any >> > previously derived Diffie-Hellman keying material Kij and >> > ENCRYPTED_KEY keying material it might have generated upon >> > sending the I2 packet previously. The peer Diffie-Hellman key, >> > ENCRYPTED_KEY, and the nonce #J are taken from the just arrived >> > I2 packet. The local Diffie-Hellman key, ENCRYPTED_KEY keying >> > material, and the nonce #I are the ones that were sent earlier >> > in the R1 packet. >> >> Please replace "sender" with "peer" (or remote host) in this section >> for more symmetric terminology. >> >> get -> obtain >> >> >> I can make these changes if you insist, but I was going for a minimal >> diff to RFC 7401. >> > > Not insisting. > > >> > 11. The implementation SHOULD also verify that the Initiator's H= IT >> > in the I2 packet corresponds to the Host Identity sent in the I2 >> > packet. (Note: some middleboxes may not be able to make this >> > verification.) >> >> Why SHOULD? Why not MUST? I think we're talking about end-hosts here >> anyway. >> >> >> It is defined this way in RFC 7401. Do you really want to change the >> packet processing behavior for HIP DEX only? >> > > Fix similarly as the first RFC7401 issue in this email. > > > 6.10. Processing UPDATE, CLOSE, and CLOSE_ACK Packets >> >> > UPDATE, CLOSE, and CLOSE_ACK packets are handled similarly in HIP >> DEX >> > as in HIP BEX (see Sections 6.11, 6.12, 6.14, and 6.15 of >> [RFC7401]). >> > The only difference is the that the HIP_SIGNATURE is never presen= t >> > and, therefore, is not required to be processed by the receiving >> > party. >> >> How does rekeying work with the extract and expand functions? >> >> >> Rekeying is not defined in this document, same as for RFC 7401. That >> being said, the rekeying procedure with reuse of the KEYMAT from RFC >> 7402 directly translates to HIP DEX. For new KEYMAT, the peers need to >> establish a new connection due to the use of static DH keys. >> > > Maybe this should be explicitly stated in the draft. > > >> >> > 7. HIP Policies >> >> > There are a number of variables that will influence the HIP >> exchanges >> > that each host must support. All HIP DEX implementations SHOULD >> > provide for an ACL of Initiator's HI to Responder's HI. This ACL >> > SHOULD also include preferred transform and local lifetimes. >> > Wildcards SHOULD also be supported for this ACL. >> >> Why ACLs are mandatory? >> >> >> It is not a MUST and considering that HIP DEX is primarly targeted at >> things, there is the need to do basic device authorizations (based on >> their identities) without a human in the loop. Of course you are also >> allowed to use more suffisticated authorization mechanisms. >> > > Ok. > > ACL -> ACL consisting of >> >> >> Changed to the following text that is closer to RFC 7401: >> " All HIP DEX implementations SHOULD provide for an Access Control Lis= t >> (ACL), representing for which hosts they accept HIP diet exchanges, >> and the preferred transport format and local lifetimes. Wildcarding >> SHOULD be supported for such ACLs." >> >> > 8. Security Considerations >> >> > o The HIP DEX HIT generation may present new attack opportunitie= s. >> >> They cannot be used in ACLs. Maybe this could be mentioned. Can this >> be mitigated by always using full HIs? >> >> >> I changed the bullet-point as follows: >> "The HIP DEX HIT generation may present new attack opportunities. >> Hence, HIP DEX HITs should not be use as the only means to >> identify a peer in an ACL. Instead, the use of the peer's HI is >> recommended." >> > > Ok. > > Note that I added a new Section 8 "Interoperability between HIP DEX and >> HIPv2" to satisfy your comment on HIP DEX and HIPv2 compatibility. >> > > Thanks! > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > > --001a1148a9d29df789053c40eb47 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Miika,

going through your email a= gain, I saw a total of four suggestions.

Three of = them refer to imprecisions in the text of RFC 7401 (which I copy/pasted for= HIP DEX). There, I understood that consistency with RFC 7401 has a higher = priority than only fixing your comments for HIP DEX, but keeping the text a= s is for RFC 7401. This means, I will not modify the text in the HIP DEX dr= aft. Is this also your intention?

The last remaini= ng issue is related to the UPDATE message and the rekeying procedure (Secti= on=C2=A06.10.). = Here, I added the following paragraph for clarification purposes:

=C2=A0 =C2=A0[RFC7402] specifies the rekeying of an ex= isting HIP SA using the
=C2=A0 =C2=A0UPDATE message.=C2=A0 This r= ekeying procedure can also be used with HIP
=C2=A0 =C2=A0DEX.=C2= =A0 However, where rekeying involves a new Diffie-Hellman key
=C2= =A0 =C2=A0exchange, HIP DEX peers MUST establish a new connection in order = to
=C2=A0 =C2=A0create a new Pair-wise Key SA due to the use of s= tatic ECDH key-pairs
=C2=A0 =C2=A0with HIP DEX.
<= br>
Does this fix your issue?

BR
Ren=C3=A9



On Tue, Jun 7, 2016 at 3:11 PM, Miika = Komu <miika.komu@ericsson.com> wrote:
Hi,

On 06/03/2016 02:20 PM, Ren=C3=A9 Hummen wrote:
This is part 3 of 3.

 I am fine with your fixes. Some comments below.

On Mon, Mar 28, 2016 at 10:05 PM, Miika Komu <miika.komu@ericsson.com
 <mailto:mii= ka.komu@ericsson.com>> wrote:
> [...]
=C2=A0 =C2=A0 =C2=A0> 6.2.1.=C2=A0 CMAC Calculation
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> [...]
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> 5.=C2=A0 Set Checksum and Header Length fields in = the HIP header to
=C2=A0 =C2=A0 =C2=A0> original values.=C2=A0 Note that the Checksum and = Length fields
=C2=A0 =C2=A0 =C2=A0> contain incorrect values after this step.

=C2=A0 =C2=A0 I guess also the values following HIP_MAC should be restored = since
=C2=A0 =C2=A0 they were wiped in the step 2.


I also found this description a bit imprecise, but it is taken from
RFC7401. Step 2 already hints at the fact that parameters following
HIP_MAC may still be of interest:
"Remove the HIP_MAC parameter, as well as all other parameters
=C2=A0 =C2=A0 =C2=A0 =C2=A0 that follow it with greater Type value, saving = the contents if
=C2=A0 =C2=A0 =C2=A0 =C2=A0 they will be needed later."

The question is whether we want to fix the description for HIP DEX or to keep things as they are for consistency reasons. In the former case, I
would prefer to completely rewrite the verification procedure to work on the received packet without removing any parameters. However, we should
then probably also post an errata to RFC7401. If there are no stong
opinions about that, I would go for the latter option.

 Latter option works for me too.

=C2=A0 =C2=A0 =C2=A0> The CKDF-Extract function is the following operati= on:
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> CKDF-Extract(I, IKM, info) -> PRK

=C2=A0 =C2=A0 What does the arrow operator signify? I thought that it produ= ces PRK,
=C2=A0 =C2=A0 but PRK is actually defined below.


The arrow is part of a basic mathematical function definition. So yes,
PRK is the output (domain), but we still need to give it a proper name.
I changed the artwork to clearly point out the inputs and outputs.

 Thanks, it is now better.

Please check this section again in the updated version and get back to
me if the above changes do not sufficiently help your understanding.

 It is good now, thanks!

=C2=A0 =C2=A0 =C2=A0> L=C2=A0 =C2=A0 =C2=A0 =C2=A0 length of output keyi= ng material in octets
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (<=3D 255*RHA= SH_len/8)
=C2=A0 =C2=A0 =C2=A0> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 denotes the concatena= tion
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> The output keying material OKM is calculated as fo= llows:
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> N=C2=A0 =C2=A0 =C2=A0 =C2=A0=3D=C2=A0 ceil(L/RHASH= _len/8)
=C2=A0 =C2=A0 =C2=A0> T=C2=A0 =C2=A0 =C2=A0 =C2=A0=3D=C2=A0 T(1) | T(2) = | T(3) | ... | T(N)
=C2=A0 =C2=A0 =C2=A0> OKM=C2=A0 =C2=A0 =C2=A0=3D=C2=A0 first L octets of= T
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> where
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> T(0) =3D empty string (zero length)
=C2=A0 =C2=A0 =C2=A0> T(1) =3D CMAC(PRK, T(0) | info | 0x01)
=C2=A0 =C2=A0 =C2=A0> T(2) =3D CMAC(PRK, T(1) | info | 0x02)
=C2=A0 =C2=A0 =C2=A0> T(3) =3D CMAC(PRK, T(2) | info | 0x03)
=C2=A0 =C2=A0 =C2=A0> ...

=C2=A0 =C2=A0 The Expand was a bit more clear, but still didn't underst= and how to
=C2=A0 =C2=A0 get to the
=C2=A0 =C2=A0 Expanded key material due the arrow notation.


Ok, let's clarify this as several comments are related to the arrow
notation. For the function definition we use the mathematical arrow
notation (same as RFC 5869) and for the actual opertation we use the
equals sign (same as RFC 5869). In the end, they denote the same thing:
"assign X to Y".

 Ok, this is what I guessed too.

=C2=A0 =C2=A0 =C2=A0> (where the constant concatenated to the end of eac= h T(n) is a
=C2=A0 =C2=A0 =C2=A0> single octet.)

=C2=A0 =C2=A0 Is there a max value?


I am not sure what you mean here. If you refer to the N in T(N) then it
is defined above as N =3D ceil(L/RHASH_len/8).

 Yes, I asked about the maximum value for N (which depends on L), but never = mind.

=C2=A0 =C2=A0 =C2=A0> 8.=C2=A0 =C2=A0The R1 packet may have the A-bit se= t - in this case, the system
=C2=A0 =C2=A0 =C2=A0> MAY choose to refuse it by dropping the R1 packet = and returning
=C2=A0 =C2=A0 =C2=A0> to state UNASSOCIATED.=C2=A0 The system SHOULD con= sider dropping the
=C2=A0 =C2=A0 =C2=A0> R1 packet only if it used a NULL HIT in the I1 pac= ket.

=C2=A0 =C2=A0 I didn't understand the logic in the last sentence.


Someone must have had a reason for this recommendation, but that someone wasn't me. This is text from RFC7401. Any suggestions how to proceed?

Fix similarly as the other RFC7401 issue in the beginning of this email.

=C2=A0 =C2=A0 =C2=A0> 6.7.=C2=A0 Processing Incoming I2 Packets
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> [...]
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> 5.=C2=A0 =C2=A0If the system's state machine i= s in the I2-SENT state, the
=C2=A0 =C2=A0 =C2=A0> system MUST make a comparison between its local an= d sender's
=C2=A0 =C2=A0 =C2=A0> HITs (similarly as in Section 6.3).=C2=A0 If the l= ocal HIT is smaller
=C2=A0 =C2=A0 =C2=A0> than the sender's HIT, it should drop the I2 p= acket, use the
=C2=A0 =C2=A0 =C2=A0> peer Diffie-Hellman key, ENCRYPTED_KEY keying mate= rial and nonce
=C2=A0 =C2=A0 =C2=A0> #I from the R1 packet received earlier, and get th= e local
=C2=A0 =C2=A0 =C2=A0> Diffie-Hellman key, ENCRYPTED_KEY keying material,= and nonce #J
=C2=A0 =C2=A0 =C2=A0> from the I2 packet sent to the peer earlier.=C2=A0= Otherwise, the
=C2=A0 =C2=A0 =C2=A0> system should process the received I2 packet and d= rop any
=C2=A0 =C2=A0 =C2=A0> previously derived Diffie-Hellman keying material = Kij and
=C2=A0 =C2=A0 =C2=A0> ENCRYPTED_KEY keying material it might have genera= ted upon
=C2=A0 =C2=A0 =C2=A0> sending the I2 packet previously.=C2=A0 The peer D= iffie-Hellman key,
=C2=A0 =C2=A0 =C2=A0> ENCRYPTED_KEY, and the nonce #J are taken from the= just arrived
=C2=A0 =C2=A0 =C2=A0> I2 packet.=C2=A0 The local Diffie-Hellman key, ENC= RYPTED_KEY keying
=C2=A0 =C2=A0 =C2=A0> material, and the nonce #I are the ones that were = sent earlier
=C2=A0 =C2=A0 =C2=A0> in the R1 packet.

=C2=A0 =C2=A0 Please replace "sender" with "peer" (or r= emote host) in this section
=C2=A0 =C2=A0 for more symmetric terminology.

=C2=A0 =C2=A0 get -> obtain


I can make these changes if you insist, but I was going for a minimal
diff to RFC 7401.

Not insisting.


=C2=A0 =C2=A0 =C2=A0> 11.=C2=A0 The implementation SHOULD also verify th= at the Initiator's HIT
=C2=A0 =C2=A0 =C2=A0> in the I2 packet corresponds to the Host Identity = sent in the I2
=C2=A0 =C2=A0 =C2=A0> packet.=C2=A0 (Note: some middleboxes may not be a= ble to make this
=C2=A0 =C2=A0 =C2=A0> verification.)

=C2=A0 =C2=A0 Why SHOULD? Why not MUST? I think we're talking about end= -hosts here
=C2=A0 =C2=A0 anyway.


It is defined this way in RFC 7401. Do you really want to change the
packet processing behavior for HIP DEX only?

 Fix similarly as the first RFC7401 issue in this email.
=C2=A0 =C2=A0 =C2=A0> 6.10.=C2=A0 Processing UPDATE, CLOSE, and CLOSE_AC= K Packets

=C2=A0 =C2=A0 =C2=A0> UPDATE, CLOSE, and CLOSE_ACK packets are handled s= imilarly in HIP DEX
=C2=A0 =C2=A0 =C2=A0> as in HIP BEX (see Sections 6.11, 6.12, 6.14, and = 6.15 of [RFC7401]).
=C2=A0 =C2=A0 =C2=A0> The only difference is the that the HIP_SIGNATURE = is never present
=C2=A0 =C2=A0 =C2=A0> and, therefore, is not required to be processed by= the receiving
=C2=A0 =C2=A0 =C2=A0> party.

=C2=A0 =C2=A0 How does rekeying work with the extract and expand functions?=


Rekeying is not defined in this document, same as for RFC 7401. That
being said, the rekeying procedure with reuse of the KEYMAT from RFC
7402 directly translates to HIP DEX. For new KEYMAT, the peers need to
establish a new connection due to the use of static DH keys.

 Maybe this should be explicitly stated in the draft.



=C2=A0 =C2=A0 =C2=A0> 7.=C2=A0 HIP Policies

=C2=A0 =C2=A0 =C2=A0> There are a number of variables that will influenc= e the HIP exchanges
=C2=A0 =C2=A0 =C2=A0> that each host must support.=C2=A0 All HIP DEX imp= lementations SHOULD
=C2=A0 =C2=A0 =C2=A0> provide for an ACL of Initiator's HI to Respon= der's HI.=C2=A0 This ACL
=C2=A0 =C2=A0 =C2=A0> SHOULD also include preferred transform and local = lifetimes.
=C2=A0 =C2=A0 =C2=A0> Wildcards SHOULD also be supported for this ACL.
=C2=A0 =C2=A0 Why ACLs are mandatory?


It is not a MUST and considering that HIP DEX is primarly targeted at
things, there is the need to do basic device authorizations (based on
their identities) without a human in the loop. Of course you are also
allowed to use more suffisticated authorization mechanisms.

 Ok.

=C2=A0 =C2=A0 ACL -> ACL consisting of


Changed to the following text that is closer to RFC 7401:
"=C2=A0 =C2=A0All HIP DEX implementations SHOULD provide for an Access= Control List
=C2=A0 =C2=A0 (ACL), representing for which hosts they accept HIP diet exch= anges,
=C2=A0 =C2=A0 and the preferred transport format and local lifetimes.=C2=A0= Wildcarding
=C2=A0 =C2=A0 SHOULD be supported for such ACLs."

=C2=A0 =C2=A0 =C2=A0> 8.=C2=A0 Security Considerations

=C2=A0 =C2=A0 =C2=A0> o=C2=A0 The HIP DEX HIT generation may present new= attack opportunities.

=C2=A0 =C2=A0 They cannot be used in ACLs. Maybe this could be mentioned. C= an this
=C2=A0 =C2=A0 be mitigated by always using full HIs?


I changed the bullet-point as follows:
"The HIP DEX HIT generation may present new attack opportunities.
=C2=A0 =C2=A0 =C2=A0 =C2=A0Hence, HIP DEX HITs should not be use as the onl= y means to
=C2=A0 =C2=A0 =C2=A0 =C2=A0identify a peer in an ACL.=C2=A0 Instead, the us= e of the peer's HI is
=C2=A0 =C2=A0 =C2=A0 =C2=A0recommended."

 Ok.

Note that I added a new Section 8 "Interoperability between HIP DEX an= d
HIPv2" to satisfy your comment on HIP DEX and HIPv2 compatibility.

 Thanks!


_______________________________________________
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

--001a1148a9d29df789053c40eb47-- From nobody Mon Sep 12 03:36:09 2016 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 A9B2812B1E8 for ; Mon, 12 Sep 2016 03:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.708 X-Spam-Level: X-Spam-Status: No, score=-5.708 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] 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 71uCngMXl2ks for ; Mon, 12 Sep 2016 03:36:05 -0700 (PDT) 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 8350312B03A for ; Mon, 12 Sep 2016 03:36:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 8AB2562131; Mon, 12 Sep 2016 06:36:03 -0400 (EDT) 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 TFiBpFG-rIAp; Mon, 12 Sep 2016 06:35:39 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [5.148.40.66]) (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 E50F16212F; Mon, 12 Sep 2016 06:35:37 -0400 (EDT) To: =?UTF-8?Q?Ren=c3=a9_Hummen?= , Miika Komu References: <20160321203627.12199.62928.idtracker@ietfa.amsl.com> <56F98E90.10601@ericsson.com> <5756C81D.3080601@ericsson.com> From: Robert Moskowitz Message-ID: <347fb1f8-8aca-d89f-dffb-7403f953f87d@htt-consult.com> Date: Mon, 12 Sep 2016 06:35:34 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------28284CB5C6E8D0E063B71622" Archived-At: Cc: hipsec@ietf.org Subject: Re: [Hipsec] A review of draft-ietf-hip-dex-02.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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, 12 Sep 2016 10:36:09 -0000 This is a multi-part message in MIME format. --------------28284CB5C6E8D0E063B71622 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 09/11/2016 04:06 PM, René Hummen wrote: > Hello Miika, > > going through your email again, I saw a total of four suggestions. > > Three of them refer to imprecisions in the text of RFC 7401 (which I > copy/pasted for HIP DEX). There, I understood that consistency with > RFC 7401 has a higher priority than only fixing your comments for HIP > DEX, but keeping the text as is for RFC 7401. This means, I will not > modify the text in the HIP DEX draft. Is this also your intention? And how do we produce an errata for 7401 to address the issues within 7401... > > The last remaining issue is related to the UPDATE message and the > rekeying procedure (Section 6.10.). Here, I added the following > paragraph for clarification purposes: > > [RFC7402] specifies the rekeying of an existing HIP SA using the > UPDATE message. This rekeying procedure can also be used with HIP > DEX. However, where rekeying involves a new Diffie-Hellman key > exchange, HIP DEX peers MUST establish a new connection in order to > create a new Pair-wise Key SA due to the use of static ECDH key-pairs > with HIP DEX. > > Does this fix your issue? > > BR > René > > > > On Tue, Jun 7, 2016 at 3:11 PM, Miika Komu > wrote: > > Hi, > > On 06/03/2016 02:20 PM, René Hummen wrote: > > This is part 3 of 3. > > > I am fine with your fixes. Some comments below. > > On Mon, Mar 28, 2016 at 10:05 PM, Miika Komu > > >> wrote: > > > [...] > > > 6.2.1. CMAC Calculation > > > > [...] > > > > > > 5. Set Checksum and Header Length fields in the HIP > header to > > original values. Note that the Checksum and Length fields > > contain incorrect values after this step. > > I guess also the values following HIP_MAC should be > restored since > they were wiped in the step 2. > > > I also found this description a bit imprecise, but it is taken > from > RFC7401. Step 2 already hints at the fact that parameters > following > HIP_MAC may still be of interest: > "Remove the HIP_MAC parameter, as well as all other parameters > that follow it with greater Type value, saving the > contents if > they will be needed later." > > The question is whether we want to fix the description for HIP > DEX or to > keep things as they are for consistency reasons. In the former > case, I > would prefer to completely rewrite the verification procedure > to work on > the received packet without removing any parameters. However, > we should > then probably also post an errata to RFC7401. If there are no > stong > opinions about that, I would go for the latter option. > > > Latter option works for me too. > > > The CKDF-Extract function is the following operation: > > > > CKDF-Extract(I, IKM, info) -> PRK > > What does the arrow operator signify? I thought that it > produces PRK, > but PRK is actually defined below. > > > The arrow is part of a basic mathematical function definition. > So yes, > PRK is the output (domain), but we still need to give it a > proper name. > I changed the artwork to clearly point out the inputs and outputs. > > > Thanks, it is now better. > > Please check this section again in the updated version and get > back to > me if the above changes do not sufficiently help your > understanding. > > > It is good now, thanks! > > > L length of output keying material in octets > > (<= 255*RHASH_len/8) > > | denotes the concatenation > > > > The output keying material OKM is calculated as follows: > > > > N = ceil(L/RHASH_len/8) > > T = T(1) | T(2) | T(3) | ... | T(N) > > OKM = first L octets of T > > > > where > > > > T(0) = empty string (zero length) > > T(1) = CMAC(PRK, T(0) | info | 0x01) > > T(2) = CMAC(PRK, T(1) | info | 0x02) > > T(3) = CMAC(PRK, T(2) | info | 0x03) > > ... > > The Expand was a bit more clear, but still didn't > understand how to > get to the > Expanded key material due the arrow notation. > > > Ok, let's clarify this as several comments are related to the > arrow > notation. For the function definition we use the mathematical > arrow > notation (same as RFC 5869) and for the actual opertation we > use the > equals sign (same as RFC 5869). In the end, they denote the > same thing: > "assign X to Y". > > > Ok, this is what I guessed too. > > > (where the constant concatenated to the end of each > T(n) is a > > single octet.) > > Is there a max value? > > > I am not sure what you mean here. If you refer to the N in > T(N) then it > is defined above as N = ceil(L/RHASH_len/8). > > > Yes, I asked about the maximum value for N (which depends on L), > but never mind. > > > 8. The R1 packet may have the A-bit set - in this > case, the system > > MAY choose to refuse it by dropping the R1 packet and > returning > > to state UNASSOCIATED. The system SHOULD consider > dropping the > > R1 packet only if it used a NULL HIT in the I1 packet. > > I didn't understand the logic in the last sentence. > > > Someone must have had a reason for this recommendation, but > that someone > wasn't me. This is text from RFC7401. Any suggestions how to > proceed? > > > Fix similarly as the other RFC7401 issue in the beginning of this > email. > > > 6.7. Processing Incoming I2 Packets > > > > [...] > > > > 5. If the system's state machine is in the I2-SENT > state, the > > system MUST make a comparison between its local and > sender's > > HITs (similarly as in Section 6.3). If the local HIT > is smaller > > than the sender's HIT, it should drop the I2 packet, > use the > > peer Diffie-Hellman key, ENCRYPTED_KEY keying material > and nonce > > #I from the R1 packet received earlier, and get the local > > Diffie-Hellman key, ENCRYPTED_KEY keying material, and > nonce #J > > from the I2 packet sent to the peer earlier. Otherwise, the > > system should process the received I2 packet and drop any > > previously derived Diffie-Hellman keying material Kij and > > ENCRYPTED_KEY keying material it might have generated upon > > sending the I2 packet previously. The peer > Diffie-Hellman key, > > ENCRYPTED_KEY, and the nonce #J are taken from the just > arrived > > I2 packet. The local Diffie-Hellman key, ENCRYPTED_KEY > keying > > material, and the nonce #I are the ones that were sent > earlier > > in the R1 packet. > > Please replace "sender" with "peer" (or remote host) in > this section > for more symmetric terminology. > > get -> obtain > > > I can make these changes if you insist, but I was going for a > minimal > diff to RFC 7401. > > > Not insisting. > > > > 11. The implementation SHOULD also verify that the > Initiator's HIT > > in the I2 packet corresponds to the Host Identity sent > in the I2 > > packet. (Note: some middleboxes may not be able to > make this > > verification.) > > Why SHOULD? Why not MUST? I think we're talking about > end-hosts here > anyway. > > > It is defined this way in RFC 7401. Do you really want to > change the > packet processing behavior for HIP DEX only? > > > Fix similarly as the first RFC7401 issue in this email. > > > 6.10. Processing UPDATE, CLOSE, and CLOSE_ACK Packets > > > UPDATE, CLOSE, and CLOSE_ACK packets are handled > similarly in HIP DEX > > as in HIP BEX (see Sections 6.11, 6.12, 6.14, and 6.15 > of [RFC7401]). > > The only difference is the that the HIP_SIGNATURE is > never present > > and, therefore, is not required to be processed by the > receiving > > party. > > How does rekeying work with the extract and expand functions? > > > Rekeying is not defined in this document, same as for RFC > 7401. That > being said, the rekeying procedure with reuse of the KEYMAT > from RFC > 7402 directly translates to HIP DEX. For new KEYMAT, the peers > need to > establish a new connection due to the use of static DH keys. > > > Maybe this should be explicitly stated in the draft. > > > > > 7. HIP Policies > > > There are a number of variables that will influence the > HIP exchanges > > that each host must support. All HIP DEX > implementations SHOULD > > provide for an ACL of Initiator's HI to Responder's > HI. This ACL > > SHOULD also include preferred transform and local > lifetimes. > > Wildcards SHOULD also be supported for this ACL. > > Why ACLs are mandatory? > > > It is not a MUST and considering that HIP DEX is primarly > targeted at > things, there is the need to do basic device authorizations > (based on > their identities) without a human in the loop. Of course you > are also > allowed to use more suffisticated authorization mechanisms. > > > Ok. > > ACL -> ACL consisting of > > > Changed to the following text that is closer to RFC 7401: > " All HIP DEX implementations SHOULD provide for an Access > Control List > (ACL), representing for which hosts they accept HIP diet > exchanges, > and the preferred transport format and local lifetimes. > Wildcarding > SHOULD be supported for such ACLs." > > > 8. Security Considerations > > > o The HIP DEX HIT generation may present new attack > opportunities. > > They cannot be used in ACLs. Maybe this could be > mentioned. Can this > be mitigated by always using full HIs? > > > I changed the bullet-point as follows: > "The HIP DEX HIT generation may present new attack opportunities. > Hence, HIP DEX HITs should not be use as the only means to > identify a peer in an ACL. Instead, the use of the > peer's HI is > recommended." > > > Ok. > > Note that I added a new Section 8 "Interoperability between > HIP DEX and > HIPv2" to satisfy your comment on HIP DEX and HIPv2 compatibility. > > > Thanks! > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > > > > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec --------------28284CB5C6E8D0E063B71622 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

On 09/11/2016 04:06 PM, René Hummen wrote:
Hello Miika,

going through your email again, I saw a total of four suggestions.

Three of them refer to imprecisions in the text of RFC 7401 (which I copy/pasted for HIP DEX). There, I understood that consistency with RFC 7401 has a higher priority than only fixing your comments for HIP DEX, but keeping the text as is for RFC 7401. This means, I will not modify the text in the HIP DEX draft. Is this also your intention?

And how do we produce an errata for 7401 to address the issues within 7401...


The last remaining issue is related to the UPDATE message and the rekeying procedure (Section 6.10.). Here, I added the following paragraph for clarification purposes:

   [RFC7402] specifies the rekeying of an existing HIP SA using the
   UPDATE message.  This rekeying procedure can also be used with HIP
   DEX.  However, where rekeying involves a new Diffie-Hellman key
   exchange, HIP DEX peers MUST establish a new connection in order to
   create a new Pair-wise Key SA due to the use of static ECDH key-pairs
   with HIP DEX.

Does this fix your issue?

BR
René



On Tue, Jun 7, 2016 at 3:11 PM, Miika Komu <miika.komu@ericsson.com> wrote:
Hi,

On 06/03/2016 02:20 PM, René Hummen wrote:
This is part 3 of 3.

 I am fine with your fixes. Some comments below.

On Mon, Mar 28, 2016 at 10:05 PM, Miika Komu <miika.komu@ericsson.com
 <mailto:miika.komu@ericsson.com>> wrote:
> [...]
     > 6.2.1.  CMAC Calculation
     >
     > [...]
     >
     >
     > 5.  Set Checksum and Header Length fields in the HIP header to
     > original values.  Note that the Checksum and Length fields
     > contain incorrect values after this step.

    I guess also the values following HIP_MAC should be restored since
    they were wiped in the step 2.


I also found this description a bit imprecise, but it is taken from
RFC7401. Step 2 already hints at the fact that parameters following
HIP_MAC may still be of interest:
"Remove the HIP_MAC parameter, as well as all other parameters
        that follow it with greater Type value, saving the contents if
        they will be needed later."

The question is whether we want to fix the description for HIP DEX or to
keep things as they are for consistency reasons. In the former case, I
would prefer to completely rewrite the verification procedure to work on
the received packet without removing any parameters. However, we should
then probably also post an errata to RFC7401. If there are no stong
opinions about that, I would go for the latter option.

 Latter option works for me too.

     > The CKDF-Extract function is the following operation:
     >
     > CKDF-Extract(I, IKM, info) -> PRK

    What does the arrow operator signify? I thought that it produces PRK,
    but PRK is actually defined below.


The arrow is part of a basic mathematical function definition. So yes,
PRK is the output (domain), but we still need to give it a proper name.
I changed the artwork to clearly point out the inputs and outputs.

 Thanks, it is now better.

Please check this section again in the updated version and get back to
me if the above changes do not sufficiently help your understanding.

 It is good now, thanks!

     > L        length of output keying material in octets
     >          (<= 255*RHASH_len/8)
     > |        denotes the concatenation
     >
     > The output keying material OKM is calculated as follows:
     >
     > N       =  ceil(L/RHASH_len/8)
     > T       =  T(1) | T(2) | T(3) | ... | T(N)
     > OKM     =  first L octets of T
     >
     > where
     >
     > T(0) = empty string (zero length)
     > T(1) = CMAC(PRK, T(0) | info | 0x01)
     > T(2) = CMAC(PRK, T(1) | info | 0x02)
     > T(3) = CMAC(PRK, T(2) | info | 0x03)
     > ...

    The Expand was a bit more clear, but still didn't understand how to
    get to the
    Expanded key material due the arrow notation.


Ok, let's clarify this as several comments are related to the arrow
notation. For the function definition we use the mathematical arrow
notation (same as RFC 5869) and for the actual opertation we use the
equals sign (same as RFC 5869). In the end, they denote the same thing:
"assign X to Y".

 Ok, this is what I guessed too.

     > (where the constant concatenated to the end of each T(n) is a
     > single octet.)

    Is there a max value?


I am not sure what you mean here. If you refer to the N in T(N) then it
is defined above as N = ceil(L/RHASH_len/8).

 Yes, I asked about the maximum value for N (which depends on L), but never mind.

     > 8.   The R1 packet may have the A-bit set - in this case, the system
     > MAY choose to refuse it by dropping the R1 packet and returning
     > to state UNASSOCIATED.  The system SHOULD consider dropping the
     > R1 packet only if it used a NULL HIT in the I1 packet.

    I didn't understand the logic in the last sentence.


Someone must have had a reason for this recommendation, but that someone
wasn't me. This is text from RFC7401. Any suggestions how to proceed?

 Fix similarly as the other RFC7401 issue in the beginning of this email.

     > 6.7.  Processing Incoming I2 Packets
     >
     > [...]
     >
     > 5.   If the system's state machine is in the I2-SENT state, the
     > system MUST make a comparison between its local and sender's
     > HITs (similarly as in Section 6.3).  If the local HIT is smaller
     > than the sender's HIT, it should drop the I2 packet, use the
     > peer Diffie-Hellman key, ENCRYPTED_KEY keying material and nonce
     > #I from the R1 packet received earlier, and get the local
     > Diffie-Hellman key, ENCRYPTED_KEY keying material, and nonce #J
     > from the I2 packet sent to the peer earlier.  Otherwise, the
     > system should process the received I2 packet and drop any
     > previously derived Diffie-Hellman keying material Kij and
     > ENCRYPTED_KEY keying material it might have generated upon
     > sending the I2 packet previously.  The peer Diffie-Hellman key,
     > ENCRYPTED_KEY, and the nonce #J are taken from the just arrived
     > I2 packet.  The local Diffie-Hellman key, ENCRYPTED_KEY keying
     > material, and the nonce #I are the ones that were sent earlier
     > in the R1 packet.

    Please replace "sender" with "peer" (or remote host) in this section
    for more symmetric terminology.

    get -> obtain


I can make these changes if you insist, but I was going for a minimal
diff to RFC 7401.

 Not insisting.


     > 11.  The implementation SHOULD also verify that the Initiator's HIT
     > in the I2 packet corresponds to the Host Identity sent in the I2
     > packet.  (Note: some middleboxes may not be able to make this
     > verification.)

    Why SHOULD? Why not MUST? I think we're talking about end-hosts here
    anyway.


It is defined this way in RFC 7401. Do you really want to change the
packet processing behavior for HIP DEX only?

 Fix similarly as the first RFC7401 issue in this email.

     > 6.10.  Processing UPDATE, CLOSE, and CLOSE_ACK Packets

     > UPDATE, CLOSE, and CLOSE_ACK packets are handled similarly in HIP DEX
     > as in HIP BEX (see Sections 6.11, 6.12, 6.14, and 6.15 of [RFC7401]).
     > The only difference is the that the HIP_SIGNATURE is never present
     > and, therefore, is not required to be processed by the receiving
     > party.

    How does rekeying work with the extract and expand functions?


Rekeying is not defined in this document, same as for RFC 7401. That
being said, the rekeying procedure with reuse of the KEYMAT from RFC
7402 directly translates to HIP DEX. For new KEYMAT, the peers need to
establish a new connection due to the use of static DH keys.

 Maybe this should be explicitly stated in the draft.



     > 7.  HIP Policies

     > There are a number of variables that will influence the HIP exchanges
     > that each host must support.  All HIP DEX implementations SHOULD
     > provide for an ACL of Initiator's HI to Responder's HI.  This ACL
     > SHOULD also include preferred transform and local lifetimes.
     > Wildcards SHOULD also be supported for this ACL.

    Why ACLs are mandatory?


It is not a MUST and considering that HIP DEX is primarly targeted at
things, there is the need to do basic device authorizations (based on
their identities) without a human in the loop. Of course you are also
allowed to use more suffisticated authorization mechanisms.

 Ok.

    ACL -> ACL consisting of


Changed to the following text that is closer to RFC 7401:
"   All HIP DEX implementations SHOULD provide for an Access Control List
    (ACL), representing for which hosts they accept HIP diet exchanges,
    and the preferred transport format and local lifetimes.  Wildcarding
    SHOULD be supported for such ACLs."

     > 8.  Security Considerations

     > o  The HIP DEX HIT generation may present new attack opportunities.

    They cannot be used in ACLs. Maybe this could be mentioned. Can this
    be mitigated by always using full HIs?


I changed the bullet-point as follows:
"The HIP DEX HIT generation may present new attack opportunities.
       Hence, HIP DEX HITs should not be use as the only means to
       identify a peer in an ACL.  Instead, the use of the peer's HI is
       recommended."

 Ok.

Note that I added a new Section 8 "Interoperability between HIP DEX and
HIPv2" to satisfy your comment on HIP DEX and HIPv2 compatibility.

 Thanks!


_______________________________________________
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec




_______________________________________________
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

--------------28284CB5C6E8D0E063B71622-- From nobody Mon Sep 12 07:28:03 2016 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 0376412B398; Mon, 12 Sep 2016 07:28:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147369048095.8941.13027964102448014990.idtracker@ietfa.amsl.com> Date: Mon, 12 Sep 2016 07:28:00 -0700 Archived-At: Cc: hipsec@ietf.org, hip-chairs@ietf.org, draft-ietf-hip-rfc5206-bis@ietf.org Subject: [Hipsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-hip-rfc5206-bis-13=3A_=28with_COMMENT=29?= X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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 Sep 2016 14:28:01 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-hip-rfc5206-bis-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5206-bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Some concrete comments: 1) Can you further explain the scenario assumed in these sentences! What is the middblebox supposed/expected to do? "In this case, the OLD SPI and NEW SPI parameters both are set to the value of the preexisting incoming SPI; this ESP_INFO does not trigger a rekeying event but is instead included for possible parameter-inspecting middleboxes on the path. " and "An additional potential benefit of performing address verification is to allow middleboxes in the network along the new path to obtain the peer host's inbound SPI." 2) Section 3.2.1. step 2: I guess the peer would also need to retransmit the UPDATE+ECHO_REQUEST if it doesn't get a reply in time? (Didn't check RFC7401...) 3) section 4: Can you give any hints how large the lifetime typically should be? Can only the original address have an unbounded lifetime (see section 5) or can I also set the lifetime value in a certain way to declare the lifetime of this address of unbounded? 4) section 4/5: maybe state more clearly that a 'new' LOCATOR_SET replaces the old one and therefore if a hosts sens a LOCATOR_SET is MUST include all active addresses. I believe that's what you are doing from the description in section 5 but it's never really spelled out... 5) section 5.4: How long will an address be in UNVERIFIED state in case the verification is not successful (no reply). Is there a timer? How often will the peer retry the verification test? How long does the peer wait until resending the verification packet? 6) section 5.6: The proposed Credit-Based Authorization seems quite complicated for me. First please state clearly the goal: I guess the scenario is that that you send data to the host and the host switches to new address. To be able to keep sending data with the same rate during the "switch-over 3-way-handshake" you need this credit system. So, what you actually need is to estimate the current sending rate in packets per RTT and take this number of packets as your credit. If you know the RTT you can simply count the packets. You can probably always estimate the RTT during the initial HIP 'handshake'/UPDATE exchange. If you don't have a way to update this RTT estimate during the connection, you might just use 2xRTT or 3xRTT to be safe... And more general comments: 1) Did you see any deployment problems because you don't expose a port number (at a know location above the IP header) with e.g. NATs? 2) Usually documents that obsolete another rfc have a "changes from RFCXXXX" section. Not sure if this is needed in this case when you move from experimental to proposed stanadard but given the rather larger number of changes, I would find it helpful. 3) I believe reading would be easier for me if section 4 would have been first but not sure... 4) This docuemnt states several times that mutlihoming is out of scope and only the handover case is described. I think it would be better to state this clearly at the very beginning and remove the other cases (I believe these are anyway kind of left-overs from the previous document.) From nobody Tue Sep 13 02:14:22 2016 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 C913C12B25C for ; Tue, 13 Sep 2016 02:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.709 X-Spam-Level: X-Spam-Status: No, score=-5.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] 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 z3Wyjm0fuLGK for ; Tue, 13 Sep 2016 02:14:20 -0700 (PDT) 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 6E05A12B25B for ; Tue, 13 Sep 2016 02:14:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 9BCDE62175; Tue, 13 Sep 2016 05:14:19 -0400 (EDT) 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 qFmzZEo17fP6; Tue, 13 Sep 2016 05:14:14 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [5.148.40.66]) (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 3458662126; Tue, 13 Sep 2016 05:14:13 -0400 (EDT) To: Mirja Kuehlewind References: <147369048095.8941.13027964102448014990.idtracker@ietfa.amsl.com> From: Robert Moskowitz Message-ID: <8a78c1eb-25c2-ccd4-2276-6f4ac962273e@htt-consult.com> Date: Tue, 13 Sep 2016 10:14:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <147369048095.8941.13027964102448014990.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: hipsec@ietf.org Subject: Re: [Hipsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-hip-rfc5206-bis-13=3A_=28with_COMMENT=29?= X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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 Sep 2016 09:14:22 -0000 I have one question on sec 5.4 before I enter a comment... On 09/12/2016 03:28 PM, Mirja Kuehlewind wrote: > 5) section 5.4: How long will an address be in UNVERIFIED state in case > the verification is not successful (no reply). Is there a timer? How > often will the peer retry the verification test? How long does the peer > wait until resending the verification packet? > It took me a couple readings of 5.4 to THINK I understand fig 7. I THINK this occurs after Mobile Host has sent its HIP UPDATE with the new locator information. I believe the implication of this figure is that the stationary node (peer host) sends its address validation HIP UPDATE and instead of receiving the HIP UPDATE with ACK, it receives actual data which it may interpret as the ACK. So I have two points. First does this only apply when there are new SPI? What about a move with no SPI changes? Second, the actual figure should include the original HIP UPDATE from Mobile Host to make it clear the nature of the mobility. Sorry for the late review of this draft. I can submit an official comment if others think my questions raise clarity issues. Bob From nobody Tue Sep 13 07:37:47 2016 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 DD3DD12B667; Tue, 13 Sep 2016 07:37:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147377746074.11000.15207997128478492922.idtracker@ietfa.amsl.com> Date: Tue, 13 Sep 2016 07:37:40 -0700 Archived-At: Cc: hipsec@ietf.org, hip-chairs@ietf.org, draft-ietf-hip-rfc5206-bis@ietf.org Subject: [Hipsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-hip-rfc5206-bis-13=3A_=28with_COMMENT=29?= X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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 Sep 2016 14:37:41 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-hip-rfc5206-bis-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5206-bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Some concrete comments: 1) Can you further explain the scenario assumed in these sentences! What is the middblebox supposed/expected to do? "In this case, the OLD SPI and NEW SPI parameters both are set to the value of the preexisting incoming SPI; this ESP_INFO does not trigger a rekeying event but is instead included for possible parameter-inspecting middleboxes on the path. " and "An additional potential benefit of performing address verification is to allow middleboxes in the network along the new path to obtain the peer host's inbound SPI." 2) Section 3.2.1. step 2: I guess the peer would also need to retransmit the UPDATE+ECHO_REQUEST if it doesn't get a reply in time? (Didn't check RFC7401...) 3) section 4: Can you give any hints how large the lifetime typically should be? Can only the original address have an unbounded lifetime (see section 5) or can I also set the lifetime value in a certain way to declare the lifetime of this address of unbounded? 4) section 4/5: maybe state more clearly that a 'new' LOCATOR_SET replaces the old one and therefore if a hosts sens a LOCATOR_SET is MUST include all active addresses. I believe that's what you are doing from the description in section 5 but it's never really spelled out... 5) section 5.4: How long will an address be in UNVERIFIED state in case the verification is not successful (no reply). Is there a timer? How often will the peer retry the verification test? How long does the peer wait until resending the verification packet? 6) section 5.6: The proposed Credit-Based Authorization seems quite complicated for me. First please state clearly the goal: I guess the scenario is that that you send data to the host and the host switches to new address. To be able to keep sending data with the same rate during the "switch-over 3-way-handshake" you need this credit system. So, what you actually need is to estimate the current sending rate in packets per RTT and take this number of packets as your credit. If you know the RTT you can simply count the packets. You can probably always estimate the RTT during the initial HIP 'handshake'/UPDATE exchange. If you don't have a way to update this RTT estimate during the connection, you might just use 2xRTT or 3xRTT to be safe... And more general comments: 1) Did you see any deployment problems because you don't expose a port number (at a know location above the IP header) with e.g. NATs? 2) Usually documents that obsolete another rfc have a "changes from RFCXXXX" section. Not sure if this is needed in this case when you move from experimental to proposed stanadard but given the rather larger number of changes, I would find it helpful. 3) I believe reading would be easier for me if section 4 would have been first but not sure... 4) This docuemnt states several times that mutlihoming is out of scope and only the handover case is described. I think it would be better to state this clearly at the very beginning and remove the other cases (I believe these are anyway kind of left-overs from the previous document.) 5) The security section should also talk about privacy concerns when exposing identifiers to middleboxes (see comment 1 above) From nobody Tue Sep 13 07:40:32 2016 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 352BE12B81F; Tue, 13 Sep 2016 07:40:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147377763017.10979.10082464433054958894.idtracker@ietfa.amsl.com> Date: Tue, 13 Sep 2016 07:40:30 -0700 Archived-At: Cc: draft-ietf-hip-multihoming@ietf.org, hipsec@ietf.org, hip-chairs@ietf.org Subject: [Hipsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-hip-multihoming-11=3A_=28with_COMMENT=29?= X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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 Sep 2016 14:40:30 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-hip-multihoming-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-hip-multihoming/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- One big general comment: The split between this document and draft-ietf-hip-rfc5206-bis-13 (still) seems a little artificial. draft-ietf-hip-rfc5206-bis-13 describes some general parts that actually covers both use cases. I guess it would be at least nice to spell out clearly in this document which parts of draft-ietf-hip-rfc5206-bis-13 are required to read (section 4 and parts of section 5) if that's is somehow clearly separately. E.g. I believe the following should be in draft-ietf-hip-rfc5206-bis-13 and not in this doc: "Hosts MUST NOT announce broadcast or multicast addresses in LOCATOR_SETs. " I this is more relevant for the case described in this document but is true for the general case. draft-ietf-hip-rfc5206-bis-13 stated the following but that's not the same because it only describes the peer side: " For each locator listed in the LOCATOR_SET parameter, check that the address therein is a legal unicast or anycast address. That is, the address MUST NOT be a broadcast or multicast address." What worries me more is that I believe that one would need to always read both documents to implement the peer functionality correctly. E.g. this documents says the following: "An Initiator MAY include one or more LOCATOR_SET parameters in the I2 packet, independent of whether or not there was a LOCATOR_SET parameter in the R1. These parameters MUST be protected by the I2 signature. Even if the I2 packet contains LOCATOR_SET parameters, the Responder MUST still send the R2 packet to the source address of the I2." However, when I read draft-ietf-hip-rfc5206-bis-13, it is not clear that there are specifications in this document that are important for a correct implementation. Smaller comments: 1) Regarding the following sentence: "In summary, whether and how a host decides to leverage additional addresses in a load-balancing or fault-tolerant manner is outside the scope of the specification." I agree that it is out of scope for this doc. But maybe it would be useful to provide pointers to existng work. The scheduling problem is well know and e.g. basically the same for MPTCP. 2) Regarding the following recommendation: "Although the protocol may allow for configurations in which there is an asymmetric number of SAs between the hosts (e.g., one host has two interfaces and two inbound SAs, while the peer has one interface and one inbound SA), it is RECOMMENDED that inbound and outbound SAs be created pairwise between hosts. When an ESP_INFO arrives to rekey a particular outbound SA, the corresponding inbound SA should be also rekeyed at that time." I believe I agree but why? 3) I (again) would find it easier to have section 4.9, 4.10, and 4.11 before 4.2-4.8. However, I guess that's a matter of taste. Alternatively maybe have most of the text from 4.2-4.8 in a separate supersection first and call it 'usage scenarios' or something like this, while summerizing the protocol actions in one subsection in the 'protocol overview' section because it seems that the actions are actually quite similar for all use cases, no? 4) Maybe indicate clearly what is recommendated in draft-ietf-hip-rfc5206-bis the following way: OLD "[I-D.ietf-hip-rfc5206-bis] recommends that a host should send a LOCATOR_SET whenever it recognizes a change of its IP addresses in use on an active HIP association, and assumes that the change is going to last at least for a few seconds. " NEW "[I-D.ietf-hip-rfc5206-bis] recommends that "a host should send a LOCATOR_SET whenever it recognizes a change of its IP addresses in use on an active HIP association, and assumes that the change is going to last at least for a few seconds. "" 5) How does a host know about this? Can you give examples? "The grouping should consider also whether middlebox interaction requires sending the same LOCATOR_SET in separate UPDATEs on different paths." From nobody Tue Sep 13 12:22:46 2016 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 B02CF12B4F2; Tue, 13 Sep 2016 12:22:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147379456167.25378.17070605132907462726.idtracker@ietfa.amsl.com> Date: Tue, 13 Sep 2016 12:22:41 -0700 Archived-At: Cc: draft-ietf-hip-multihoming@ietf.org, hipsec@ietf.org, hip-chairs@ietf.org Subject: [Hipsec] Kathleen Moriarty's No Objection on draft-ietf-hip-multihoming-11: (with COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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 Sep 2016 19:22:42 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-hip-multihoming-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-hip-multihoming/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm wondering if split-tunneling should be listed as a security consideration. I see the following in section 4.1 that might be used to help prevent split tunneling: In the outbound direction, as a result of SPD processing, when an outbound SA is selected, the correct IP destination address for the peer must also be assigned. Then also the entirety of section 4.3. I read this as split tunneling could be an issue in some circumstances depending on policy and it might be good to mention this in the security considerations section. Or let me know if I am missing some background that would prevent split tunneling so implementers don't need to be made aware of this consideration. Thanks. From nobody Wed Sep 14 00:15:49 2016 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 C0AA312B026; Wed, 14 Sep 2016 00:15:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147383734774.1754.14602598736270302802.idtracker@ietfa.amsl.com> Date: Wed, 14 Sep 2016 00:15:47 -0700 Archived-At: Cc: hipsec@ietf.org, hip-chairs@ietf.org, draft-ietf-hip-rfc5206-bis@ietf.org Subject: [Hipsec] Alexey Melnikov's No Objection on draft-ietf-hip-rfc5206-bis-13: (with COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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, 14 Sep 2016 07:15:48 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-hip-rfc5206-bis-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5206-bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have a couple of minor nearly DISCUSSes that should be easy to fix: This document doesn't have "Changes since RFC XXXX" section as required for any -bis document. Can you please convert Appendix A to be such a section? As this is a -bis document that obsoletes the original RFC 5206, its IANA Considerations section should be self contained. I think you should mention that IANA has allocated type 193 for LOCATOR_SET and type 46 for LOCATOR_TYPE_UNSUPPORTED Notify Message Type, as specified in RFC 5206. From nobody Wed Sep 14 04:25:37 2016 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 99E5012B265; Wed, 14 Sep 2016 04:25:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147385233558.1992.10624848840546043105.idtracker@ietfa.amsl.com> Date: Wed, 14 Sep 2016 04:25:35 -0700 Archived-At: Cc: draft-ietf-hip-multihoming@ietf.org, hipsec@ietf.org, hip-chairs@ietf.org Subject: [Hipsec] Stephen Farrell's No Objection on draft-ietf-hip-multihoming-11: (with COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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, 14 Sep 2016 11:25:35 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-hip-multihoming-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-hip-multihoming/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - I think section 6 ought note the privacy issue that was relatively recently with WebRTC and ICE where a client might not want all of it's IP addresses exposed, as doing so could expose the fact that the client e.g. is using Tor or another VPN service. The issue being that in some locations, that information may be quite sensitive. 4.2 notes this but in a quite opaque way, ("may be held back") but it'd be better to say some more. 5.1 is also relevant maybe in that it says one "SHOULD avoid" sending info about virtual interfaces. Anyway, I think it'd be good to add some recognition of this privacy issue to section 6. I am not arguing that this draft ought specify the one true way to avoid this problem, but only that it be recognised. - 4.11: what's the concern about anti-replay windows? I didn't get that fwiw, not sure if that just my relative ignorance of HIP or if more needs to be said in the document. From nobody Wed Sep 14 05:16:38 2016 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 29AD412B327; Wed, 14 Sep 2016 05:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.408 X-Spam-Level: X-Spam-Status: No, score=-3.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508] 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 Dz6EeXsZ4ZZj; Wed, 14 Sep 2016 05:16:12 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 59E6012B322; Wed, 14 Sep 2016 05:16:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 1FE172CC9C; Wed, 14 Sep 2016 15:16:10 +0300 (EEST) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kga-jC_ZfYyC; Wed, 14 Sep 2016 15:16:09 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 350B22CC9B; Wed, 14 Sep 2016 15:16:09 +0300 (EEST) (envelope-from jari.arkko@piuha.net) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_4880A146-FCDD-4135-9599-19BAB4D02ECC"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Jari Arkko In-Reply-To: <147385233558.1992.10624848840546043105.idtracker@ietfa.amsl.com> Date: Wed, 14 Sep 2016 15:16:08 +0300 Message-Id: <812AA6E1-B1D9-43C8-9422-C0D997F99E79@piuha.net> References: <147385233558.1992.10624848840546043105.idtracker@ietfa.amsl.com> To: Stephen Farrell X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: draft-ietf-hip-multihoming@ietf.org, hipsec@ietf.org, hip-chairs@ietf.org, The IESG Subject: Re: [Hipsec] Stephen Farrell's No Objection on draft-ietf-hip-multihoming-11: (with COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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, 14 Sep 2016 12:16:15 -0000 --Apple-Mail=_4880A146-FCDD-4135-9599-19BAB4D02ECC Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Thanks for your review, Stephen. > - I think section 6 ought note the privacy issue that > was relatively recently with WebRTC and ICE where a > client might not want all of it's IP addresses > exposed, as doing so could expose the fact that the > client e.g. is using Tor or another VPN service. The > issue being that in some locations, that information > may be quite sensitive. 4.2 notes this but in a quite > opaque way, ("may be held back") but it'd be better to > say some more. Seems very reasonable. > 5.1 is also relevant maybe in that it > says one "SHOULD avoid" sending info about virtual > interfaces. Anyway, I think it'd be good to add some > recognition of this privacy issue to section 6. I am > not arguing that this draft ought specify the one true > way to avoid this problem, but only that it be > recognised. Yes Jari --Apple-Mail=_4880A146-FCDD-4135-9599-19BAB4D02ECC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJX2T+IAAoJEM80gCTQU46qc04P/iY7g0JzKEBB7k4Re9VaYmI5 vs3BaRdN76CB2r7L1Dp07ZOciEN4B9e+yDaDLDC4p66NOkf3geggV7yggtbAK2a9 subG7HLi0TuLcixTdKOvxa65eTw1oyhmC2Etgg2WNuD9MZfZRVV+8diQ263qX2L3 oT2MJ8YrQThAF3VVe+gEtE5ESLEKJQI9jbmcPmEQG2k7yiY3m0Sfovh8Jx2RE01I WPCteoA0qlivWJp3I111MipkWuD8+LYTwzXH9+w6rdpCqc+vxzTZiGXG66sfUuyN 6FjQ7nBEV25YWIFh+RGtIF26m7Lr2o3oonv+KYJ9iwhp1MFPBUQ4OefPxiWtdMdj yXfLpvIA9pFyUWtGiVnwbHqfcccetucTRmp6pBh+EKpUkh2ZZ0pghVxy5Uj9mhn0 x9r+mWWM+J+Evb5oxdsD1Otr0XE54/tjjTmAAr23mp69N0h3jv83LECZ+O28zNuY A26kMH4WvNKXi9lOBOZWH7kxqtB0iG2gW3Yg1VXaAoqVVQpVAvaJk6nl/Jkvd7g7 lP00NP63K2P9qZjSvNwbMOiH5Le49iCtkkIYCAdtI9BRSjc2TUUZ83At3GgyfVsa 0pvlbpQLlgYOfiuDj4ygPn+EXZ0/BHhTnFhJA4pNr0yc/jI+paOTxg0BW35Fpkfn Y2a5dH6q/KgfBO8Q461m =LrqY -----END PGP SIGNATURE----- --Apple-Mail=_4880A146-FCDD-4135-9599-19BAB4D02ECC-- From nobody Wed Sep 14 15:18:55 2016 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 AB396127A90; Wed, 14 Sep 2016 15:18:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147389153065.29849.8209733472001539786.idtracker@ietfa.amsl.com> Date: Wed, 14 Sep 2016 15:18:50 -0700 Archived-At: Cc: hipsec@ietf.org, hip-chairs@ietf.org, draft-ietf-hip-rfc5206-bis@ietf.org Subject: [Hipsec] Stephen Farrell's No Objection on draft-ietf-hip-rfc5206-bis-13: (with COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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, 14 Sep 2016 22:18:51 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-hip-rfc5206-bis-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5206-bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- My review was based on the diff vs. 5206 [1], and turned up nothing new of note:-) Seems like a reasonable update to me. I do however agree about the privacy issue raised by Mirja wrt exposing locators. It is worth noting that, so that implementers have it flagged that they need to consider that - not doing so caused quite a fuss for WebRTC so better to not repeat that. [1] https://tools.ietf.org/rfcdiff?url1=rfc5206&url2=draft-ietf-hip-rfc5206-bis-13.txt From nobody Wed Sep 14 21:52:16 2016 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 BA70212B170; Wed, 14 Sep 2016 21:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] 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 jl_JSMeyurDt; Wed, 14 Sep 2016 21:52:07 -0700 (PDT) Received: from mxout21.s.uw.edu (mxout21.s.uw.edu [140.142.32.139]) (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 AB09612B16E; Wed, 14 Sep 2016 21:52:04 -0700 (PDT) Received: from hymn01.u.washington.edu (hymn01.u.washington.edu [140.142.9.110]) by mxout21.s.uw.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u8F4m8Pg031591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Sep 2016 21:48:09 -0700 Received: from hymn01.u.washington.edu (localhost [127.0.0.1]) by hymn01.u.washington.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u8F4m8bM032133; Wed, 14 Sep 2016 21:48:08 -0700 Received: from localhost (Unknown UID 21258@localhost) by hymn01.u.washington.edu (8.14.4+UW14.03/8.14.4+Submit-local) with ESMTP id u8F4m7no032124; Wed, 14 Sep 2016 21:48:08 -0700 X-Auth-Received: from [73.140.18.44] by hymn01.u.washington.edu via HTTP; Wed, 14 Sep 2016 21:48:07 PDT Date: Wed, 14 Sep 2016 21:48:07 -0700 (PDT) From: Tom Henderson To: ietf@kuehlewind.net Message-ID: User-Agent: Web Alpine 2.01 (LRH 1302 2010-07-20) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1903399415-99189172-1473914887=:22599" X-PMX-Version: 6.2.1.2493963, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.9.15.44217 X-PMX-Server: mxout21.s.uw.edu X-Uwash-Spam: Gauge=XI, Probability=11%, Report=' TO_IN_SUBJECT 0.5, MULTIPLE_RCPTS 0.1, HTML_00_01 0.05, HTML_00_10 0.05, MIME_TEXT_ONLY_MP_MIXED 0.05, SUPERLONG_LINE 0.05, BODY_SIZE_6000_6999 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, LEGITIMATE_NEGATE 0, LEGITIMATE_SIGNS 0, MSG_THREAD 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_NOT_1 0, __CP_URI_IN_BODY 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_MIXED 0, __FORWARDED_MSG 0, __HAS_CC_HDR 0, __HAS_FROM 0, __HAS_MSGID 0, __HTTPS_URI 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MULTIPLE_RCPTS_CC_X2 0, __MULTIPLE_URI_TEXT 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __SUBJ_HIGHBIT 0, __TO_IN_SUBJECT 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_IN_BODY 0, __URI_NO_MAILTO 0, __URI_NO_WWW 0, __URI_NS , __URI_WITH_PATH 0, __USER_AGENT 0' Archived-At: Cc: hipsec@ietf.org, draft-ietf-hip-rfc5206-bis@ietf.org, iesg@ietf.org, hip-chairs@ietf.org Subject: Re: [Hipsec] =?iso-8859-15?q?Mirja_K=FChlewind=27s_No_Objection_on_dr?= =?iso-8859-15?q?aft-ietf-hip-rfc5206-bis-13=3A_=28with_COMMENT=29?= X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 15 Sep 2016 04:52:10 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1903399415-99189172-1473914887=:22599 Content-Type: TEXT/PLAIN; charset=ISO-8859-15 Content-Transfer-Encoding: 8BIT On 09/12/2016 07:28 AM, Mirja Kuehlewind wrote: > Mirja Kühlewind has entered the following ballot position for > draft-ietf-hip-rfc5206-bis-13: No Objection Mirja, thank you for the review; responses inline below. - Tom > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Some concrete comments: > 1) Can you further explain the scenario assumed in these sentences! What > is the middblebox supposed/expected to do? > "In this case, the OLD SPI and NEW SPI parameters > both are set to the value of the preexisting incoming SPI; this > ESP_INFO does not trigger a rekeying event but is instead > included for possible parameter-inspecting middleboxes on the > path. " > and > "An additional potential benefit of performing address verification is > to allow middleboxes in the network along the new path to obtain the > peer host's inbound SPI." These scenarios are explained further in an informational RFC from a few years back (5207). https://tools.ietf.org/html/rfc5207 In brief, firewalls may wish to authenticate the HIP message exchanges and then limit access to the SPIs involved in the association. How about adding an informational reference to RFC 5207 when we raise such issues in this document? > > 2) Section 3.2.1. step 2: I guess the peer would also need to retransmit > the UPDATE+ECHO_REQUEST if it doesn't get a reply in time? (Didn't check > RFC7401...) Yes, in RFC 7401, the UPDATE messages are protected by a retransmission timer: https://tools.ietf.org/html/rfc7401#section-6.11 > > 3) section 4: Can you give any hints how large the lifetime typically > should be? Can only the original address have an unbounded lifetime (see > section 5) or can I also set the lifetime value in a certain way to > declare the lifetime of this address of unbounded? Effectively unbounded lifetimes can be set by setting the 32-bit field to the maximum value. In practice, I don't know of any guidance to offer, other than perhaps aligning it with lifetimes of the addresses such as DHCP leased addresses. I guess that we could add a statement that an 'effectively unbounded' lifetime can be set by setting the field to the maximum (unsigned) value. > > 4) section 4/5: maybe state more clearly that a 'new' LOCATOR_SET > replaces the old one and therefore if a hosts sens a LOCATOR_SET is MUST > include all active addresses. I believe that's what you are doing from > the description in section 5 but it's never really spelled out... Yes, I agree it could be stated more clearly. Perhaps early in Section 5.2, on sending LOCATOR_SET parameters, we could add a sentence such as "The sending of a new LOCATOR_SET parameter replaces the locator information from any previously sent LOCATOR_SET parameter, and therefore if a host sends a new LOCATOR_SET parameter, it MUST continue to include all active locators." Later in the text regarding processing of the received LOCATOR_SET parameter, it clearly states to deprecate locators that are no longer present. > > 5) section 5.4: How long will an address be in UNVERIFIED state in case > the verification is not successful (no reply). Is there a timer? How > often will the peer retry the verification test? How long does the peer > wait until resending the verification packet? This point is somewhat implied, but the verification is expected to be conducted using HIP UPDATE packet exchanges, which are protected by timers and a maximum retry count (RFC7401). Perhaps this can be stated more clearly such as "A typical verification that is protected by retransmission timers is to include an ECHO REQUEST within an UPDATE sent to the new address." > > 6) section 5.6: The proposed Credit-Based Authorization seems quite > complicated for me. First please state clearly the goal: I guess the > scenario is that that you send data to the host and the host switches to > new address. To be able to keep sending data with the same rate during > the "switch-over 3-way-handshake" you need this credit system. So, what > you actually need is to estimate the current sending rate in packets per > RTT and take this number of packets as your credit. If you know the RTT > you can simply count the packets. You can probably always estimate the > RTT during the initial HIP 'handshake'/UPDATE exchange. If you don't have > a way to update this RTT estimate during the connection, you might just > use 2xRTT or 3xRTT to be safe... I just reviewed the text again. Yes, the goal is as you stated, to provide for data transfer during this transient handshake period while minimizing the potential for abuse. The text doesn't offer any specific guidance on how to set the credit limit, but we could consider to add a heuristic such as you sketched out above. > > And more general comments: > 1) Did you see any deployment problems because you don't expose a port > number (at a know location above the IP header) with e.g. NATs? Well, to traverse legacy NATs requires UDP encapsulation (e.g. RFC 5770); I am not sure there is much experience with any NAT that is HIP aware or permissive in this regard. > > 2) Usually documents that obsolete another rfc have a "changes from > RFCXXXX" section. Not sure if this is needed in this case when you move > from experimental to proposed stanadard but given the rather larger > number of changes, I would find it helpful. Someone else also recently suggested this section; I will add one to the next version. > > 3) I believe reading would be easier for me if section 4 would have been > first but not sure... I'm not sure about reordering sections without more specific change proposals. > > 4) This docuemnt states several times that mutlihoming is out of scope > and only the handover case is described. I think it would be better to > state this clearly at the very beginning and remove the other cases (I > believe these are anyway kind of left-overs from the previous document.) Can you point to what you would like to have removed or changed? Early on, we moved most of this material to the other draft, and in scanning it again just now, I am not sure what more to take out or rephrase. It is hard to completely avoid the topic of having multiple addresses in this draft, particularly since we are defining the LOCATOR_SET parameter that is used in the multihoming specification. ---1903399415-99189172-1473914887=:22599-- From nobody Thu Sep 15 01:10:20 2016 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 E7B5212B1C9; Thu, 15 Sep 2016 01:10:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147392701592.12063.3491113610531611322.idtracker@ietfa.amsl.com> Date: Thu, 15 Sep 2016 01:10:15 -0700 Archived-At: Cc: hipsec@ietf.org, mehmet.ersue@nokia.com, hip-chairs@ietf.org, draft-ietf-hip-rfc5206-bis@ietf.org Subject: [Hipsec] Benoit Claise's No Objection on draft-ietf-hip-rfc5206-bis-13: (with COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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, 15 Sep 2016 08:10:16 -0000 Benoit Claise has entered the following ballot position for draft-ietf-hip-rfc5206-bis-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5206-bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Alexey's comment: This document doesn't have "Changes since RFC XXXX" section as required for any -bis document. Can you please convert Appendix A to be such a section? From nobody Thu Sep 15 07:42:54 2016 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 6F9C612B5E7 for ; Thu, 15 Sep 2016 07:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.41 X-Spam-Level: X-Spam-Status: No, score=-3.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 0vCvUtSDHaju for ; Thu, 15 Sep 2016 07:42:48 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A847612B5E8 for ; Thu, 15 Sep 2016 06:55:23 -0700 (PDT) Received: (qmail 32169 invoked from network); 15 Sep 2016 15:55:21 +0200 Received: from nb-10510.ethz.ch (HELO ?82.130.103.143?) (82.130.103.143) by kuehlewind.net with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 15 Sep 2016 15:55:21 +0200 To: Tom Henderson References: From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: Date: Thu, 15 Sep 2016 15:55:20 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=iso-8859-15; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: hipsec@ietf.org, draft-ietf-hip-rfc5206-bis@ietf.org, iesg@ietf.org, hip-chairs@ietf.org Subject: Re: [Hipsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-hip-rfc5206-bis-13=3A_=28with_COMMENT=29?= X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 15 Sep 2016 14:42:53 -0000 Hi Tom, please see inline. On 15.09.2016 06:48, Tom Henderson wrote: > On 09/12/2016 07:28 AM, Mirja Kuehlewind wrote: >> Mirja Kühlewind has entered the following ballot position for >> draft-ietf-hip-rfc5206-bis-13: No Objection > > Mirja, thank you for the review; responses inline below. > > - Tom > >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Some concrete comments: >> 1) Can you further explain the scenario assumed in these sentences! What >> is the middblebox supposed/expected to do? >> "In this case, the OLD SPI and NEW SPI parameters >> both are set to the value of the preexisting incoming SPI; this >> ESP_INFO does not trigger a rekeying event but is instead >> included for possible parameter-inspecting middleboxes on the >> path. " >> and >> "An additional potential benefit of performing address verification is >> to allow middleboxes in the network along the new path to obtain the >> peer host's inbound SPI." > > These scenarios are explained further in an informational RFC from a few years back (5207). > > https://tools.ietf.org/html/rfc5207 > > In brief, firewalls may wish to authenticate the HIP message exchanges and then limit access to the SPIs involved in the association. > > How about adding an informational reference to RFC 5207 when we raise such issues in this document? Yes, please. Maybe a sentence or two what the main points of rfc5207 are would be good as well. I would even recommend to not talk about "middleboxes" in general but "NAT and firewall traversal" as rfc5207 does. > >> >> 2) Section 3.2.1. step 2: I guess the peer would also need to retransmit >> the UPDATE+ECHO_REQUEST if it doesn't get a reply in time? (Didn't check >> RFC7401...) > > Yes, in RFC 7401, the UPDATE messages are protected by a retransmission timer: > https://tools.ietf.org/html/rfc7401#section-6.11 I would also recommend to spell this out (because it's done for the previous step) > >> >> 3) section 4: Can you give any hints how large the lifetime typically >> should be? Can only the original address have an unbounded lifetime (see >> section 5) or can I also set the lifetime value in a certain way to >> declare the lifetime of this address of unbounded? > > Effectively unbounded lifetimes can be set by setting the 32-bit field to the maximum value. Okay that's not spelled out in the doc. > In practice, I don't know of any guidance to offer, other than perhaps aligning it with lifetimes of the addresses such as DHCP leased addresses. That means like useful guidance. > > I guess that we could add a statement that an 'effectively unbounded' lifetime can be set by setting the field to the maximum (unsigned) value. Would you then also need to talk about risks when doing so...? > >> >> 4) section 4/5: maybe state more clearly that a 'new' LOCATOR_SET >> replaces the old one and therefore if a hosts sens a LOCATOR_SET is MUST >> include all active addresses. I believe that's what you are doing from >> the description in section 5 but it's never really spelled out... > > Yes, I agree it could be stated more clearly. Perhaps early in Section 5.2, on sending LOCATOR_SET parameters, we could add a sentence such as "The sending of a new LOCATOR_SET parameter replaces the locator information from any previously sent LOCATOR_SET parameter, and therefore if a host sends a new LOCATOR_SET parameter, it MUST continue to include all active locators." Later in the text regarding processing of the received LOCATOR_SET parameter, it clearly states to deprecate locators that are no longer present. Yes, thanks. > >> >> 5) section 5.4: How long will an address be in UNVERIFIED state in case >> the verification is not successful (no reply). Is there a timer? How >> often will the peer retry the verification test? How long does the peer >> wait until resending the verification packet? > > This point is somewhat implied, but the verification is expected to be conducted using HIP UPDATE packet exchanges, which are protected by timers and a maximum retry count (RFC7401). Perhaps this can be stated more clearly such as > "A typical verification that is protected by retransmission timers is to include an ECHO REQUEST within an UPDATE sent to the new address." Yes, please. > >> >> 6) section 5.6: The proposed Credit-Based Authorization seems quite >> complicated for me. First please state clearly the goal: I guess the >> scenario is that that you send data to the host and the host switches to >> new address. To be able to keep sending data with the same rate during >> the "switch-over 3-way-handshake" you need this credit system. So, what >> you actually need is to estimate the current sending rate in packets per >> RTT and take this number of packets as your credit. If you know the RTT >> you can simply count the packets. You can probably always estimate the >> RTT during the initial HIP 'handshake'/UPDATE exchange. If you don't have >> a way to update this RTT estimate during the connection, you might just >> use 2xRTT or 3xRTT to be safe... > > I just reviewed the text again. Yes, the goal is as you stated, to provide for data transfer during this transient handshake period while minimizing the potential for abuse. > > The text doesn't offer any specific guidance on how to set the credit limit, but we could consider to add a heuristic such as you sketched out above. For me that would make sense! Also state the goal make clear, so people know what to optimize for if they implement their own heuristic. > >> >> And more general comments: >> 1) Did you see any deployment problems because you don't expose a port >> number (at a know location above the IP header) with e.g. NATs? > > Well, to traverse legacy NATs requires UDP encapsulation (e.g. RFC 5770); I am not sure there is much experience with any NAT that is HIP aware or permissive in this regard. I think a reference to rfc5207/rfc5770 would be good. > >> >> 2) Usually documents that obsolete another rfc have a "changes from >> RFCXXXX" section. Not sure if this is needed in this case when you move >> from experimental to proposed stanadard but given the rather larger >> number of changes, I would find it helpful. > > Someone else also recently suggested this section; I will add one to the next version. Thx. It seems even required ;-) > >> >> 3) I believe reading would be easier for me if section 4 would have been >> first but not sure... > > I'm not sure about reordering sections without more specific change proposals. Or you could add a paragraph in the intro explaining where to find what. > >> >> 4) This docuemnt states several times that mutlihoming is out of scope >> and only the handover case is described. I think it would be better to >> state this clearly at the very beginning and remove the other cases (I >> believe these are anyway kind of left-overs from the previous document.) > > Can you point to what you would like to have removed or changed? Early on, we moved most of this material to the other draft, and in scanning it again just now, I am not sure what more to take out or rephrase. It is hard to completely avoid the topic of having multiple addresses in this draft, particularly since we are defining the LOCATOR_SET parameter that is used in the multihoming specification. > Maybe just grab from the word multihoming and double-check if you really need it there. For me it somtimes showed up at place there I thought it's actually not needed to mentioned that again. But that's nothing big... Mirja From nobody Thu Sep 15 08:32:54 2016 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 55D1912B8DC for ; Thu, 15 Sep 2016 08:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.709 X-Spam-Level: X-Spam-Status: No, score=-5.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] 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 bskPjN2EftDh for ; Thu, 15 Sep 2016 08:32:49 -0700 (PDT) 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 7D6A212B5C7 for ; Thu, 15 Sep 2016 07:34:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id AA7A362201 for ; Thu, 15 Sep 2016 10:34:19 -0400 (EDT) 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 1PVkkSM4UJLB for ; Thu, 15 Sep 2016 10:34:15 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [5.148.40.66]) (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 44CDD621FD for ; Thu, 15 Sep 2016 10:34:15 -0400 (EDT) To: hipsec@ietf.org From: Robert Moskowitz Message-ID: <6afe4119-3f13-b39a-62d8-fe361cfb9c95@htt-consult.com> Date: Thu, 15 Sep 2016 15:34:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Hipsec] Comment on VIA_RVS parameter - 5204 & 06 -bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 15 Sep 2016 15:32:54 -0000 5206-bis specifies how to user RVS for the 'double-jump' mobility problem. 3.2.3 1) says: 1. The mobile host sending an UPDATE to the peer, and not receiving an ACK, MAY resend the UPDATE to a rendezvous server (RVS) of the peer, if such a server is known. But it DOES know there is an RVS IF the I1 had FROM and RVS_HMAC parameters and it had created a VIA_RVS parameter to send in the R1. This VIA_RVS provides the knowledge and locator of the peer's RVS. In fact an aggressive mobility UPDATE would be sent simultaneously to the host and its RVS. If the host had not moved itself, it gets both and drops the one from the RVS. This comment recommends changes to 5204-bis 4.2.3 that the main goal of VIA_RVS is to facilitate support for the double-jump mobility problem and secondarily "to allow operators ...". And to 5206-bis section 3.2.3 to use the VIA_RVS to 'know' that there is an RVS for the host and to optionally aggressively send HIP mobility UPDATES to the RVS. From nobody Thu Sep 15 22:32:10 2016 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 5A94712B01F; Thu, 15 Sep 2016 22:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] 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 VTptcrZzRBXG; Thu, 15 Sep 2016 22:32:03 -0700 (PDT) Received: from mxout21.s.uw.edu (mxout21.s.uw.edu [140.142.32.139]) (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 E38EC1200DF; Thu, 15 Sep 2016 22:32:02 -0700 (PDT) Received: from hymn02.u.washington.edu (hymn02.u.washington.edu [140.142.8.71]) by mxout21.s.uw.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u8G5V0an002717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Sep 2016 22:31:00 -0700 Received: from hymn02.u.washington.edu (localhost [127.0.0.1]) by hymn02.u.washington.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u8G5Uu5D029449; Thu, 15 Sep 2016 22:30:56 -0700 Received: from localhost (Unknown UID 5440@localhost) by hymn02.u.washington.edu (8.14.4+UW14.03/8.14.4+Submit-local) with ESMTP id u8G5Ut4E029446; Thu, 15 Sep 2016 22:30:56 -0700 X-Auth-Received: from [73.140.18.44] by hymn02.u.washington.edu via HTTP; Thu, 15 Sep 2016 22:30:55 PDT Date: Thu, 15 Sep 2016 22:30:55 -0700 (PDT) From: Tom Henderson To: =?ISO-8859-15?Q?Mirja_K=FChlewind?= In-Reply-To: Message-ID: User-Agent: Web Alpine 2.01 (LRH 1302 2010-07-20) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1903409400-473519141-1474003855=:24569" X-PMX-Version: 6.2.1.2493963, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.9.16.52116 X-PMX-Server: mxout21.s.uw.edu X-Uwash-Spam: Gauge=XI, Probability=11%, Report=' TO_IN_SUBJECT 0.5, MULTIPLE_RCPTS 0.1, HTML_00_01 0.05, HTML_00_10 0.05, MIME_TEXT_ONLY_MP_MIXED 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_2000_2999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, IN_REP_TO 0, LEGITIMATE_NEGATE 0, LEGITIMATE_SIGNS 0, MSG_THREAD 0, MULTIPLE_REAL_RCPTS 0, NO_CTA_URI_FOUND 0, NO_URI_FOUND 0, NO_URI_HTTPS 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_MIXED 0, __FORWARDED_MSG 0, __HAS_CC_HDR 0, __HAS_FROM 0, __HAS_MSGID 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MULTIPLE_RCPTS_CC_X2 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __SUBJ_HIGHBIT 0, __TO_IN_SUBJECT 0, __TO_MALFORMED_2 0, __TO_NAME 0, __TO_NAME_DIFF_FROM_ACC 0, __TO_REAL_NAMES 0, __USER_AGENT 0' Archived-At: Cc: hipsec@ietf.org, draft-ietf-hip-rfc5206-bis@ietf.org, iesg@ietf.org, hip-chairs@ietf.org Subject: Re: [Hipsec] =?iso-8859-15?q?Mirja_K=FChlewind=27s_No_Objection_on_dr?= =?iso-8859-15?q?aft-ietf-hip-rfc5206-bis-13=3A_=28with_COMMENT=29?= X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 16 Sep 2016 05:32:04 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1903409400-473519141-1474003855=:24569 Content-Type: TEXT/PLAIN; format=flowed; charset=ISO-8859-15 Content-Transfer-Encoding: 8BIT Mirja, Inline below (the points still being discussed).... On Thu, 15 Sep 2016, Mirja Kühlewind wrote: >>> 3) section 4: Can you give any hints how large the lifetime typically >>> should be? Can only the original address have an unbounded lifetime (see >>> section 5) or can I also set the lifetime value in a certain way to >>> declare the lifetime of this address of unbounded? >> >> Effectively unbounded lifetimes can be set by setting the 32-bit field to >> the maximum value. > > Okay that's not spelled out in the doc. > >> In practice, I don't know of any guidance to offer, other than perhaps >> aligning it with lifetimes of the addresses such as DHCP leased addresses. > > That means like useful guidance. >> >> I guess that we could add a statement that an 'effectively unbounded' >> lifetime can be set by setting the field to the maximum (unsigned) value. > > Would you then also need to talk about risks when doing so...? I can make the above changes about lifetimes, but for the last one, I am not sure that there are any risks to it-- I won't mention risks unless someone in the list has ideas about any. >>> >>> 3) I believe reading would be easier for me if section 4 would have been >>> first but not sure... >> >> I'm not sure about reordering sections without more specific change >> proposals. > > Or you could add a paragraph in the intro explaining where to find what. OK > >> >>> >>> 4) This docuemnt states several times that mutlihoming is out of scope >>> and only the handover case is described. I think it would be better to >>> state this clearly at the very beginning and remove the other cases (I >>> believe these are anyway kind of left-overs from the previous document.) >> >> Can you point to what you would like to have removed or changed? Early on, >> we moved most of this material to the other draft, and in scanning it again >> just now, I am not sure what more to take out or rephrase. It is hard to >> completely avoid the topic of having multiple addresses in this draft, >> particularly since we are defining the LOCATOR_SET parameter that is used >> in the multihoming specification. >> > Maybe just grab from the word multihoming and double-check if you really need > it there. For me it somtimes showed up at place there I thought it's actually > not needed to mentioned that again. > But that's nothing big... I searched for the word just now and wasn't inclined to remove any of those remaining references, so I think I'll leave it for now unless someone proposes a specific change. - Tom ---1903409400-473519141-1474003855=:24569-- From nobody Thu Sep 15 22:42:17 2016 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 4CFA01200DF; Thu, 15 Sep 2016 22:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.708 X-Spam-Level: X-Spam-Status: No, score=-5.708 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] 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 q5GB3FdlYWWh; Thu, 15 Sep 2016 22:28:09 -0700 (PDT) Received: from mxout24.cac.washington.edu (mxout24.cac.washington.edu [140.142.234.158]) (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 D888012B0C2; Thu, 15 Sep 2016 22:28:08 -0700 (PDT) Received: from hymn02.u.washington.edu (hymn02.u.washington.edu [140.142.8.71]) by mxout24.cac.washington.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u8G5PeGT022372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Sep 2016 22:25:40 -0700 Received: from hymn02.u.washington.edu (localhost [127.0.0.1]) by hymn02.u.washington.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u8G5PbVa025482; Thu, 15 Sep 2016 22:25:37 -0700 Received: from localhost (Unknown UID 5440@localhost) by hymn02.u.washington.edu (8.14.4+UW14.03/8.14.4+Submit-local) with ESMTP id u8G5Pbie025479; Thu, 15 Sep 2016 22:25:37 -0700 X-Auth-Received: from [73.140.18.44] by hymn02.u.washington.edu via HTTP; Thu, 15 Sep 2016 22:25:37 PDT Date: Thu, 15 Sep 2016 22:25:37 -0700 (PDT) From: Tom Henderson To: Benoit Claise In-Reply-To: <147392701592.12063.3491113610531611322.idtracker@ietfa.amsl.com> Message-ID: User-Agent: Web Alpine 2.01 (LRH 1302 2010-07-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Content-Transfer-Encoding: 8BIT X-PMX-Version: 6.2.1.2493963, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.9.16.51517 X-PMX-Server: mxout24.cac.washington.edu X-Uwash-Spam: Gauge=IIIIIIII, Probability=8%, Report=' MULTIPLE_RCPTS 0.1, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_400_499 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, IN_REP_TO 0, LEGITIMATE_NEGATE 0, LEGITIMATE_SIGNS 0, MSG_THREAD 0, MULTIPLE_REAL_RCPTS 0, NO_CTA_URI_FOUND 0, NO_URI_FOUND 0, NO_URI_HTTPS 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CC_NAME 0, __CC_NAME_DIFF_FROM_ACC 0, __CC_REAL_NAMES 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_CC_HDR 0, __HAS_FROM 0, __HAS_MSGID 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MULTIPLE_RCPTS_CC_X2 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __TO_NAME 0, __TO_NAME_DIFF_FROM_ACC 0, __TO_REAL_NAMES 0, __USER_AGENT 0' Archived-At: X-Mailman-Approved-At: Thu, 15 Sep 2016 22:42:15 -0700 Cc: draft-ietf-hip-rfc5206-bis@ietf.org, hipsec@ietf.org, jari.arkko@piuha.net, hip-chairs@ietf.org, mehmet.ersue@nokia.com, alias-bounces@ietf.org, mail@christianvogt.net, The IESG Subject: Re: [Hipsec] Benoit Claise's No Objection on draft-ietf-hip-rfc5206-bis-13: (with COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 16 Sep 2016 05:28:10 -0000 On Thu, 15 Sep 2016, Benoit Claise wrote: > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I support Alexey's comment: > This document doesn't have "Changes since RFC XXXX" section as required > for any -bis document. Can you please convert Appendix A to be such a > section? > Agreed (also was suggested in another review). - Tom From nobody Thu Sep 15 22:58:15 2016 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 E479E12B0B6 for ; Thu, 15 Sep 2016 22:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] 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 Mc1vwaoWpb8p for ; Thu, 15 Sep 2016 22:58:12 -0700 (PDT) Received: from mxout22.s.uw.edu (mxout22.s.uw.edu [128.95.242.222]) (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 7F893126FDC for ; Thu, 15 Sep 2016 22:58:12 -0700 (PDT) Received: from hymn02.u.washington.edu (hymn02.u.washington.edu [140.142.8.71]) by mxout22.s.uw.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u8G5vleY026560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Sep 2016 22:57:47 -0700 Received: from hymn02.u.washington.edu (localhost [127.0.0.1]) by hymn02.u.washington.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u8G5vkBP014371; Thu, 15 Sep 2016 22:57:46 -0700 Received: from localhost (Unknown UID 5440@localhost) by hymn02.u.washington.edu (8.14.4+UW14.03/8.14.4+Submit-local) with ESMTP id u8G5vkZi014368; Thu, 15 Sep 2016 22:57:46 -0700 X-Auth-Received: from [73.140.18.44] by hymn02.u.washington.edu via HTTP; Thu, 15 Sep 2016 22:57:45 PDT Date: Thu, 15 Sep 2016 22:57:46 -0700 (PDT) From: Tom Henderson To: Robert Moskowitz In-Reply-To: <6afe4119-3f13-b39a-62d8-fe361cfb9c95@htt-consult.com> Message-ID: User-Agent: Web Alpine 2.01 (LRH 1302 2010-07-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Content-Transfer-Encoding: 8BIT X-PMX-Version: 6.2.1.2493963, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.9.16.54819 X-PMX-Server: mxout22.s.uw.edu X-Uwash-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_00_01 0.05, HTML_00_10 0.05, SUPERLONG_LINE 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_2000_2999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, IN_REP_TO 0, LEGITIMATE_NEGATE 0, LEGITIMATE_SIGNS 0, MSG_THREAD 0, MULTIPLE_REAL_RCPTS 0, NO_CTA_URI_FOUND 0, NO_URI_FOUND 0, NO_URI_HTTPS 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_CC_HDR 0, __HAS_FROM 0, __HAS_MSGID 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __TO_NAME 0, __TO_NAME_DIFF_FROM_ACC 0, __TO_REAL_NAMES 0, __USER_AGENT 0' Archived-At: Cc: hipsec@ietf.org Subject: Re: [Hipsec] Comment on VIA_RVS parameter - 5204 & 06 -bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 16 Sep 2016 05:58:14 -0000 On Thu, 15 Sep 2016, Robert Moskowitz wrote: > 5206-bis specifies how to user RVS for the 'double-jump' mobility problem. > > 3.2.3 1) says: > > 1. The mobile host sending an UPDATE to the peer, and not receiving an ACK, > MAY resend the UPDATE to a rendezvous server (RVS) of the peer, if such a > server is known. > > But it DOES know there is an RVS IF the I1 had FROM and RVS_HMAC parameters > and it had created a VIA_RVS parameter to send in the R1. Yes, but the responder may not know the initiator's RVS even if the the responder's RVS was used, and it also may be the case that neither host's RVS was involved in the session setup. > This VIA_RVS provides the knowledge and locator of the peer's RVS. > > In fact an aggressive mobility UPDATE would be sent simultaneously to the > host and its RVS. If the host had not moved itself, it gets both and drops > the one from the RVS. I believe that Baris Boyvat on the InfraHIP project was looking a while back at such an approach to fast mobility; it was called 'shotgun' approach to mobility and multihoming (try all candidates simultaneously), if I remember correctly. > > This comment recommends changes to 5204-bis 4.2.3 that the main goal of > VIA_RVS is to facilitate support for the double-jump mobility problem and > secondarily "to allow operators ...". > > And to 5206-bis section 3.2.3 to use the VIA_RVS to 'know' that there is an > RVS for the host and to optionally aggressively send HIP mobility UPDATES to > the RVS. > It seems to me that we ought to state that hosts should be prepared to handle duplicate mobility updates sent in parallel to different locators (such as to RVS(es) and to more than one of the host's addresses). We could also state that the aggressiveness of a host replicating its UPDATES to multiple destinations, to try them in parallel instead of serially, is a policy choice outside of the specification. Any other comments on this possible change? - Tom From nobody Fri Sep 16 00:58:16 2016 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 26B0412B04D for ; Fri, 16 Sep 2016 00:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.709 X-Spam-Level: X-Spam-Status: No, score=-5.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] 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 PxzmX4WQYAuJ for ; Fri, 16 Sep 2016 00:58:14 -0700 (PDT) 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 399E412B44C for ; Fri, 16 Sep 2016 00:58:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 1B3B962221; Fri, 16 Sep 2016 03:58:12 -0400 (EDT) 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 FHyALP6i9h-J; Fri, 16 Sep 2016 03:57:55 -0400 (EDT) Received: from lx120e.htt-consult.com (199.sub-70-194-67.myvzw.com [70.194.67.199]) (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 3EEC36221C; Fri, 16 Sep 2016 03:57:51 -0400 (EDT) To: Tom Henderson References: From: Robert Moskowitz Message-ID: Date: Fri, 16 Sep 2016 08:57:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: hipsec@ietf.org Subject: Re: [Hipsec] Comment on VIA_RVS parameter - 5204 & 06 -bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 16 Sep 2016 07:58:16 -0000 On 09/16/2016 06:57 AM, Tom Henderson wrote: > > > > On Thu, 15 Sep 2016, Robert Moskowitz wrote: > >> 5206-bis specifies how to user RVS for the 'double-jump' mobility >> problem. >> >> 3.2.3 1) says: >> >> 1. The mobile host sending an UPDATE to the peer, and not receiving >> an ACK, MAY resend the UPDATE to a rendezvous server (RVS) of the >> peer, if such a server is known. >> >> But it DOES know there is an RVS IF the I1 had FROM and RVS_HMAC >> parameters and it had created a VIA_RVS parameter to send in the R1. > > Yes, but the responder may not know the initiator's RVS even if the > the responder's RVS was used, and it also may be the case that neither > host's RVS was involved in the session setup. Correct, but this would be a NAT/Firewall traversal case. And right now I am not reviewing that work as my project is 5GPP mobility with IPv6. I am looking at the 5206 case with the Responder found via RVS. > >> This VIA_RVS provides the knowledge and locator of the peer's RVS. >> >> In fact an aggressive mobility UPDATE would be sent simultaneously to >> the host and its RVS. If the host had not moved itself, it gets both >> and drops the one from the RVS. > > I believe that Baris Boyvat on the InfraHIP project was looking a > while back at such an approach to fast mobility; it was called > 'shotgun' approach to mobility and multihoming (try all candidates > simultaneously), if I remember correctly. OK. > >> >> This comment recommends changes to 5204-bis 4.2.3 that the main goal >> of VIA_RVS is to facilitate support for the double-jump mobility >> problem and secondarily "to allow operators ...". >> >> And to 5206-bis section 3.2.3 to use the VIA_RVS to 'know' that there >> is an RVS for the host and to optionally aggressively send HIP >> mobility UPDATES to the RVS. >> > > It seems to me that we ought to state that hosts should be prepared to > handle duplicate mobility updates sent in parallel to different > locators (such as to RVS(es) and to more than one of the host's > addresses). We could also state that the aggressiveness of a host > replicating its UPDATES to multiple destinations, to try them in > parallel instead of serially, is a policy choice outside of the > specification. Any other comments on this possible change? No. This is what I am looking for. And I am putting together an ID for a set of policies for accelerated mobility. > > - Tom > > Bob From nobody Fri Sep 16 03:38:05 2016 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 4BCF912B11B for ; Fri, 16 Sep 2016 03:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.41 X-Spam-Level: X-Spam-Status: No, score=-3.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 25dWgrSFYGHt for ; Fri, 16 Sep 2016 03:38:02 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA7A612B009 for ; Fri, 16 Sep 2016 03:38:01 -0700 (PDT) Received: (qmail 7920 invoked from network); 16 Sep 2016 12:31:19 +0200 Received: from p5dec28a4.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.40.164) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 16 Sep 2016 12:31:19 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Fri, 16 Sep 2016 12:31:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5EAC8C66-94CF-419F-8D65-B4D0335801F8@kuehlewind.net> References: To: Tom Henderson X-Mailer: Apple Mail (2.3124) Archived-At: Cc: hipsec@ietf.org, hip-chairs@ietf.org, iesg@ietf.org, draft-ietf-hip-rfc5206-bis@ietf.org Subject: Re: [Hipsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-hip-rfc5206-bis-13=3A_=28with_COMMENT=29?= X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 16 Sep 2016 10:38:03 -0000 Okay. > Am 16.09.2016 um 07:30 schrieb Tom Henderson = : >=20 > Mirja, > Inline below (the points still being discussed).... >=20 > On Thu, 15 Sep 2016, Mirja K=C3=BChlewind wrote: >=20 >>>> 3) section 4: Can you give any hints how large the lifetime = typically >>>> should be? Can only the original address have an unbounded lifetime = (see >>>> section 5) or can I also set the lifetime value in a certain way to >>>> declare the lifetime of this address of unbounded? >>> Effectively unbounded lifetimes can be set by setting the 32-bit = field to the maximum value. >>=20 >> Okay that's not spelled out in the doc. >>=20 >>> In practice, I don't know of any guidance to offer, other than = perhaps aligning it with lifetimes of the addresses such as DHCP leased = addresses. >>=20 >> That means like useful guidance. >>> I guess that we could add a statement that an 'effectively = unbounded' lifetime can be set by setting the field to the maximum = (unsigned) value. >>=20 >> Would you then also need to talk about risks when doing so...? >=20 > I can make the above changes about lifetimes, but for the last one, I = am not sure that there are any risks to it-- I won't mention risks = unless someone in the list has ideas about any. >=20 >=20 >>>> 3) I believe reading would be easier for me if section 4 would have = been >>>> first but not sure... >>> I'm not sure about reordering sections without more specific change = proposals. >>=20 >> Or you could add a paragraph in the intro explaining where to find = what. >=20 > OK >=20 >>=20 >>>> 4) This docuemnt states several times that mutlihoming is out of = scope >>>> and only the handover case is described. I think it would be better = to >>>> state this clearly at the very beginning and remove the other cases = (I >>>> believe these are anyway kind of left-overs from the previous = document.) >>> Can you point to what you would like to have removed or changed? = Early on, we moved most of this material to the other draft, and in = scanning it again just now, I am not sure what more to take out or = rephrase. It is hard to completely avoid the topic of having multiple = addresses in this draft, particularly since we are defining the = LOCATOR_SET parameter that is used in the multihoming specification. >> Maybe just grab from the word multihoming and double-check if you = really need it there. For me it somtimes showed up at place there I = thought it's actually not needed to mentioned that again. >> But that's nothing big... >=20 > I searched for the word just now and wasn't inclined to remove any of = those remaining references, so I think I'll leave it for now unless = someone proposes a specific change. >=20 > - Tom From nobody Fri Sep 16 04:49:47 2016 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 7000612B113 for ; Fri, 16 Sep 2016 04:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.709 X-Spam-Level: X-Spam-Status: No, score=-5.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] 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 cvbNW8K8gGKa for ; Fri, 16 Sep 2016 04:49:43 -0700 (PDT) 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 7132012B02A for ; Fri, 16 Sep 2016 04:49:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 5807C6093E; Fri, 16 Sep 2016 07:49:42 -0400 (EDT) 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 kZ1rADUFbKOY; Fri, 16 Sep 2016 07:49:37 -0400 (EDT) Received: from lx120e.htt-consult.com (246.sub-174-201-17.myvzw.com [174.201.17.246]) (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 D98FE6218A; Fri, 16 Sep 2016 07:48:33 -0400 (EDT) To: Tom Henderson References: From: Robert Moskowitz Message-ID: Date: Fri, 16 Sep 2016 12:45:27 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: hipsec@ietf.org Subject: Re: [Hipsec] Comment on VIA_RVS parameter - 5204 & 06 -bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 16 Sep 2016 11:49:45 -0000 On 09/16/2016 06:57 AM, Tom Henderson wrote: > > > > On Thu, 15 Sep 2016, Robert Moskowitz wrote: > >> 5206-bis specifies how to user RVS for the 'double-jump' mobility >> problem. >> >> 3.2.3 1) says: >> >> 1. The mobile host sending an UPDATE to the peer, and not receiving >> an ACK, MAY resend the UPDATE to a rendezvous server (RVS) of the >> peer, if such a server is known. >> >> But it DOES know there is an RVS IF the I1 had FROM and RVS_HMAC >> parameters and it had created a VIA_RVS parameter to send in the R1. > > Yes, but the responder may not know the initiator's RVS even if the > the responder's RVS was used, and it also may be the case that neither > host's RVS was involved in the session setup. I see now. As currently speced, R has no way of learning I's RVS. The 'easy' way to fix this is for I to include a VIA_RVS in the I2 packet for mobility support. "If you every want to get back to me, I can always be reached at this number". > >> This VIA_RVS provides the knowledge and locator of the peer's RVS. >> >> In fact an aggressive mobility UPDATE would be sent simultaneously to >> the host and its RVS. If the host had not moved itself, it gets both >> and drops the one from the RVS. > > I believe that Baris Boyvat on the InfraHIP project was looking a > while back at such an approach to fast mobility; it was called > 'shotgun' approach to mobility and multihoming (try all candidates > simultaneously), if I remember correctly. > >> >> This comment recommends changes to 5204-bis 4.2.3 that the main goal >> of VIA_RVS is to facilitate support for the double-jump mobility >> problem and secondarily "to allow operators ...". >> >> And to 5206-bis section 3.2.3 to use the VIA_RVS to 'know' that there >> is an RVS for the host and to optionally aggressively send HIP >> mobility UPDATES to the RVS. >> > > It seems to me that we ought to state that hosts should be prepared to > handle duplicate mobility updates sent in parallel to different > locators (such as to RVS(es) and to more than one of the host's > addresses). We could also state that the aggressiveness of a host > replicating its UPDATES to multiple destinations, to try them in > parallel instead of serially, is a policy choice outside of the > specification. Any other comments on this possible change? > > - Tom > > From nobody Sun Sep 18 09:40:18 2016 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 26A8B12B139; Sun, 18 Sep 2016 09:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] 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 vaFwoKT1LIGN; Sun, 18 Sep 2016 09:40:14 -0700 (PDT) Received: from mxout26.s.uw.edu (mxout26.s.uw.edu [140.142.234.176]) (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 60F9112B134; Sun, 18 Sep 2016 09:40:14 -0700 (PDT) Received: from hymn04.u.washington.edu (hymn04.u.washington.edu [140.142.8.72]) by mxout26.s.uw.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u8IGe6TU029026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 18 Sep 2016 09:40:06 -0700 Received: from hymn04.u.washington.edu (localhost [127.0.0.1]) by hymn04.u.washington.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u8IGe3nx028266; Sun, 18 Sep 2016 09:40:03 -0700 Received: from localhost (Unknown UID 17623@localhost) by hymn04.u.washington.edu (8.14.4+UW14.03/8.14.4+Submit-local) with ESMTP id u8IGe23P028257; Sun, 18 Sep 2016 09:40:03 -0700 X-Auth-Received: from [73.140.18.44] by hymn04.u.washington.edu via HTTP; Sun, 18 Sep 2016 09:40:02 PDT Date: Sun, 18 Sep 2016 09:40:02 -0700 (PDT) From: Tom Henderson To: ietf@kuehlewind.net Message-ID: User-Agent: Web Alpine 2.01 (LRH 1302 2010-07-20) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1903409144-968076942-1474216802=:32623" X-PMX-Version: 6.2.1.2493963, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.9.18.163317 X-PMX-Server: mxout26.s.uw.edu X-Uwash-Spam: Gauge=XI, Probability=11%, Report=' TO_IN_SUBJECT 0.5, MULTIPLE_RCPTS 0.1, HTML_00_01 0.05, HTML_00_10 0.05, MIME_TEXT_ONLY_MP_MIXED 0.05, SUPERLONG_LINE 0.05, DATE_TZ_NA 0, LEGITIMATE_NEGATE 0, LEGITIMATE_SIGNS 0, MSG_THREAD 0, NO_CTA_URI_FOUND 0, NO_URI_FOUND 0, NO_URI_HTTPS 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_NOT_1 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_MIXED 0, __FORWARDED_MSG 0, __HAS_CC_HDR 0, __HAS_FROM 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_TEXT_P 0, __MIME_TEXT_P1 0, __MIME_VERSION 0, __MULTIPLE_RCPTS_CC_X2 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __SUBJ_HIGHBIT 0, __TO_IN_SUBJECT 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __USER_AGENT 0' Archived-At: Cc: draft-ietf-hip-multihoming@ietf.org, hip-chairs@ietf.org, iesg@ietf.org, hipsec@ietf.org Subject: Re: [Hipsec] =?iso-8859-15?q?Mirja_K=FChlewind=27s_No_Objection_on_dr?= =?iso-8859-15?q?aft-ietf-hip-multihoming-11=3A_=28with_COMMENT=29?= X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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: Sun, 18 Sep 2016 16:40:16 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1903409144-968076942-1474216802=:32623 Content-Type: TEXT/PLAIN; charset=ISO-8859-15 Content-Transfer-Encoding: 8BIT Mirja, thank you for your comments; replies again are inline below. On 09/13/2016 07:40 AM, Mirja Kuehlewind wrote: > Mirja Kühlewind has entered the following ballot position for > draft-ietf-hip-multihoming-11: No Objection > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > One big general comment: > > The split between this document and draft-ietf-hip-rfc5206-bis-13 (still) > seems a little artificial. draft-ietf-hip-rfc5206-bis-13 describes some > general parts that actually covers both use cases. I guess it would be at > least nice to spell out clearly in this document which parts of > draft-ietf-hip-rfc5206-bis-13 are required to read (section 4 and parts > of section 5) if that's is somehow clearly separately. OK > > E.g. I believe the following should be in draft-ietf-hip-rfc5206-bis-13 > and not in this doc: > "Hosts MUST NOT announce broadcast or multicast addresses in > LOCATOR_SETs. " > I this is more relevant for the case described in this document but is > true for the general case. draft-ietf-hip-rfc5206-bis-13 stated the > following but that's not the same because it only describes the peer > side: > " For > each locator listed in the LOCATOR_SET parameter, check that the > address therein is a legal unicast or anycast address. That is, the > address MUST NOT be a broadcast or multicast address." > > What worries me more is that I believe that one would need to always read > both documents to implement the peer functionality correctly. E.g. this > documents says the following: > "An Initiator MAY include one or more LOCATOR_SET parameters in the I2 > packet, independent of whether or not there was a LOCATOR_SET > parameter in the R1. These parameters MUST be protected by the I2 > signature. Even if the I2 packet contains LOCATOR_SET parameters, > the Responder MUST still send the R2 packet to the source address of > the I2." > However, when I read draft-ietf-hip-rfc5206-bis-13, it is not clear that > there are specifications in this document that are important for a > correct implementation. In the above case, the rationale for placing that text in the multihoming draft is that the possible need to expose additional locators during the base exchange arises in a multihoming context. I don't think that draft-ietf-hip-rfc5206-bis-13 implementations (without multihoming support) need to support inclusion in the base exchange. I'm fine with moving this sentence: "Hosts MUST NOT announce broadcast or multicast addresses in LOCATOR_SETs. " to RFC 5206-bis, and I agree to write some introductory paragraph to this document that points to the necessary parts of 5206-bis to support. > > Smaller comments: > 1) Regarding the following sentence: > "In summary, whether and how a host decides to leverage additional > addresses in a load-balancing or fault-tolerant manner is outside the > scope of the specification." > I agree that it is out of scope for this doc. But maybe it would be > useful to provide pointers to existng work. The scheduling problem is > well know and e.g. basically the same for MPTCP. Can you or someone suggest specific RFCs to cite here? > > 2) Regarding the following recommendation: > "Although the protocol may allow for configurations in which there is > an asymmetric number of SAs between the hosts (e.g., one host has two > interfaces and two inbound SAs, while the peer has one interface and > one inbound SA), it is RECOMMENDED that inbound and outbound SAs be > created pairwise between hosts. When an ESP_INFO arrives to rekey a > particular outbound SA, the corresponding inbound SA should be also > rekeyed at that time." > I believe I agree but why? I believe that the reason for this was to try to keep the implementation simpler, and keep the inbound/outbound SA lifetimes consistent. This recommendation removes the decision point in the implementation, when receiving a request to rekey, whether or not to rekey the corresponding SA. There is less operational experience with multihoming extensions, which was one of the reasons to split RFC5206 originally (to complete mobility specification but perhaps allow multihoming specifications to evolve further over time). It is possible to create lots of pairwise SAs between various locators, but it is not as clear when to do that versus when to try to reuse SAs across multiple locators. For instance, when multihoming is used actively for load balancing, perhaps multiple SA pairs are favorable (to avoid anti-replay checks failing from reordered packets), but maybe in a fault tolerance situation, they are less needed. I believe that the text in section 4.4 that you cite could have a pointer that section 4.11 later discusses this issue in more detail. > > 3) I (again) would find it easier to have section 4.9, 4.10, and 4.11 > before 4.2-4.8. However, I guess that's a matter of taste. Alternatively > maybe have most of the text from 4.2-4.8 in a separate supersection first > and call it 'usage scenarios' or something like this, while summerizing > the protocol actions in one subsection in the 'protocol overview' section > because it seems that the actions are actually quite similar for all use > cases, no? I think that 4.9-4.11 are more refinements or special cases than the subsections preceding them, so I would refrain from reordering them. However, I'll take a stab at adding a 'master scenario overview' that could be used as a roadmap to the rest of the subsections. > > 4) Maybe indicate clearly what is recommendated in > draft-ietf-hip-rfc5206-bis the following way: > OLD > "[I-D.ietf-hip-rfc5206-bis] > recommends that a host should send a LOCATOR_SET whenever it > recognizes a change of its IP addresses in use on an active HIP > association, and assumes that the change is going to last at least > for a few seconds. " > NEW > "[I-D.ietf-hip-rfc5206-bis] > recommends that "a host should send a LOCATOR_SET whenever it > recognizes a change of its IP addresses in use on an active HIP > association, and assumes that the change is going to last at least > for a few seconds. "" OK > > 5) How does a host know about this? Can you give examples? > "The grouping should consider also whether middlebox > interaction requires sending the same LOCATOR_SET in separate UPDATEs > on different paths." This comment arises from the consideration of (future) HIP-aware NATs that might perform parameter inspection. I'm not sure that there are any solid ways to know about whether these exist, other than operational knowledge about the networks where HIP is deployed. How about rephrasing such as this? "If hosts are deployed in an operational environment in which HIP-aware NATs (that may perform parameter inspection) exist, and different NATs may exist on different paths, hosts may take that knowledge into consideration about how addresses are grouped, and may send the same LOCATOR_SET in separate UPDATEs on the different paths. However, more detailed guidelines about how to operate in the presence of such HIP-aware NATs is a topic for further study." The alternative might be to delete this topic entirely since it is a bit speculative. - Tom ---1903409144-968076942-1474216802=:32623-- From nobody Sun Sep 18 09:56:04 2016 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 3137712B144; Sun, 18 Sep 2016 09:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] 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 ZoZX0KJtQj4u; Sun, 18 Sep 2016 09:56:03 -0700 (PDT) Received: from mxout24.cac.washington.edu (mxout24.cac.washington.edu [140.142.234.158]) (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 3ED3712B13B; Sun, 18 Sep 2016 09:56:02 -0700 (PDT) Received: from hymn04.u.washington.edu (hymn04.u.washington.edu [140.142.8.72]) by mxout24.cac.washington.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u8IGtUJc002485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 18 Sep 2016 09:55:31 -0700 Received: from hymn04.u.washington.edu (localhost [127.0.0.1]) by hymn04.u.washington.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u8IGtR5J004576; Sun, 18 Sep 2016 09:55:27 -0700 Received: from localhost (Unknown UID 17623@localhost) by hymn04.u.washington.edu (8.14.4+UW14.03/8.14.4+Submit-local) with ESMTP id u8IGtRmF004573; Sun, 18 Sep 2016 09:55:27 -0700 X-Auth-Received: from [73.140.18.44] by hymn04.u.washington.edu via HTTP; Sun, 18 Sep 2016 09:55:26 PDT Date: Sun, 18 Sep 2016 09:55:27 -0700 (PDT) From: Tom Henderson To: Kathleen.Moriarty.ietf@gmail.com Message-ID: User-Agent: Web Alpine 2.01 (LRH 1302 2010-07-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8BIT X-PMX-Version: 6.2.1.2493963, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.9.18.164817 X-PMX-Server: mxout24.cac.washington.edu X-Uwash-Spam: Gauge=IIIIIIIII, Probability=9%, Report=' MULTIPLE_RCPTS 0.1, HTML_00_01 0.05, HTML_00_10 0.05, SUPERLONG_LINE 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1900_1999 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, LEGITIMATE_NEGATE 0, LEGITIMATE_SIGNS 0, MSG_THREAD 0, MULTIPLE_REAL_RCPTS 0, NO_CTA_URI_FOUND 0, NO_URI_FOUND 0, NO_URI_HTTPS 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CC_NAME 0, __CC_NAME_DIFF_FROM_ACC 0, __CC_REAL_NAMES 0, __CP_NOT_1 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_CC_HDR 0, __HAS_FROM 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_TEXT_P 0, __MIME_TEXT_P1 0, __MIME_VERSION 0, __MULTIPLE_RCPTS_CC_X2 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __USER_AGENT 0' Archived-At: Cc: draft-ietf-hip-multihoming@ietf.org, hip-chairs@ietf.org, The IESG , hipsec@ietf.org Subject: Re: [Hipsec] Kathleen Moriarty's No Objection on draft-ietf-hip-multihoming-11: (with COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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: Sun, 18 Sep 2016 16:56:04 -0000 Hi Kathleen, thank you for your comment. On 09/13/2016 12:22 PM, Kathleen Moriarty wrote: > Kathleen Moriarty has entered the following ballot position for > draft-ietf-hip-multihoming-11: No Objection > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I'm wondering if split-tunneling should be listed as a security > consideration. I see the following in section 4.1 that might be used to > help prevent split tunneling: > In the outbound direction, as a result of SPD processing, when > an outbound SA is selected, the correct IP destination address for > the peer must also be assigned. > > Then also the entirety of section 4.3. > > I read this as split tunneling could be an issue in some circumstances > depending on policy and it might be good to mention this in the security > considerations section. Or let me know if I am missing some background > that would prevent split tunneling so implementers don't need to be made > aware of this consideration. >From my recollection, support (or prevention) of split tunneling was not a consideration of these parts of the text. The first sentence you quote from 4.1 was intended as a hint to implementers that there is this additional level of indirection with HIP that must be managed (mapping of SA to IP address) when multihoming is in use. Section 4.3 is mainly about how to manage the possibly large number of valid SA configurations that could arise from multihoming. My understanding of the common use of the term 'split tunneling' is that it pertains to VPN tunnel situations where some set of connections should be tunneled but others not. In HIP, the security association is end-to-end and the same VPN scenario is not applicable, so by split tunnel, do you mean that some transport sessions between two hosts are within HIP/ESP protection and others not? - Tom From nobody Sun Sep 18 11:29:14 2016 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 4120712B015 for ; Sun, 18 Sep 2016 11:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] 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 c0BmRawOKTJx for ; Sun, 18 Sep 2016 11:29:10 -0700 (PDT) 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 1ED8112B174 for ; Sun, 18 Sep 2016 11:20:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id E513162168 for ; Sun, 18 Sep 2016 14:19:58 -0400 (EDT) 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 5Vvm4bDjU0Pc for ; Sun, 18 Sep 2016 14:19:46 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [185.34.11.162]) (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 0912F6212A for ; Sun, 18 Sep 2016 14:19:45 -0400 (EDT) To: hipsec@ietf.org From: Robert Moskowitz Message-ID: <6bdc4938-6381-b69b-3298-b6000ab13926@htt-consult.com> Date: Sun, 18 Sep 2016 19:19:40 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Hipsec] Please refresh my memory on HIP_SIGNATURE in UPDATE X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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: Sun, 18 Sep 2016 18:29:12 -0000 I cannot remember why we mandated HIP_SIGNATURE in UPDATE packet, particularly when we have the HIP_MAC. Sec 5.3.5 in 7401. I am sure we had a good reason, but I am not finding it.... thanks Bob From nobody Sun Sep 18 12:01:05 2016 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 2AE1E12B14B; Sun, 18 Sep 2016 12:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] 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 sZhU55804Aeh; Sun, 18 Sep 2016 12:01:01 -0700 (PDT) Received: from mxout21.s.uw.edu (mxout21.s.uw.edu [140.142.32.139]) (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 3335112B14D; Sun, 18 Sep 2016 12:01:01 -0700 (PDT) Received: from hymn04.u.washington.edu (hymn04.u.washington.edu [140.142.8.72]) by mxout21.s.uw.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u8IJ0N7I003797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 18 Sep 2016 12:00:24 -0700 Received: from hymn04.u.washington.edu (localhost [127.0.0.1]) by hymn04.u.washington.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u8IJ0IGl018101; Sun, 18 Sep 2016 12:00:18 -0700 Received: from localhost (Unknown UID 17623@localhost) by hymn04.u.washington.edu (8.14.4+UW14.03/8.14.4+Submit-local) with ESMTP id u8IJ0IC7018092; Sun, 18 Sep 2016 12:00:18 -0700 X-Auth-Received: from [73.140.18.44] by hymn04.u.washington.edu via HTTP; Sun, 18 Sep 2016 12:00:18 PDT Date: Sun, 18 Sep 2016 12:00:18 -0700 (PDT) From: Tom Henderson To: Stephen Farrell Message-ID: User-Agent: Web Alpine 2.01 (LRH 1302 2010-07-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8BIT X-PMX-Version: 6.2.1.2493963, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.9.18.185117 X-PMX-Server: mxout21.s.uw.edu X-Uwash-Spam: Gauge=IIIIIIII, Probability=8%, Report=' MULTIPLE_RCPTS 0.1, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_2000_2999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, LEGITIMATE_NEGATE 0, LEGITIMATE_SIGNS 0, MSG_THREAD 0, MULTIPLE_REAL_RCPTS 0, SINGLE_URI_IN_BODY 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CC_NAME 0, __CC_NAME_DIFF_FROM_ACC 0, __CC_REAL_NAMES 0, __CP_NOT_1 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_CC_HDR 0, __HAS_FROM 0, __HAS_MSGID 0, __HTTPS_URI 0, __MIME_TEXT_ONLY 0, __MIME_TEXT_P 0, __MIME_TEXT_P1 0, __MIME_VERSION 0, __MULTIPLE_RCPTS_CC_X2 0, __SANE_MSGID 0, __SINGLE_URI_TEXT 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __TO_NAME 0, __TO_NAME_DIFF_FROM_ACC 0, __TO_REAL_NAMES 0, __URI_IN_BODY 0, __URI_NO_MAILTO 0, __URI_NS , __URI_WITH_PATH 0, __USER_AGENT 0' Archived-At: Cc: draft-ietf-hip-multihoming@ietf.org, hip-chairs@ietf.org, The IESG , hipsec@ietf.org Subject: Re: [Hipsec] Stephen Farrell's No Objection on draft-ietf-hip-multihoming-11: (with COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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: Sun, 18 Sep 2016 19:01:04 -0000 Stephen, thanks for your comments; replies inline below On 09/14/2016 04:25 AM, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-hip-multihoming-11: No Objection > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > - I think section 6 ought note the privacy issue that > was relatively recently with WebRTC and ICE where a > client might not want all of it's IP addresses > exposed, as doing so could expose the fact that the > client e.g. is using Tor or another VPN service. The > issue being that in some locations, that information > may be quite sensitive. 4.2 notes this but in a quite > opaque way, ("may be held back") but it'd be better to > say some more. 5.1 is also relevant maybe in that it > says one "SHOULD avoid" sending info about virtual > interfaces. Anyway, I think it'd be good to add some > recognition of this privacy issue to section 6. I am > not arguing that this draft ought specify the one true > way to avoid this problem, but only that it be > recognised. Your comment led me to review this draft https://www.ietf.org/id/draft-ietf-rtcweb-ip-handling-01.txt which I would be inclined to cite, but I am not sure whether it will be put forward for publication soon (and therefore am not sure about citing it). The below might make a possible summary paragraph to add, however: "The exposure of all of a host's IP addresses through HIP multihoming extensions may raise privacy concerns. A host may be trying to hide its location in some contexts through the use of a VPN or other virtual interfaces. Similar privacy issues also arise in other frameworks such as WebRTC and are not specific to HIP. Implementations SHOULD provide a mechanism to allow the host administrator to block the exposure of selected addresses or address ranges." > > - 4.11: what's the concern about anti-replay windows? > I didn't get that fwiw, not sure if that just my > relative ignorance of HIP or if more needs to be said > in the document. It is explained in this sentence: "However, the use of different source and destination addresses typically leads to different paths, with different latencies in the network, and if packets were to arrive via an arbitrary destination IP address (or path) for a given SPI, the reordering due to different latencies may cause some packets to fall outside of the ESP anti-replay window." Can you suggest changes or do you have a concern with what is stated? - Tom From nobody Sun Sep 18 21:19:47 2016 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 1355512B0CE for ; Sun, 18 Sep 2016 21:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] 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 U4l1RABJjRTZ for ; Sun, 18 Sep 2016 21:19:45 -0700 (PDT) Received: from mxout24.cac.washington.edu (mxout24.cac.washington.edu [140.142.234.158]) (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 E01E612B0C8 for ; Sun, 18 Sep 2016 21:19:44 -0700 (PDT) Received: from hymn02.u.washington.edu (hymn02.u.washington.edu [140.142.8.71]) by mxout24.cac.washington.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u8J4JFCr011631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 18 Sep 2016 21:19:16 -0700 Received: from hymn02.u.washington.edu (localhost [127.0.0.1]) by hymn02.u.washington.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u8J4JCKa019344; Sun, 18 Sep 2016 21:19:12 -0700 Received: from localhost (Unknown UID 5440@localhost) by hymn02.u.washington.edu (8.14.4+UW14.03/8.14.4+Submit-local) with ESMTP id u8J4JC6G019341; Sun, 18 Sep 2016 21:19:12 -0700 X-Auth-Received: from [73.140.18.44] by hymn02.u.washington.edu via HTTP; Sun, 18 Sep 2016 21:19:11 PDT Date: Sun, 18 Sep 2016 21:19:12 -0700 (PDT) From: Tom Henderson To: Robert Moskowitz In-Reply-To: <6bdc4938-6381-b69b-3298-b6000ab13926@htt-consult.com> Message-ID: User-Agent: Web Alpine 2.01 (LRH 1302 2010-07-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Content-Transfer-Encoding: 8BIT X-PMX-Version: 6.2.1.2493963, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.9.19.40917 X-PMX-Server: mxout24.cac.washington.edu X-Uwash-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODYTEXTP_SIZE_400_LESS 0, BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_300_399 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, IN_REP_TO 0, LEGITIMATE_NEGATE 0, LEGITIMATE_SIGNS 0, MSG_THREAD 0, MULTIPLE_REAL_RCPTS 0, SINGLE_URI_IN_BODY 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_CC_HDR 0, __HAS_FROM 0, __HAS_MSGID 0, __HTTPS_URI 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_TEXT_P 0, __MIME_TEXT_P1 0, __MIME_VERSION 0, __SANE_MSGID 0, __SINGLE_URI_TEXT 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __TO_NAME 0, __TO_NAME_DIFF_FROM_ACC 0, __TO_REAL_NAMES 0, __URI_IN_BODY 0, __URI_NO_MAILTO 0, __URI_NO_WWW 0, __URI_NS , __URI_WITH_PATH 0, __USER_AGENT 0' Archived-At: Cc: hipsec@ietf.org Subject: Re: [Hipsec] Please refresh my memory on HIP_SIGNATURE in UPDATE X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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, 19 Sep 2016 04:19:46 -0000 On Sun, 18 Sep 2016, Robert Moskowitz wrote: > I cannot remember why we mandated HIP_SIGNATURE in UPDATE packet, > particularly when we have the HIP_MAC. Sec 5.3.5 in 7401. > > I am sure we had a good reason, but I am not finding it.... For middleboxes; this dates back to section 6.1.1 of https://tools.ietf.org/html/draft-nikander-hip-mm-00 - Tom From nobody Sun Sep 18 22:20:09 2016 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 5B1FE12B150 for ; Sun, 18 Sep 2016 22:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] 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 M3YvHflrkUYw for ; Sun, 18 Sep 2016 22:20:06 -0700 (PDT) Received: from mxout21.s.uw.edu (mxout21.s.uw.edu [140.142.32.139]) (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 53C6212B121 for ; Sun, 18 Sep 2016 22:20:05 -0700 (PDT) Received: from hymn03.u.washington.edu (hymn03.u.washington.edu [140.142.9.111]) by mxout21.s.uw.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u8J5JSQI030423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 18 Sep 2016 22:19:28 -0700 Received: from hymn03.u.washington.edu (localhost [127.0.0.1]) by hymn03.u.washington.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u8J5JOY4010178; Sun, 18 Sep 2016 22:19:24 -0700 Received: from localhost (Unknown UID 24282@localhost) by hymn03.u.washington.edu (8.14.4+UW14.03/8.14.4+Submit-local) with ESMTP id u8J5JOx3010173; Sun, 18 Sep 2016 22:19:24 -0700 X-Auth-Received: from [73.140.18.44] by hymn03.u.washington.edu via HTTP; Sun, 18 Sep 2016 22:19:23 PDT Date: Sun, 18 Sep 2016 22:19:24 -0700 (PDT) From: Tom Henderson To: Robert Moskowitz Message-ID: User-Agent: Web Alpine 2.01 (LRH 1302 2010-07-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8BIT X-PMX-Version: 6.2.1.2493963, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.9.19.51218 X-PMX-Server: mxout21.s.uw.edu X-Uwash-Spam: Gauge=IIIIIIIII, Probability=9%, Report=' MULTIPLE_RCPTS 0.1, HTML_00_01 0.05, HTML_00_10 0.05, SUPERLONG_LINE 0.05, BODY_SIZE_3000_3999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, LEGITIMATE_NEGATE 0, LEGITIMATE_SIGNS 0, MSG_THREAD 0, MULTIPLE_REAL_RCPTS 0, SINGLE_URI_IN_BODY 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CC_NAME 0, __CC_NAME_DIFF_FROM_ACC 0, __CC_REAL_NAMES 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_CC_HDR 0, __HAS_FROM 0, __HAS_MSGID 0, __HTTPS_URI 0, __MIME_TEXT_ONLY 0, __MIME_TEXT_P 0, __MIME_TEXT_P1 0, __MIME_VERSION 0, __MULTIPLE_RCPTS_CC_X2 0, __PHISH_PHRASE1_B 0, __SANE_MSGID 0, __SINGLE_URI_TEXT 0, __SUBJ_ALPHA_NEGATE 0, __SUBJ_HIGHBIT 0, __TO_MALFORMED_2 0, __TO_NAME 0, __TO_NAME_DIFF_FROM_ACC 0, __TO_REAL_NAMES 0, __URI_IN_BODY 0, __URI_NS , __URI_WITH_PATH 0, __USER_AGENT 0' Archived-At: Cc: hipsec@ietf.org, Mirja Kuehlewind Subject: Re: [Hipsec] =?iso-8859-15?q?Mirja_K=FChlewind=27s_No_Objection_on_dr?= =?iso-8859-15?q?aft-ietf-hip-rfc5206-bis-13=3A_=28with_COMMENT=29?= X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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, 19 Sep 2016 05:20:08 -0000 Bob, sorry for the delay in replying (inline below) On 09/13/2016 02:14 AM, Robert Moskowitz wrote: > I have one question on sec 5.4 before I enter a comment... > > On 09/12/2016 03:28 PM, Mirja Kuehlewind wrote: >> 5) section 5.4: How long will an address be in UNVERIFIED state in case >> the verification is not successful (no reply). Is there a timer? How >> often will the peer retry the verification test? How long does the peer >> wait until resending the verification packet? >> > > It took me a couple readings of 5.4 to THINK I understand fig 7. > > I THINK this occurs after Mobile Host has sent its HIP UPDATE with the > new locator information. Yes. > > I believe the implication of this figure is that the stationary node > (peer host) sends its address validation HIP UPDATE and instead of > receiving the HIP UPDATE with ACK, it receives actual data which it may > interpret as the ACK. Yes, actual data that implies that the mobile host received its previous message at the new address. > > So I have two points. > > First does this only apply when there are new SPI? What about a move > with no SPI changes? I think the original intent may have been to cover the case where the UPDATE with ACK (the third leg of the handshake) was lost or slow to return, and that data plane may be faster at picking up the address change and using it immediately. However, I am not seeing the scenario with a new SA where there is not a third UPDATE, as in: Mobile Peer 1) --UPDATE -> 2) <--UPDATE- 3) --UPDATE -> If message 2) has "NEW SPI in ESP_INFO (UPDATE)", then it will need a SEQ and a retransmission timer to protect it, until the packet 3) arrives with the ACK. In a move with no SPI changes, the draft says that a nonce like an ECHO_REQUEST should be exchanged (Figure 3). > > Second, the actual figure should include the original HIP UPDATE from > Mobile Host to make it clear the nature of the mobility. OK, I agree. I would be inclined to modify it something along the lines below. Mobile host Peer host ESP_INFO, LOCATOR_SET (UPDATE) ----------------------------------> prepare incoming SA NEW SPI in ESP_INFO (UPDATE) <----------------------------------- switch to new outgoing SA data on new SA -----------------------------------> mark address ACTIVE ACk (UPDATE) (later arrives) ------------------------------------> Figure 7: Address Activation Via Use of a New SA > > Sorry for the late review of this draft. > > I can submit an official comment if others think my questions raise > clarity issues. > > Bob > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec From nobody Sun Sep 18 22:24:12 2016 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 B220E12B121; Sun, 18 Sep 2016 22:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] 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 vAUuFhAAP9Hs; Sun, 18 Sep 2016 22:24:05 -0700 (PDT) Received: from mxout24.cac.washington.edu (mxout24.cac.washington.edu [140.142.234.158]) (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 B499412B104; Sun, 18 Sep 2016 22:24:05 -0700 (PDT) Received: from hymn02.u.washington.edu (hymn02.u.washington.edu [140.142.8.71]) by mxout24.cac.washington.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u8J5Ms7m024073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 18 Sep 2016 22:22:54 -0700 Received: from hymn02.u.washington.edu (localhost [127.0.0.1]) by hymn02.u.washington.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u8J5Mnnx031370; Sun, 18 Sep 2016 22:22:49 -0700 Received: from localhost (Unknown UID 5440@localhost) by hymn02.u.washington.edu (8.14.4+UW14.03/8.14.4+Submit-local) with ESMTP id u8J5Mngi031367; Sun, 18 Sep 2016 22:22:49 -0700 X-Auth-Received: from [73.140.18.44] by hymn02.u.washington.edu via HTTP; Sun, 18 Sep 2016 22:22:49 PDT Date: Sun, 18 Sep 2016 22:22:49 -0700 (PDT) From: Tom Henderson To: Alexey Melnikov Message-ID: User-Agent: Web Alpine 2.01 (LRH 1302 2010-07-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8BIT X-PMX-Version: 6.2.1.2493963, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.9.19.51218 X-PMX-Server: mxout24.cac.washington.edu X-Uwash-Spam: Gauge=IIIIIIII, Probability=8%, Report=' MULTIPLE_RCPTS 0.1, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1000_1099 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, LEGITIMATE_NEGATE 0, LEGITIMATE_SIGNS 0, MSG_THREAD 0, MULTIPLE_REAL_RCPTS 0, NO_CTA_URI_FOUND 0, NO_URI_FOUND 0, NO_URI_HTTPS 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CC_NAME 0, __CC_NAME_DIFF_FROM_ACC 0, __CC_REAL_NAMES 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_CC_HDR 0, __HAS_FROM 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_TEXT_P 0, __MIME_TEXT_P1 0, __MIME_VERSION 0, __MULTIPLE_RCPTS_CC_X2 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __TO_NAME 0, __TO_NAME_DIFF_FROM_ACC 0, __TO_REAL_NAMES 0, __USER_AGENT 0' Archived-At: Cc: hipsec@ietf.org, draft-ietf-hip-rfc5206-bis@ietf.org, The IESG , hip-chairs@ietf.org Subject: Re: [Hipsec] Alexey Melnikov's No Objection on draft-ietf-hip-rfc5206-bis-13: (with COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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, 19 Sep 2016 05:24:07 -0000 Alexey, thank you for the comments; please see below. On 09/14/2016 12:15 AM, Alexey Melnikov wrote: > Alexey Melnikov has entered the following ballot position for > draft-ietf-hip-rfc5206-bis-13: No Objection > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I have a couple of minor nearly DISCUSSes that should be easy to fix: > > This document doesn't have "Changes since RFC XXXX" section as required > for any -bis document. Can you please convert Appendix A to be such a > section? Agreed (others have asked the same). > > As this is a -bis document that obsoletes the original RFC 5206, its IANA > Considerations section should be self contained. I think you should > mention that IANA has allocated type 193 for LOCATOR_SET and type 46 for > LOCATOR_TYPE_UNSUPPORTED Notify Message Type, as specified in RFC 5206. Agreed, we got some guidance earlier this summer on how to write this better; I will apply to the next version. - Tom h From nobody Sun Sep 18 22:31:35 2016 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 70BCE12B104; Sun, 18 Sep 2016 22:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] 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 CMjOFZc2rsDe; Sun, 18 Sep 2016 22:31:27 -0700 (PDT) Received: from mxout24.cac.washington.edu (mxout24.cac.washington.edu [140.142.234.158]) (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 5DF5212B02F; Sun, 18 Sep 2016 22:31:27 -0700 (PDT) Received: from hymn02.u.washington.edu (hymn02.u.washington.edu [140.142.8.71]) by mxout24.cac.washington.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u8J5V6sM025630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 18 Sep 2016 22:31:07 -0700 Received: from hymn02.u.washington.edu (localhost [127.0.0.1]) by hymn02.u.washington.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u8J5V3E9003480; Sun, 18 Sep 2016 22:31:03 -0700 Received: from localhost (Unknown UID 5440@localhost) by hymn02.u.washington.edu (8.14.4+UW14.03/8.14.4+Submit-local) with ESMTP id u8J5V3h1003457; Sun, 18 Sep 2016 22:31:03 -0700 X-Auth-Received: from [73.140.18.44] by hymn02.u.washington.edu via HTTP; Sun, 18 Sep 2016 22:31:03 PDT Date: Sun, 18 Sep 2016 22:31:03 -0700 (PDT) From: Tom Henderson To: Stephen Farrell Message-ID: User-Agent: Web Alpine 2.01 (LRH 1302 2010-07-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8BIT X-PMX-Version: 6.2.1.2493963, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.9.19.52717 X-PMX-Server: mxout24.cac.washington.edu X-Uwash-Spam: Gauge=IIIIIIIII, Probability=9%, Report=' MULTIPLE_RCPTS 0.1, HTML_00_01 0.05, HTML_00_10 0.05, SUPERLONG_LINE 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1200_1299 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, LEGITIMATE_NEGATE 0, LEGITIMATE_SIGNS 0, MSG_THREAD 0, MULTIPLE_REAL_RCPTS 0, NO_CTA_URI_FOUND 0, NO_URI_FOUND 0, NO_URI_HTTPS 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CC_NAME 0, __CC_NAME_DIFF_FROM_ACC 0, __CC_REAL_NAMES 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_CC_HDR 0, __HAS_FROM 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_TEXT_P 0, __MIME_TEXT_P1 0, __MIME_VERSION 0, __MULTIPLE_RCPTS_CC_X2 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __TO_NAME 0, __TO_NAME_DIFF_FROM_ACC 0, __TO_REAL_NAMES 0, __USER_AGENT 0' Archived-At: Cc: hipsec@ietf.org, draft-ietf-hip-rfc5206-bis@ietf.org, The IESG , hip-chairs@ietf.org Subject: Re: [Hipsec] Stephen Farrell's No Objection on draft-ietf-hip-rfc5206-bis-13: (with COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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, 19 Sep 2016 05:31:28 -0000 Hi Stephen, please see below. On 09/14/2016 03:18 PM, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-hip-rfc5206-bis-13: No Objection > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > My review was based on the diff vs. 5206 [1], and turned > up nothing new of note:-) Seems like a reasonable update > to me. > > I do however agree about the privacy issue raised by Mirja > wrt exposing locators. It is worth noting that, so that > implementers have it flagged that they need to consider > that - not doing so caused quite a fuss for WebRTC so > better to not repeat that. I proposed some text about privacy issues with exposing locators in the multihoming draft comment resolution (earlier today)-- do you think something along those lines fits with this draft also (mobility)? Perhaps rephrased to mention that even in a non-multihoming case, a host should be aware of any privacy issues of the locator that it chooses to next expose after a mobility event renders its current locator unusable... - Tom From nobody Sun Sep 18 23:44:43 2016 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 D6DF312B064 for ; Sun, 18 Sep 2016 23:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] 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 fmhsZG4bjYoi for ; Sun, 18 Sep 2016 23:44:36 -0700 (PDT) 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 46E3812B0A1 for ; Sun, 18 Sep 2016 23:44:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 31C6662149; Mon, 19 Sep 2016 02:44:34 -0400 (EDT) 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 ZrgxCoKwVsau; Mon, 19 Sep 2016 02:44:29 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [185.34.11.162]) (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 3C2F9615D8; Mon, 19 Sep 2016 02:44:27 -0400 (EDT) To: Tom Henderson References: From: Robert Moskowitz Message-ID: Date: Mon, 19 Sep 2016 07:44:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: hipsec@ietf.org Subject: Re: [Hipsec] Please refresh my memory on HIP_SIGNATURE in UPDATE X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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, 19 Sep 2016 06:44:42 -0000 On 09/19/2016 05:19 AM, Tom Henderson wrote: > > > > On Sun, 18 Sep 2016, Robert Moskowitz wrote: > >> I cannot remember why we mandated HIP_SIGNATURE in UPDATE packet, >> particularly when we have the HIP_MAC. Sec 5.3.5 in 7401. >> >> I am sure we had a good reason, but I am not finding it.... > > For middleboxes; this dates back to section 6.1.1 of > https://tools.ietf.org/html/draft-nikander-hip-mm-00 Ah yes, those nasty guys in the middle by policy. In a perfect IPv6 mobile world they don't exist, but we know otherwise... Thanks for the refresher. Bob From nobody Sun Sep 18 23:47:08 2016 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 CE4F312B13F for ; Sun, 18 Sep 2016 23:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] 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 YumegYllQXDT for ; Sun, 18 Sep 2016 23:47:06 -0700 (PDT) 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 6B6CA12B0A1 for ; Sun, 18 Sep 2016 23:47:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 2B2C762149; Mon, 19 Sep 2016 02:47:05 -0400 (EDT) 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 cdAFyNRnS5Cd; Mon, 19 Sep 2016 02:46:57 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [185.34.11.162]) (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 ECFDA615D8; Mon, 19 Sep 2016 02:46:54 -0400 (EDT) To: Tom Henderson References: From: Robert Moskowitz Message-ID: Date: Mon, 19 Sep 2016 07:46:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: hipsec@ietf.org, Mirja Kuehlewind Subject: Re: [Hipsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-hip-rfc5206-bis-13=3A_=28with_COMMENT=29?= X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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, 19 Sep 2016 06:47:08 -0000 On 09/19/2016 06:19 AM, Tom Henderson wrote: > Bob, sorry for the delay in replying (inline below) > > On 09/13/2016 02:14 AM, Robert Moskowitz wrote: >> I have one question on sec 5.4 before I enter a comment... >> >> On 09/12/2016 03:28 PM, Mirja Kuehlewind wrote: >>> 5) section 5.4: How long will an address be in UNVERIFIED state in case >>> the verification is not successful (no reply). Is there a timer? How >>> often will the peer retry the verification test? How long does the peer >>> wait until resending the verification packet? >>> >> It took me a couple readings of 5.4 to THINK I understand fig 7. >> >> I THINK this occurs after Mobile Host has sent its HIP UPDATE with the >> new locator information. > Yes. > >> I believe the implication of this figure is that the stationary node >> (peer host) sends its address validation HIP UPDATE and instead of >> receiving the HIP UPDATE with ACK, it receives actual data which it may >> interpret as the ACK. > Yes, actual data that implies that the mobile host received its previous message at the new address. > >> So I have two points. >> >> First does this only apply when there are new SPI? What about a move >> with no SPI changes? > I think the original intent may have been to cover the case where the UPDATE with ACK (the third leg of the handshake) was lost or slow to return, and that data plane may be faster at picking up the address change and using it immediately. > > However, I am not seeing the scenario with a new SA where there is not a third UPDATE, as in: > > Mobile Peer > 1) --UPDATE -> > 2) <--UPDATE- > 3) --UPDATE -> > > If message 2) has "NEW SPI in ESP_INFO (UPDATE)", then it will need a SEQ and a retransmission timer to protect it, until the packet 3) arrives with the ACK. > > In a move with no SPI changes, the draft says that a nonce like an ECHO_REQUEST should be exchanged (Figure 3). > >> Second, the actual figure should include the original HIP UPDATE from >> Mobile Host to make it clear the nature of the mobility. > OK, I agree. > > I would be inclined to modify it something along the lines below. > > Mobile host Peer host > > ESP_INFO, LOCATOR_SET (UPDATE) > ----------------------------------> > > prepare incoming SA > NEW SPI in ESP_INFO (UPDATE) > <----------------------------------- > switch to new outgoing SA > data on new SA > -----------------------------------> > mark address ACTIVE > > ACk (UPDATE) (later arrives) > ------------------------------------> > > Figure 7: Address Activation Via Use of a New SA This is much better. Thanks > > >> Sorry for the late review of this draft. >> >> I can submit an official comment if others think my questions raise >> clarity issues. >> >> Bob >> >> _______________________________________________ >> Hipsec mailing list >> Hipsec@ietf.org >> https://www.ietf.org/mailman/listinfo/hipsec > > From nobody Tue Sep 20 08:46:46 2016 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 3EA6B12B21B for ; Tue, 20 Sep 2016 08:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 OcKREN0UH6eE for ; Tue, 20 Sep 2016 08:46:41 -0700 (PDT) Received: from out.west.exch081.serverdata.net (cas081-co-1.exch081.serverdata.net [199.193.204.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29F7512B0CC for ; Tue, 20 Sep 2016 08:46:41 -0700 (PDT) Received: from MBX081-W5-CO-2.exch081.serverpod.net (10.224.129.85) by MBX081-W5-CO-1 (10.224.129.84) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 20 Sep 2016 08:46:39 -0700 Received: from MBX081-W5-CO-2.exch081.serverpod.net ([10.224.129.85]) by MBX081-W5-CO-2.exch081.serverpod.net ([10.224.129.85]) with mapi id 15.00.1178.000; Tue, 20 Sep 2016 08:46:39 -0700 From: Jeff Ahrenholz To: Tom Henderson , Robert Moskowitz Thread-Topic: [Hipsec] Using Next Header with IPv6 Thread-Index: AQHSCusji+yjMNngbUqn2BWXVVqMYKCCloQA Date: Tue, 20 Sep 2016 15:46:39 +0000 Message-ID: <5A75F2FB-2131-49AA-A662-68F9AA213252@temperednetworks.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [216.168.34.194] Content-Type: multipart/mixed; boundary="_002_5A75F2FB213149AAA66268F9AA213252temperednetworkscom_" MIME-Version: 1.0 Archived-At: Cc: "hipsec@ietf.org" Subject: Re: [Hipsec] Using Next Header with IPv6 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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, 20 Sep 2016 15:46:43 -0000 --_002_5A75F2FB213149AAA66268F9AA213252temperednetworkscom_ Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 SGkgQm9iLA0KQWRkaW5nIHRvIFRvbeKAmXMgY29tbWVudHMuLi4NCg0KPj4gV2UgcHJvdmlkZWQg aW4gNzQwMSBhIE5leHQgSGVhZGVyIGZpZWxkIGFzIGFsbCBnb29kIElQdjYgcGF5bG9hZHMgYXJl DQo+PiBzdXBwb3NlIHRvIGRvLiAgQnV0IHdlIHJlYWxseSBoYXZlIG5vdCB1c2VkIGl0IGluIGZy b250IG9mICdyZWFsJyBJUHY2DQo+PiBwYXlsb2FkcyBsaWtlIEVTUCwgVENQLCBVRFAsIG9yIElQ bklQLiAgT3IgaGF2ZSB3ZSBhbmQgSSBoYXZlIGp1c3QNCj4+IG1pc3NlZCBpdD8NCj4gICAgDQo+ ICAgIFRoZSBISUNDVVBTIFJGQyBkZXNjcmliZXMgYSB1c2Ugb2YgaXQuDQo+ICAgIGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2MDc4DQoNClllcywgd2UgaGF2ZW7igJl0IHJlYWxseSBi ZWVuIHVzaW5nIHRoZSBOZXh0IEhlYWRlciBmaWVsZCBmb3IgcGF5bG9hZHMuDQogICAgDQo+PiBJ IGFtIG5vdCBhIHBlcnNvbiB0aGF0IGhhcyBkZWFsdCB3aXRoIHRoZSBpbnNpZGVzIG9mIHRoZSBP UyhzKSB0byBrbm93DQo+PiBob3cgdGhpcyB3b3VsZCBiZSBkb25lIG9yIGlmIGl0IGlzIHJlYWxs eSBwcmFjdGljYWwuDQo+ICAgIA0KPiAgICBUaGUgZGF0YSBwbGFuZSBmb3IgSElQLXN1cHBvcnRl ZCBzZXNzaW9ucyBjYW4gYmUgaW1wbGVtZW50ZWQgaW4gdXNlcnNwYWNlDQo+ICAgIG9yIGtlcm5l bCAocmV1c2luZyBrZXJuZWwgSVBzZWMgaGFuZGxpbmcpLiBJZiBwdXJlbHkgdXNlcnNwYWNlIChh bGwgcGFja2V0cw0KPiAgICBhcmUgc2h1bnRlZCB0byB1c2Vyc3BhY2UpIGl0IHNlZW1zIGxpa2Ug aXQgd291bGQgbm90IGJlIHRlcnJpYmx5IGRpZmZpY3VsdA0KPiAgICB0byBkby4gIElmIGtlcm5l bCBzcGFjZSBoYW5kbGluZyBzdWNoIGFzIExpbnV4IFhGUk0sIEknbSBndWVzc2luZyB0aGF0IGEN Cj4gICAgc3RhY2sgbW9kaWZpY2F0aW9uIHdvdWxkIGJlIG5lZWRlZC4NCg0KV2XigJlyZSB1c2lu ZyBhIHVzZXJzcGFjZSBpbXBsZW1lbnRhdGlvbiBwbHVzIFVEUCBlbmNhcHN1bGF0aW9uLg0KDQpT byBvbmUgVURQIHNvY2tldCByZWNlaXZlcyB0aGUgcG9ydCAxMDUwMCB0cmFmZmljLiBCb3RoIEhJ UCBjb250cm9sIHBhY2tldHMgKGhhdmluZyBTUEk9MCkgYW5kIEVTUCBwYWNrZXRzIGFyZSByZWNl aXZlZCBhbmQgZGVtdXhlZCBvbiB0aGlzIHNvY2tldC4gU28gaXQgd291bGQgYmUgZmFpcmx5IHN0 cmFpZ2h0Zm9yd2FyZCB0byBwaWNrIG9mZiBhbiBVUERBVEUgYW5kIHRoZW4gcHJvY2VzcyB0aGUg RVNQIGRhdGEgdGhhdCBmb2xsb3dzIGl0Lg0KDQpJZiB3ZSB3ZXJlIG5vdCB1c2luZyBVRFAgZW5j YXBzIHRoZW4geWVzIGl0IHNlZW1zIHlvdeKAmWQgaGF2ZSB0byB3cml0ZSBhIG5ldyBmcmFtZSBi YWNrIHRvIHRoZSBzdGFjay4NCiAgICANCj4+IA0KPj4gT2gsIGFuZCB3aGF0IGlzIHRoZSBsZW5n dGggb2YgdGhlIGJhc2ljIEhJUCBVUERBVEUgaW4gNTIwNi1iaXM/ICBJIGNhbg0KPj4gZG8gbXkg YmVzdCBjYWxjdWxhdGlvbiBpbiBhIGJpdCwgYnV0IGlmIHNvbWVvbmUgaGFzIGl0Li4uDQo+ICAg IA0KPiAgICBISVAgaGVhZGVyIDQwIGJ5dGVzDQo+ICAgIEVTUF9JTkZPIDE2IGJ5dGVzDQo+ICAg IExPQ0FUT1JfU0VUIChtaW5pbWFsKSB+MzIgYnl0ZXMNCj4gICAgU0VRIHBhcmFtZXRlciA4IGJ5 dGVzDQo+ICAgIA0KPiAgICBzbyBvbiB0aGUgb3JkZXIgb2YgOTYgYnl0ZXM7IG1vcmUgaWYgbW9y ZSB0aGFuIG9uZSBsb2NhdG9yIGludm9sdmVkDQoNCkhlcmUgaXMgd2hhdCB3ZSBoYXZlIGZvciBh biBJUHY0IHJlLWFkZHJlc3MgZXZlbnQgb3ZlciBVRFAuIEF0dGFjaGVkIGlzIGEgcGNhcCBmaWxl ICh5b3UgY2FuIG9wZW4gaW4gV2lyZXNoYXJrKS4NCg0KVGhlIHRocmVlIFVQREFURSBwYWNrZXRz IGFyZSAzMDIsIDI4NiwgMjYyIGJ5dGVzIGluIGxlbmd0aC4gVGhleSBsb29rIGxpa2UgdGhpczoN ClVQREFURShFU1BfSU5GTywgTE9DQVRPUiwgU0VRLCBITUFDLCBISVBfU0lHTkFUVVJFKQ0KVVBE QVRFKEVTUF9JTkZPLCBTRVEsIEFDSywgSE1BQywgSElQX1NJR05BVFVSRSwgRUNIT19SRVFVRVNU X1VOU0lHTkVEKQ0KVVBEQVRFKEVTUF9JTkZPLCBBQ0ssIEhNQUMsIEhJUF9TSUdOQVRVUkUsIEVD SE9fUkVTUE9OU0VfVU5TSUdORUQpDQoNCi1KZWZmDQoNCg0K --_002_5A75F2FB213149AAA66268F9AA213252temperednetworkscom_ Content-Type: application/octet-stream; name="hip-over-udp-readdress-20160920.pcapng" Content-Description: hip-over-udp-readdress-20160920.pcapng Content-Disposition: attachment; filename="hip-over-udp-readdress-20160920.pcapng"; size=1929; creation-date="Tue, 20 Sep 2016 15:46:39 GMT"; modification-date="Tue, 20 Sep 2016 15:46:39 GMT" Content-ID: <8376241928CCDB4FB0D6AAEB871A6131@exch081.serverpod.net> Content-Transfer-Encoding: base64 H4sIAAAAAAAAA42VCVQTSRqAuyGEEAwGyHIKRFgUCEQwgzCADhMU5FRRWXWVjWQ45IwRoggKiFwi w6UG8UAJILcjyBHIcF86wqgwDgPKLXKIiQRBDmXTSRBwWN/We3ldVV3911df/VVBolBIbwAA7M1w SiDvuSgsooA8YHfCN+AMloA3IOD19bYR9NxdfV2pJ8gADNAGdgb4UMjHKVgDvIE+fhtWiyasuFH9 fLA+x0/5u1L1oC5tQFCgOaD4dsLn4iIAiABIgObq72GI18e7GQCABO8NnPdu3TfmBoQxoHE1wtgz amLAa1K71G1e/bagK5c/SS4AIIBdAJCw3tUcMJeW60YCAJL3w2jDtGFA8FHxeJWYYt44ZF58nopD l1OBkXHZnbZygmtYMS1bVUq9YDBoj/GtwxgzhaGgM8UhpnqNSc4mzk8iPbISwvdYPooUn9etbmzx 2h0QV+FSh3Ma9SL/cb3Z34Z9dDAVHnoTt5FGEaHW/TP3bmYEPdIwZ1sWI1zhO5aA+2t+Qs7Aan7h KgT8uK0Q/zwKYofWIOAXT/OSt0jhjZNkm8o0dBdFl8Yt5HfYv+9O+uWPqaPmheDPE9x9EvSfZovz ysxOqBq1HT8HP1JzxyRcuaYnoizKHZ3VEK1pH/a464nKO496ZfOg+/92jNpFlMYTYjiXqlALzYGf T+YR6qJ0b5VGlDkhpvdo3e6UlVybn5078C3/F/n+Wav9h5oL/Us616M7WD2IT54WooPfkfBl8ToJ G6aLK88wEDFNRvTTWjI72vxwYtvlwyVP1h+3StJkqI7e9+/jbAi/UZ72q8z572uM5YtyY/VLu0gS F19y/2TZbZWD++WMhlEG0ZJ5c7tmLoSZvIk1bikYMN35j2V+uxX8oTZjUjq8us6XMyDkh0N7AIct rYdHjxJ8Ba1jORdXxipfEWvVXi7FEhG0BRGWoy7F2gsux6rmxcLz2njw715BrKUo5LU3B/p+ySu4 TtkXGmqqhpaGnlgQUEhniTCf/QJrS3kjjeK1MZ1OZ0lpkWwj609BOsCPvAPH2yMol0oR1xhALbAB AMV484gj+O0vZXERmgcM410AvML5EcBQniEUXvk+7gjo+kk5xoKiqHTHmvkeBMLEzrdg3VMt9Hc3 cqitx2IjaTFg8P7stosbF2hqrVH5iS/X3Z5tyj2l91esreKYXkWj9fP3HJPmhw44dpA6cev0XAZF zLpFY52/yum4B9z5y76quZs92+5Fv9Of7UlTsKRryxEjPhPZFu7Kl36Ptf9cero/0IV+lp5glTXo 1+/e0RcZxueFPEI+zVf4HHIYk1LltVWXfK44ZyC6JBPySZEXnjMUP08XwHC+T5UvPlf5+9rvkk8o t9VFTs4u+QJrl72JVwyPPLK7lqTlnc7REJXM1EbYyfK9xRN+v6iEGkG+8yJ6bnIKVxJDz0zcsHM8 U5HLDPJ41TslM8bu6DxIdDMZH75hS7ahwaXnj10uwii7oNivMxnPDT46FZ+33oTHHJ1HOxoZl0yr 5lcNSuFlFeVfkHpNFHAx15OTyjf67zYUYcW9zfzt1563clFVovUWI9ja0/XkWw2VPL6PBQAMs7/J R+AN8qe1wl+p45gUHOpfIx+Bj5Ywfj4+XZmPwNC4Ad+f0v+Xjys9uWQaWnpgGq68Tu8cSRlycWnc +uYD35O4af8P660C8BmV7c8eil3lslOt7TnpRt0v9pF7uU/MpnFXNidOHgzBL4p3xe3zufeUaTPg TNYtJLkQj/UwL2WHlH5qL+6xDNKYGFckGOokV1FFKtM+3jRr6FNn7fZYvF55r6bHpyzFaS98vIlJ lkomnvOWCbkWYUAnXNl7tfG5xjHIRu2SJy3w7/ehyNT7b9znJa/4efafVXkWnMEVnjew8wfJgYbQ jXE2Gh6hil1RiJiXOXepynOmO/vdSJp/zh+Q21S974PUg7P2UckMjn3r7FRtOxeN9E+7NFmdWR1i XlEeoY6/QAw0G86yLWqET9Td39XM6FYm47vHcsDJUxOJGjAcJpExtGV9Uc2pte/zZmdw/f/mL6VB /H5Nq/m54UJ+kbj6vFZyvnorXNmq4effPJkmD4jX+rudH1ItJPwYthHY7S5WU3WY1nbSkcpAq8NM P+PDFzpSQ/rCxieyUmR0aAN6C/RaPOdc79zioyP09PL8V9ebdtSMqNUXsSaRDGC/AehdKKMlK+do oZHctTb/PdJX/Kv+jyzVIf4+pVV5GhwxBJ1XyP/5DCvbFFzsoZod1mVah0uueGurkg0nZcPZ3dkp XAw6OaKSkqqWZdvCttFEVIwOG9HHDeSD8h08M3p7CxIxB9WH22+1UDSz/pphRVdjn23RQme7gq7S I5X+pFqnnekEvERicXVJspNnPGxyfm3+pw/Q3/Lfzvd/YrX/6VKhf1GW4vaQ6PmY7+fe9jVycgvr W/MOGCpVuRU5yETC9DbrpjLTjiTPhFp/GNVA3TQPNqt7/KL/UEIwgzpB21RPNgrqqy3U0XU4YFky hCzswYBcxZtXszL+NXNoS1yUyfRnr7v291OpYk8vk5gbXgeOCLj/CxpQsRhICgAA --_002_5A75F2FB213149AAA66268F9AA213252temperednetworkscom_-- From nobody Tue Sep 20 18:39:06 2016 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 6331212B4D9; Tue, 20 Sep 2016 18:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFvXjDSkiff4; Tue, 20 Sep 2016 18:39:02 -0700 (PDT) Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36C8D12B178; Tue, 20 Sep 2016 18:39:02 -0700 (PDT) Received: by mail-yb0-x233.google.com with SMTP id 2so12937000ybv.0; Tue, 20 Sep 2016 18:39:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=2+j8MIoEfD4gpcKcm9vZTF4AKbYXqLIEPK9U+9/QyrI=; b=tUfmTLmsr2CRreuFKDIh+fcH9MBUrniC6K/EyVFcGD400qaJ4VgkKGKR53Xc4c4PZk /GPQ1VTUw5DzfIJkyWHZcOMsfE9vexBg1/xuxdKcjxUcq2MHjrznth2BrxQYyel1B9I/ iFS/R8QrL+XcFFhraD2pYPRKcERC6i2U8TwNhJrCZwDJGTgbfgUc1B1OVadI3aY9eeCK dZtyhmeylfqWEw+EYWMm1YKeqYdftUKyfShfUrt12H6nXxOY0o65Sy+9ek/aClgR2yzW 3+wzmtLzH9Tr2/4JqvMuvEa9d2zuqEWONPktUVSV9sbPecpSyYJAzHkVxnyb0tCMVyWo dTGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=2+j8MIoEfD4gpcKcm9vZTF4AKbYXqLIEPK9U+9/QyrI=; b=B0b5Hibd/zFDDL24CPVigCJZFWfVzcU9l6XNB1T+SEqsHvJdREUp3tPWepvDeeCwQm Z+Li76N0h6rr2lRy5dMdzCRrQvL7RzzeKQ/CTMXkFIn2U8uV7RpxXVVBv6jiEkW4zk8G f4J4oJEQupiQcwgyunqUey4xKZHpLy/e2c2VGGFJBICiDauArrtSqxrm9nRpzaz+ofLB 8wgKaXvAlUJHk2BJRk6fTz3Lo8UxpqDLj44nQ+Imiy/5uspwwoM0rYSw7+G2Wq0e6YZi Zax3XgWXxISLZEEoED4rpI8mqUGqc1VVJEl9dL+gCbDdiIDZsKZCJ8s2yU++qkHLr20E PWvA== X-Gm-Message-State: AE9vXwPws9Iral5haW75Z811mPExOxo6t/d0p9r869t3BODq0AWsYFmulhjq75G0WZFm9hM+CNTVO277eLZN0A== X-Received: by 10.37.64.65 with SMTP id n62mr20859405yba.85.1474421941491; Tue, 20 Sep 2016 18:39:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.65.8 with HTTP; Tue, 20 Sep 2016 18:39:01 -0700 (PDT) In-Reply-To: References: From: Kathleen Moriarty Date: Tue, 20 Sep 2016 21:39:01 -0400 Message-ID: To: Tom Henderson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: draft-ietf-hip-multihoming@ietf.org, hip-chairs@ietf.org, The IESG , hipsec@ietf.org Subject: Re: [Hipsec] Kathleen Moriarty's No Objection on draft-ietf-hip-multihoming-11: (with COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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, 21 Sep 2016 01:39:04 -0000 Hi Tom, On Sun, Sep 18, 2016 at 12:55 PM, Tom Henderson wrote: > Hi Kathleen, thank you for your comment. > > On 09/13/2016 12:22 PM, Kathleen Moriarty wrote: >> Kathleen Moriarty has entered the following ballot position for >> draft-ietf-hip-multihoming-11: No Objection >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> I'm wondering if split-tunneling should be listed as a security >> consideration. I see the following in section 4.1 that might be used to >> help prevent split tunneling: >> In the outbound direction, as a result of SPD processing, when >> an outbound SA is selected, the correct IP destination address for >> the peer must also be assigned. >> >> Then also the entirety of section 4.3. >> >> I read this as split tunneling could be an issue in some circumstances >> depending on policy and it might be good to mention this in the security >> considerations section. Or let me know if I am missing some background >> that would prevent split tunneling so implementers don't need to be made >> aware of this consideration. > > From my recollection, support (or prevention) of split tunneling was not = a consideration of these parts of the text. The first sentence you quote f= rom 4.1 was intended as a hint to implementers that there is this additiona= l level of indirection with HIP that must be managed (mapping of SA to IP a= ddress) when multihoming is in use. Section 4.3 is mainly about how to man= age the possibly large number of valid SA configurations that could arise f= rom multihoming. > > My understanding of the common use of the term 'split tunneling' is that = it pertains to VPN tunnel situations where some set of connections should b= e tunneled but others not. In HIP, the security association is end-to-end = and the same VPN scenario is not applicable, so by split tunnel, do you mea= n that some transport sessions between two hosts are within HIP/ESP protect= ion and others not? Thanks for your response. Yes, I was poking to see if there was a possibility of leakage to an unintended destination when multi-homing was in place, like what is possible with split tunneling. It might not be split tunneling exactly, but if leakage is possible, it would be good to note that as a consideration. Thanks, Kathleen > > - Tom > > > > --=20 Best regards, Kathleen From nobody Wed Sep 21 00:25:11 2016 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 D390112B156; Wed, 21 Sep 2016 00:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.617 X-Spam-Level: X-Spam-Status: No, score=-6.617 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, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 prb0Rdpvj8eT; Wed, 21 Sep 2016 00:25:01 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B40C12B151; Wed, 21 Sep 2016 00:25:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EC57EBE5B; Wed, 21 Sep 2016 08:24:59 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s_2x_PqWy_Yy; Wed, 21 Sep 2016 08:24:58 +0100 (IST) Received: from [193.167.168.236] (eduroam-168-236.csc.fi [193.167.168.236]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 02470BE56; Wed, 21 Sep 2016 08:24:57 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1474442698; bh=ZYC6FvsIGBtsP/bD6SdNVflDkY4+/IGiK4sfsiy1dk8=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=Htd0DxEebKNuj3cXG5wA+htAZqYTSwZa9HFChYUXw41C/xocw5pJLS8UdnuF10BfU tMpVlj/C5Dj6m91KqyuTdT/VABK7NHSC0+z4g2PMJgtd6FC6+9h2hhmmqoRupknyZY dDsDimfZxRpWpqpcScCnfpvEMRU+k4w0f4gQvO4o= To: Tom Henderson References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <854d7796-0fb3-b154-c8c1-0d599526052a@cs.tcd.ie> Date: Wed, 21 Sep 2016 08:24:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060006010604060308080607" Archived-At: Cc: hipsec@ietf.org, draft-ietf-hip-rfc5206-bis@ietf.org, The IESG , hip-chairs@ietf.org Subject: Re: [Hipsec] Stephen Farrell's No Objection on draft-ietf-hip-rfc5206-bis-13: (with COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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, 21 Sep 2016 07:25:04 -0000 This is a cryptographically signed message in MIME format. --------------ms060006010604060308080607 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Tom, On 19/09/16 06:31, Tom Henderson wrote: > Hi Stephen, please see below. >=20 > On 09/14/2016 03:18 PM, Stephen Farrell wrote: >> Stephen Farrell has entered the following ballot position for=20 >> draft-ietf-hip-rfc5206-bis-13: No Objection >>=20 >> ----------------------------------------------------------------------= >> >>=20 COMMENT: >> ----------------------------------------------------------------------= >> >> >> >>=20 My review was based on the diff vs. 5206 [1], and turned >> up nothing new of note:-) Seems like a reasonable update to me. >>=20 >> I do however agree about the privacy issue raised by Mirja wrt >> exposing locators. It is worth noting that, so that implementers >> have it flagged that they need to consider that - not doing so >> caused quite a fuss for WebRTC so better to not repeat that. >=20 > I proposed some text about privacy issues with exposing locators in > the multihoming draft comment resolution (earlier today)-- do you > think something along those lines fits with this draft also > (mobility)?=20 Sure. Warning folks about non-obvious things over which we've previously tripped seems like a generally good thing. (Well, at least until we all learn to not trip over that thing;-) > Perhaps rephrased to mention that even in a > non-multihoming case, a host should be aware of any privacy issues of > the locator that it chooses to next expose after a mobility event > renders its current locator unusable... I trust you to find the relevant wording. Cheers, S. >=20 > - Tom >=20 >=20 >=20 >=20 >=20 --------------ms060006010604060308080607 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA5MjEw NzI0NTdaMC8GCSqGSIb3DQEJBDEiBCD3Vwe6YaesQig3WryHMEkS0U/ThCBEqfnCO/z1VOpl qDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAF2Uat4ZDl9xBmIS1I50zkJ6PlP2QnBrmJulD5NGdDa97fXs6zkU/7 kjd0nnur3UBbMuGR4mHlJXu7q/lnJNAX2YoL2z2cAcTiFG0NuHu+Nj8MmY/r4ffd7b4wGmk7 MO2B4KWM8JHRANcNI7eoNSTh3ziFx6A/6goNq/RWKJlOS1fbTfjxqxIPgP9wTygd+AIhniOa +TiSWiZMCjZDilp6ydWBPEAIW/LHfmuLYckahFKY0DFcNEr7h+ShRiXUXNMbOjq4bx45wgOD Rwi+z8kgpQVJGW2aFmwoJuW68OolTsEf0KiJY/EmSZnKACAbCXNp/9zRdIa+LEu5CWd4/md+ AAAAAAAA --------------ms060006010604060308080607-- From nobody Wed Sep 21 00:28:54 2016 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 9B87212B151; Wed, 21 Sep 2016 00:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.617 X-Spam-Level: X-Spam-Status: No, score=-6.617 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, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 QQ2TdsJ02XkS; Wed, 21 Sep 2016 00:28:47 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBFF112B147; Wed, 21 Sep 2016 00:28:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 710A3BE5B; Wed, 21 Sep 2016 08:28:45 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03ok9Byg6SEz; Wed, 21 Sep 2016 08:28:44 +0100 (IST) Received: from [193.167.168.236] (eduroam-168-236.csc.fi [193.167.168.236]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1AB9ABE56; Wed, 21 Sep 2016 08:28:43 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1474442924; bh=5pSJ9CaMLa8Upng8qva1A9nJMLU6KOR6WBswQs6uLQM=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=ENl4x23Txhu/lbt7NP7KhOZD70PK1hhCYmTUco439dqgSHg6TZx6rZVK7w8scjf3B gjcqPhXfGY+VT+NhZDhLlnW94IW7bIql5VBvDr0fnZ5WmpS30fea6mCQzTEi9y1p+T tzfIolkHApENxMavljV3uKwZ0uSyaPQi/avS2BRs= To: Tom Henderson References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <3344fc32-496b-79a6-1a80-8fbefd681e1f@cs.tcd.ie> Date: Wed, 21 Sep 2016 08:28:42 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030403000508010504060208" Archived-At: Cc: draft-ietf-hip-multihoming@ietf.org, hip-chairs@ietf.org, The IESG , hipsec@ietf.org Subject: Re: [Hipsec] Stephen Farrell's No Objection on draft-ietf-hip-multihoming-11: (with COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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, 21 Sep 2016 07:28:48 -0000 This is a cryptographically signed message in MIME format. --------------ms030403000508010504060208 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Tom, On 18/09/16 20:00, Tom Henderson wrote: > Stephen, thanks for your comments; replies inline below >=20 > On 09/14/2016 04:25 AM, Stephen Farrell wrote: >> Stephen Farrell has entered the following ballot position for >> draft-ietf-hip-multihoming-11: No Objection >> ----------------------------------------------------------------------= >> COMMENT: >> ----------------------------------------------------------------------= >> >> >> - I think section 6 ought note the privacy issue that >> was relatively recently with WebRTC and ICE where a >> client might not want all of it's IP addresses >> exposed, as doing so could expose the fact that the >> client e.g. is using Tor or another VPN service. The >> issue being that in some locations, that information >> may be quite sensitive. 4.2 notes this but in a quite >> opaque way, ("may be held back") but it'd be better to >> say some more. 5.1 is also relevant maybe in that it >> says one "SHOULD avoid" sending info about virtual >> interfaces. Anyway, I think it'd be good to add some >> recognition of this privacy issue to section 6. I am >> not arguing that this draft ought specify the one true >> way to avoid this problem, but only that it be >> recognised. >=20 > Your comment led me to review this draft >=20 > https://www.ietf.org/id/draft-ietf-rtcweb-ip-handling-01.txt >=20 > which I would be inclined to cite, but I am not sure whether it will be= put forward for publication soon (and therefore am not sure about citing= it). >=20 > The below might make a possible summary paragraph to add, however: >=20 > "The exposure of all of a host's IP addresses through HIP > multihoming extensions may raise privacy concerns. A host > may be trying to hide its location in some contexts through > the use of a VPN or other virtual interfaces. Similar > privacy issues also arise in other frameworks such as WebRTC > and are not specific to HIP. Implementations SHOULD provide > a mechanism to allow the host administrator to block the=20 > exposure of selected addresses or address ranges." >=20 Looks good to me, thanks. >> >> - 4.11: what's the concern about anti-replay windows? >> I didn't get that fwiw, not sure if that just my >> relative ignorance of HIP or if more needs to be said >> in the document. >=20 > It is explained in this sentence: >=20 > "However, the use of different source > and destination addresses typically leads to different paths, with > different latencies in the network, and if packets were to arrive vi= a > an arbitrary destination IP address (or path) for a given SPI, the > reordering due to different latencies may cause some packets to fall= > outside of the ESP anti-replay window." Really? I'm surprised that that's at all likely. What size of window do folks tend to use? It must be small if path diversity has that effect. (Note: I'm not asking for a change to the text just wondering about it/educating myself:-) Cheers, S. >=20 > Can you suggest changes or do you have a concern with what is stated? >=20 > - Tom >=20 --------------ms030403000508010504060208 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA5MjEw NzI4NDJaMC8GCSqGSIb3DQEJBDEiBCDjDRuts5NV2l3gmj8H/O6K5Vv2JAd1/FaTv/MA4tCe 7jBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCbV8/27sOMXhOkj2DYE4Oh5wXypb3XF9S5lZu7MqajMM1Cc84XYBGI 5x9d88KyyRxIZ3RxoABGk/LgQsC7LDxjDi0mJZQwzaZNyVLFJu0WgBjx3F0M6+sflTDs0Po9 lpRv0qEPMhRqxmh4rI+DSQoGXxPWzdqlBcNELSukUXq32aWKnoQ/89T/GIoQhhjvTnHhMRop y71rc526Fv1N7i9QbBbKdZPhsNKz3YFd6t2fPWq9Dh83rGkcvAe6CY2S/G7P6m7iy1E/eCjo uNetWtcrJEbKDAMqCVF9uwjxqER1eaLclro5JKqwdtkfdcVaK4fYIEFT/K8CAp1EoDlTs2BF AAAAAAAA --------------ms030403000508010504060208-- From nobody Thu Sep 22 07:02:10 2016 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 530D412DE91 for ; Thu, 22 Sep 2016 07:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.218 X-Spam-Level: X-Spam-Status: No, score=-4.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.316, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 Db6gL8gRWaye for ; Thu, 22 Sep 2016 07:02:04 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D46D412D7ED for ; Thu, 22 Sep 2016 06:42:46 -0700 (PDT) Received: (qmail 16269 invoked from network); 22 Sep 2016 15:36:04 +0200 Received: from p5dec2850.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.40.80) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 22 Sep 2016 15:36:04 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Thu, 22 Sep 2016 15:36:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Tom Henderson X-Mailer: Apple Mail (2.3124) Archived-At: Cc: draft-ietf-hip-multihoming@ietf.org, hipsec@ietf.org, hip-chairs@ietf.org, iesg@ietf.org Subject: Re: [Hipsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-hip-multihoming-11=3A_=28with_COMMENT=29?= X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 22 Sep 2016 14:02:08 -0000 Hi Tom, see below. > Am 18.09.2016 um 18:40 schrieb Tom Henderson = : >=20 > Mirja, thank you for your comments; replies again are inline below. >=20 > On 09/13/2016 07:40 AM, Mirja Kuehlewind wrote: >> Mirja K=C3=BChlewind has entered the following ballot position for >> draft-ietf-hip-multihoming-11: No Objection >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> One big general comment: >>=20 >> The split between this document and draft-ietf-hip-rfc5206-bis-13 = (still) >> seems a little artificial. draft-ietf-hip-rfc5206-bis-13 describes = some >> general parts that actually covers both use cases. I guess it would = be at >> least nice to spell out clearly in this document which parts of >> draft-ietf-hip-rfc5206-bis-13 are required to read (section 4 and = parts >> of section 5) if that's is somehow clearly separately. >=20 > OK >=20 >>=20 >> E.g. I believe the following should be in = draft-ietf-hip-rfc5206-bis-13 >> and not in this doc: >> "Hosts MUST NOT announce broadcast or multicast addresses in >> LOCATOR_SETs. " >> I this is more relevant for the case described in this document but = is >> true for the general case. draft-ietf-hip-rfc5206-bis-13 stated the >> following but that's not the same because it only describes the peer >> side: >> " For >> each locator listed in the LOCATOR_SET parameter, check that the >> address therein is a legal unicast or anycast address. That is, = the >> address MUST NOT be a broadcast or multicast address." >>=20 >> What worries me more is that I believe that one would need to always = read >> both documents to implement the peer functionality correctly. E.g. = this >> documents says the following: >> "An Initiator MAY include one or more LOCATOR_SET parameters in the = I2 >> packet, independent of whether or not there was a LOCATOR_SET >> parameter in the R1. These parameters MUST be protected by the I2 >> signature. Even if the I2 packet contains LOCATOR_SET parameters, >> the Responder MUST still send the R2 packet to the source address = of >> the I2." >> However, when I read draft-ietf-hip-rfc5206-bis-13, it is not clear = that >> there are specifications in this document that are important for a >> correct implementation.=20 >=20 > In the above case, the rationale for placing that text in the = multihoming draft is that the possible need to expose additional = locators during the base exchange arises in a multihoming context. I = don't think that draft-ietf-hip-rfc5206-bis-13 implementations (without = multihoming support) need to support inclusion in the base exchange. >=20 > I'm fine with moving this sentence:=20 >=20 > "Hosts MUST NOT announce broadcast or multicast addresses in = LOCATOR_SETs. " >=20 > to RFC 5206-bis, and I agree to write some introductory paragraph to = this document that points to the necessary parts of 5206-bis to support. >=20 Okay. >>=20 >> Smaller comments: >> 1) Regarding the following sentence: >> "In summary, whether and how a host decides to leverage additional >> addresses in a load-balancing or fault-tolerant manner is outside = the >> scope of the specification." >> I agree that it is out of scope for this doc. But maybe it would be >> useful to provide pointers to existng work. The scheduling problem is >> well know and e.g. basically the same for MPTCP. >=20 > Can you or someone suggest specific RFCs to cite here? I=E2=80=99m not aware about an respective RFC out of my head. I was also = thinking about research papers, e.g. I know this one: Experimental evaluation of multipath TCP schedulers by Christoph Paasch, Simone Ferlin, Ozgu Alay, Olivier Bonaventure http://dl.acm.org/citation.cfm?id=3D2631977 >=20 >>=20 >> 2) Regarding the following recommendation: >> "Although the protocol may allow for configurations in which there is >> an asymmetric number of SAs between the hosts (e.g., one host has = two >> interfaces and two inbound SAs, while the peer has one interface = and >> one inbound SA), it is RECOMMENDED that inbound and outbound SAs be >> created pairwise between hosts. When an ESP_INFO arrives to rekey = a >> particular outbound SA, the corresponding inbound SA should be also >> rekeyed at that time." >> I believe I agree but why? >=20 > I believe that the reason for this was to try to keep the = implementation simpler, and keep the inbound/outbound SA lifetimes = consistent. This recommendation removes the decision point in the = implementation, when receiving a request to rekey, whether or not to = rekey the corresponding SA. >=20 > There is less operational experience with multihoming extensions, = which was one of the reasons to split RFC5206 originally (to complete = mobility specification but perhaps allow multihoming specifications to = evolve further over time). It is possible to create lots of pairwise = SAs between various locators, but it is not as clear when to do that = versus when to try to reuse SAs across multiple locators. For instance, = when multihoming is used actively for load balancing, perhaps multiple = SA pairs are favorable (to avoid anti-replay checks failing from = reordered packets), but maybe in a fault tolerance situation, they are = less needed. >=20 > I believe that the text in section 4.4 that you cite could have a = pointer that section 4.11 later discusses this issue in more detail. Yes. Also maybe just don=E2=80=99t use normative language here, if you = are actually not sure. >=20 >>=20 >> 3) I (again) would find it easier to have section 4.9, 4.10, and 4.11 >> before 4.2-4.8. However, I guess that's a matter of taste. = Alternatively >> maybe have most of the text from 4.2-4.8 in a separate supersection = first >> and call it 'usage scenarios' or something like this, while = summerizing >> the protocol actions in one subsection in the 'protocol overview' = section >> because it seems that the actions are actually quite similar for all = use >> cases, no? >=20 > I think that 4.9-4.11 are more refinements or special cases than the = subsections preceding them, so I would refrain from reordering them. = However, I'll take a stab at adding a 'master scenario overview' that = could be used as a roadmap to the rest of the subsections. That might help. Thanks! Otherwise no strong opinion here, so whatever = you do should be fine. >=20 >>=20 >> 4) Maybe indicate clearly what is recommendated in >> draft-ietf-hip-rfc5206-bis the following way: >> OLD >> "[I-D.ietf-hip-rfc5206-bis] >> recommends that a host should send a LOCATOR_SET whenever it >> recognizes a change of its IP addresses in use on an active HIP >> association, and assumes that the change is going to last at least >> for a few seconds. " >> NEW >> "[I-D.ietf-hip-rfc5206-bis] >> recommends that "a host should send a LOCATOR_SET whenever it >> recognizes a change of its IP addresses in use on an active HIP >> association, and assumes that the change is going to last at least >> for a few seconds. "" >=20 > OK=20 >=20 >>=20 >> 5) How does a host know about this? Can you give examples? >> "The grouping should consider also whether middlebox >> interaction requires sending the same LOCATOR_SET in separate = UPDATEs >> on different paths." >=20 > This comment arises from the consideration of (future) HIP-aware NATs = that might perform parameter inspection. I'm not sure that there are = any solid ways to know about whether these exist, other than operational = knowledge about the networks where HIP is deployed. >=20 > How about rephrasing such as this? >=20 > "If hosts are deployed in an operational environment in which = HIP-aware NATs (that may perform parameter inspection) exist, and = different NATs may exist on different paths, hosts may take that = knowledge into consideration about how addresses are grouped, and may = send the same LOCATOR_SET in separate UPDATEs on the different paths. = However, more detailed guidelines about how to operate in the presence = of such HIP-aware NATs is a topic for further study.=E2=80=9C Already much better. >=20 > The alternative might be to delete this topic entirely since it is a = bit speculative. Also an option=E2=80=A6 Thanks! Mirja >=20 > - Tom From nobody Mon Sep 26 06:08:31 2016 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 8378B12B1C7 for ; Mon, 26 Sep 2016 06:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 AC2QpLmdE0CY for ; Mon, 26 Sep 2016 06:08:25 -0700 (PDT) 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 8587012B1B8 for ; Mon, 26 Sep 2016 06:08:25 -0700 (PDT) X-AuditID: c1b4fb25-5405a9800000793b-f2-57e91dc75a75 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by (Symantec Mail Security) with SMTP id 1F.F8.31035.7CD19E75; Mon, 26 Sep 2016 15:08:23 +0200 (CEST) Received: from [131.160.51.22] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.83) with Microsoft SMTP Server id 14.3.301.0; Mon, 26 Sep 2016 15:08:19 +0200 To: References: From: Miika Komu Organization: Ericsson AB Message-ID: <9dceaf66-40e7-08d4-86b7-b6228d25f6bb@ericsson.com> Date: Mon, 26 Sep 2016 16:08:19 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010207070004010503030607" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOLMWRmVeSWpSXmKPExsUyM2J7oO5x2ZfhBnfWW1pMXTSZ2YHRY8mS n0wBjFFcNimpOZllqUX6dglcGYfevmMvWGJXsXTSTJYGxsOWXYycHBICJhIXpz9k6WLk4hAS WM8ocfnQRzYIZzWjxP9Z+9m7GDk4hAWcJTYdFARpEBEQlZjy4TQzRE0To0T/4g4WkASbgJbE qjvXmUFsfgFJiQ0Nu5lBenkF7CXuv2ADCbMIqErc/LiUEcQWFYiQuPUQopVXQFDi5MwnYDYn 0KqmX+fBbmAW6GaUODlpKQvIHCEBFYmLx4InMPLPQtIyC1kZSIJZwFbiztzdzBC2tsSyha+h bGuJGb8OskHYihJTuh+yQ9imEq+PfmSEsI0llq37y7aAkWMVo2hxanFSbrqRsV5qUWZycXF+ nl5easkmRmCQH9zyW3UH4+U3jocYBTgYlXh4E248DxdiTSwrrsw9xKgCNOfRhtUXGKVY8vLz UpVEeDeJvQwX4k1JrKxKLcqPLyrNSS0+xCjNwaIkzmu28n64kEB6YklqdmpqQWoRTJaJg1Oq gVHBR3DZGaOZr4qvXDm1lc9cztBd0MlJOmJy46zOn+1yRbNFfxudWTylMTomtETjT/v1a6Xi F8S3JIneey69SeHV91CWzG7L2fczX076kLbJ8Lb8yqAlS/xmSx/6FVIicIbViTNB2KvMTHOZ 8XztD5dYpnZ9zwj7nj/14twPzDks/5S+1O5oma7EUpyRaKjFXFScCADvdJYyegIAAA== Archived-At: Subject: Re: [Hipsec] Comment on VIA_RVS parameter - 5204 & 06 -bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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 Sep 2016 13:08:30 -0000 --------------ms010207070004010503030607 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hi, On 09/16/2016 02:45 PM, Robert Moskowitz wrote: > > > On 09/16/2016 06:57 AM, Tom Henderson wrote: >> >> >> >> On Thu, 15 Sep 2016, Robert Moskowitz wrote: >> >>> 5206-bis specifies how to user RVS for the 'double-jump' mobility >>> problem. >>> >>> 3.2.3 1) says: >>> >>> 1. The mobile host sending an UPDATE to the peer, and not receiving >>> an ACK, MAY resend the UPDATE to a rendezvous server (RVS) of the >>> peer, if such a server is known. >>> >>> But it DOES know there is an RVS IF the I1 had FROM and RVS_HMAC >>> parameters and it had created a VIA_RVS parameter to send in the R1. >> >> Yes, but the responder may not know the initiator's RVS even if the >> the responder's RVS was used, and it also may be the case that neither= >> host's RVS was involved in the session setup. > > I see now. As currently speced, R has no way of learning I's RVS. The > 'easy' way to fix this is for I to include a VIA_RVS in the I2 packet > for mobility support. > > "If you every want to get back to me, I can always be reached at this > number". do you actually need the initiator's RVS for double jump? I think the=20 responder's RVS is enough. >>> This VIA_RVS provides the knowledge and locator of the peer's RVS. >>> >>> In fact an aggressive mobility UPDATE would be sent simultaneously to= >>> the host and its RVS. If the host had not moved itself, it gets both= >>> and drops the one from the RVS. >> >> I believe that Baris Boyvat on the InfraHIP project was looking a >> while back at such an approach to fast mobility; it was called >> 'shotgun' approach to mobility and multihoming (try all candidates >> simultaneously), if I remember correctly. Yes, the idea was to send I1 (or UPDATE) through all the available=20 address pairs, but I think the idea is now achieved in a more controlled = way in draft-ietf-hip-native-nat-traversal-13 --------------ms010207070004010503030607 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DKMwggXlMIIDzaADAgECAhAJdtiEOz4F3oNPssxObH7GMA0GCSqGSIb3DQEBBQUAMDoxETAP BgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYy MB4XDTE0MTIxNTEyNDQwMVoXDTE3MTIxNTEyNDQwMFowYjERMA8GA1UECgwIRXJpY3Nzb24x EzARBgNVBAMMCk1paWthIEtvbXUxJjAkBgkqhkiG9w0BCQEWF21paWthLmtvbXVAZXJpY3Nz b24uY29tMRAwDgYDVQQFEwdlbWlpa29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAsf2pgwYbVXxhx+wwvwrS5q56tLoEhnBUsb3JG3KHYATjfQryyJsDfn90YHMl49fXFORD tFO1PPA+QB22yusgCLhjgawckYn3XBzipClxTq1UHxNq01i/RzBotdrVWYMyP4KmsBzsg/vp 0Bu5KjltP6VBGpcOi8juVeXL10uNh4XpnBbaEq2uViZJOH9+mSr0IEgh4y/lEZKnlIGpcy3v lYL4S4Vhm8Ix9X8INveWuTMdo2od1j9fdEJgtv3cg5KN2+h+pI3oN8n5ikv1xs5kaDCYFunL UnMDglkcAT8k1ebqLV0jQUNSlvDCB2hrOzVFPyEycb0ZNbX1AkOTVnlrNwIDAQABo4IBvTCC AbkwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nz b25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxo dHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1 c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jZXIwIgYDVR0R BBswGYEXbWlpa2Eua29tdUBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMB ARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJh LmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBQTnHDg 6XexOtdZ/qMkn3QHKZCVZDAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9LNzAOBgNV HQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBALSVMD6C/sZZz43wJ2r/Hp8BtBigpKc6 CuX60vmkzQ8vGrxeNbPJmkC56FSeGtFo85DtF56xyBd704T18jr1tHTXra8cNP37qABYzgaL aLuGjtqcOnGQY//0ZQfLJBfKJnlJHX9ZB+QFPbhwpOFm9QM2oRYFse0Gjc8LV3WJ0jMUMvZD FyYoZeQ+sak+mObsTRfkR2vsuuB4Elo4MSudCmZqqFUU7gBmp36G2ySJLt/tJlJDld+egJJP 1gXnGkwW2n33Gkcy+SVLj0CSTyy76GibPp72AiuR/wz+GIaCgQ3APVbWXkB3ld4avno+Mq2u 6+2qYphYsmYwIs5SUsh6Zn1OQWNKUtbZbs2z4ALQbA3rHmndI8eLf4z7ZqML6UBzrQjukWi0 6D8yV7OXLz/TzBrp1sdPpNpDVSEWmuC0dJ3Ro8UJOLiO91KtLKwTYOPVlg+u62A5vYN6DVyT nBksz5CpUiVN7x3DDAcjarORQnteoIwBaOeZd/JZJbr900UEOmt9aLXnh8vFZOOx7db0Xccb WO473yOnt/Kr9XX5t2kvFQnNSEI3RkFqM06z+r5WiZd+BhGJPSU80QNOJzzoEXT69DihhWhF pSirFDV6CdUSxKoFD/8qIkB2QXuQUESN0WUBuGy2HOuIqnx+BIR5fGFsaiFEY5pXLHeSvByA b3yTMIIGtjCCBJ6gAwIBAgIRAKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEU MBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEw HhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjEl MCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEB BQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXsMmGSWShc6A5IEyFboXMZW3lF Hso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHfOzlwk7uwojJ34tHLiX/y QoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FAcLiIEeTMPRgXcn+8 GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgAmInJ4Ga8S6ME 2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zANhenIUwYCKNPq 5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP5XnI cMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+NV8VTaTrF nHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLx BiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIB tDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxp YXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlh c29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0 dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNV HQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvU GHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg36XYkNS7Ot0A1UqdjGFrtnII SI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiXg5HMTdOl6mlDbJaTIEGa gdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ6fEAOLW1j2IjJ0cy DI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+kXDJGbOaK42H2 ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5tTQYQeO7 QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk9OAijkG6n5oE GOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh +lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz 9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYID FDCCAxACAQEwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwg SW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjANBglghkgBZQMEAgEFAKCCAZcw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwOTI2MTMwODE5 WjAvBgkqhkiG9w0BCQQxIgQgQ6kvHIWex35RyFshbO3hUbwB1RRAf0k+zhYYarSlCkYwXQYJ KwYBBAGCNxAEMVAwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjBfBgsqhkiG9w0BCRACCzFQ oE4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1 YWwgQ0EgdjICEAl22IQ7PgXeg0+yzE5sfsYwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQME ASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQBaBdsIK0t1 zh3concJRH6ZcWxojy7NFP9Ny50tXksDZsfboVeez4UpPRF0gb2P3C83yuWDj3MrOoAUujHz ogTfptHdmwuKVCiYPAu3CDuONJQWmqlezyPoddiHfygRSCJY+YpiF1h/5oytL460tohXnS3t XsrEm8wBUFAwxJBclnPfvf5lgkz/pR2ts0oTB5JofPy8b0tfXZDhUIu9HiTGjHOhDhsD0PCH 4kel9NFVIClsREFSmAdnjDq4s68DeG5cNwFQo8hmL6iNGvaGuENVHYcdss/XlbifAIAXPPv4 nWS6hrXLIAHe9qZyZDLCaDyGLsV3i1N4ls0IRYkLyF8YAAAAAAAA --------------ms010207070004010503030607-- From nobody Mon Sep 26 06:46:58 2016 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 D87DD12B26C for ; Mon, 26 Sep 2016 06:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 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 RYUNmovz5ZT7 for ; Mon, 26 Sep 2016 06:46:43 -0700 (PDT) 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 AF82512B239 for ; Mon, 26 Sep 2016 06:46:42 -0700 (PDT) X-AuditID: c1b4fb3a-ab7ff7000000099a-05-57e926bfdcc4 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by (Symantec Mail Security) with SMTP id 88.98.02458.FB629E75; Mon, 26 Sep 2016 15:46:40 +0200 (CEST) Received: from [131.160.51.22] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.71) with Microsoft SMTP Server id 14.3.301.0; Mon, 26 Sep 2016 15:46:37 +0200 To: =?UTF-8?Q?Ren=c3=a9_Hummen?= References: <20160321203627.12199.62928.idtracker@ietfa.amsl.com> <56F98E90.10601@ericsson.com> <5756C81D.3080601@ericsson.com> From: Miika Komu Organization: Ericsson AB Message-ID: <1ade65d6-187e-20e0-fb9b-c3d5b73f42df@ericsson.com> Date: Mon, 26 Sep 2016 16:46:38 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060407030206030908000109" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsUyM2K7q+4BtZfhBpduSVlMXTSZ2WLxuW9s DkweO2fdZfdYsuQnUwBTFJdNSmpOZllqkb5dAlfGrfknGAsmTmSsaL13h62B8UF2FyMnh4SA icTno8vYuxi5OIQE1jNKPFz8lgnCWc0o0fT6DCNIlbCAtcTUDzfZQWwRAQuJCWvXMEIUTWSS aP7awNrFyMHBLCAqsX1WFUgNm4CWxKo715lBbH4BSYkNDbvBbF4Be4n2Ww9YQWwWAVWJ/n+z wWxRgQiJWw87WCBqBCVOznwCZnMKBEpcObSZDWQXs0A3o8ScHVMZQXYJCahIXDwWPIFRYBaS llnIykASzAJmEvM2P2SGsLUlli18DWVbS8z4dZANwlaUmNL9kB3CNpV4ffQjVK+xxLJ1f9kW MHKsYhQtTi0uzk03MtJLLcpMLi7Oz9PLSy3ZxAiMioNbflvtYDz43PEQowAHoxIPb8KN5+FC rIllxZW5hxhVgOY82rD6AqMUS15+XqqSCO8FlZfhQrwpiZVVqUX58UWlOanFhxilOViUxHnN Vt4PFxJITyxJzU5NLUgtgskycXBKNTCu3lG8rclhq/c6j1UmS/yK/kSkHL/3WvzsPcXWLytO XVm2/coaESUdx4lCj7OasycUvo7U4JOePlXmgsDt8DOLcvMPXRf8Jsz5a/7/96/mV9u67pgp tNDr5vytf6auE+1NjngQs83hy88bKzv2a2w0/uumV7PoycU/8rP2qBsbmjMt8tCUf539VYml OCPRUIu5qDgRAL2r4NWSAgAA Archived-At: Cc: hipsec@ietf.org Subject: Re: [Hipsec] A review of draft-ietf-hip-dex-02.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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 Sep 2016 13:46:57 -0000 --------------ms060407030206030908000109 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Ren=C3=A9, On 09/11/2016 11:06 PM, Ren=C3=A9 Hummen wrote: > Hello Miika, > > going through your email again, I saw a total of four suggestions. > > Three of them refer to imprecisions in the text of RFC 7401 (which I > copy/pasted for HIP DEX). There, I understood that consistency with RFC= > 7401 has a higher priority than only fixing your comments for HIP DEX, > but keeping the text as is for RFC 7401. This means, I will not modify > the text in the HIP DEX draft. Is this also your intention? yes, 7401 takes precedence over my comments. > The last remaining issue is related to the UPDATE message and the > rekeying procedure (Section 6.10.). Here, I added the following > paragraph for clarification purposes: > > [RFC7402] specifies the rekeying of an existing HIP SA using the > UPDATE message. This rekeying procedure can also be used with HIP > DEX. However, where rekeying involves a new Diffie-Hellman key > exchange, HIP DEX peers MUST establish a new connection in order to > create a new Pair-wise Key SA due to the use of static ECDH key-pair= s > with HIP DEX. > > Does this fix your issue? Yes. I assume you mean a new HIP association with connection. > BR > Ren=C3=A9 > > > > On Tue, Jun 7, 2016 at 3:11 PM, Miika Komu > wrote: > > Hi, > > On 06/03/2016 02:20 PM, Ren=C3=A9 Hummen wrote: > > This is part 3 of 3. > > > I am fine with your fixes. Some comments below. > > On Mon, Mar 28, 2016 at 10:05 PM, Miika Komu > > >> wrote: > > > [...] > > > 6.2.1. CMAC Calculation > > > > [...] > > > > > > 5. Set Checksum and Header Length fields in the HIP > header to > > original values. Note that the Checksum and Length fiel= ds > > contain incorrect values after this step. > > I guess also the values following HIP_MAC should be restore= d > since > they were wiped in the step 2. > > > I also found this description a bit imprecise, but it is taken = from > RFC7401. Step 2 already hints at the fact that parameters follo= wing > HIP_MAC may still be of interest: > "Remove the HIP_MAC parameter, as well as all other parameters > that follow it with greater Type value, saving the > contents if > they will be needed later." > > The question is whether we want to fix the description for HIP > DEX or to > keep things as they are for consistency reasons. In the former > case, I > would prefer to completely rewrite the verification procedure t= o > work on > the received packet without removing any parameters. However, w= e > should > then probably also post an errata to RFC7401. If there are no s= tong > opinions about that, I would go for the latter option. > > > Latter option works for me too. > > > The CKDF-Extract function is the following operation: > > > > CKDF-Extract(I, IKM, info) -> PRK > > What does the arrow operator signify? I thought that it > produces PRK, > but PRK is actually defined below. > > > The arrow is part of a basic mathematical function definition. > So yes, > PRK is the output (domain), but we still need to give it a > proper name. > I changed the artwork to clearly point out the inputs and outpu= ts. > > > Thanks, it is now better. > > Please check this section again in the updated version and get > back to > me if the above changes do not sufficiently help your understan= ding. > > > It is good now, thanks! > > > L length of output keying material in octets > > (<=3D 255*RHASH_len/8) > > | denotes the concatenation > > > > The output keying material OKM is calculated as follows:= > > > > N =3D ceil(L/RHASH_len/8) > > T =3D T(1) | T(2) | T(3) | ... | T(N) > > OKM =3D first L octets of T > > > > where > > > > T(0) =3D empty string (zero length) > > T(1) =3D CMAC(PRK, T(0) | info | 0x01) > > T(2) =3D CMAC(PRK, T(1) | info | 0x02) > > T(3) =3D CMAC(PRK, T(2) | info | 0x03) > > ... > > The Expand was a bit more clear, but still didn't understan= d > how to > get to the > Expanded key material due the arrow notation. > > > Ok, let's clarify this as several comments are related to the a= rrow > notation. For the function definition we use the mathematical a= rrow > notation (same as RFC 5869) and for the actual opertation we us= e the > equals sign (same as RFC 5869). In the end, they denote the sam= e > thing: > "assign X to Y". > > > Ok, this is what I guessed too. > > > (where the constant concatenated to the end of each T(n)= is a > > single octet.) > > Is there a max value? > > > I am not sure what you mean here. If you refer to the N in T(N)= > then it > is defined above as N =3D ceil(L/RHASH_len/8). > > > Yes, I asked about the maximum value for N (which depends on L), bu= t > never mind. > > > 8. The R1 packet may have the A-bit set - in this case= , > the system > > MAY choose to refuse it by dropping the R1 packet and > returning > > to state UNASSOCIATED. The system SHOULD consider > dropping the > > R1 packet only if it used a NULL HIT in the I1 packet. > > I didn't understand the logic in the last sentence. > > > Someone must have had a reason for this recommendation, but tha= t > someone > wasn't me. This is text from RFC7401. Any suggestions how to > proceed? > > > Fix similarly as the other RFC7401 issue in the beginning of this e= mail. > > > 6.7. Processing Incoming I2 Packets > > > > [...] > > > > 5. If the system's state machine is in the I2-SENT > state, the > > system MUST make a comparison between its local and send= er's > > HITs (similarly as in Section 6.3). If the local HIT is= > smaller > > than the sender's HIT, it should drop the I2 packet, use= the > > peer Diffie-Hellman key, ENCRYPTED_KEY keying material > and nonce > > #I from the R1 packet received earlier, and get the loca= l > > Diffie-Hellman key, ENCRYPTED_KEY keying material, and > nonce #J > > from the I2 packet sent to the peer earlier. Otherwise,= the > > system should process the received I2 packet and drop an= y > > previously derived Diffie-Hellman keying material Kij an= d > > ENCRYPTED_KEY keying material it might have generated up= on > > sending the I2 packet previously. The peer > Diffie-Hellman key, > > ENCRYPTED_KEY, and the nonce #J are taken from the just > arrived > > I2 packet. The local Diffie-Hellman key, ENCRYPTED_KEY > keying > > material, and the nonce #I are the ones that were sent > earlier > > in the R1 packet. > > Please replace "sender" with "peer" (or remote host) in thi= s > section > for more symmetric terminology. > > get -> obtain > > > I can make these changes if you insist, but I was going for a > minimal > diff to RFC 7401. > > > Not insisting. > > > > 11. The implementation SHOULD also verify that the > Initiator's HIT > > in the I2 packet corresponds to the Host Identity sent i= n > the I2 > > packet. (Note: some middleboxes may not be able to make= this > > verification.) > > Why SHOULD? Why not MUST? I think we're talking about > end-hosts here > anyway. > > > It is defined this way in RFC 7401. Do you really want to chang= e the > packet processing behavior for HIP DEX only? > > > Fix similarly as the first RFC7401 issue in this email. > > > 6.10. Processing UPDATE, CLOSE, and CLOSE_ACK Packets > > > UPDATE, CLOSE, and CLOSE_ACK packets are handled > similarly in HIP DEX > > as in HIP BEX (see Sections 6.11, 6.12, 6.14, and 6.15 o= f > [RFC7401]). > > The only difference is the that the HIP_SIGNATURE is > never present > > and, therefore, is not required to be processed by the > receiving > > party. > > How does rekeying work with the extract and expand function= s? > > > Rekeying is not defined in this document, same as for RFC 7401.= That > being said, the rekeying procedure with reuse of the KEYMAT fro= m RFC > 7402 directly translates to HIP DEX. For new KEYMAT, the peers > need to > establish a new connection due to the use of static DH keys. > > > Maybe this should be explicitly stated in the draft. > > > > > 7. HIP Policies > > > There are a number of variables that will influence the > HIP exchanges > > that each host must support. All HIP DEX implementation= s > SHOULD > > provide for an ACL of Initiator's HI to Responder's HI. > This ACL > > SHOULD also include preferred transform and local lifeti= mes. > > Wildcards SHOULD also be supported for this ACL. > > Why ACLs are mandatory? > > > It is not a MUST and considering that HIP DEX is primarly > targeted at > things, there is the need to do basic device authorizations > (based on > their identities) without a human in the loop. Of course you ar= e > also > allowed to use more suffisticated authorization mechanisms. > > > Ok. > > ACL -> ACL consisting of > > > Changed to the following text that is closer to RFC 7401: > " All HIP DEX implementations SHOULD provide for an Access > Control List > (ACL), representing for which hosts they accept HIP diet > exchanges, > and the preferred transport format and local lifetimes. > Wildcarding > SHOULD be supported for such ACLs." > > > 8. Security Considerations > > > o The HIP DEX HIT generation may present new attack > opportunities. > > They cannot be used in ACLs. Maybe this could be mentioned.= > Can this > be mitigated by always using full HIs? > > > I changed the bullet-point as follows: > "The HIP DEX HIT generation may present new attack opportunitie= s. > Hence, HIP DEX HITs should not be use as the only means = to > identify a peer in an ACL. Instead, the use of the > peer's HI is > recommended." > > > Ok. > > Note that I added a new Section 8 "Interoperability between HIP= > DEX and > HIPv2" to satisfy your comment on HIP DEX and HIPv2 compatibili= ty. > > > Thanks! > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > > > --------------ms060407030206030908000109 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DKMwggXlMIIDzaADAgECAhAJdtiEOz4F3oNPssxObH7GMA0GCSqGSIb3DQEBBQUAMDoxETAP BgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYy MB4XDTE0MTIxNTEyNDQwMVoXDTE3MTIxNTEyNDQwMFowYjERMA8GA1UECgwIRXJpY3Nzb24x EzARBgNVBAMMCk1paWthIEtvbXUxJjAkBgkqhkiG9w0BCQEWF21paWthLmtvbXVAZXJpY3Nz b24uY29tMRAwDgYDVQQFEwdlbWlpa29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAsf2pgwYbVXxhx+wwvwrS5q56tLoEhnBUsb3JG3KHYATjfQryyJsDfn90YHMl49fXFORD tFO1PPA+QB22yusgCLhjgawckYn3XBzipClxTq1UHxNq01i/RzBotdrVWYMyP4KmsBzsg/vp 0Bu5KjltP6VBGpcOi8juVeXL10uNh4XpnBbaEq2uViZJOH9+mSr0IEgh4y/lEZKnlIGpcy3v lYL4S4Vhm8Ix9X8INveWuTMdo2od1j9fdEJgtv3cg5KN2+h+pI3oN8n5ikv1xs5kaDCYFunL UnMDglkcAT8k1ebqLV0jQUNSlvDCB2hrOzVFPyEycb0ZNbX1AkOTVnlrNwIDAQABo4IBvTCC AbkwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nz b25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxo dHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1 c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jZXIwIgYDVR0R BBswGYEXbWlpa2Eua29tdUBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMB ARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJh LmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBQTnHDg 6XexOtdZ/qMkn3QHKZCVZDAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9LNzAOBgNV HQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBALSVMD6C/sZZz43wJ2r/Hp8BtBigpKc6 CuX60vmkzQ8vGrxeNbPJmkC56FSeGtFo85DtF56xyBd704T18jr1tHTXra8cNP37qABYzgaL aLuGjtqcOnGQY//0ZQfLJBfKJnlJHX9ZB+QFPbhwpOFm9QM2oRYFse0Gjc8LV3WJ0jMUMvZD FyYoZeQ+sak+mObsTRfkR2vsuuB4Elo4MSudCmZqqFUU7gBmp36G2ySJLt/tJlJDld+egJJP 1gXnGkwW2n33Gkcy+SVLj0CSTyy76GibPp72AiuR/wz+GIaCgQ3APVbWXkB3ld4avno+Mq2u 6+2qYphYsmYwIs5SUsh6Zn1OQWNKUtbZbs2z4ALQbA3rHmndI8eLf4z7ZqML6UBzrQjukWi0 6D8yV7OXLz/TzBrp1sdPpNpDVSEWmuC0dJ3Ro8UJOLiO91KtLKwTYOPVlg+u62A5vYN6DVyT nBksz5CpUiVN7x3DDAcjarORQnteoIwBaOeZd/JZJbr900UEOmt9aLXnh8vFZOOx7db0Xccb WO473yOnt/Kr9XX5t2kvFQnNSEI3RkFqM06z+r5WiZd+BhGJPSU80QNOJzzoEXT69DihhWhF pSirFDV6CdUSxKoFD/8qIkB2QXuQUESN0WUBuGy2HOuIqnx+BIR5fGFsaiFEY5pXLHeSvByA b3yTMIIGtjCCBJ6gAwIBAgIRAKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEU MBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEw HhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjEl MCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEB BQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXsMmGSWShc6A5IEyFboXMZW3lF Hso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHfOzlwk7uwojJ34tHLiX/y QoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FAcLiIEeTMPRgXcn+8 GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgAmInJ4Ga8S6ME 2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zANhenIUwYCKNPq 5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP5XnI cMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+NV8VTaTrF nHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLx BiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIB tDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxp YXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlh c29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0 dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNV HQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvU GHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg36XYkNS7Ot0A1UqdjGFrtnII SI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiXg5HMTdOl6mlDbJaTIEGa gdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ6fEAOLW1j2IjJ0cy DI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+kXDJGbOaK42H2 ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5tTQYQeO7 QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk9OAijkG6n5oE GOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh +lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz 9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYID FDCCAxACAQEwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwg SW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjANBglghkgBZQMEAgEFAKCCAZcw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwOTI2MTM0NjM4 WjAvBgkqhkiG9w0BCQQxIgQg7B0V16sQ2vJb8zFpTGnSzNtCpl2EHujPWe0xHvzfWpQwXQYJ KwYBBAGCNxAEMVAwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjBfBgsqhkiG9w0BCRACCzFQ oE4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1 YWwgQ0EgdjICEAl22IQ7PgXeg0+yzE5sfsYwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQME ASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQBRtWEQBgwY DvGnv2TYzDCeZBsyVgQbEas/BZdw+Qv15y/cFfYg8uTefI/qvKNcPbd3icmE3nKx2beO4jp8 quefqREs2YehwEX/NlVKPHUPjVdJma4vuRZlqeOPX2kZE9r22TwmYhELdBIHqmA/3US8S3fd Hbi+EEji5xGlGEuESYz13I7LiC140EDTLuAvzVksjoOyHaaHYIIjjqFKUmSlX0dLR3MTveWp pjWcqGPPjy1DSEnyQMU4thaLMUk3bwHE/noug6h857PvSuW2yuQJWMbE1tqDrEVbX8+QR4h7 WeFJKVmUnP1Jk2LNnQGMTCQLr4FVQfFnm28NMDjxMCLyAAAAAAAA --------------ms060407030206030908000109-- From nobody Mon Sep 26 17:56:58 2016 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 406DD12B3A4 for ; Mon, 26 Sep 2016 17:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] 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 C6gzsay1nNCJ for ; Mon, 26 Sep 2016 17:56:54 -0700 (PDT) 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 EE07512B047 for ; Mon, 26 Sep 2016 17:56:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id DEEBF621EC; Mon, 26 Sep 2016 20:56:51 -0400 (EDT) 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 liKdCt3QQbp1; Mon, 26 Sep 2016 20:56:27 -0400 (EDT) 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 4E008621E8; Mon, 26 Sep 2016 20:56:27 -0400 (EDT) To: Miika Komu , hipsec@ietf.org References: <9dceaf66-40e7-08d4-86b7-b6228d25f6bb@ericsson.com> From: Robert Moskowitz Message-ID: Date: Mon, 26 Sep 2016 20:56:17 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <9dceaf66-40e7-08d4-86b7-b6228d25f6bb@ericsson.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Hipsec] Comment on VIA_RVS parameter - 5204 & 06 -bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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 Sep 2016 00:56:56 -0000 On 09/26/2016 09:08 AM, Miika Komu wrote: > Hi, > > On 09/16/2016 02:45 PM, Robert Moskowitz wrote: >> >> >> On 09/16/2016 06:57 AM, Tom Henderson wrote: >>> >>> >>> >>> On Thu, 15 Sep 2016, Robert Moskowitz wrote: >>> >>>> 5206-bis specifies how to user RVS for the 'double-jump' mobility >>>> problem. >>>> >>>> 3.2.3 1) says: >>>> >>>> 1. The mobile host sending an UPDATE to the peer, and not receiving >>>> an ACK, MAY resend the UPDATE to a rendezvous server (RVS) of the >>>> peer, if such a server is known. >>>> >>>> But it DOES know there is an RVS IF the I1 had FROM and RVS_HMAC >>>> parameters and it had created a VIA_RVS parameter to send in the R1. >>> >>> Yes, but the responder may not know the initiator's RVS even if the >>> the responder's RVS was used, and it also may be the case that neither >>> host's RVS was involved in the session setup. >> >> I see now. As currently speced, R has no way of learning I's RVS. The >> 'easy' way to fix this is for I to include a VIA_RVS in the I2 packet >> for mobility support. >> >> "If you every want to get back to me, I can always be reached at this >> number". > > do you actually need the initiator's RVS for double jump? I think the > responder's RVS is enough. Then the Initiator's UPDATE must be successful before the Responder can perform its UPDATE successfully. This way they can operate in parallel. > >>>> This VIA_RVS provides the knowledge and locator of the peer's RVS. >>>> >>>> In fact an aggressive mobility UPDATE would be sent simultaneously to >>>> the host and its RVS. If the host had not moved itself, it gets both >>>> and drops the one from the RVS. >>> >>> I believe that Baris Boyvat on the InfraHIP project was looking a >>> while back at such an approach to fast mobility; it was called >>> 'shotgun' approach to mobility and multihoming (try all candidates >>> simultaneously), if I remember correctly. > > Yes, the idea was to send I1 (or UPDATE) through all the available > address pairs, but I think the idea is now achieved in a more > controlled way in draft-ietf-hip-native-nat-traversal-13 I will look at that. But what if there is no NATs to traverse? That there are 2+ interfaces, all native IPv6? But I will review nat-traversal. thanks Bob From nobody Tue Sep 27 01:58:24 2016 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 8DA1B12B09F for ; Tue, 27 Sep 2016 01:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 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 ygkf0KuN0ew1 for ; Tue, 27 Sep 2016 01:58:21 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 35BBB12B018 for ; Tue, 27 Sep 2016 01:58:21 -0700 (PDT) X-AuditID: c1b4fb30-b73ff70000000cb2-99-57ea34aa229a Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by (Symantec Mail Security) with SMTP id C6.A3.03250.AA43AE75; Tue, 27 Sep 2016 10:58:19 +0200 (CEST) Received: from [131.160.51.22] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.50) with Microsoft SMTP Server id 14.3.301.0; Tue, 27 Sep 2016 10:58:18 +0200 To: References: <9dceaf66-40e7-08d4-86b7-b6228d25f6bb@ericsson.com> From: Miika Komu Organization: Ericsson AB Message-ID: Date: Tue, 27 Sep 2016 11:58:18 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080509060809070001020606" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBLMWRmVeSWpSXmKPExsUyM2K7ge5qk1fhBkv3yFtMXTSZ2YHRY8mS n0wBjFFcNimpOZllqUX6dglcGYufv2EtmOhS0b5vPksD42y7LkZODgkBE4mnT3YwdzFycQgJ rGeUOPRiIiOEs5pRonvzaaAMB4ewgLPEpoOCIA0iAqISUz6chmr4yCgxac50NpAEm4CWxKo7 15lBbH4BSYkNDbvBbF4Be4kpTe/ZQWwWAVWJ318egNWLCkRI3HrYwQJRIyhxcuYTMJsTaNfq 9W/BjmAW6GaUeNhwnRXkCCEBFYmLx4InMPLPQtIyC1kZSIJZwExi3uaHzBC2tsSyha+hbGuJ Gb8OskHYihJTuh+yQ9imEq+PfmSEsI0llq37y7aAkWMVo2hxanFSbrqRkV5qUWZycXF+nl5e askmRmCYH9zy22AH48vnjocYBTgYlXh4E2a9DBdiTSwrrsw9xKgCNOfRhtUXGKVY8vLzUpVE eD8ZvAoX4k1JrKxKLcqPLyrNSS0+xCjNwaIkzmu28n64kEB6YklqdmpqQWoRTJaJg1OqgXGR 7JKYG8on/tufm/GQcd/1mPer1mmpRD9k99v4i2mpltafTYoHjwjlaAed+82dFH9MjmXhyVNW n3kkwucaPZRQSasMfLM7ruj/OhlGqSTTB6/MfERMTatLDu7J2LDResb954axrBXxSqw/GeN/ 5S1iF30xq4qtqKjl1fJPvELzJmz592al8A4lluKMREMt5qLiRAD4Sn+bewIAAA== Archived-At: Subject: Re: [Hipsec] Comment on VIA_RVS parameter - 5204 & 06 -bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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 Sep 2016 08:58:23 -0000 --------------ms080509060809070001020606 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi, On 09/27/2016 03:56 AM, Robert Moskowitz wrote: > > > On 09/26/2016 09:08 AM, Miika Komu wrote: >> Hi, >> >> On 09/16/2016 02:45 PM, Robert Moskowitz wrote: >>> >>> >>> On 09/16/2016 06:57 AM, Tom Henderson wrote: >>>> >>>> >>>> >>>> On Thu, 15 Sep 2016, Robert Moskowitz wrote: >>>> >>>>> 5206-bis specifies how to user RVS for the 'double-jump' mobility >>>>> problem. >>>>> >>>>> 3.2.3 1) says: >>>>> >>>>> 1. The mobile host sending an UPDATE to the peer, and not receiving= >>>>> an ACK, MAY resend the UPDATE to a rendezvous server (RVS) of the >>>>> peer, if such a server is known. >>>>> >>>>> But it DOES know there is an RVS IF the I1 had FROM and RVS_HMAC >>>>> parameters and it had created a VIA_RVS parameter to send in the R1= =2E >>>> >>>> Yes, but the responder may not know the initiator's RVS even if the >>>> the responder's RVS was used, and it also may be the case that neith= er >>>> host's RVS was involved in the session setup. >>> >>> I see now. As currently speced, R has no way of learning I's RVS. Th= e >>> 'easy' way to fix this is for I to include a VIA_RVS in the I2 packet= >>> for mobility support. >>> >>> "If you every want to get back to me, I can always be reached at this= >>> number". >> >> do you actually need the initiator's RVS for double jump? I think the >> responder's RVS is enough. > > Then the Initiator's UPDATE must be successful before the Responder can= > perform its UPDATE successfully. This way they can operate in parallel= =2E I see, you really want to avoid packets being dropped. >>>>> This VIA_RVS provides the knowledge and locator of the peer's RVS. >>>>> >>>>> In fact an aggressive mobility UPDATE would be sent simultaneously = to >>>>> the host and its RVS. If the host had not moved itself, it gets bo= th >>>>> and drops the one from the RVS. >>>> >>>> I believe that Baris Boyvat on the InfraHIP project was looking a >>>> while back at such an approach to fast mobility; it was called >>>> 'shotgun' approach to mobility and multihoming (try all candidates >>>> simultaneously), if I remember correctly. >> >> Yes, the idea was to send I1 (or UPDATE) through all the available >> address pairs, but I think the idea is now achieved in a more >> controlled way in draft-ietf-hip-native-nat-traversal-13 > > I will look at that. But what if there is no NATs to traverse? That > there are 2+ interfaces, all native IPv6? > > But I will review nat-traversal. Basically the nat-traversal draft is about connectivity checks (that=20 traverse NATs), nothing much IPv4 specific there. Feedback is still welco= me. --------------ms080509060809070001020606 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DKMwggXlMIIDzaADAgECAhAJdtiEOz4F3oNPssxObH7GMA0GCSqGSIb3DQEBBQUAMDoxETAP BgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYy MB4XDTE0MTIxNTEyNDQwMVoXDTE3MTIxNTEyNDQwMFowYjERMA8GA1UECgwIRXJpY3Nzb24x EzARBgNVBAMMCk1paWthIEtvbXUxJjAkBgkqhkiG9w0BCQEWF21paWthLmtvbXVAZXJpY3Nz b24uY29tMRAwDgYDVQQFEwdlbWlpa29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAsf2pgwYbVXxhx+wwvwrS5q56tLoEhnBUsb3JG3KHYATjfQryyJsDfn90YHMl49fXFORD tFO1PPA+QB22yusgCLhjgawckYn3XBzipClxTq1UHxNq01i/RzBotdrVWYMyP4KmsBzsg/vp 0Bu5KjltP6VBGpcOi8juVeXL10uNh4XpnBbaEq2uViZJOH9+mSr0IEgh4y/lEZKnlIGpcy3v lYL4S4Vhm8Ix9X8INveWuTMdo2od1j9fdEJgtv3cg5KN2+h+pI3oN8n5ikv1xs5kaDCYFunL UnMDglkcAT8k1ebqLV0jQUNSlvDCB2hrOzVFPyEycb0ZNbX1AkOTVnlrNwIDAQABo4IBvTCC AbkwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nz b25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxo dHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1 c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jZXIwIgYDVR0R BBswGYEXbWlpa2Eua29tdUBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMB ARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJh LmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBQTnHDg 6XexOtdZ/qMkn3QHKZCVZDAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9LNzAOBgNV HQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBALSVMD6C/sZZz43wJ2r/Hp8BtBigpKc6 CuX60vmkzQ8vGrxeNbPJmkC56FSeGtFo85DtF56xyBd704T18jr1tHTXra8cNP37qABYzgaL aLuGjtqcOnGQY//0ZQfLJBfKJnlJHX9ZB+QFPbhwpOFm9QM2oRYFse0Gjc8LV3WJ0jMUMvZD FyYoZeQ+sak+mObsTRfkR2vsuuB4Elo4MSudCmZqqFUU7gBmp36G2ySJLt/tJlJDld+egJJP 1gXnGkwW2n33Gkcy+SVLj0CSTyy76GibPp72AiuR/wz+GIaCgQ3APVbWXkB3ld4avno+Mq2u 6+2qYphYsmYwIs5SUsh6Zn1OQWNKUtbZbs2z4ALQbA3rHmndI8eLf4z7ZqML6UBzrQjukWi0 6D8yV7OXLz/TzBrp1sdPpNpDVSEWmuC0dJ3Ro8UJOLiO91KtLKwTYOPVlg+u62A5vYN6DVyT nBksz5CpUiVN7x3DDAcjarORQnteoIwBaOeZd/JZJbr900UEOmt9aLXnh8vFZOOx7db0Xccb WO473yOnt/Kr9XX5t2kvFQnNSEI3RkFqM06z+r5WiZd+BhGJPSU80QNOJzzoEXT69DihhWhF pSirFDV6CdUSxKoFD/8qIkB2QXuQUESN0WUBuGy2HOuIqnx+BIR5fGFsaiFEY5pXLHeSvByA b3yTMIIGtjCCBJ6gAwIBAgIRAKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEU MBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEw HhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjEl MCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEB BQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXsMmGSWShc6A5IEyFboXMZW3lF Hso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHfOzlwk7uwojJ34tHLiX/y QoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FAcLiIEeTMPRgXcn+8 GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgAmInJ4Ga8S6ME 2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zANhenIUwYCKNPq 5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP5XnI cMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+NV8VTaTrF nHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLx BiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIB tDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxp YXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlh c29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0 dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNV HQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvU GHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg36XYkNS7Ot0A1UqdjGFrtnII SI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiXg5HMTdOl6mlDbJaTIEGa gdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ6fEAOLW1j2IjJ0cy DI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+kXDJGbOaK42H2 ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5tTQYQeO7 QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk9OAijkG6n5oE GOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh +lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz 9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYID FDCCAxACAQEwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwg SW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjANBglghkgBZQMEAgEFAKCCAZcw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwOTI3MDg1ODE4 WjAvBgkqhkiG9w0BCQQxIgQgPijEkrBhaWw+rMHVn3PmMgiJFPDY+zurkuxKsM4ZQT4wXQYJ KwYBBAGCNxAEMVAwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjBfBgsqhkiG9w0BCRACCzFQ oE4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1 YWwgQ0EgdjICEAl22IQ7PgXeg0+yzE5sfsYwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQME ASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQBjoYCRenuQ W/MbhZhL5+DlfSPDKw4TcJovyPWzyJ0O7e2J18B7yPxvzF78QSkRGo6iVXLb7F6XcEdgNwKK ZAygk4pNA6Ft2FMEH9VH8cwHQA/NQOx6v5TXz4A2b5RQBUN3A/lMUI6VfUxinfYgEnArb6r8 xV+4HZ543VqdkNnlwkNLDwnbMPwGrDPXZkTSW9OmJYcbfasGr8ACWVoP8jnhdcSfEyJccq+i bTBe3I+FsDc5/g3H9n0LICnKZHaHoEbOeqXNOrAybMj7JJdaDg3PG5/aCf0yCNOF10I36Vj0 5yTs1Nhc4t4rzLuip6Wl/KeMp5rAvykKvEEcQXxgmAQwAAAAAAAA --------------ms080509060809070001020606-- From nobody Tue Sep 27 02:26:01 2016 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 85B8812B0A2 for ; Tue, 27 Sep 2016 02:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] 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 XfhlPCQQ8Ytn for ; Tue, 27 Sep 2016 02:25:56 -0700 (PDT) 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 BD1A712B00A for ; Tue, 27 Sep 2016 02:25:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id DA42862182; Tue, 27 Sep 2016 05:25:55 -0400 (EDT) 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 2YyFzIEHcAS4; Tue, 27 Sep 2016 05:25:37 -0400 (EDT) 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 9F3076216F; Tue, 27 Sep 2016 05:25:37 -0400 (EDT) To: Miika Komu , hipsec@ietf.org References: <9dceaf66-40e7-08d4-86b7-b6228d25f6bb@ericsson.com> From: Robert Moskowitz Message-ID: <071df3b8-7a71-92d8-31b4-efa1023b2014@htt-consult.com> Date: Tue, 27 Sep 2016 05:25:29 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------FD0D29F0DBA0E2CF77C1AE3D" Archived-At: Subject: Re: [Hipsec] Comment on VIA_RVS parameter - 5204 & 06 -bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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 Sep 2016 09:25:59 -0000 This is a multi-part message in MIME format. --------------FD0D29F0DBA0E2CF77C1AE3D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 09/27/2016 04:58 AM, Miika Komu wrote: > Hi, > > On 09/27/2016 03:56 AM, Robert Moskowitz wrote: >> >> >> On 09/26/2016 09:08 AM, Miika Komu wrote: >>> Hi, >>> >>> On 09/16/2016 02:45 PM, Robert Moskowitz wrote: >>>> >>>> >>>> On 09/16/2016 06:57 AM, Tom Henderson wrote: >>>>> >>>>> >>>>> >>>>> On Thu, 15 Sep 2016, Robert Moskowitz wrote: >>>>> >>>>>> 5206-bis specifies how to user RVS for the 'double-jump' mobility >>>>>> problem. >>>>>> >>>>>> 3.2.3 1) says: >>>>>> >>>>>> 1. The mobile host sending an UPDATE to the peer, and not receiving >>>>>> an ACK, MAY resend the UPDATE to a rendezvous server (RVS) of the >>>>>> peer, if such a server is known. >>>>>> >>>>>> But it DOES know there is an RVS IF the I1 had FROM and RVS_HMAC >>>>>> parameters and it had created a VIA_RVS parameter to send in the R1. >>>>> >>>>> Yes, but the responder may not know the initiator's RVS even if the >>>>> the responder's RVS was used, and it also may be the case that >>>>> neither >>>>> host's RVS was involved in the session setup. >>>> >>>> I see now. As currently speced, R has no way of learning I's RVS. The >>>> 'easy' way to fix this is for I to include a VIA_RVS in the I2 packet >>>> for mobility support. >>>> >>>> "If you every want to get back to me, I can always be reached at this >>>> number". >>> >>> do you actually need the initiator's RVS for double jump? I think the >>> responder's RVS is enough. >> >> Then the Initiator's UPDATE must be successful before the Responder can >> perform its UPDATE successfully. This way they can operate in parallel. > > I see, you really want to avoid packets being dropped. Draft on Fast Mobility schedule for publication on Wednesday. ;) Just about finished with pre-draft reviews. > >>>>>> This VIA_RVS provides the knowledge and locator of the peer's RVS. >>>>>> >>>>>> In fact an aggressive mobility UPDATE would be sent >>>>>> simultaneously to >>>>>> the host and its RVS. If the host had not moved itself, it gets >>>>>> both >>>>>> and drops the one from the RVS. >>>>> >>>>> I believe that Baris Boyvat on the InfraHIP project was looking a >>>>> while back at such an approach to fast mobility; it was called >>>>> 'shotgun' approach to mobility and multihoming (try all candidates >>>>> simultaneously), if I remember correctly. >>> >>> Yes, the idea was to send I1 (or UPDATE) through all the available >>> address pairs, but I think the idea is now achieved in a more >>> controlled way in draft-ietf-hip-native-nat-traversal-13 >> >> I will look at that. But what if there is no NATs to traverse? That >> there are 2+ interfaces, all native IPv6? >> >> But I will review nat-traversal. > > Basically the nat-traversal draft is about connectivity checks (that > traverse NATs), nothing much IPv4 specific there. Feedback is still > welcome. > > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec --------------FD0D29F0DBA0E2CF77C1AE3D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 09/27/2016 04:58 AM, Miika Komu wrote:
Hi,

On 09/27/2016 03:56 AM, Robert Moskowitz wrote:


On 09/26/2016 09:08 AM, Miika Komu wrote:
Hi,

On 09/16/2016 02:45 PM, Robert Moskowitz wrote:


On 09/16/2016 06:57 AM, Tom Henderson wrote:



On Thu, 15 Sep 2016, Robert Moskowitz wrote:

5206-bis specifies how to user RVS for the 'double-jump' mobility
problem.

3.2.3 1) says:

1. The mobile host sending an UPDATE to the peer, and not receiving
an ACK, MAY resend the UPDATE to a rendezvous server (RVS) of the
peer, if such a server is known.

But it DOES know there is an RVS IF the I1 had FROM and RVS_HMAC
parameters and it had created a VIA_RVS parameter to send in the R1.

Yes, but the responder may not know the initiator's RVS even if the
the responder's RVS was used, and it also may be the case that neither
host's RVS was involved in the session setup.

I see now.  As currently speced, R has no way of learning I's RVS. The
'easy' way to fix this is for I to include a VIA_RVS in the I2 packet
for mobility support.

"If you every want to get back to me, I can always be reached at this
number".

do you actually need the initiator's RVS for double jump? I think the
responder's RVS is enough.

Then the Initiator's UPDATE must be successful before the Responder can
perform its UPDATE successfully.  This way they can operate in parallel.

I see, you really want to avoid packets being dropped.

Draft on Fast Mobility schedule for publication on Wednesday. ;)

Just about finished with pre-draft reviews.



This VIA_RVS provides the knowledge and locator of the peer's RVS.

In fact an aggressive mobility UPDATE would be sent simultaneously to
the host and its RVS.  If the host had not moved itself, it gets both
and drops the one from the RVS.

I believe that Baris Boyvat on the InfraHIP project was looking a
while back at such an approach to fast mobility; it was called
'shotgun' approach to mobility and multihoming (try all candidates
simultaneously), if I remember correctly.

Yes, the idea was to send I1 (or UPDATE) through all the available
address pairs, but I think the idea is now achieved in a more
controlled way in draft-ietf-hip-native-nat-traversal-13

I will look at that.  But what if there is no NATs to traverse? That
there are 2+ interfaces, all native IPv6?

But I will review nat-traversal.

Basically the nat-traversal draft is about connectivity checks (that traverse NATs), nothing much IPv4 specific there. Feedback is still welcome. 



_______________________________________________
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

--------------FD0D29F0DBA0E2CF77C1AE3D-- From nobody Tue Sep 27 06:48:28 2016 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 4446412B1B8 for ; Tue, 27 Sep 2016 06:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] 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 1aCIOxI9WODs for ; Tue, 27 Sep 2016 06:48:24 -0700 (PDT) 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 E104112B1BA for ; Tue, 27 Sep 2016 06:48:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 8E1D0621C5 for ; Tue, 27 Sep 2016 09:48:21 -0400 (EDT) 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 htiyugEsPEMy for ; Tue, 27 Sep 2016 09:46:48 -0400 (EDT) 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 4A8066212C for ; Tue, 27 Sep 2016 09:46:48 -0400 (EDT) To: hipsec@ietf.org From: Robert Moskowitz Message-ID: Date: Tue, 27 Sep 2016 09:46:41 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Hipsec] Relaying to non-hip aware servers X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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 Sep 2016 13:48:26 -0000 Where did we describe connections from a mobile hip-aware host to a legacy non-HIP 'stable' server. I thought it was HIPBONE (as it is not what HIP nat traversal is about), but I am not seeing this function there. Basically, the Mobile host has its HIP SA with a relay that decapsulates the ESP traffic onto legacy Internet. This can cause some nasty routing scenarios unless the HIP host can treat a group of relays as multihome interfaces or the like and use the best relay for any connection. Which would drive TCP/UDP crazy though? I recall through the window, darkly, that we had these discussions. But my search foo is weak and I am not finding them. Bob From nobody Tue Sep 27 07:02:10 2016 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 6360012B1E4 for ; Tue, 27 Sep 2016 07:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 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 8yS4Th13SrGt for ; Tue, 27 Sep 2016 07:02:06 -0700 (PDT) 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 0C61D12B1D6 for ; Tue, 27 Sep 2016 07:02:05 -0700 (PDT) X-AuditID: c1b4fb3a-ab7ff7000000099a-f9-57ea7bdab08e Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by (Symantec Mail Security) with SMTP id 46.F6.02458.ADB7AE75; Tue, 27 Sep 2016 16:02:04 +0200 (CEST) Received: from [131.160.51.22] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.35) with Microsoft SMTP Server id 14.3.301.0; Tue, 27 Sep 2016 16:02:01 +0200 To: Robert Moskowitz , hip WG References: From: Miika Komu Organization: Ericsson AB Message-ID: <5a42438c-fcb6-d74f-b590-7f310a9d5447@ericsson.com> Date: Tue, 27 Sep 2016 17:02:01 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090006080404020904030500" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyM2K7ou6d6lfhBj82SFtMXTSZ2aJh3WdG ByaP3ZOa2D2WLPnJFMAUxWWTkpqTWZZapG+XwJXx7dRM1oINZhW/roo0MO427mLk4JAQMJHY 8VCli5GLQ0hgPaPEmpUrmSCc1YwSV2ZOYOxi5OQQFjCXOLCtjQ3EFhFwkdizbDE7iC0k4CSx rWM5C4jNJqAlserOdWYQm19AUmJDw24wm1fAXmLW9GdgvSwCqhLPn9wAs0UFIiRuPexggagR lDg58wmYzSngLPHqwTFWkCOYBboZJdY+3sMKcqmQgIrExWPBExj5ZyFpmYWsDCTBLGArcWfu bmYIW1ti2cLXULa1xIxfB9kgbEWJKd0P2SFsU4nXRz8yQtjGEsvW/WVbwMixilG0OLW4ODfd yEgvtSgzubg4P08vL7VkEyMw7A9u+W21g/Hgc8dDjAIcjEo8vAnAeBBiTSwrrsw9xKgCNOfR htUXGKVY8vLzUpVEeM8VA6V5UxIrq1KL8uOLSnNSiw8xSnOwKInzmq28Hy4kkJ5YkpqdmlqQ WgSTZeLglGpg3FSVzdAvup9JTHyD+tMzLl+rJipfXKy1VVjBp3VCTmTy9ahVMxf8nnh23rfL ux9P/NH9ptczTSNc0fn81ahjO1YdZH/5z+hw66fG6/qTnANbNX+nx6jWpov6ns0IvHXra2Ob p1vvrN5oqcuiQm1hazx/R0/WqUjZ8oT7oyDzszO3zM9n11qHKLEUZyQaajEXFScCANPOGWiD AgAA Archived-At: Subject: Re: [Hipsec] Relaying to non-hip aware servers X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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 Sep 2016 14:02:10 -0000 --------------ms090006080404020904030500 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hi Robert, On 09/27/2016 04:46 PM, Robert Moskowitz wrote: > Where did we describe connections from a mobile hip-aware host to a > legacy non-HIP 'stable' server. > > I thought it was HIPBONE (as it is not what HIP nat traversal is about)= , > but I am not seeing this function there. > > Basically, the Mobile host has its HIP SA with a relay that decapsulate= s > the ESP traffic onto legacy Internet. > > This can cause some nasty routing scenarios unless the HIP host can > treat a group of relays as multihome interfaces or the like and use the= > best relay for any connection. Which would drive TCP/UDP crazy though?= > > I recall through the window, darkly, that we had these discussions. But= > my search foo is weak and I am not finding them. proxy HIP: https://tools.ietf.org/html/draft-melen-hip-proxy-02 https://tools.ietf.org/html/draft-irtf-hiprg-proxies-05 --------------ms090006080404020904030500 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DKMwggXlMIIDzaADAgECAhAJdtiEOz4F3oNPssxObH7GMA0GCSqGSIb3DQEBBQUAMDoxETAP BgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYy MB4XDTE0MTIxNTEyNDQwMVoXDTE3MTIxNTEyNDQwMFowYjERMA8GA1UECgwIRXJpY3Nzb24x EzARBgNVBAMMCk1paWthIEtvbXUxJjAkBgkqhkiG9w0BCQEWF21paWthLmtvbXVAZXJpY3Nz b24uY29tMRAwDgYDVQQFEwdlbWlpa29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAsf2pgwYbVXxhx+wwvwrS5q56tLoEhnBUsb3JG3KHYATjfQryyJsDfn90YHMl49fXFORD tFO1PPA+QB22yusgCLhjgawckYn3XBzipClxTq1UHxNq01i/RzBotdrVWYMyP4KmsBzsg/vp 0Bu5KjltP6VBGpcOi8juVeXL10uNh4XpnBbaEq2uViZJOH9+mSr0IEgh4y/lEZKnlIGpcy3v lYL4S4Vhm8Ix9X8INveWuTMdo2od1j9fdEJgtv3cg5KN2+h+pI3oN8n5ikv1xs5kaDCYFunL UnMDglkcAT8k1ebqLV0jQUNSlvDCB2hrOzVFPyEycb0ZNbX1AkOTVnlrNwIDAQABo4IBvTCC AbkwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nz b25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxo dHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1 c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jZXIwIgYDVR0R BBswGYEXbWlpa2Eua29tdUBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMB ARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJh LmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBQTnHDg 6XexOtdZ/qMkn3QHKZCVZDAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9LNzAOBgNV HQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBALSVMD6C/sZZz43wJ2r/Hp8BtBigpKc6 CuX60vmkzQ8vGrxeNbPJmkC56FSeGtFo85DtF56xyBd704T18jr1tHTXra8cNP37qABYzgaL aLuGjtqcOnGQY//0ZQfLJBfKJnlJHX9ZB+QFPbhwpOFm9QM2oRYFse0Gjc8LV3WJ0jMUMvZD FyYoZeQ+sak+mObsTRfkR2vsuuB4Elo4MSudCmZqqFUU7gBmp36G2ySJLt/tJlJDld+egJJP 1gXnGkwW2n33Gkcy+SVLj0CSTyy76GibPp72AiuR/wz+GIaCgQ3APVbWXkB3ld4avno+Mq2u 6+2qYphYsmYwIs5SUsh6Zn1OQWNKUtbZbs2z4ALQbA3rHmndI8eLf4z7ZqML6UBzrQjukWi0 6D8yV7OXLz/TzBrp1sdPpNpDVSEWmuC0dJ3Ro8UJOLiO91KtLKwTYOPVlg+u62A5vYN6DVyT nBksz5CpUiVN7x3DDAcjarORQnteoIwBaOeZd/JZJbr900UEOmt9aLXnh8vFZOOx7db0Xccb WO473yOnt/Kr9XX5t2kvFQnNSEI3RkFqM06z+r5WiZd+BhGJPSU80QNOJzzoEXT69DihhWhF pSirFDV6CdUSxKoFD/8qIkB2QXuQUESN0WUBuGy2HOuIqnx+BIR5fGFsaiFEY5pXLHeSvByA b3yTMIIGtjCCBJ6gAwIBAgIRAKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEU MBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEw HhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjEl MCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEB BQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXsMmGSWShc6A5IEyFboXMZW3lF Hso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHfOzlwk7uwojJ34tHLiX/y QoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FAcLiIEeTMPRgXcn+8 GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgAmInJ4Ga8S6ME 2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zANhenIUwYCKNPq 5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP5XnI cMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+NV8VTaTrF nHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLx BiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIB tDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxp YXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlh c29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0 dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNV HQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvU GHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg36XYkNS7Ot0A1UqdjGFrtnII SI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiXg5HMTdOl6mlDbJaTIEGa gdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ6fEAOLW1j2IjJ0cy DI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+kXDJGbOaK42H2 ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5tTQYQeO7 QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk9OAijkG6n5oE GOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh +lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz 9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYID FDCCAxACAQEwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwg SW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjANBglghkgBZQMEAgEFAKCCAZcw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwOTI3MTQwMjAx WjAvBgkqhkiG9w0BCQQxIgQgnYnZ8ovLu+Ki5qLpiezOjwK19CCWQ47gI3bN3WBeXX0wXQYJ KwYBBAGCNxAEMVAwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjBfBgsqhkiG9w0BCRACCzFQ oE4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1 YWwgQ0EgdjICEAl22IQ7PgXeg0+yzE5sfsYwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQME ASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQBd9Go5swhr FM+LFAtFwpEuTKts0ZuSzj22IGAn1u09QvrDoosZGF3KRDCvNFyaa0uARQQVehfd3AyeF1eH fT3LvUNJ3qEsFQImp5/D3Sf+VArdu/ueRgJCDlZXq66hZ1oFl1nP+lF2MX/6m8JcyWQiuhu9 YYVnWaD2va/FxW6VUpWjUFy1r9GiMiWm7kLLIz9EoB1+PFSKwVdamZfA7lCyZoAtDU8NZJP2 e0Y4YMKkz6CbLJ/9MPgkkRAe3FpTNxNl/Tk6xxN3BSAd3Iym8wRXphygFujlF+T2e2287hZ5 OOPd3NGzXPUrxArLCx2tRcp0taEt5ZZ1Oj7B667SFpngAAAAAAAA --------------ms090006080404020904030500-- From nobody Tue Sep 27 07:15:35 2016 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 D2F2712B1F2 for ; Tue, 27 Sep 2016 07:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] 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 CBQ2NvErhL39 for ; Tue, 27 Sep 2016 07:15:31 -0700 (PDT) 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 E26B612B1E1 for ; Tue, 27 Sep 2016 07:15:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 2EDFD621C4; Tue, 27 Sep 2016 10:15:30 -0400 (EDT) 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 fkq-Wzfby8WU; Tue, 27 Sep 2016 10:15:28 -0400 (EDT) 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 492DD621C5; Tue, 27 Sep 2016 10:15:25 -0400 (EDT) To: Miika Komu , hip WG References: <5a42438c-fcb6-d74f-b590-7f310a9d5447@ericsson.com> From: Robert Moskowitz Message-ID: <6b8d5b7c-1eff-a858-5a67-153253c18870@htt-consult.com> Date: Tue, 27 Sep 2016 10:15:24 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <5a42438c-fcb6-d74f-b590-7f310a9d5447@ericsson.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Hipsec] Relaying to non-hip aware servers X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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 Sep 2016 14:15:34 -0000 On 09/27/2016 10:02 AM, Miika Komu wrote: > Hi Robert, > > On 09/27/2016 04:46 PM, Robert Moskowitz wrote: >> Where did we describe connections from a mobile hip-aware host to a >> legacy non-HIP 'stable' server. >> >> I thought it was HIPBONE (as it is not what HIP nat traversal is about), >> but I am not seeing this function there. >> >> Basically, the Mobile host has its HIP SA with a relay that decapsulates >> the ESP traffic onto legacy Internet. >> >> This can cause some nasty routing scenarios unless the HIP host can >> treat a group of relays as multihome interfaces or the like and use the >> best relay for any connection. Which would drive TCP/UDP crazy though? >> >> I recall through the window, darkly, that we had these discussions. But >> my search foo is weak and I am not finding them. > > proxy HIP: proxy. like I said weak search foo.... thanks > > https://tools.ietf.org/html/draft-melen-hip-proxy-02 > https://tools.ietf.org/html/draft-irtf-hiprg-proxies-05 > From nobody Wed Sep 28 05:24:24 2016 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 AF29612B10C for ; Wed, 28 Sep 2016 05:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.507 X-Spam-Level: X-Spam-Status: No, score=-6.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=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 qFfcJCy4YHQK for ; Wed, 28 Sep 2016 05:24:19 -0700 (PDT) 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 CEC4812B115 for ; Wed, 28 Sep 2016 05:24:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 094DB62240 for ; Wed, 28 Sep 2016 08:24:18 -0400 (EDT) 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 LDxzyydEHTkR for ; Wed, 28 Sep 2016 08:24:12 -0400 (EDT) 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 5344B62234 for ; Wed, 28 Sep 2016 08:24:12 -0400 (EDT) To: hip WG From: Robert Moskowitz Message-ID: Date: Wed, 28 Sep 2016 08:24:04 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Hipsec] 4 Internet drafts X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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 Sep 2016 12:24:23 -0000 I have just uploaded 4 drafts. One a revision of my earlier Hierarchical HIT draft. With the other 3 you will begin to see where I am going with all this. I request and welcome all comments. I will be a Seoul for extended discussions on this and next steps. There are probably 2 more drafts minimal to put the proposal together. Bob A new version of I-D, draft-moskowitz-hip-based-5gpp-ip-mobility-00.txt has been successfully submitted by Robert Moskowitz and posted to the IETF repository. Name: draft-moskowitz-hip-based-5gpp-ip-mobility Revision: 00 Title: HIP Enabled ID/Loc separation for fast 5GPP IP mobility Document date: 2016-09-27 Group: Individual Submission Pages: 7 URL: https://www.ietf.org/internet-drafts/draft-moskowitz-hip-based-5gpp-ip-mobility-00.txt Status: https://datatracker.ietf.org/doc/draft-moskowitz-hip-based-5gpp-ip-mobility/ Htmlized: https://tools.ietf.org/html/draft-moskowitz-hip-based-5gpp-ip-mobility-00 Abstract: HIP [RFC7401] stands alone in providing a secure Endpoint ID for decoupling the Internetworking and Transport protocol layers. The addition of a secure rendezvous service to facilitate mobility will form the cornerstones for this 5GPP mobility technology. This document will describe complete mobility environment and the additional components needed. ====================================================================== A new version of I-D, draft-moskowitz-hierarchical-hip-01.txt has been successfully submitted by Robert Moskowitz and posted to the IETF repository. Name: draft-moskowitz-hierarchical-hip Revision: 01 Title: Hierarchical HITs for HIPv2 Document date: 2016-09-26 Group: Individual Submission Pages: 14 URL: https://www.ietf.org/internet-drafts/draft-moskowitz-hierarchical-hip-01.txt Status: https://datatracker.ietf.org/doc/draft-moskowitz-hierarchical-hip/ Htmlized: https://tools.ietf.org/html/draft-moskowitz-hierarchical-hip-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-moskowitz-hierarchical-hip-01 Abstract: This document describes using a hierarchical HIT to facilitate large deployments in mobile networks. ====================================================================== A new version of I-D, draft-moskowitz-hip-fast-mobility-00.txt has been successfully submitted by Robert Moskowitz and posted to the IETF repository. Name: draft-moskowitz-hip-fast-mobility Revision: 00 Title: Fast HIP Host Mobility Document date: 2016-09-26 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/internet-drafts/draft-moskowitz-hip-fast-mobility-00.txt Status: https://datatracker.ietf.org/doc/draft-moskowitz-hip-fast-mobility/ Htmlized: https://tools.ietf.org/html/draft-moskowitz-hip-fast-mobility-00 Abstract: This document describes mobility scenarios and how to aggressively support them in HIP. The goal is minimum lag in the mobility event. ====================================================================== A new version of I-D, draft-moskowitz-hip-ipnhip-00.txt has been successfully submitted by Robert Moskowitz and posted to the IETF repository. Name: draft-moskowitz-hip-ipnhip Revision: 00 Title: Encapsulation of IP within IP managed by HIP Document date: 2016-09-28 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/internet-drafts/draft-moskowitz-hip-ipnhip-00.txt Status: https://datatracker.ietf.org/doc/draft-moskowitz-hip-ipnhip/ Htmlized: https://tools.ietf.org/html/draft-moskowitz-hip-ipnhip-00 Abstract: This document defines how to encapsulate IP within IP when the tunnel is managed with HIPv2 [RFC7401]. The goal is reduced header size and improved security over IPnIP [RFC2003] and RFC2004 [RFC2004].