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
- [lisp] Eric Rescorla's Discuss on draft-ietf-lisp… Eric Rescorla
- Re: [lisp] Eric Rescorla's Discuss on draft-ietf-… Dino Farinacci
- Re: [lisp] Eric Rescorla's Discuss on draft-ietf-… Eric Rescorla
- Re: [lisp] Eric Rescorla's Discuss on draft-ietf-… Joel M. Halpern
- Re: [lisp] Eric Rescorla's Discuss on draft-ietf-… Eric Rescorla
- Re: [lisp] Eric Rescorla's Discuss on draft-ietf-… Joel M. Halpern
- Re: [lisp] Eric Rescorla's Discuss on draft-ietf-… Eric Rescorla
- Re: [lisp] Eric Rescorla's Discuss on draft-ietf-… Joel M. Halpern
- Re: [lisp] Eric Rescorla's Discuss on draft-ietf-… Eric Rescorla
- Re: [lisp] Eric Rescorla's Discuss on draft-ietf-… Dino Farinacci
- Re: [lisp] Eric Rescorla's Discuss on draft-ietf-… Eric Rescorla
- Re: [lisp] Eric Rescorla's Discuss on draft-ietf-… Dino Farinacci
- Re: [lisp] Eric Rescorla's Discuss on draft-ietf-… Eric Rescorla
- Re: [lisp] Eric Rescorla's Discuss on draft-ietf-… Dino Farinacci
- Re: [lisp] Eric Rescorla's Discuss on draft-ietf-… Benjamin Kaduk