Re: [lisp] draft-ermagan-lisp-nat-traversal question

Albert López <alopez@ac.upc.edu> Tue, 21 November 2017 14:49 UTC

Return-Path: <alopez@ac.upc.edu>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDB9C12949A for <lisp@ietfa.amsl.com>; Tue, 21 Nov 2017 06:49:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 wSXfFnv1JnBa for <lisp@ietfa.amsl.com>; Tue, 21 Nov 2017 06:49:44 -0800 (PST)
Received: from roura.ac.upc.es (roura.ac.upc.edu [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 3634B1294A1 for <lisp@ietf.org>; Tue, 21 Nov 2017 06:49:43 -0800 (PST)
Received: from correu-1.ac.upc.es (correu-1.ac.upc.es [147.83.30.91]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id vALEna2n005744; Tue, 21 Nov 2017 15:49:36 +0100
Received: from [147.83.35.39] (sirius.ac.upc.es [147.83.35.39]) by correu-1.ac.upc.es (Postfix) with ESMTPSA id 9B47E1985; Tue, 21 Nov 2017 15:49:31 +0100 (CET)
To: "Vina Ermagan (vermagan)" <vermagan@cisco.com>, Dino Farinacci <farinacci@gmail.com>
Cc: "lisp@ietf.org" <lisp@ietf.org>
References: <f574957a-e4fd-6984-99ef-185cd2c1bc15@ac.upc.edu> <B5138540-69F2-482B-AAC5-544BB2BD69D8@gmail.com> <2b946dce-7c33-5317-8f3b-9ffd2568381e@ac.upc.edu> <D628A765.D9526%vermagan@cisco.com>
From: Albert López <alopez@ac.upc.edu>
Message-ID: <a0da2cea-4da5-cb78-9d7f-d52d2e4f2bbf@ac.upc.edu>
Date: Tue, 21 Nov 2017 15:49:31 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <D628A765.D9526%vermagan@cisco.com>
Content-Type: multipart/alternative; boundary="------------9A6C65A5C08596A015DA1165"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/P5VcawzFa4cbCUnqDPMRQr30WwU>
Subject: Re: [lisp] draft-ermagan-lisp-nat-traversal question
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Nov 2017 14:49:48 -0000

Hi all,

I have some more questions regarding this draft.

* 3.1.  LISP NAT Traversal Overview

/   The ETR encapsulates the Map-Register message in a LISP ECM header 
destined//
//   to the RTR's RLOC.  The RTR strips the LISP ECM header, re-originates//
//   the Map-Register message, and sends it to the Map-Server.

/At this point, it seems to me that the RTR sends a simple Map Register 
(like it does
  it previous version of the draft) instead of an Encap Map Register

* 4.3.  LISP Map-Register Message

/The 6th bit in the ECM LISP header is allocated as the "R"//
//   bit.  The R bit indicates that the encapsulated Map-Register is to be//
//   processed by an RTR.  The 7th bit in the ECM header is allocated as//
//   the "N" bit.

/I suppose that are the 6th and 7th bit after the Type field otherwise 
it overlaps
with other flag bits. Maybe it could be indicated in the draft.


* /4.4.  LISP Map-Notify//
//
//   MS-RTR Authentication Data: The message digest used from the output//
//   of the Message Authentication Code (MAC) algorithm. //*The entire 
Map-*//*
*//*   Notify payload*//is authenticated./

Do we also refer to  the inner IP and UDP header with entire Map Notify 
payload?


Why the RTR is changing the address of the inner IP header of ECM? Is 
not possible to use
the external IP header to obtain required information like the RTR 
address in the MS ?

     1- Encap Map Reg -> int src ip:  From ETR local locator to RTR address
     2- Data Map Notify -> int dst IP:  From RTR address to ETR local 
locator /
/
Best regards

Albert López

El 08/11/17 a les 21:33, Vina Ermagan (vermagan) ha escrit:
> Hi Albert,
>
> ³Map Register TTL² in the referenced paragraph is indeed the TTL for which
> a Map Register stays valid in a Map Server. Suggested time in the RFC for
> periodic Map Registers is 1 minute. And MS will expire the registration
> after 3 minutes if it does not receive a renewal. So this TTL in RTR
> should be set no larger than 3 minutes, and no smaller than 1 minute.
> Unfortunately NAPT devices don¹t have a standard TTL for expiring their
> address associations; some use 2 minutes as the threshold. So the 3 minute
> recommendation for expiring a Map Register seems suitable here.
>
> Hope this clarifies it.
>
> Best,
> Vina
>
>
> On 11/6/17, 1:01 AM, "lisp on behalf of Albert López"
> <lisp-bounces@ietf.org on behalf of alopez@ac.upc.edu> wrote:
>
>> In that case, I think that It would be better if the validation time /
>> expiration time of the locator associated with the ECM-ed Map Register &
>> ECM-ed Map Notify is related with the periodic time of sending ECM-ed
>> Map Registers.
>> Usually a hole in the nat box is less than two minutes so we send
>> periodic ECM Mag register to maintain this hole opened apart from
>> maintaining the status in the Map Server. If we use the TTL of the
>> record to maintain an entry in the Map Cacahe of the RTR, it is possible
>> we maintain an entry which is no longer valid or send packets to an
>> invalid rloc.  What do you think?
>>
>> Regards
>>
>> Albert
>>
>> El 03/11/17 a les 18:38, Dino Farinacci ha escrit:
>>> The TTL in the Map-Register is the TTL returned in Map-Replies. So it
>>> is the expiry time for a map-cache entry. Note it is the ³Record TTL² in
>>> the EID-record which both appear in Map-Register and Map-Reply messages.
>>>
>>> Dino
>>>
>>>> On Nov 3, 2017, at 1:35 AM, Albert López <alopez@ac.upc.edu> wrote:
>>>>
>>>> Dear all,
>>>>
>>>> In section 5.3 of the draft  draft-ermagan-lisp-nat-traversal which
>>>> describe the RTR processing, it says that when the RTR receive and
>>>> ECM-ed Map Notify, once it is validated, it changes the state of the
>>>> associated map-cache entry to verified for the duration of the Map
>>>> Register TTL.  What does it mean by Map Register TTL?  it means the TTL
>>>> of the record of the Map Register or it is the same concept of the Map
>>>> Register TTL of the Map Server which is 3 minutes? If I understand
>>>> correctly, if we don't receive more Encap Map Register / Map Notify to
>>>> renew this verified period, the map-cache entry of the RTR expires, at
>>>> least the locator of the map-cache entry associated with the Encap Map
>>>> register.
>>>>
>>>>     "Once the authenticity of the message is verified,
>>>>     RTR can confirm that the Map-Register message for the ETR with the
>>>>     matching xTR-ID was accepted by the Map-Server.  At this point the
>>>>     RTR can change the state of the associated map-cache entry to
>>>>     verified for the duration of the Map-Register TTL"
>>>>
>>>> Thank you in advance.
>>>>
>>>> Albert López
>>>>
>>>>
>>>> _______________________________________________
>>>> lisp mailing list
>>>> lisp@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/lisp
>> _______________________________________________
>> lisp mailing list
>> lisp@ietf.org
>> https://www.ietf.org/mailman/listinfo/lisp