Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal-15

Miika Komu <miika.komu@ericsson.com> Tue, 21 March 2017 11:38 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 3D14D129713 for <hipsec@ietfa.amsl.com>; Tue, 21 Mar 2017 04:38:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 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, URIBL_BLOCKED=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 N0w5W_gbPG6Y for <hipsec@ietfa.amsl.com>; Tue, 21 Mar 2017 04:38:45 -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 844891296EF for <hipsec@ietf.org>; Tue, 21 Mar 2017 04:31:02 -0700 (PDT)
X-AuditID: c1b4fb30-3efff7000000628e-93-58d10ef4c121
Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by (Symantec Mail Security) with SMTP id A6.2D.25230.4FE01D85; Tue, 21 Mar 2017 12:31:00 +0100 (CET)
Received: from [131.160.51.186] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.29) with Microsoft SMTP Server id 14.3.319.2; Tue, 21 Mar 2017 12:30:59 +0100
To: Jeff Ahrenholz <j.ahrenholz@temperednetworks.com>, Tom Henderson <tomhend@u.washington.edu>
References: <E4E329A8-6B10-4037-8846-0A6079E102B7@temperednetworks.com> <alpine.LRH.2.01.1703141129520.27473@hymn02.u.washington.edu> <7110ABD9BA66454293AEE83D6D37016617B30AA9@ESESSMB109.ericsson.se> <E3DCEBDF-DCC2-4C22-8DCB-6E0B8C2FE1E2@temperednetworks.com>
CC: HIP <hipsec@ietf.org>
From: Miika Komu <miika.komu@ericsson.com>
Organization: Ericsson AB
Message-ID: <83997d74-43c4-d5f7-69f7-cc3a0309d47f@ericsson.com>
Date: Tue, 21 Mar 2017 13:30:59 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <E3DCEBDF-DCC2-4C22-8DCB-6E0B8C2FE1E2@temperednetworks.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM2K7tO4XvosRBv/emFtMXTSZ2aJ1yk1m i5nnD7I5MHssWfKTyWPrnk4Wj5brMQHMUVw2Kak5mWWpRfp2CVwZf7pbWQp+8VfsWHmCpYHx JE8XIyeHhICJRP+Cd8xdjFwcQgLrGCUm797ICOGsYZTYuOMeE0iVsICTxJz+94wgtohAosTS bTPYQGwhgU4miY8fwOLMApISyzf9AouzCWhJrLpznRnE5geKb2jYDWbzCthLrLi3GWwmi4Cq xL+nz8FsUYEIiflPVzFB1AhKnJz5hAXE5hTwkHi75RETxHwLiZnzz0PtkpfY/nYO0EwOoBtU JC4eC57AKDgLSfcsJB2zkHQsYGRexShanFqclJtuZKSXWpSZXFycn6eXl1qyiREYwAe3/DbY wfjyueMhRgEORiUe3oJ35yOEWBPLiitzDzFKcDArifBmAsNfiDclsbIqtSg/vqg0J7X4EKM0 B4uSOK/jvgsRQgLpiSWp2ampBalFMFkmDk6pBsbkzx+aK1bOutGzytqoUEOnWDA1KGue8HyP WM+vJzK3n5u073s2772omwVbahPPl1pFtG6PY09YfEZN7u3EdZoxyz3snzy12a0z0/6PjnHE /4f7k9jvuBYcnJG/1FCQvU2/KkPd6cJzr5LfDyJvSxw8wv3s36ttl5iTxZS1RA4yNukwRq3+ 5KzEUpyRaKjFXFScCADoc55BXAIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/w1xNQ0w7Wl_utJHjOFdC50PyafY>
Subject: Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal-15
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <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, 21 Mar 2017 11:38:47 -0000

Hi,

On 03/15/2017 04:37 PM, Jeff Ahrenholz wrote:
>>> I might suggest to recommend NOTIFY (and define the keepalive) and state
>>> that other messages including ICMPv6 or UPDATE may be substituted.  If
>>> there is a need for bi-directional connectivity checking, recommend to use
>>> UPDATE;  if there are specific known scenarios where an ICMPv6 is
>>> recommended instead, state those scenarios.
>>
>> Tom, this sounds fine to me. Normal UPDATEs over UDP should be fine, but I
>> think we shouldn't device a new UPDATE mechanism tied to controlled role
>> (sorry for thinking aloud :)
>>
>> Jeff, is this ok for you?
>
> Yes, this sounds good.

I have reflected this discussion now in section 5.3 of the preliminary 
version:

http://mkomu.kapsi.fi/temp/draft-hip-native-nat-traversal-19.txt

    The RECOMMENDED encoding format for keepalives is HIP NOTIFY packets
    as specified in [RFC7401] with Notify message type field set to
    NAT_KEEPALIVE [TBD by IANA: 16384] and with an empty Notification
    data field.  It is worth noting that sending of such a HIP NOTIFY
    message MAY be omitted if the host is actively (or passively) sending
    other traffic to the peer host over the UDP tunnel associate with the
    host association (and IPsec security associations since the same port
    pair is reused) during the Tr period.  For instance, the host MAY
    actively send ICMPv6 requests (or respond with an ICMPv6 response)
    inside the ESP tunnel to test the health of the associated IPsec
    security associations.  Alternatively, the host MAY use UPDATE
    packets as a substitute.  A minimal UPDATE packet would consist of a
    SEQ and ECHO_REQ_SIGN parameters, and a more complex would involve
    rekeying procedures as specified in section 6.8 in [RFC7402].  It is
    worth noting that a host actively sending periodic UPDATE packets to
    a busy server may increase the computational load of the server since
    it has to verify HMACs and signatures in UPDATE messages.