> On 3 Nov 2016, at 00:24, Fabio Maino <[email protected]> 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 <[email protected] >>> <mailto:[email protected]>> 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 <[email protected] >>>>> <mailto:[email protected]>> 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> >> >
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
