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

[Luigi Iannone <[e-mail]>]

HI Stephen,

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



> On 20 Jan 2016, at 15:46, Stephen Farrell <[e-mail]> 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.