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

Miika Komu <miika.komu@ericsson.com> Tue, 21 March 2017 11:14 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 CEE961293F8 for <hipsec@ietfa.amsl.com>; Tue, 21 Mar 2017 04:14:17 -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=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 qza01U2MPaLK for <hipsec@ietfa.amsl.com>; Tue, 21 Mar 2017 04:14:16 -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 ADCC0129482 for <hipsec@ietf.org>; Tue, 21 Mar 2017 04:14:15 -0700 (PDT)
X-AuditID: c1b4fb25-0b71498000002d78-0f-58d10b057935
Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by (Symantec Mail Security) with SMTP id 70.72.11640.50B01D85; Tue, 21 Mar 2017 12:14:13 +0100 (CET)
Received: from [131.160.51.186] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.83) with Microsoft SMTP Server id 14.3.319.2; Tue, 21 Mar 2017 12:14:28 +0100
To: hipsec@ietf.org
References: <alpine.LRH.2.01.1702190718360.26978@hymn03.u.washington.edu>
From: Miika Komu <miika.komu@ericsson.com>
Organization: Ericsson AB
Message-ID: <b3a876c9-4462-e396-33b4-eefc49c66ab6@ericsson.com>
Date: Tue, 21 Mar 2017 13:14:08 +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: <alpine.LRH.2.01.1702190718360.26978@hymn03.u.washington.edu>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUyM2J7oC4r98UIg90LzCymLprM7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujE93uxgLXotXvFn8h7WB8ZpQFyMHh4SAicTfdWFdjFwcQgLr GCXebVjBCOGsYZTYtOYnaxcjJ4ewgJPEnP73jCC2iICoxJQPp5lBmoUEPCVWTtMCCbMJaEms unOdGcTmF5CU2NCwG8zmFbCXeH3oDdgYFgFViQ+3L4LZogIREvOfrmKCqBGUODnzCQuIzSng JXFv91l2kPHMQL0PtpaBhJkF5CW2v50DtVVF4uKx4AmMArOQNM9CaJiFpGEBI/MqRtHi1OKk 3HQjY73Uoszk4uL8PL281JJNjMDQO7jlt+oOxstvHA8xCnAwKvHwFrw7HyHEmlhWXJl7iFGC g1lJhNe170KEEG9KYmVValF+fFFpTmrxIUZpDhYlcV7HfUApgfTEktTs1NSC1CKYLBMHp1QD o67GtsRZ509MOcyXGKUcFjpL7KfQTz1uuW+GgvvOh9prypv+7Jzzyy6V/3ystP+GWzfiJZUf rs11lbn3fuqRqwL/vxot+hq0JP2KBO8UZ42qLVF3JaM/fjkixRwRbjKl8snhyBqhqnndD6ae Tnmp2NItpcFbeGtV7Y2d+RmnD07Q/Gh/aZ7YVCWW4oxEQy3mouJEAEOjmvI5AgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/PDy-CSHreeoSAMg3rt0YmcXfVPc>
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:14:18 -0000

Hi,

a preliminary version here:

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

Not yet on IETF site since I missed the cut-off deadline.

On 02/19/2017 05:18 PM, Tom Henderson wrote:
> Hello, I have read the latest (-17) draft and sent some purely editorial
> comments to Miika.  I had a few non-editorial questions and comments.
>
> 1) In appendix D, it states:
>
>    o  A minimal implementation would conform only to Section 4.7.1 or
>       Section 4.7.2, thus merely tunneling HIP control and data traffic
>       over UDP.  The drawback here is that it works only in the limited
>       cases where the Responder has a public address.
>
> However, in section 5.4, it states:
>
>    Implementations conforming to this specification MUST implement both
>    UDP-ENCAPSULATION and ICE-HIP-UDP modes.
>
> The contradictory text should be resolved.  In my opinion,
> implementations that want to support only the UDP-ENCAPSULATION mode
> (and its restricted set of use cases) should be allowed.  However, I
> don't know what might need to be done to avoid a situation where a
> product claims RFC compliance but only implements one of the two modes.
> It could perhaps be avoided by a statement that states "Implementations
> that choose to only support the UDP-ENCAPSULATION mode should clarify
> this point when any claims of <RFC-to-be> compliance are made."

now it says:

"Implementations conforming to this specification MUST implement UDP-
ENCAPSULATION and SHOULD implement ICE-HIP-UDP modes."

I can also add some other wording if it is really necessary (and common 
in RFC specifications). Btw, while ICE lite is not really the same as 
ICE-HIP-UDP, ICE lite vs full ICE is not really enforced in the 
specification.

> 2) Appendix C states:
>
>    o  The considerations on Diffserv Codepoint markings in ICE are not
>       applicable to HIP since Diffserv is not used in HIP.
>
> Why wouldn't the same issues arise in HIP as in ICE on this matter?
> Should this draft instead copy or reference the RFC 5245 recommendation:
>
>    If the agent is using Diffserv Codepoint markings [RFC2475] in its
>    media packets, it SHOULD apply those same markings to its
>    connectivity checks.
>
> Also, I don't think that the HIP control plane should be excluded from
> using diffserv.

done.

> 3) In section 4.10 (NAT keepalives), it states:
>
>    Both a registered client and relay server SHOULD
>    send a HIP NOTIFY packets to each other every 15 seconds (the so-
>    called Tr value in ICE) unless they have exchange some other traffic
>    over the used UDP ports.
>
> However, I couldn't find an explanation anywhere (also in RFC 5770)
> about how to code this NOTIFY.  Would it make sense to define also a
> "NAT_KEEPALIVE" NOTIFY message type for this purpose?
>
> Once these issues are resolved, I think that the draft would be ready to
> publish.

done.

P.S. The new version of the draft also includes some nits from Alex Elsayed.