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.
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.)
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.
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?
Editorial:
Return- Routability
s/- /-/
datragram. If a LISP encapsulated packet arrives at an ETR, it MAY
datagram
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]./
Jari
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
