Re: [Tsv-art] Tsvart last call review of draft-ietf-lisp-rfc6833bis-13

Dino Farinacci <> Wed, 12 September 2018 18:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E7E11128D0C; Wed, 12 Sep 2018 11:58:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hYVYMP53NyLm; Wed, 12 Sep 2018 11:58:17 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::62f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 053F4128BAC; Wed, 12 Sep 2018 11:58:17 -0700 (PDT)
Received: by with SMTP id w14-v6so1412519plp.6; Wed, 12 Sep 2018 11:58:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fY5F+6L4zQpnbZ4aXQMFPefD6zYu/8E+ZQhTnHdic5c=; b=eL7EeBnEUd99sLlRKczl6BIVU4OTTM0I0kBFYuPQaPl+xTrm4qHfiu/5hFJFkG0vUn /FbEM247f3Hnur20nftYb8AgDPlK91MO17oUZi1bBdpBmXwedIy9kuLn6dvaSGULo14u bAN6JeQqkGtYqcnTaTjqbmnDYUCEkATDpwdHw0cG0e75dPUZLjvSdX6gt8Nqzn0RnXBO SZJKkjfB3ArI2l/sD+z1lNIRNtV9GZWAJWDcROZWw788PPQ4ZzfsxOk31TsaAnK884fK lyHHgmocPJu/FmU1sWVEjT/ooCJq0TcFiYlVzaeh77Agn+rrfLrHSCV58RGGymlNW6kZ Fi8g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fY5F+6L4zQpnbZ4aXQMFPefD6zYu/8E+ZQhTnHdic5c=; b=dp471+MRb9jzl2OKmtaddL6g3Mg7/PthzcNrG5EHfaihz25+LRFmyfyGK7ARcAYqWV WZM+E0rolM14/Cu/U4w8enqWGXvgf+0aOnF0FWsIjYk27I4HUlQueXx5ps2lBvvkQUXn YsNoB8/TY1Bu7CugsaQO4oV9WQhdqDOggsTakSwFrLB/T3RKLSVdMC7pzCa/iWda69ch HUADLtLkBf1DAUh6iayL//3zmJbE97ieblC/tMHMEt+QopW1NT/6OUfKZ+08wpo7nlzy bsQ5XUq298aO9FUQN6H/s/AkgZ5IMTio9W3tKs2p7dp/wEN7xYWu6ubpbddePjQ+ucwN crjg==
X-Gm-Message-State: APzg51AwVZWW+iSYOa1AHHsqEulwr8IiHf3OGhNMsMAWsVLYEatd/w6x s4zrOBKnmlNINsMIoWuBxmtyuAHd
X-Google-Smtp-Source: ANB0VdZ+TKSXqoShIiX6a5XZBgDSQx2sApwGP4FAtqDYh9xlGk2dRaVISzll/7M8xa2/z6CmG2bmSQ==
X-Received: by 2002:a17:902:4e:: with SMTP id 72-v6mr3790872pla.318.1536778696447; Wed, 12 Sep 2018 11:58:16 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id j22-v6sm2627826pfh.45.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Sep 2018 11:58:15 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Dino Farinacci <>
In-Reply-To: <>
Date: Wed, 12 Sep 2018 11:58:13 -0700
Cc:,, IETF Discussion Mailing List <>, " list" <>, Dino Farinacci <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Colin Perkins <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-lisp-rfc6833bis-13
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 12 Sep 2018 18:58:20 -0000

Thanks for the response, no worries on the slow follow-up. I have cut out some email text.

>> The control-plane does’t try to send MTU size packets. It depends on IP fragmentation/reassembly. But an implementation should know it cannot build a LISP message larger than 65535 bytes.
> I’m not convinced relying on IP fragmentation is a good idea. In the best case, loss of a fragment results in loss of the entire packet, multiplying the effective loss rate. There can also be middleboxes that drop fragments. It would be better if the control place could fragment to MTU size packets (either the actual MTU, or a typical MTU – 1280 octets perhaps).

Well an implementation can certainly build messages of effective MTU length which in most cases is 1280/1500 as well.

>>> The draft does not mention congestion control, but many of the messages are
>>> rate limited. If the intent of the rate limits is that no further congestion
>>> control is needed, then it needs to be made explicit that this is the case, and
>> Yes, that is the intent.
>>> some justification needs to be added to explain why it is safe. This could,
>>> perhaps, take the form of an appendix that analyses the expected control plane
>>> traffic that will flow over a particular path when the protocol is in use, and
>>> demonstrates that this will be low enough rate not to be problematic. In any
>>> case, the draft needs some discussion of how congestion control is addressed.
>> The flow-control is coupled with protecting caches as well as request and register load on map-resolvers and map-servers.
> Sure, but as I mentioned, the draft needs some justification for why this is safe from a congestion control viewpoint.

Can you suggest some simple text that would be sufficient. We have done the analysis in other drafts. Would simply pointing a reference to them be sufficient you think?

>>> It’s unclear what messages need to be retransmitted if they’re lost, and how to
>>> determine if a message is lost (e.g., what is the timeout) and what is the
>>> retransmission schedule. This may be clear to a reader with an in-depth
>>> understanding of LISP, but it would be helpful to provide more explicit
>>> statements about loss detection and retransmission.
>> Map-Registers are sent periodically but the text says that if Map-Notify messages are desired for acknowledgement, the Map-Registers can be transmitted more quickly in the case of loss.
>> Map-Notify messages are obviously acknowledgement by Map-Notify-Ack. That was an added message to RFC6833bis.
>> Map-Requests and Map-Replies are reliability sent for cache population. And the nonce is used for both security purproses and to associated a Map-Reply to a previous sent Map-Request, which is rate-limited.
>> That is pretty much it and I think is explained in pretty much detail. So if you have any specific comments, please provide them. Thanks.
> I perhaps missed it, but didn’t see any discussion of timeouts to detect loss, retransmission frequency, how often retransmissions should be retried before giving up, and what might happen if the retransmissions fail. It’s not sufficient to just say a response is retransmitted, without saying how loss is detected and how retransmissions work.
>>> Many of these issues could perhaps be addressed by running the control plane
>>> over TCP rather than UDP, as is beginning to happen with the DNS. I understand
>>> that this would be a significant late change to the protocol.
>> We have a draft that is considering running the LISP control-plane over TCP/QUIC with the addition of encryped security TLS/QUIC. But not as a replacement to UDP but so an LISP control-plane implementation cam be simplfied.
> I’d encourage this work, with the goal of eventually replacing the UDP-based transport.

Fabio and Marc have been working on it. A draft expired, so I don’t know their status. I agree with you.

>>> The control plane messages contain embedded IP addresses. Does this cause any
>>> issues in the presence of NAT boxes, either by leaking information about
>>> private addressing or by distributing addresses that are unreachable outside
>>> their realm? I noticed there is a mention of an individual draft on LISP NAT
>>> Traversal in Section 5.6, but the embedded addresses are included in more
>>> places.
>> We want private addresses to be inside of LISP control-plane packet payload because there are cases where two xTRs want to determine if they are behind the same NAT, so they can encapsulate directly to each other with those private addresses. For xTRs that are not behind this common NAT, RLOC-probing will tell them they cannot reach the private address.
> That’s fine, there should be some discussion of the privacy implications of exposing those addresses. The WebRTC community has run into considerable issues due to leaking IP addressing information – perhaps this is not a concern for LISP, but the issue should be considered, if only to add a note explaining why it’s not a concern.

This only happens in the NAT-traversal cases. I think it should go in the Security Consideration section of that draft. Not this draft. The standardization effort at this point in time is not including NAT-traversal mechanisms because that draft has not been accepted as a working group draft yet.

> Is there a need to protect the addresses? STUN uses XOR-mapping of embedded IP addresses, because NATs were found that tried to translate embedded IP addresses, outside of the IP header, and broke the protocol. Does LISP need something similar?

No it doesn’t but as we evolved the NAT-traversal draft, we will consider this. Thanks for the heads-up.

Thanks again,