Re: [lisp] Eric Rescorla's Discuss on draft-ietf-lisp-rfc6833bis-16: (with DISCUSS and COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Fri, 30 August 2019 19:21 UTC

Return-Path: <kaduk@mit.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 664A11201DE; Fri, 30 Aug 2019 12:21:44 -0700 (PDT)
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, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 gWb9juqXvyd4; Fri, 30 Aug 2019 12:21:42 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BAE11200E7; Fri, 30 Aug 2019 12:21:41 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x7UJLaPY004648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 30 Aug 2019 15:21:38 -0400
Date: Fri, 30 Aug 2019 14:21:35 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: draft-ietf-lisp-rfc6833bis@ietf.org
Cc: The IESG <iesg@ietf.org>, ggx@gigix.net, lisp-chairs@ietf.org, lisp@ietf.org
Message-ID: <20190830192135.GN84368@kduck.mit.edu>
References: <153805056019.26512.877252229948689152.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <153805056019.26512.877252229948689152.idtracker@ietfa.amsl.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/O2ycn4CkWsPhFyqrZuB4ZJBNnl0>
Subject: Re: [lisp] Eric Rescorla's Discuss on draft-ietf-lisp-rfc6833bis-16: (with DISCUSS and COMMENT)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 30 Aug 2019 19:21:45 -0000

Since Ekr has cycled off the IESG, I'll try to take over any remaining
points here.  It seems like there may just be the one left, hooray!
The authors very helpfully put together a spreadsheet with all the
comments, discussion about them, and pointers to what changed (if anything)
in the document as a result; thank you for that!

On Thu, Sep 27, 2018 at 05:16:00AM -0700, Eric Rescorla wrote:
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
[trimming heavily]
> 
> S 6.1.
> >      receives an SMR-based Map-Request and the source is not in the
> >      Locator-Set for the stored Map-Cache entry, then the responding Map-
> >      Request MUST be sent with an EID destination to the mapping database
> >      system.  Since the mapping database system is a more secure way to
> >      reach an authoritative ETR, it will deliver the Map-Request to the
> >      authoritative source of the mapping data.
> 
> If I'm understanding this correctly, this allows an ETR to prevent an
> ITR from learning that it is no longer the appropriate ETR for a
> prefix. The way this attack works is that before the topology shift, I
> send SMRs, thus causing Map-Requests, which, because my entry is
> cached, refresh the cache on the ITR past the topology shift. I can
> keep doing this indefinitely. Am I missing something

If I can perhaps try to refine the questionable scenario, suppose there's
an ITR "A" that's trying to direct traffic to EID "B", and "B" is currently
behind an evil ETR "C" but will shortly move behind a different ETR "D".
For simplicity, suppose further that C is the only ETR at that site, so
there is only one RLOC in the legitimate mapping data.  The claim here is
that, if C knows what timeout/configuration A has stored for the mapping
information for B, then C can periodically send SMR to A, and the
procedures in this section cause A to send the solicited Map-Reply not
through the mapping system, but directly to C, since C's RLOC is already in
the Map-Cache entry that A has stored for mapping B's EID.  Since C is evil
and wants to keep looking at B's traffic, C will then reply with a
(now-false, after B has moved away) Map-Reply that "confirms" that C is the
right RLOC for reaching B, and A continues to route traffic for B through
C.  Thus, C is able to "hold on to" traffic to B even after B has moved
away.  If A bothered to send a Map-Request to the mapping system, it would
discover the truth, but I didn't find anything that required that to
happen.  In this simple example, there's only the one ETR, and since D has
never seen traffic from A it may not know to send an SMR to A that would
trigger a request to the mapping system.

I do see in numbered point (2) that "If the source Locator is the only
Locator in the cached Locator-Set, the remote ITR SHOULD send a Map-Request
to the database mapping system just in case the single Locator has changed
and may no longer be reachable to accept the Map-Request", but (a) that's
only a SHOULD, and (b) while this is true in my simplified example above,
it would not be hard to construct more complicated scenarios where it
failed to apply.

I also consider the case that if B is sending return traffic towards
[something behind] A, and that traffic goes through D where D acts as an
ITR, then D will know to send its own SMR to A.  But, (c) nothing requires
D to be an xTR as opposed to just an ETR, and (d) unidirectional flows
would still be affected.

-Ben