Re: [Hipsec] Eric Rescorla's No Objection on draft-ietf-hip-rfc4423-bis-19: (with COMMENT)

Miika Komu <miika.komu@ericsson.com> Tue, 08 January 2019 15:49 UTC

Return-Path: <miika.komu@ericsson.com>
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 79724130EAE for <hipsec@ietfa.amsl.com>; Tue, 8 Jan 2019 07:49:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.365
X-Spam-Level:
X-Spam-Status: No, score=-4.365 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=RuuXI0hq; dkim=pass (1024-bit key) header.d=ericsson.com header.b=UOtrY41k
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 Svrop493kLeq for <hipsec@ietfa.amsl.com>; Tue, 8 Jan 2019 07:48:58 -0800 (PST)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECD03130EA1 for <hipsec@ietf.org>; Tue, 8 Jan 2019 07:48:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1546962536; x=1549554536; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=gHaCWuP9dl51kmFA+D2lwbX55FW1DVrYDdzLvL12QjM=; b=RuuXI0hq8AO4inTGVgZHDJNh+88lpEY75+CzFji52JClKAyIdtPKuQW3fZaIsHc9 w2JicuPA67cIAUgY5pn3Bpn5RCxdAflCqqcNAp8llOMnFBfIv+lIrQwsw65vBKmt 6PRnecNKhsfePJX9aJZFvozC0LWm8vPP7MZbggXXzFA=;
X-AuditID: c1b4fb3a-167ff7000000672c-d6-5c34c668fad6
Received: from ESESSMB502.ericsson.se (Unknown_Domain [153.88.183.120]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 62.E5.26412.866C43C5; Tue, 8 Jan 2019 16:48:56 +0100 (CET)
Received: from ESESSMR506.ericsson.se (153.88.183.128) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 8 Jan 2019 16:48:55 +0100
Received: from ESESBMB501.ericsson.se (153.88.183.168) by ESESSMR506.ericsson.se (153.88.183.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 8 Jan 2019 16:48:55 +0100
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB501.ericsson.se (153.88.183.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Tue, 8 Jan 2019 16:48:55 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gHaCWuP9dl51kmFA+D2lwbX55FW1DVrYDdzLvL12QjM=; b=UOtrY41kA7EIkjU2tBl2zuFf0XsEz2AzRNueNorUYkIgojaTng1VDx01NzBxXvjTwpoMEOxNB3jf6UPm5G1P0420IaZ4IO/fsHCM5JciYi3Xui5ifWIQ0RcYAwu9X5IILanPtyBWx9b1eLQnY+Z/t3S2O176w/2WO1S0H8sSrHQ=
Received: from VI1PR0701MB2957.eurprd07.prod.outlook.com (10.173.72.135) by VI1PR0701MB2288.eurprd07.prod.outlook.com (10.169.137.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1516.4; Tue, 8 Jan 2019 15:48:54 +0000
Received: from VI1PR0701MB2957.eurprd07.prod.outlook.com ([fe80::116c:b456:232b:a2ea]) by VI1PR0701MB2957.eurprd07.prod.outlook.com ([fe80::116c:b456:232b:a2ea%3]) with mapi id 15.20.1516.010; Tue, 8 Jan 2019 15:48:54 +0000
From: Miika Komu <miika.komu@ericsson.com>
To: Eric Rescorla <ekr@rtfm.com>, "mkomu@kapsi.fi" <mkomu@kapsi.fi>
CC: IESG <iesg@ietf.org>, "hipsec@ietf.org" <hipsec@ietf.org>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>, "draft-ietf-hip-rfc4423-bis@ietf.org" <draft-ietf-hip-rfc4423-bis@ietf.org>, "hip-chairs@ietf.org" <hip-chairs@ietf.org>
Thread-Topic: Eric Rescorla's No Objection on draft-ietf-hip-rfc4423-bis-19: (with COMMENT)
Thread-Index: AQHT5YLxe6LepMqB0kKL89VZqk/vXKVaTjGAgAGJ8ICASzAnAA==
Date: Tue, 08 Jan 2019 15:48:54 +0000
Message-ID: <d68e3ce9-4758-e40e-5859-7e0805902e4c@ericsson.com>
References: <152564286489.26793.2457846656783140871.idtracker@ietfa.amsl.com> <70e4c94f-0097-0b13-140c-db0a5732ab67@kapsi.fi> <CABcZeBPUvZW0qa5X+SGzAaDgJhArw5Q3NSnSj6cYhBce4cnzqw@mail.gmail.com>
In-Reply-To: <CABcZeBPUvZW0qa5X+SGzAaDgJhArw5Q3NSnSj6cYhBce4cnzqw@mail.gmail.com>
Accept-Language: fi-FI, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: HE1PR09CA0085.eurprd09.prod.outlook.com (2603:10a6:7:3d::29) To VI1PR0701MB2957.eurprd07.prod.outlook.com (2603:10a6:800:87::7)
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [89.166.49.243]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2288; 6:/i4rN9b5OB4JAY1jrSukU+1a/hicjnAql8vF7+wpy6lSH6XAyzPObnUGsUCWq7ihkKNqSjIjTskSfcCh3hSBZA+AdL3THD3HMQwZu4FwW/dOS7C0202Q1UAucuxleoS018+3MEr42rlXkc0Y0Je2E8NnjmxOp9h0Ip9MIliEij1xGjIp7092o7uneLUt9ACIKG5DU6zB46Lt9Ayn0mGDmSj6Mz6q9BFIA4JiQrVrsR0pWpCPCbiAzeOV1X5k/G5QRzPDwOVAWyrg9QCXG1gWlECM1pF96Iwpi42FY/o3XIeYHN+Yd7Y1gpR8A+xcSzPg2cnPa24sUUzndB2HcmtyAMoCGy0tqDot4PHo62cn8qD/43K23HbpI5u7vwGg72LLAyptLr94yNZRDxepI/XCPlMYm8aZQzee84KJlBysviTy20FOtmy52YAjv+a51nMAjdqnrd44v3kqd9Z936qiUw==; 5:gmTPdFzLVsUBteXWzW25ZJqKcTBHzXu6xGuaBHd8KZ2od/MgKULoCu0TFcKGU/Noya13fsTKZWrlZpCC49ldkfdCrlCGf/f6XQduQNnWfDXJVg96vYObN5WT6BHpWf1C/RRLUBirwEazFlWTD/FCGTRrNO83Ko9gGDG0C+DgSDg/HrNl4W5L4EoR4qL8nUodafj8J87h+vW2bJvGD7kYGw==; 7:OqH45YiYTBSmrdkflnlc1xKiL66EfIDuKxryJwDBKAEZAjaRrbYQ0XBdF+vV3zQ/koMOiOgcs4VWM80AVyFVOJG87cUIztwbvU01Dcol9IalWOYbIPx2OWUD1FjYCjw+P/tj9rRD10Tfbji6G/MjjA==
x-ms-office365-filtering-correlation-id: 80a8878e-d1ad-4a16-06ce-08d67580cae7
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(2017052603328)(7153060)(7193020); SRVR:VI1PR0701MB2288;
x-ms-traffictypediagnostic: VI1PR0701MB2288:
x-microsoft-antispam-prvs: <VI1PR0701MB2288441D737A6BA5988F953DFC8A0@VI1PR0701MB2288.eurprd07.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(908002)(999002)(5005026)(6040522)(8220060)(2401047)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231475)(944501520)(52105112)(6041310)(20161123562045)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:VI1PR0701MB2288; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2288;
x-forefront-prvs: 0911D5CE78
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(136003)(39860400002)(396003)(366004)(376002)(199004)(189003)(97736004)(2616005)(229853002)(31686004)(11346002)(99286004)(476003)(14454004)(8676002)(81156014)(81166006)(316002)(446003)(2906002)(256004)(486006)(6346003)(186003)(478600001)(26005)(66066001)(14444005)(52116002)(44832011)(966005)(106356001)(105586002)(8936002)(386003)(7736002)(102836004)(305945005)(86362001)(6436002)(36756003)(6512007)(76176011)(53546011)(6506007)(71200400001)(71190400001)(6116002)(3846002)(31696002)(4326008)(6486002)(6246003)(54906003)(561944003)(110136005)(5660300001)(25786009)(53936002)(6306002)(68736007)(2501003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2288; H:VI1PR0701MB2957.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=miika.komu@ericsson.com;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: pHIUj8xKd7zSKbma8dSRxlyQg9Y42gsXcAzilPnvn+4H3nXjV2InsJOZdTUAM3PodchEizoNYt2zWOpwEUN4mr1v465gJTac9+iNTXiA/GRhyg2F2329H4LkjxB2afprfSmT4yxoNj53o0bbsB+oWoHL6q4TLxZsWkNtEOcO/Os8RWipAFqDvAM24rLOUFYp6A0OHs+Pc4sEr/BrXmb/L7c+l88He4Uo5elelSxBO5dtVlNMoaOrpvl/z3xUu8JDoo5ezBPoPi9d5bYI938CxOqyIy/gLvKFHFTFGS5Kxzt7YCob0lq82FrF9T0fmV67
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <78522C80A2353B4A8BF81E270E28F4EC@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 80a8878e-d1ad-4a16-06ce-08d67580cae7
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2019 15:48:53.5952 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2288
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02SfyzUYRzH99zzvbsv6/I4zGdizY3ERHTL1STqn/uDlvxTXKtbvsO4Y/fF 6C81tXYKEYXWUZooOxRRnc3tXKqRXaTFMb9KS0zFZnHr7r60/nu9P+/383me9/bQWPyE70Nn qHMZjVqZJRG4UjWnnxfsSzdLFftvzFMyq+meUPbo+5BQZrqiFcqq7ldi2Z2Nm1g2WjrLjxXI GxvXeXLL0AaWV85exSdxsmt0KpOVkc9owmPOu6Z/mV7HOXNJBYs/+/hFaDhRi1xoIFLQGUqE WuRKi4kJwepy05ZYRfCufkjwT+gfd/A48YAHFQvdfIegSDmGl5X1W7FqHgwuDSNOzCMYLO0U OK4RkBBomRjDDvYkx0F/rRI7Qpj8QjD7ts4Z8iAKWCvrEHChs2CcMVNaRNv5GJQOhDvGFAmA j9YB5x4ROQo9NhNysJiYEVjakh3sQhKht6vBuQYRP2h+anPmMfGGz3M6HlebQOOr95hjL/g2 a+NzXI2gqvkQx6EwODaHOPa3F5veOusHFl2JsySQYiHcfd0r4IwEmDLUUZxhQdDaXyTc3lS8 XMN3lAGSDW3tgVxmFEObbRKVowO1/z2w1h7DJBj0L8K5sRxWdIMUx/5wq2RaWOvs7w5vauao esRvQV4sw7KqtMjIMEaTcYFls9Vhaia3A9n/UN+zP4e7Ud/XOCMiNJLsEG0YpAoxX5nPFqqM CGgs8RTp8+wjUaqy8CKjyT6nyctiWCPaRVMSb9GG2F0hJmnKXCaTYXIYzbbLo118ilB0m8r6 MDNe78cb6zw1EhA1uffgB8XSwu+gFGv/J1/pTIH3np7+H5urlvzdUa0qX99Ydi0iWOw2Fb8z UDu+6F+w2dikXD0Tx44YUtjuxDJGNx596fpwQ+GR0Nsn2usnpNLsrpgEozm44rLKjSSveCe1 h6JWUZAHKQ+eNkz0LkooNl0ZEYI1rPIvt/MYSD8DAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/NjUn_qKEBwMTNUwR4Qvm-Uy9bTw>
Subject: Re: [Hipsec] Eric Rescorla's No Objection on draft-ietf-hip-rfc4423-bis-19: (with COMMENT)
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hipsec/>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Jan 2019 15:49:02 -0000

Hi Eric,

(some other questions still remain to be discussed besides the second 
preimage collision issue)

On 11/21/18 21:37, Eric Rescorla wrote:
> 
> 
> On Tue, Nov 20, 2018 at 12:07 PM Miika Komu <mkomu@kapsi.fi 
> <mailto:mkomu@kapsi.fi>> wrote:
> 
>     Hi Eric,
> 
>     On 5/7/18 00:41, Eric Rescorla wrote:
>      > Eric Rescorla has entered the following ballot position for
>      > draft-ietf-hip-rfc4423-bis-19: 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-rfc4423-bis/
>      >
>      >
>      >
>      >
>     ----------------------------------------------------------------------
>      > COMMENT:
>      >
>     ----------------------------------------------------------------------
>      >
>      > Rich version of this review at:
>      > https://mozphab-ietf.devsvcdev.mozaws.net/D3709
>      >
>      >
>      > Maybe I'm missing something important, but I don't see in this
>      > document how you go from a HI (or HIT) to the corresponding IP
>      > locator. That seems pretty critical to making this work. Can you
>     point
>      > me in the right direction?
> 
>     (I interpret "right" direction here as how to implement this in
>     practice; please let me know if you were asking for something else)
> 
>     Existing applications can utilize LSIs or HITs, for instance, via
>     /etc/hosts in Linux or if the developer/user uses them directly.
>     Mappings can be configured manually. A better way is to use ,e.g., DNS
>     to store the FQDN, HIs, IP address mappings:
> 
>     https://tools.ietf.org/html/rfc8005
> 
>     An application can receive LSIs or HITs from DNS queries when a HI
>     record exists for a host. This can be implemented  in the local
>     resolver
>     library (e.g. glibc in Linux) supports it and sends the HI-to-IP
>     address
>     mapping to the local HIP daemon. As an alternative implementation
>     technique, dynamic relinking of applications (i.e., LD_PRELOAD in
>     Linux):
> 
>     https://tools.ietf.org/html/rfc6538#section-4.1
> 
>     As yet another alternative, RFC5338 (section 3.2) suggests interposing
>     HIP-aware agents (think about HIP-capable DNS proxy like "dnsmasq" in
>     Linux) that translate HIs into LSIs and HITs to the application and
>     cache the IP address mapping to the HIP daemon:
> 
>     https://tools.ietf.org/html/rfc5338#section-3.2
> 
>     That's all for existing applications. New HIP native applications could
>     use DNS library extensions for getaddrinfo() that would be implemented
>     e.g. in glibc in Linux:
> 
>     https://tools.ietf.org/html/rfc6317
> 
>     All of the mentioned references are mentioned in the draft. Should I
>     add
>     something more compressed along these lines of text or is this too
>     detailed?
> 
> 
> Maybe I'm missing something, but it seems like this is not an 
> interoperable state of affairs.

the WG has been experimenting with different ways implementing things. 
Some things are implementation specific (and hence outside of the focus 
of IETF), but, in general, I would argue the most common approach to "go 
from HI or HIT to the corresponding locator" in a typical Linux system 
in the case of a non-hip-aware application works as follows:

1. client app makes are getaddrinfo() call to look up foo.bar from DNS
2. local dns proxy (e.g. standard dnsmasq in Linux) catches the call
3. dns proxy looks up A, AAAA and HI records for foo.bar
3.a. no HI found: dns proxy operates as normally and returns only A/AAAA 
records to the getaddrinfo() call (via glibc) as it would normally
3.b. HI found:
- dnsmasq sends the HI, HIT and IP address to the local HIP daemon
- dnsmasq returns the HIT to the application

The "generic" approach listed here has been tested and implemented (in 
addition some other implementation alternatives mentioned in the HIP 
experiment report). And three different HIP implementations have been 
tested to interoperate with each other.

If this still does not address you concern, please be more specific?

>      > IMPORTANT
>      > S 11.3.1.
>      >>       avoiding manual configurations. The three components are
>     further
>      >>       described in the HIP experiment report [RFC6538].
>      >>
>      >>       Based on the interviews, Levae et al suggest further
>     directions to
>      >>       facilitate HIP deployment.  Transitioning the HIP
>     specifications to
>      >>       the standards track may help, but other measures could be
>     taken.  As
>      >
>      > This confuses me, because we seem to be looking to advance some
>     of the
>      > HIP specs (e.g., hip-dex) at PS
> 
>     Can you elaborate? And do you mean protocol stack by PS?
> 
> 
> Proposed Standard.

Would the following replacement text fix the issue?

"Transitioning a number of HIP specifications to the standards track in 
IETF has already taken place, but the authors suggest other additional 
measures  based on the interviews."

As an alternative, I can just omit the related paragraph.

>      > S 5.1.
>      >>       At the server side, utilizing DNS is a better alternative
>     than a
>      >>       shared Host Identity to implement load balancing.  A
>     single FQDN
>      >>       entry can be configured to refer to multiple Host
>     Identities.  Each
>      >>       of the FQDN entries can be associatedwith the related
>     locators, or a
>      >>       single shared locator in the case theservers are using
>     the same HIP
>      >>       rendezvous server Section 6.3 or HIP relay server Section 6.4.
>      >
>      > This is becoming a less common practice. How do you handle anycast,
>      > which is the modern practice?
> 
>     I added the following statement:
> 
>     "It is also worth noting that opportunistic mode is also required
> 
> 
>     in practice when anycast IP addresses would be utilized as locators:"
> 
>     Does this address your concern?
> 
>     Btw, opportunistic mode is further described in the following documents:
> 
> 
> I'm not following how this solves the problem. It seems like you're 
> still going to get
> badly suboptimal routing.

Without opportunistic HIP, i.e, by using a destination HIT explicitly, 
the situation is challenging because the HI(T)-IP binding at the client 
would be:

* A HI(T) belonging to server A (returned by DNS look up)
* IP anycast address (would be bound to some server B during routing 
process)

The challenge here is that we want make sure that server A is the same 
server as B. AFAIK, this has not been experimented before. Is this what 
you meant by suboptimal routing?

With opportunistic HIP, the problem is easier because the HI(T)-IP 
binding at the client would be:

* "Wild card" HIT (would be bound to a specific HIT after receiving R1 
packet from the anycast address)
* IP anycast address (would be bound to some server B during routing 
process)

Implementation experience exist on HIP opportunistic mode, but AFAIK 
none in the context of IP anycast.

Would this address your concern (so that I can draft some proposal text)?