> 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. Did you mean LISP relies on a secure mapping database system? >> 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. >> 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. >> 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. > Editorial: > >> Return- Routability > > s/- /-/ Fixed. >> datragram. If a LISP encapsulated packet arrives at an ETR, it MAY >> > > datagram Fixed. >> system [KARP <http://tools.ietf.org/html/draft-ietf-lisp-15#ref-KARP>], >> [RPKI <http://tools.ietf.org/html/draft-ietf-lisp-15#ref-RPKI>], >> [BGP-SEC <http://tools.ietf.org/html/draft-ietf-lisp-15#ref-BGP-SEC>], >> [LISP-SEC <http://tools.ietf.org/html/draft-ietf-lisp-15#ref-LISP-SEC>], > > s/[LISP-SEC],/[LISP-SEC]./ Fixed. Dino > > Jari > > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
