Re: [lisp] Mirja Kühlewind's Discuss on draft-ietf-lisp-rfc6830bis-16: (with DISCUSS and COMMENT)

Dino Farinacci <> Tue, 11 September 2018 16:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 349E7130DE3; Tue, 11 Sep 2018 09:46:04 -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 KcpYk8ExgCfg; Tue, 11 Sep 2018 09:46:01 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8A85B128B14; Tue, 11 Sep 2018 09:46:01 -0700 (PDT)
Received: by with SMTP id x26-v6so12543419pge.12; Tue, 11 Sep 2018 09:46:01 -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=xFH0nvAKF7TpMkuMhgANvpCNDge+LZDc9z2JArJ31eQ=; b=jrk5M+HnBdYPe2lUP8zOourCyCMDQ+aipXj4eyP4CUmJ71jAG9ZV8XnoXybgrFfatY dQ/mUVcMKRCeTTmuzIhbAKrc3CLzApF9z/Nep5VEqHCEAQMip6qP9z+MXkwnqIQcjdJr ZQhuc9cr8T0bjyn0Dtul7D8UcDfCXKQLLcNfKP5zWWwBbNnD+jpX3VGFxlO4lcbH8JNC 35FmL/ttlD+G7HjEfqpObysRlYvQiwurWkIdJRvoo9FGKkL3zV0wEWZ7e7QEmRAF4qfB jOARWiSZUM5B2HROp22KTpI9YPZDCGsa12LPvLu/KWMoD6b9VeJWzABQWLxInBh3xjM9 fW8w==
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=xFH0nvAKF7TpMkuMhgANvpCNDge+LZDc9z2JArJ31eQ=; b=rSW4o/9hXbY8Nm4QmU01omn12ePFn67VCWFqBrBCMwJyNsW0KUwBXuFIGkNiEJ1YBN D9SC9NGvMF0UCg84aZtSutMxb1Yb9L9KR5HF8TmHB4nLMMwtYGBvC0F5+LPFfsZqjBky d5tP1IDTEP2oCuEd3/JdOBJigLA7expSrXc0oncI/SSTDHckhNI5iNgtjRq0wt4fONbu AKPuZ4+xgWkgNWm/NNLDIvspOOPQV2SsNQSOCHWkCjui1pS6XXvuvwbvTI77LnGYWKcA CNyBwFbUygEr0cWpMMH4iSn/Z93+zGxrcYXuNGqvPkcM67PwXeXu0fNQTPuVV63hNR9K nYkw==
X-Gm-Message-State: APzg51BskRvlcTKQKPz3+96ylJFqtexs13sH2DvVpmtpkXDLb/V3Zm2u kn/YzAzGzydIJDpo0XmySxib3xxr
X-Google-Smtp-Source: ANB0VdbgkgczhM7yoMObSQpVLRCT5ZgPH8iabVpyd1topYzF3tvbWQ8uNvNFjFfPg9qR2Qjd30kV4w==
X-Received: by 2002:aa7:83cd:: with SMTP id j13-v6mr30399494pfn.236.1536684361066; Tue, 11 Sep 2018 09:46:01 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id w5-v6sm23592931pfn.44.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 09:46:00 -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: Tue, 11 Sep 2018 09:45:59 -0700
Cc: The IESG <>,, Luigi Iannone <>,, " list" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: "Mirja Kuehlewind (IETF)" <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [lisp] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lisp-rfc6830bis-16=3A_=28with_DISCUSS_and_COMMENT=29?=
X-Mailman-Version: 2.1.29
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: Tue, 11 Sep 2018 16:46:04 -0000

>> Well it doesn’t have to be. I am a bit hesitant to just point to another long complicated RFC. This text has gone through review for quite a long time and many ECN experts decided we should write it this way. And this text did go through IESG review when RFC6830 was made experimental RFC.
> Procedere explained in RFC6040 are actually not that complicated. It’s mainly the table provided in section 3.2. Please have a look at the draft. However, I disagree that it „negative“ to point for this part to another RFC. This is not a unique problem, that’s why we have RFC6040 and all approaches that face this problem should point to RFC6040 and implement the same strategy.

I am just worried it will be ignored because there are implementations out there that do what they already do. If we want to suggest to consider the procedures in RFC6040, I am okay with that, but you need to provide the wording because I certainly don’t want it too strong.

>>> 3) Sec 7.1. only takes about ICMPv6 "Packet Too Big" packets while
>>> "IPv4-encapsulated packet with the DF bit set to 1" should be addressed as well.
>> This is discussed in length. I don’t know how you could have missed this.
> I didn't miss that discussion but the text got fixed incorrectly because it doesn’t not address IPv4 through the whole text. Please have a look and fix that as well. I think this is mainly an editorial issue but and important one to fix.

I am sorry. I don’t know what you think is wrong. Please point to the text specifically.

>>> 6) And now the more-discussion-needed point:
>>> So my underlying concern is the same as brought up by the TSV-ART review that
>>> lisp information are not end-to-end integrity protected or authenticated.
>> I would like you to be more specific. Beacuse there is a lot of security in the protocol and we believe the current drafts, in their entirety, inicdate so.
> I was thinking about the option to add an authenticated hash, anyway…

LISP uses lisp-crypto (RFC8061) which uses AEAD.

>>> However, while briefly thinking about how this could be eventually realized, I
>>> noticed that there is actually no mechanism to extend the LISP header in any
>> Right, by design so it is efficient for hardware AND software forwarding. But we do have the LISP-GPE header that can be used for extensions. But that has limited deployment.
>>> way. There is no version, no option and the LISP header seems to have a fixed,
>> We decdied as a working group that the UDP port number would indicate what header follows and therefore what LISP version is used.
> Okay, that needs to be explained in the doc!
> Mirja

The document says that UDP port 4341 is assigned and when so, the LISP header as docmented is used. We shouldn’t just encourage versioning if the philosophy it not to churn often.