Re: [lisp] LISP-SEC review (finally)

[Luigi Iannone <[e-mail]>]

> On 3 Nov 2016, at 00:24, Fabio Maino <[e-mail]> wrote:
> 
> On 11/2/16 9:02 AM, Luigi Iannone wrote:
>> Hi Fabio,
>> 
>> I went through the last version of the document.
>> 
>> I still think that in a few place SHOULD should be replaced by MUST. But it is just  my point of view. You can leave SHOULD.
>> 
>> There are just few residual issues:
>> 
>> - Introduction: The second sentence is not coherent with the first one. The concept of EID-to-RLOC mappings as not been introduced so starting the sentence with “These EID-to-RLOC mapping s…” is pretty unclear. I would suggest you add another sentence.
>> 
>> - Section 7 IANA Considerations: For almost all of the registries the value “0” has a special meaning that this demo is defining, hence the “defined in” field should state “this memo”
>> 
>> - - Section 7 IANA Considerations: The section is not yet 5226 compliant. More specifically, you have to state for each registry how new values are allocated (e.g. FCFS, expert review, etc..)
> 
> Thanks Luigi, 
> do you have any suggestion for the best policy to use for allocation of unassigned values? 
> 
> It seems to me that given the experimental nature of the draft, for all of the registries created, we could require that 'unassigned values are to be assigned according to the "Specification Required" policy defined in [RFC5226].'
> 

Hi,


I have no strong opinion on the issue. To be honest, since the size of the fields are pretty big considered their potential use I would simply go for a FCFS.
Even if some values are wasted there is a large space. 

If instead you want to be sure to always have something meaningful, without introducing heavy machinery, I would go for “Expert Review”.

Ciao

L.



>    
> 
> Fabio
> 
> 
> 
>> 
>> 
>> Check again the nits:
>> 
>>  Checking nits according to http://www.ietf.org/id-info/checklist <http://www.ietf.org/id-info/checklist> :
>>   ----------------------------------------------------------------------------
>> 
>>   == There are 10 instances of lines with non-RFC6890-compliant IPv4
>>      addresses in the document.  If these are example addresses, they should
>>      be changed.
>> 
>>   Checking references for intended status: Experimental
>>   ----------------------------------------------------------------------------
>> 
>>   == Missing Reference: 'RFC4634' is mentioned on line 840, but not defined
>> 
>>   ** Obsolete undefined reference: RFC 4634 (Obsoleted by RFC 6234)
>> 
>> 
>> The above nits reminds me of another issue that the IESG will certainly raise: can we have all the examples in IPv6 only?
>> The latest directives are that either you use both v4 and v6 or v6-only, but NOT v4-only.
>> 
>> Thanks
>> 
>> ciao
>> 
>> L.
>> 
>> 
>> 
>> 
>>> On 27 Oct 2016, at 23:48, Fabio Maino <[e-mail] <mailto:[e-mail]>> wrote:
>>> 
>>> Luigi, 
>>> I agree with all the comments. 
>>> 
>>> The document attached should reflect all your suggestions. 
>>> 
>>> A few notes below, just to explicitly ack the changes you suggested. 
>>> 
>>> 
>>> On 10/26/16 2:13 AM, Luigi Iannone wrote:
>>>> Hi Fabio,
>>>> 
>>>> Yes we are converging, very few points are left. 
>>>> 
>>>> Inline are my comments, I snipped everything that we already agreed up on.
>>>> 
>>>> L.
>>>> 
>>>>> On 26 Oct 2016, at 02:14, Fabio Maino <[e-mail] <mailto:[e-mail]>> wrote:
>>>>> 
>>>> 
>>>> [snip]
>>>> 
>>>> 
>>>>> 
>>>>>> 
>>>>>> Also, what is the MS stubbornly insists in using an algorithm that the ITR does not support?
>>>>> 
>>>>> The MS might not have alternatives, as it might only support one algorithm. 
>>>>> 
>>>> 
>>>> Sure
>>>> 
>>>> The question is: can we have situations in which MS replies always with the same algorithm (because has no alternatives) and the ITR is never able to understand that reply (because has no alternatives).
>>>> 
>>>> From my understanding this can happen, right? 
>>>> 
>>>> LISP-SEC has no way to prevent it, right?
>>>> 
>>>> What is needed is a policy like “ITR tries using all of the algorithm it supports and then gives up”, right?
>>>> 
>>>> If the answer to those questions is yes, then IMO this should be spelled out somewhere.
>>>> 
>>>> 
>>> 
>>> got it. Agreed. 
>>> 
>>> 
>>>>> 
>>>>> 
>>>> [snip]
>>>> 
>>>>>> 
>>>>>>> 
>>>>>>>> 
>>>>>>>>>    The KDF ID field, specifies the suggested key derivation function to
>>>>>>>>>    be used by the Map-Server to derive the MS-OTK.
>>>>>>>> 
>>>>>>>> What happens if the MS will choose a KDF ID not supported by the ITR?
>>>>>>>> Can you clarify how to solve this situation or explain why this will never happen?
>>>>>>> 
>>>>>>> This is described a few paragraphs below: 
>>>>>>> "
>>>>>>> If the KDF ID in the Map-Reply does not match the
>>>>>>>    KDF ID requested in the Map-Request, the ITR SHOULD discard the Map-
>>>>>>>    Reply and send, at the first opportunity it needs to, a new Map-
>>>>>>>    Request with a different KDF ID, according to ITR's... 
>>>>>>> "
>>>>>>> 
>>>>>> 
>>>>>> This does not guarantee that the MS will reply with something the ITR understands….
>>>>> 
>>>>> For some local ITR's policy it may not be guaranteed. It's a balance between reachability and security that the ITR will have to choose. 
>>>>> 
>>>>> 
>>>> I am not sure I understand your reply.
>>>> 
>>>> My point was the same as above: what if MS and ITR are not able to talk?
>>> 
>>> ok. So this is addressed by the same fix used for the previous comment. I'll specify that the ITR will stop re-sending map-requests once all HMAC IDs supported by the ITR have been attempted. 
>>>  
>>>> 
>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>>> 
>>>>>>>>>    The EID-AD length is set to 4 bytes, since the Authentication Data
>>>>>>>>>    does not contain EID-prefix Authentication Data, and the EID-AD
>>>>>>>>>    contains only the KDF ID field.
>>>>>>>>> 
>>>>>>>>>    In response to an encapsulated Map-Request that has the S-bit set, an
>>>>>>>>>    ITR MUST receive a Map-Reply with the S-bit set, that includes an
>>>>>>>>>    EID-AD and a PKT-AD.  If the Map-Reply does not include both ADs, the
>>>>>>>>>    ITR MUST discard it.  In response to an encapsulated Map-Request with
>>>>>>>>>    S-bit set to 0, the ITR expects a Map-Reply with S-bit set to 0, and
>>>>>>>>>    the ITR SHOULD discard the Map-Reply if the S-bit is set.
>>>>>>>> Why a “SHOULD”? If the Map-Request has S-bit=0 it mean that there is no AD, hence no OTK, how can the ITR decrypt the reply?????
>>>>>>>> It MUST discard…..
>>>>>>> 
>>>>>>> If S-bit = 0 there's no Authentication Data. The Map-reply is in clear, and can be read.
>>>>>> 
>>>>>> I am not sure you understood my point.
>>>>>> 
>>>>>> You send a Map-Request with S=0, hence unenbcrypted. How can you possible receive a Map-Reply with S=1?
>>>>>> How is it encrypted if the ITR did not provide any OTK?
>>>>> 
>>>>> Misconfiguration, bugs? I was just trying to enumerate the behaviors of the ITR. There's probably something wrong, and the map-reply should be discarded. Still the mapping is readable, so an ITR favoring reachability may decide to use the mapping. 
>>>>> 
>>>> 
>>>> Oh… I may see the misunderstanding. You are saying that the bit is set in the Map-Reply, but actually the content is not encrypted, right? SO the ITR can decide whether or not to use it.
>>>> 
>>>> Is that right?
>>> 
>>> right. 
>>> 
>>>> 
>>>> 
>>>> [snip]
>>>>>>>> I think “log message" is too much implementation specific. 
>>>>>>>> If there is a notification, and how this notification is done, is implementation specific IMHO.
>>>>>>> ok. Same as above.
>>>>>>>> 
>>>>>>>>>    The EID-record with EID-prefix 1.1.2.0/24 is stored in the map-cache
>>>>>>>>>    because it matches the second EID-prefix contained in the EID-AD.
>>>>>>>>> 
>>>>>>>>>    The EID-record with EID-prefix 1.2.0.0/16 is not processed since it
>>>>>>>>>    is not included in any of the EID-ADs signed by the Map-Server.  A
>>>>>>>>>    log message is issued.
>>>>>>>> I think “log message" is too much implementation specific. 
>>>>>>>> If there is a notification, and how this notification is done, is implementation specific IMHO.
>>>>>>> ok. Same as above
>>>>>>>> 
>>>>>>>>>   In this last example the ETR is trying to
>>>>>>>>>    over claim the EID-prefix 1.2.0.0/16, but the Map-Server authorized
>>>>>>>>>    only 1.2.3.0/24, hence the EID-record is discarded.
>>>>>>>> Reading the example I am not sure I would follow this behaviour.
>>>>>>>> Only 1 record out of 3 is valid so why should I actually trust the ETR instead of throwing everything away?
>>>>>>>> Can you explain ???
>>>>>>> The other two records are validated by the MS, so there is no reason to throw those away.
>>>>>> 
>>>>>> Yes, but the ETR is still trying to cheat on the third one….
>>>>>> So the ETR may be compromised, why should I send traffic to him???
>>>>> 
>>>>> ITR has flagged the security exception with the log entry, and some local ITR policy will decide what to do (including stop encapsulating to the ETR, if that's what is specified by the policy).  At the LISP level LISP-SEC has done its job: verified mapping  goes into the map-cache, overclaimed mapping is dropped. 
>>>>> 
>>>> 
>>>> This is not what the above text states. The text states that the valid EID-record is stored in the map-cache.
>>>> To be consistent with your reply you should change and state that the EID-record is eligible to be used by the ITR.
>>> 
>>> 
>>> got it. I changed 'stored into the map-cache' with 'eligible to be used by the ITR'. For consistency I have used similar language for the other two cases (rather than not processed).  
>>> 
>>>> 
>>>> BTW to be consistent with other LISP document you should use "LISP Cache” instead of “map-cache” (in the whole document).
>>>> 
>>>> 
>>> ok. With the change above we don't use the word map-cache anymore in the document. So this is addresses as well.
>>> 
>>> Thanks!
>>> Fabio
>>> 
>>> 
>>> 
>>>> [snip]
>>>> 
>>> 
>>> <Diff_ draft-ietf-lisp-sec-11.txt - draft-ietf-lisp-sec-12b.txt.html><draft-ietf-lisp-sec-12b.txt>
>> 
>