Re: [lisp] Stephen Farrell's No Objection on draft-ietf-lisp-threats-14: (with COMMENT)

Luigi Iannone <ggx@gigix.net> Fri, 22 January 2016 12:15 UTC

Return-Path: <ggx@gigix.net>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 756C71A1AD0 for <lisp@ietfa.amsl.com>; Fri, 22 Jan 2016 04:15:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=unavailable
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 OkAml7thHsyV for <lisp@ietfa.amsl.com>; Fri, 22 Jan 2016 04:15:27 -0800 (PST)
Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88FCB1A1A7D for <lisp@ietf.org>; Fri, 22 Jan 2016 04:15:27 -0800 (PST)
Received: by mail-wm0-x235.google.com with SMTP id b14so129195206wmb.1 for <lisp@ietf.org>; Fri, 22 Jan 2016 04:15:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5bUF10U8uQMWTK4rbY9qoC/rwex23REbDBCWurG6+2o=; b=ElSGSuHLu0UjMs5Lzt87Mmsuu1sXYkmGH73EZUtNgV3MecJgoeXYUMjx4BHmF9Dgd8 +1zWMzzn136XNF1Sg3CYbOmzg9gvUCV8CMAxBjypIhps8KnhuJwEf+ILptdkpFDidqjp vyIhDnNDPa1rudv9C7FjYImolnmzFk9/JN/AGQp8KGIz4nfagrEFrE2kU3LiFH4v3bPX K79jyVNf3r5QZBpKttik3kt0DXVF9qUCx6IfmISdUOl8E/TxQvutjubMRy1y1BtoIwry hD9TatxGpw9cbmCmC7Q2uDD1GfR1ZfNxQUgLyY3uR9qaiJ/aSs+yWryoSPgxjg5KLalR dzWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=5bUF10U8uQMWTK4rbY9qoC/rwex23REbDBCWurG6+2o=; b=bd4MzA2raQgHCJhHiYWZL8KBAuYS+zkVs9W+sM0O2V5rG8W/Wu+lZlAacFk0+P3nEY MMujZ9+Km9RtOTijOI3IJMAn1q9WH+TQRRDGdv9Kb692asLLrbHpJNrr3wfLT4ZUbKPB 1U/LJshlx6dyBZk5ny9SZGcVBhwHwDj8mdvbd1M/VMMOjhBYeO1eOKB2VMyXbl76QAP2 KILCXhWubVJcpNkql9fEbyrjP7hjljj3SEtgqQWN9VxqwzldoTNR1CG2dH14DcOtTq6f 7VLbVFJIdJx+IeDgWyBmitQ9LpylHLmmrsYihmgIFCosJaFVqO1BUm4coHgENs0TH7O7 Ue9Q==
X-Gm-Message-State: AG10YOSCB9eV1KQ36t/YuP9hJfKweL9Q+ZU5KfBzTcYq40h7TatQhIcmGYrnr6a9hXvjNQ==
X-Received: by 10.28.89.195 with SMTP id n186mr3325516wmb.49.1453464926150; Fri, 22 Jan 2016 04:15:26 -0800 (PST)
Received: from ?IPv6:2001:660:330f:a4:adc3:e949:4c2:4b5a? ([2001:660:330f:a4:adc3:e949:4c2:4b5a]) by smtp.gmail.com with ESMTPSA id 73sm2688981wmm.7.2016.01.22.04.15.24 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 22 Jan 2016 04:15:24 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Luigi Iannone <ggx@gigix.net>
In-Reply-To: <569F9DDF.2060103@cs.tcd.ie>
Date: Fri, 22 Jan 2016 13:15:26 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <67542A5F-0A29-4216-A1EA-55D329C5D136@gigix.net>
References: <20160119120720.15029.11215.idtracker@ietfa.amsl.com> <569E4D30.5050807@joelhalpern.com> <569E4EB1.2060807@cs.tcd.ie> <DD9EECBA-7EF6-4E29-8C53-D8A3398CA4CF@gigix.net> <569F9DDF.2060103@cs.tcd.ie>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
X-Mailer: Apple Mail (2.3112)
Archived-At: <http://mailarchive.ietf.org/arch/msg/lisp/N5EgLpWuVvpLkXZXow4PYSDJFFE>
Cc: draft-ietf-lisp-threats@ietf.org, lisp@ietf.org, The IESG <iesg@ietf.org>, lisp-chairs@ietf.org
Subject: Re: [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
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, 22 Jan 2016 12:15:29 -0000

HI Stephen,

just a couple of points inline (I trimmed the parts where we agree)



> On 20 Jan 2016, at 15:46, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
> 

[snip]

>> 
>> 
>>>>> 
>>>>> - 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.
>>>>> 
>> 
>> At this stage there are no LISP configuration settings related to DNS.
>> Hence, IMHO, there is no need to add anything.
> 
> I guess. But don't implementations probably accept DNS names
> in their configs? If they do then it might be an idea to use
> something like the above to flag that on/off-path isn't quite
> so clear then.
> 

AFAICT no. There is no DNS names.
It might be proposed in the future as an LCAF type, but as of today, there is nothing like that.


>> 
>> 
>>>>> - 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.
>>>>> 
>> 
>> The idea of 2.1.5 was to provide an example. This can be done only after 
>> the different modes are explained. 
>> Instead of moving text from 2.1.5 to 2.1 I would modify  2.1 in the following manner:
>> 
>> 	Attackers can be classified according to the following four modes of
>>   	operation, i.e., the temporal and spacial diversity of the attacker.
>> 	These modes are not mutually exclusive and can be used by 
>> 	attackers in any combination.
> 
> That's better yes. But my point was also that an attacker doesn't
> have to follow our classification and will do whatever works for
> their attack, which may be something we've not thought about.
> 

What about the following:


	Attackers can be classified according to the following four modes of
  	operation, i.e., the temporal and spacial diversity of the attacker.
	These modes are not mutually exclusive, they can be used by 
	attackers in any combination, and other modes may be discovered 
	in the future.

Does this sound better?

[snip]

>> 
>>>>> 
>>>>> - 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.
>> 
>> Not sure that the collision probability would be really helpful here, but you have a point about PRNG.
>> I suggest we change this text:
>> 
>> 	If an ETR does not accept Map-Reply
>>   	messages with an invalid nonce, the risk of an off-path attack is
>>   	limited given the size of the nonce (64 bits).
>> 
>> in:
>> 
>> 	Given the size of the nonce (64 bits), if best current practice is used [RFC4086] 
>> 	and If an ETR does not accept Map-Reply messages with an invalid nonce, 
>> 	the risk of an off-path attack is limited.
>> 
> 
> TBH, I'm not sure what that change does. It might be better (but
> your call) to just say that a bad PRNG can lead to problems, so
> don't do that:-)
> 

RFC4086 is about “Randomness Requirements for Security” so I guess that following those guidelines would be enough.
Don’t you think?


>> 
>>>>> 
>>>>> - 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.
>>>>> 
>> 
>> Not sure I understand. 
>> You talking about the paragraph about the attacker is a valid ETR?
>> Why this problem is more important than others?  
>> Several attacks can cause lot of damage, why this should better highlighted?
> 
> I might well be wrong, but the overclaiming type attack seems to
> me to be more LISP-specific compared to others.
> 

Not really.  Everything in section 3 is actually LISP-Specific. 
Think for instance about Locator-Status-Bits (sec 3.2).

[snip]

Ciao

L.