IETF Logo Mail Archive

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

Miika Komu <miika.komu@ericsson.com> Tue, 12 April 2016 14:42 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 552F112E62B for <hipsec@ietfa.amsl.com>; Tue, 12 Apr 2016 07:42:47 -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 vJZfq61hmWDE for <hipsec@ietfa.amsl.com>; Tue, 12 Apr 2016 07:42:46 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8091112E0E9 for <hipsec@ietf.org>; Tue, 12 Apr 2016 07:42:45 -0700 (PDT)
X-AuditID: c1b4fb2d-f79006d000006928-a3-570d096250fa
Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 8A.53.26920.2690D075; Tue, 12 Apr 2016 16:42:43 +0200 (CEST)
Received: from [153.88.190.38] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.41) with Microsoft SMTP Server id 14.3.248.2; Tue, 12 Apr 2016 16:42:18 +0200
To: Ari Keränen <ari.keranen@ericsson.com>
References: <56AB5BCD.7060803@ericsson.com> <56BE47BE.9070406@ericsson.com> <56C32BCC.9070105@ericsson.com> <56CB299E.5030704@ericsson.com> <B26604D1-C537-438B-92CC-B3C05C486F1F@ericsson.com>
From: Miika Komu <miika.komu@ericsson.com>
Organization: Ericsson AB
Message-ID: <570D094A.3070309@ericsson.com>
Date: Tue, 12 Apr 2016 17:42:18 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <B26604D1-C537-438B-92CC-B3C05C486F1F@ericsson.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms090909060202060004010900"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZGbFdXTeZkzfc4MhZKYupiyYzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr4/22H2wF180q3s5/ztjAeMu4i5GTQ0LARGJj7x8mCFtM4sK9 9WxdjFwcQgJHGCWOrD7MBOGsZpR4OXMZO0iVsIC9xMl9t4BsDg4RAWuJ/+9VIWoOM0o8n/AC bBKzgLdE/70bYDabgJbEqjvXmUFsfgFJiQ0Nu8FsXgFtib6jRxhBbBYBVYnOp29YQWxRgQiJ J3NPMkLUCEqcnPmEBcTmFHCQOHToLdhBzALdjBKvur4yghwhJKAicfFY8ARGwVlIWmYhK5sF dpOtxJ25u5khbG2JZQtfQ9nWEjN+HWSDsBUlpnQ/ZIewTSVeH/0I1WsssWzdX7YFjByrGEWL U4uLc9ONjPVSizKTi4vz8/TyUks2MQLj4uCW37o7GFe/djzEKMDBqMTDuyCMJ1yINbGsuDL3 EKMK0JxHG1ZfYJRiycvPS1US4TVh5w0X4k1JrKxKLcqPLyrNSS0+xCjNwaIkzpsT+S9MSCA9 sSQ1OzW1ILUIJsvEwSnVwFh8t0Vh29Rji3fO23XW8E/csbnJpxQNZ+zvbbYs5j7cwHw8Kq/R Pe2q0xx2Xb93m36c8lfoXHJo/zwXbo5bBwJ+7+V53CitoPLA6k7kSiEG5rcl76rtpzi/85qQ yr7z4Nr8Cfpav/gE4qP0OO38t69e5OOcG9ziPJ3hukPVD8MtPRdfPUoQy1RiKc5INNRiLipO BADdby+FkwIAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/hipsec/6GmLHa5kvOk-_Y7pN02rn87sCmg>
Cc: "hipsec@ietf.org" <hipsec@ietf.org>, Jan Melen <jan.melen@ericsson.com>
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: Tue, 12 Apr 2016 14:42:47 -0000

Hi Ari,

On 04/10/2016 09:28 AM, Ari Keränen wrote:
>>> 3.2.  Forwarding Rules and Permissions
>>> > >
>>> > >Permissions are not required for the connectivity checks, but if a
>>> > >relayed address is selected to be used for data, the registered host
>>> > >MUST send an UPDATE message [RFC7401] with a PEER_PERMISSION
>>> > >parameter (see Section 4.2) with the address of the peer and the
>>> > >outbound and inbound SPI values the host is using with this peer.
>> >
>> >PEER_PERMISSION is not a part of RFC5770, why is it introduced here?
> Because that's needed for the data relay in order to have the same functionality as TURN server (c.f. PEER_PERMISSION in TURN RFC), i.e., to allow only explicitly singled peers to connect to the host via relay.

I would also suggest mentioning that PEER_PERMISSION must include a SEQ 
parameter to make sure that we have retransmissions (data relay sends an 
ACK).

v2.23.0 | Report a Bug | By Email