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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 20 January 2016 14:47 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 B82021A8A59; Wed, 20 Jan 2016 06:47:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level:
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
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 IpHHYANTQTsE; Wed, 20 Jan 2016 06:47:05 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E23FB1A8A5A; Wed, 20 Jan 2016 06:47:03 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9532FBE64; Wed, 20 Jan 2016 14:47:02 +0000 (GMT)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38ObV8Xywenc; Wed, 20 Jan 2016 14:47:02 +0000 (GMT)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 68547BE8A; Wed, 20 Jan 2016 14:46:56 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1453301216; bh=zTHYza9pygt5R78OP10X74BS+9isHLTDXlALAeDfU0s=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=DyE6YYDdcfjLj9IjlnOvduCGLD1lgR2OuXwPzwsjHntqvZBTudw0CePL7HOhPWj/I lm/EUXLc8tW6oTr8NN2J2SmzB//clksu2SNgpO7/To6WVE/bNItXcMm27G81QxqAqr jYNaX7hApxFU2mMyXU9Eh8omFfjaEMq7lgHdfJWE=
To: Luigi Iannone <ggx@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>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
X-Enigmail-Draft-Status: N1110
Message-ID: <569F9DDF.2060103@cs.tcd.ie>
Date: Wed, 20 Jan 2016 14:46:55 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <DD9EECBA-7EF6-4E29-8C53-D8A3398CA4CF@gigix.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/lisp/iclG2hvatbFD-6ZSiXQegL0PyHw>
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: Wed, 20 Jan 2016 14:47:07 -0000

Hi Luigi,

Couple of nits below but we're basically good...

On 20/01/16 11:51, Luigi Iannone wrote:
> Thanks for the comments Stephen.
> 
> Crypto was not meant to be normative… We will move in its right place: informative.
> 
> further comments inline.
> 
> thanks ciao
> 
> L.
> 
> 
>> On 19 Jan 2016, at 15:56, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
>>
>>
>>
>> On 19/01/16 14:50, Joel M. Halpern wrote:
>>> Stephen, than you for the comments.
>>>
>>> With regard to the question of discussing lisp-crypto, the biggest
>>> concern has been creating a normative dependence on future work. 
>>
>> Then make it informative I guess. I don't see any problem, and do
>> see benefits, in text along the lines of "privacy is an issue since
>> LISP concentrates traffic making passive monitoring of plaintext
>> arguably somewhat easier, people are working on [list-crypto] as
>> a way to deal with that." In any case, you shouldn't take anything
>> I've said as me wanting a normative reference to lisp-crypto, I
>> didn't mean to suggest that.
>>
>> As that's how you've handled lisp-sec it shouldn't pose any
>> process issues I'd hope.
>>
>> That said, I'm not a DISCUSS on this, so am non-blocking.
>>
>> Cheers,
>> S.
>>
>>
>>> The
>>> charter item was to discuss threats against LISP as documented already.
>>> I would like to see the crypto work covered, but it seems incorrect to
>>> the charter and likely to cause a further significant delay in an
>>> overdue document.
>>>
>>> Yours,
>>> Joel
>>>
>>> On 1/19/16 7:07 AM, Stephen Farrell wrote:
>>>> 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.
> 
> Good point what about change the sentences:
> 
> 	This document does not consider all the possible uses of LISP as
>    	discussed in [RFC6830] and [RFC7215]. The document focuses on LISP
>    	unicast, including as well LISP Interworking [RFC6832], LISP Map-
>    	Server [RFC6833]), and LISP Map-Versioning [RFC6834]. 
> 
> in the following manner:
> 
> 	This document does not consider all the possible uses of LISP as
>    	discussed in [RFC6830] and [RFC7215] and does not cover 
> 	threats due to specific implementations. The document focuses 
> 	on known LISP-specific threats related to LISP unicast, 
> 	including as well LISP Interworking [RFC6832], LISP Map-
>   	 Server [RFC6833]), and LISP Map-Versioning [RFC6834]. 
> 	Additional threats may be discovered in the future while 
> 	deployment continues.

WFM

> 
> 
>>>>
>>>> - 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.

> 
> 
>>>> - 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.

> 
> 
> 
>>>> - 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.)
> 
> Good point. Similarly to 2.1 I would add the following sentence to 2.2:
> 
> 	These categories are not mutually exclusive and can be used by 
> 	attackers in any combination.
>  
> Also I would add a new subsection numbered 2.10 and renumber the old 2.10 as 2.11.
> The content of the new subsection would be:
> 
> 	2.2.10 Passive Monitoring Attacks
> 	
> 	An attacker can use pervasive monitoring, which is a technical attack [RFC7258],
> 	targeting information about LISP traffic that may or not be used to mount other 
> 	type of attacks.    

Sure.

> 
>>>>
>>>> - 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:-)

> 
>>>>
>>>> - 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.

> 
>>>> - 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
>>>>
> 
> I think this is covered by the last sentence of the section. 
> If an attacker knows detailed information gathered from the mappings
> it can use it for a lot of things, not only passive monitoring as you suggest. 

True.

> 
> 
>>>> - (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.
>>>>
> 
> Thanks … it read really bad ;-)
> It is actually referred to the sentence preceding this one,
> but it’s original meaning is redundant with the sentence 
> that is right after (The exact technique still has to be designed and
> defined. ), hence, it can be simply dropped.

Sounds good,
Cheers,
S.


> 
> 
> Let us know if the suggested changes would answer your comments.
> 
> ciao
> 
> L.
> 
> 
> 
> 
> 
> 
>>>>
>>>>
>>>
>