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..) Check again the nits: Checking nits according to 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]> 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
