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]> wrote: > [snip] >>> " >>> To verify the integrity of the PKT-AD, first the MS-OTK is derived >>> from the locally stored ITR-OTK using the algorithm specified in the >>> KDF ID field. This is because the PKT-AD is generated by the ETR >>> using the MS-OTK. 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 local policy. >>> " >>> >>> >>> There are two typical use cases: >>> - strict KDF ID policy: ITR specifiy a KDF ID, and will discard map-reply >>> with different KDF IDs. If local policy allows, another map-request will be >>> sent with a different KDF ID >>> - loose KDF ID policy: ITR specify KDF ID = none, and will accept map-reply >>> with any KDF ID (if supported by ITR). If received KDF is not supported the >>> ITR shall drop the map-reply >>> >> >> The above text does not reflect the policies you are describing. That >> “SHOULD” should be a “MAY” and your policies spelled out. > I think we need to separate the recommendations for the two actions: SHOULD > drop and MAY resend. > > " > , the ITR SHOULD discard the Map- > Reply. At the first opportunity it needs to, the ITR MAY send a new Map- > Request with a different KDF ID, according to ITR's local policy. > > What do you think? Much better :-) > >> >> 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. > > [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? > > > > >> >> >> >>>> >>>>> 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? [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. BTW to be consistent with other LISP document you should use "LISP Cache” instead of “map-cache” (in the whole document). [snip]
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
