> Dino, > >>> Technical: >>> >>> Overall, the security considerations section is a bit thin. I don't think >>> we need a lot of additional text, but there are some additional pieces of >>> information that need to be added. Some suggested text below. >>> >>>> The nonce, coupled >>>> with the ITR accepting only solicited Map-Replies goes a long way >>>> toward providing decent authentication. >>> Hmm. This is not really descriptive. How about this instead: >>> >>> The nonce, coupled with the ITR accepting only solicited Map-Replies >>> provides a basic level of security, in many ways similar to the security >>> experienced in the current Internet routing system. It is hard for off-path >>> attackers to launch attacks against these Lisp mechanisms, as they do not >>> have the nonce values. Sending a large number of packets to accidentally >>> find the right nonce value is possible, but would already by itself be a >>> denial-of-service attack. On-path attackers can perform far more serious >>> attacks, but on-path attackers can launch serious attacks in the current >>> Internet as well, including eavesdropping, blocking or redirecting traffic. >>> Lisp relies on the correct operation of a BGP-based routing system >>> [LISP-ALT], but so do the current Internet routing mechanisms. >> I will add this text modulo the last sentence. I don't understand how ALT >> plays into this. So I felt it was a random statement. > > OK > >> Did you mean LISP relies on a secure mapping database system? > > I just wanted to highlight that while LISP does need its mapping system to > work correctly, so does the current Internet need BGP to run correctly. So > there is no big difference in the security of these two as far as that part > goes. > > But it is not important. If you don't want to include it, feel free to use > the text that you like.
Okay, I won't include it. >>>> >>>> It is a good idea to have instrumentation in place >>>> to detect thrashing of the cache. Implementation experimentation >>>> will be used to determine which cache management strategies work >>>> best. >>> Yes, but I think we should also acknowledge that defending against cache >>> trashing attacks is hard: >>> >>> It is a good idea to have instrumentation in place >>> to detect thrashing of the cache. Implementation experimentation >>> will be used to determine which cache management strategies work >>> best. In general, it is difficult to defend against cache trashing >>> attacks. >>> >>> (Unless, of course, I'm missing some obvious schemes that show promise of >>> avoiding some of these issues against determined attackers. It is also >>> possible that if we described the situation in more detail, we'd be able to >>> describe the threats in a more rational way. E.g., outsiders can cause some >>> (limited) problems, insiders could cause big trouble but are generally a >>> bit more trusted, etc.) >> Schemes are work in progress and hence why we don't want to list them. We >> had mentioned this before from the Nanog-triggered thread which we moved >> over to the [email protected] list. > > I agree that we should not mention any schemes. But I do want to add the last > sentence, because I think it is a true statement and more importantly, it > provides IMO a fair assessment of the potential difficulties. I added this when I responded to you. Is it not sufficient: cache sizing and maintenance is an issue to be kept in mind during implementation. It is a good idea to have instrumentation in place to detect thrashing of the cache. Implementation experimentation will be used to determine which cache management strategies work best. In general, it is difficult to defend against cache trashing attacks. It should be noted that an undersized cache in an ITR/PTR not only causes adverse affect on the site or region they support, but may also cause increased Map-Request load on the mapping system. >>>> >>>> This experimental specification does not address automated key >>>> management (AKM).BCP 107<http://tools.ietf.org/html/bcp107> provides >>>> guidance in this area. >>> Yes, but I think we should include two additional important pieces of >>> information. 1. you need to acknowledge that you are not following BCP 107 >>> in this case, as it requires AKM under certain conditions (we are within >>> those conditions, right?). And 2) more importantly, you need to document >>> the implications of not providing AKM. Personally, I do not necessarily >>> consider it a panacea, and often the nonce etc. mechanisms are far more >>> important. In any case, the reader needs to understand what we are losing >>> without AKM. >> This text was created, accepted, and agreed upon from the security ADs. So I >> dare not to touch it. > > Grumble. I think it would be better with a text that describes the > implications. And I think we could actually do a better job than the security > ADs are apparently telling you to do. It is not unheard to have a discuss > waiting for us anyway even if some text was agreed, if we haven't done our > homework. But I'll let this go in the interest of expediency, and because I > happen to believe AKM in this case is an almost complete non-issue. But I do > not want to take this approach in the other issues. The security ADs are very sensitive and particular about this text. Do you really want to fight with them? Let's wait for them to comment if you think this is going to happen. Plus the other ADs aren't terribly happy right now not getting the main spec first. So I don't think we should fuel the fire. I hope you can understand this. Dino >> >>>> 13. Network Management Considerations >>>> >>>> Considerations for Network Management tools exist so the LISP >>>> protocol suite can be operationally managed. The mechanisms can be >>>> found in [LISP-MIB] and [LISP-LIG]. >>> It is good that you point to these specifications. I wonder if there are >>> additional things you should say in this spec, however. Are there >>> parameters that Lisp needs to operate? Are they and their default values >>> described in LISP-MIB? There are many good pieces of advice about the >>> management of a Lisp network in previous sections, should there be some >>> kind of summary/pointers for these here as well? >> All described in the LISP-MIB, which is still ongoing. I will make sure we >> put any configuration guidelines in there. > > OK > > Jari > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
