[lisp] Stephen Farrell's No Objection on draft-ietf-lisp-threats-14: (with COMMENT)
"Stephen Farrell" <stephen.farrell@cs.tcd.ie> Tue, 19 January 2016 12:07 UTC
Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: lisp@ietf.org
Delivered-To: lisp@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E8F801B2D0E; Tue, 19 Jan 2016 04:07:20 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.12.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160119120720.15029.11215.idtracker@ietfa.amsl.com>
Date: Tue, 19 Jan 2016 04:07:20 -0800
Archived-At: <http://mailarchive.ietf.org/arch/msg/lisp/vrYZi_7GjFbMaR8dmuzJBGSvQ0o>
Cc: draft-ietf-lisp-threats@ietf.org, lisp@ietf.org, lisp-chairs@ietf.org
Subject: [lisp] Stephen Farrell's No Objection on draft-ietf-lisp-threats-14: (with COMMENT)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 19 Jan 2016 12:07:21 -0000
Stephen Farrell has entered the following ballot position for draft-ietf-lisp-threats-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lisp-threats/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for doing this document. I think it's a useful part of the LISP documentation set. general: I think you underestimate the purely passive threats - my point on 2.2 below was almost a DISCUSS but given the WG have already adopted draft-ietf-lisp-crypto I figured there's no need to try block this. I would really encourage you to consider the threats that are mitigated by that specification here, even if those threats weren't initially considered as being that relevant to LISP (when the work on LISP began I mean). If that had been done already in this draft, I'd have been a YES ballot, if that makes any difference;-) - intro: I think you should add a few caveats here to say that you're not covering threats due to specific implementations and also that the text here captures only those LISP-specific threats we know about today and that more *will* be discovered as deployment continues. - intro: you don't write about DNS here, but if some LISP configuration settings use DNS names then via DNS with no DNSSEC an attacker can decide to be on-path sometimes, off-path other times. That (or similar) might be a nice way to illustrate the scope here, while also alerting the implementer to other threats that might affect their implementations. - 2.1 I think it'd be valuable to say that the 2.1.x sections are really just for the sake of exposition - we cannot assume that all attackers fall into any neat category. You do note this (more or less) in 2.1.5 but I think that'd be better done in 2.1. The reason to suggest this change is that being open to attackers not conforming to our descriptions is important. - 2.2 - which section here covers purely passive monitoring? All the 2.2.x seem to only cover active attacks. (I'd also suggest moving the 2.2.10 text to 2.2 similarly to the suggestion above for 2.1.) - 3.8 - you probably need to note somewhere (not sure where) that a bad PRNG would improve the attacker's chances in various ways. I think a calculation of the probability of a nonce collision (for both a good and not-good PRNG) could be a useful addition. - 3.8, 3rd para: I would argue that this threat is a "core" point to be made, as it's arguably the main LISP-specific threat and ought be emphasised more, e.g. via a mention and pointer in the introduction, or otherwise. - section 4 is pretty weak to be honest. I think you could at least recognise that LISP, as with any mechanism that concentrates traffic (between xTRs) means that passively monitoring plaintext is easier than before and that there is therefore value in encrypting the traffic between xTRs as is proposed in draft-ietf-lisp-crypto - (nit) section 5 has a really odd sentence " The usage will be designed and defined specific for the needs of the specification." I've no idea what that means TBH.
- [lisp] Stephen Farrell's No Objection on draft-ie… Stephen Farrell
- Re: [lisp] Stephen Farrell's No Objection on draf… Joel M. Halpern
- Re: [lisp] Stephen Farrell's No Objection on draf… Stephen Farrell
- Re: [lisp] Stephen Farrell's No Objection on draf… Luigi Iannone
- Re: [lisp] Stephen Farrell's No Objection on draf… Stephen Farrell
- Re: [lisp] Stephen Farrell's No Objection on draf… Luigi Iannone
- Re: [lisp] Stephen Farrell's No Objection on draf… Stephen Farrell
- Re: [lisp] Stephen Farrell's No Objection on draf… Luigi Iannone