Re: [secdir] Secdir last call review of draft-ietf-lisp-rfc6830bis-15

Benjamin Kaduk <> Sun, 26 August 2018 16:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9BFD712785F; Sun, 26 Aug 2018 09:42:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 345xVEdSyqO5; Sun, 26 Aug 2018 09:42:43 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A8111128B14; Sun, 26 Aug 2018 09:42:42 -0700 (PDT)
X-AuditID: 1209190f-2e9ff70000006e88-17-5b82d880cdc1
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 96.81.28296.188D28B5; Sun, 26 Aug 2018 12:42:41 -0400 (EDT)
Received: from (OUTGOING-AUTH-1.MIT.EDU []) by (8.13.8/8.9.2) with ESMTP id w7QGgZGv016191; Sun, 26 Aug 2018 12:42:37 -0400
Received: from ( []) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id w7QGgVP1008674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 26 Aug 2018 12:42:33 -0400
Date: Sun, 26 Aug 2018 11:42:31 -0500
From: Benjamin Kaduk <>
To: Dino Farinacci <>
Cc: Kyle Rose <>,, " list" <>, IETF Discussion Mailing List <>,
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjleLIzCtJLcpLzFFi42IRYrdT12280RRtsGqhokXTlxvsFu27rzFa PNs4n8Vi/YtJbBZTzqpbfFj4kMWBzWPnrLvsHkuW/GTy6Lr4nSmAOYrLJiU1J7MstUjfLoEr Y8ux1IJGnorZG7exNTDe4+xi5OSQEDCROPt5F0sXIxeHkMBiJonfW5YwQTgbGSWWrt7EBlIl JHCVSWLSvnwQm0VAVeLHy0OMIDabgIpEQ/dlZhBbREBD4u773ewgzcwC+xklpv1axQSSEBbw k5i27ydYES/QutfbjrNCDC2XuPT/JiNEXFDi5MwnLCA2s4CWxI1/L4F6OYBsaYnl/zhAwpwC thIvtzSBlYgKKEvs7TvEPoFRYBaS7llIumchdC9gZF7FKJuSW6Wbm5iZU5yarFucnJiXl1qk a6KXm1mil5pSuokRFNSckvw7GOc0eB9iFOBgVOLhbVjUGC3EmlhWXJl7iFGSg0lJlPeRVVO0 EF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHeM5+BynlTEiurUovyYVLSHCxK4rz3asKjhQTSE0tS s1NTC1KLYLIyHBxKErxZ14GGChalpqdWpGXmlCCkmTg4QYbzAA13B6nhLS5IzC3OTIfIn2LU 5fjzfuokZiGWvPy8VClx3pvXgIoEQIoySvPg5oCSkUT2/ppXjOJAbwnz7gEZxQNMZHCTXgEt YQJaMuNVA8iSkkSElFQDI6eIhk7V19VzKnQ+Tl9eqdqx2UIy7/RK62vPjZTZAw1CEnknNl4K e7vnzswp+qa8hwK3PGK9/WBFY+TL6zki694wPptYbSKqtorr1/4d5w86LHrwUdt+RVGehtak 23NqQ/vZAms7lKX/1C3+9iW/NjaELc9rR8kKJ84YvlyP1D+JLp/0rdSPKrEUZyQaajEXFScC AKPauwIhAwAA
Archived-At: <>
Subject: Re: [secdir] Secdir last call review of draft-ietf-lisp-rfc6830bis-15
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 26 Aug 2018 16:42:45 -0000

Kyle, Dino,

Thanks for the review and discussion -- I look forward to seeing where it
ends up.  Just one note, inline...

On Sat, Aug 25, 2018 at 02:40:15PM -0700, Dino Farinacci wrote:
> > Reviewer: Kyle Rose
> > Review result: Has Issues
> > Another question it poses is: how does the Map-Resolver authenticate the
> > Map-Server? Symmetric authentication with the ITR-OTK demonstrates only that
> We plane to add that in draft-farinacci-lisp-ecdsa-auth. Up until now it was the clients of the mapping system that first needed to be authenticated, but the map-servers can do the same. We plan to adding signing Map-Notify messages which is typically an Ack to a signed Map-Register sent by an xTR.
> > the response is associated with the request: it's not immediately clear to me
> > what security guarantees it provides to the ITR. Limiting attacks to on-path
> > attackers, yes. But what about MitM? That class of attacks requires either a
> > pre-shared key (implying a pre-existing trust relationship between a
> We do use pre-shared keys for registering to the mapping system. And you could encrypt messages in both directions using this shared-key. This shared-key was intended for authorization of a particulary (IID, EID) pair to the mapping system, but can be easily for encryption.

If the PSK does get additionally purposed for encryption, please make sure
to use a modern key derivation hierarchy to provide separation between the
authentication and encryption usages.