IETF Logo Mail Archive

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

Tom Henderson <tomhend@u.washington.edu> Thu, 30 June 2016 05:45 UTC

Return-Path: <tomhend@u.washington.edu>
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 DA0E112D0E6 for <hipsec@ietfa.amsl.com>; Wed, 29 Jun 2016 22:45:41 -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 z8Z_wBEk58e1 for <hipsec@ietfa.amsl.com>; Wed, 29 Jun 2016 22:45:39 -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 4A30412D0E4 for <hipsec@ietf.org>; Wed, 29 Jun 2016 22:45:38 -0700 (PDT)
Received: from hymn04.u.washington.edu (hymn04.u.washington.edu [140.142.8.72]) by mxout22.s.uw.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u5U5j1Dq025119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <hipsec@ietf.org>; Wed, 29 Jun 2016 22:45:01 -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 u5U5ixl9008801 for <hipsec@ietf.org>; Wed, 29 Jun 2016 22:44:59 -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 u5U5ixqm008798 for <hipsec@ietf.org>; Wed, 29 Jun 2016 22:44:59 -0700
X-Auth-Received: from [73.239.169.224] by hymn04.u.washington.edu via HTTP; Wed, 29 Jun 2016 22:44:59 PDT
Date: Wed, 29 Jun 2016 22:44:59 -0700
From: Tom Henderson <tomhend@u.washington.edu>
To: hipsec@ietf.org
Message-ID: <alpine.LRH.2.01.1606292244590.18841@hymn04.u.washington.edu>
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.6.30.53615
X-PMX-Server: mxout22.s.uw.edu
X-Uwash-Spam: Gauge=X, Probability=10%, Report=' TO_IN_SUBJECT 0.5, 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, 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, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_FROM 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_NEGATE 0, __TO_IN_SUBJECT 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __USER_AGENT 0'
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/1ywFGhLPqBM1_Lu0U01smSuIEoU>
Subject: Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal
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." <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: Thu, 30 Jun 2016 05:45:42 -0000

Hi Miika,

> 
> trying to recap your complete opinion... do you think the 
> UDP-ENCAPSULATION should be MUST and ICE-HIP-UDP SHOULD? And RFC5770 
> MAY? Or do you think the draft should just deprecate RFC5770?

I think that UDP-ENCAPSULATION should be a MUST option because that option is sufficient if the implementation does not have to deal with inbound connections.

ICE-HIP-UDP should be a MUST for implementations that wish to support inbound, and I don't think that RFC5770 solutions for inbound should be suggested as options.  Maybe the use of STUN servers for candidate gathering is fine as a MAY since it doesn't affect HIP interoperability, but otherwise, why suggest to support two parallel implementations for the same function?  

I would be fine with making an allowance for RFC5770 implementations to live on as an option; by this I mean to not overwrite RFC5770 codepoints, etc. but stop short of suggesting it as a MAY in this document.

> 
> Btw, RFC5770 is still a normative reference because we are redundantly 
> explaining some parts of the RFC in the draft.
> 

I still believe that it would be better if this draft did not depend on reading RFC5770.

- Tom

v2.23.0 | Report a Bug | By Email