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.
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.
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.
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
