Re: [lisp] [Tsv-art] Tsvart last call review of draft-ietf-lisp-rfc6830bis-15

Dino Farinacci <> Mon, 27 August 2018 20:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 587A9130E25; Mon, 27 Aug 2018 13:39:39 -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 cbwhd1IvpGA1; Mon, 27 Aug 2018 13:39:37 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BF7DD12D7F8; Mon, 27 Aug 2018 13:39:37 -0700 (PDT)
Received: by with SMTP id h8-v6so121686pgs.4; Mon, 27 Aug 2018 13:39:37 -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=iyPLyTrhnf2AyUr0Em3iTYM7SSDykqAfnXfT8eis+ZU=; b=dqi0klgnHJ6Gyb70vSz7mKrRWN9VdyIbMoCuPJSUEA11EuWxnv07TGI24gnlwjk9GB ADRcfASWGjiHQlsoPWXekdgPo5sf29JFmuSJpaG18b9Y/GN2IKfONePhFPejoCyGJuqO QfiO3qkbNWPpMntE4LHxL3ef2ZUOxhl/LoKRgaew6o26N64U8D6K+VZwfFMbTLChgFAT 9zehhVElVUMJgduB2oR2KSsmVA49QCuOxeXG5hb8pgF4ZW7GfZZyBCBl6OG/UKW638UZ lCrNSeQnpCL29fyhWNR0XHdpwxATbGJCOPeo1pMI4sJZJCuM9m/vZKUVzx+Imf0cdw2S 6m/g==
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=iyPLyTrhnf2AyUr0Em3iTYM7SSDykqAfnXfT8eis+ZU=; b=mQ+ZcOlCuPJvuc1JujXK1Yp8XEEPH70XwvkoPZ8/Ds20YZ02C3s+xF2Mqbo/eSzomC r6wxIRM96zuOq7CzVe1KPAb3mA6YNpB3mABzSy96/qL6uaYSzU6Ju9o3qC+0QW1Yjhzg q1cMXh5OTljxogWtZeNAOBdwDTqRYsuH+r+SqUKBy/YV/VM43cMk+m3qV9gyZqreiWeM b2T6EKcbHULhl6y2Z417LsVrVOAwwErcns5aQ7w4vVGc+SKn/EQgjECZGe6uF8fpIppV DdDvgNLpBLAIFe5YFq4OPdC2SHdSFjPyFiYTeVVkVRGbrQue+40EQW2r+jVo2syDfEsx T03w==
X-Gm-Message-State: APzg51BKmnfLz0+eHqvtIgh+vuEdlFwbVSp0e9MggydQ4nildGyvRzVl +L8/+DLzjl/nih8TTp1fUbA=
X-Google-Smtp-Source: ANB0VdalP/KHD6ZeOwaiEFmsEKN6bs77FNi4/TaYAAt3DoC2OeMSiQZ0YNn4XnG1URhvM0BIg3G+SA==
X-Received: by 2002:a62:fd06:: with SMTP id p6-v6mr15800396pfh.167.1535402377316; Mon, 27 Aug 2018 13:39:37 -0700 (PDT)
Received: from ?IPv6:2603:3024:151c:55f0:c1b3:bc4c:9028:ff3b? ([2603:3024:151c:55f0:c1b3:bc4c:9028:ff3b]) by with ESMTPSA id 87-v6sm169811pfn.103.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Aug 2018 13:39:36 -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: Mon, 27 Aug 2018 13:39:34 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: "Brian Trammell (IETF)" <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [lisp] [Tsv-art] Tsvart last call review of draft-ietf-lisp-rfc6830bis-15
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 27 Aug 2018 20:39:40 -0000

>> Rather than make references, can you say what you think the issue is?
> LISP’s data plane is a UDP tunnel, and as such there are congestion control issues that must be considered. LISP inplementors and deployers using LISP to carry a mix of traffic that is not predominantly 

Could you finish your sentence. 

I am not sure what more we can say. There is an depth discussion about DSCP fields and how to use ECN. Basically copies the inner values to the outer header equiv values.

>>> (2) This is not transport-specific. Reading the document, it struck me that the
>>> design of the protocol has a few inherently unsafe features related to the fact
>>> that its wire image is neither confidentiality- nor integrity-protected. I
>>> think that all of the potential DDoS and traffic focusing attacks I could come
>>> up with in the hour I spent reviewing the document are indeed mentioned in the
>>> security considerations section, but as the security considerations section
>>> does not give any practical mitigation for dataplane overload attacks, it seems
>>> to be saying that RLOC addresses shouldn't be Internet-accessible, which as I
>>> understand it is not the point of LISP. I haven't seen a secdir review on this
>>> document yet, but I'd encourage the authors to do everything it asks.
>> RFC 8061 goes along with RFC6830bis. It addresses data-plane confidentiality.
> I haven’t read 8061 yet, but I probably should before continuing this thread.
> I will say that I’m far less concerned about LISP header confidentiality than I am about LISP header integrity, given the opportunities for on-path meddling and off-path spoofing. If the common solution to both is something like sticking everything on the ITR-ETR path in IPSec then this is less of a concern.

Well RFC8061 does AEAD on the payload. All data *after* the LISP header. The encryption is a more integrated model than IPsec, so we can be more efficient by not using extra IP headers and extra control/key exchange protocols.

>>> nit: Section 7.1. para 7 should note that the ICMPv6 message sent is called
>>> Packet Too Big, not Unreachable/Frag Needed.
>> We used “Packet Too Big” for all ICMP messages including IPv4 and hence we received comments about it on how it should change it to Network Unreachable. I will fix this for IPv6.
> Yeah, this is the one place where i noticed a rough edge on supporting v4 and v6. Thanks.

Fixed. Submitted a new revision a few hours ago.