On 23 Oct 2012, at 21:34, Vince Fuller <[email protected]> wrote:
> Hi Damien-
>
> Thanks for catching the typos. I few comments on your comments:
>
>>> 7.4. Just Enough Security
>>>
>>> How much security to have is a complex issue. It's relatively easy
>>> for designers to add good security, but much harder to get the users
>>> to jump over all the hoops necessary to use it. LISP has therefore
>>> adopted a position where we add 'just enough' security.
>>>
>>> The overall approach to security in LISP is fairly subtle, though,
>>> and is covered in more detail elsewhere (in [Architecture], Section
>>> "Security").
>>
>> I don't agree with this approach.
>
> Can you be more specific about what you don't like and suggest an alternative?
true, it was a bit short.
Well, LISP is really design to be as operational as possible for today,
in our world where infrastructure security is still not very critical (see
how weak is BGP but there is no major issue). I think however that
bad people will become more and more aware of what they can do
by attacking directly the infrastructure and then we will have troubles.
So LISP has been designed with zero security in mind and security
is seen as a patch over the system and hence the sentence "just
enough security". But how do we consider it is just enough? Actually
it is just enough because there is no targeted attack yet.
I understand that there is many LISP use cases where security is a
detail but I think that the "just enough security" and I would say "just
in time security" approach followed during LISP development makes
securing LISP hard.
>
>>> 10.1. Internetworking Mechanism
>>>
>>
>> interworking
>
> I might re-title this section "Interworking with non-LISP systems"
>
>>> 11.2. Replacement of ALT with DDT
>>>
>>> As mentioned in Section 9.2, an interface is provided to allow
>>> replacement of the indexing subsystem. LISP initially used an
>>> indexing system called ALT. [ALT] ALT was relatively easy to
>>> construct from existing tools (GRE, BGP, etc), but it had a number of
>>> issues that made it unsuitable for large-scale use. ALT is now being
>>> superseded by DDT.
>>>
>>> As indicated previously (Section 9.5), the basic structure and
>>> operation of DDT is identical to that of TREE, so the extensive
>>> simulation work done for TREE applies equally to DDT, as do the
>>> conclusions drawn about TREE's superiority to ALT. [Jakab]
>>>
>>> {{Briefly synopsize results}}
>>
>> DDT builds a hierarchy of nodes and, by default, every request has
>> to traverse the entire hierarchy from the root to a leaf (i.e., a MS).
>
> This is not entirely correct. Once a DDT Map Resolver's (MR's) referral
> cache has been populated, it does not need to send all requests to the
> root; any request for a sub-tree of the EID space which is known in the
> referral cache is sent directly to the MS's for that sub-tree.
>> This is somehow similar to LISP+ALT where requests have to traverse the
>> ALT topology to reach a MS and finally the ETR. However, an
>> important distinction has to be made. Indeed, with ALT, the mapping
>> does not follow the same logical path than the request.
>
> I don't understand these sentences.
map-replies are seen by nobody but the ITR, so no caching.
>
>> As a result, the MR has no way to discover the topology and is not able
>> to cache mapping for subsequent ITR requests.
>
> This is not entirely correct. An MR does not cache EID-to-RLOC mappings
> themselves but it does cache referrals that list the DDT Map Servers for
> every part of the EID space that it queries. The MR thus discovers the
> EID space topology and stores that information in its referral cache.
>
>> On the contrary, MR in DDT works in a recursive way: the MR first queries
>> the root that gives a referral to one of its child and so on until the
>> address of a MS is known. At this stage, the MR can cache the referral
>> such that subsequent request do not have to traverse the full hierarchy.
>> [Jackab] shows by the mean of simulations with real packet trace, that it
>> is possible to construct the hierarchy such that most of the requests are
>> sent close to the leaves in the hierarchy, significantly reducing the
>> mapping resolution time.
>
> This is mostly correct but confusing, your use of the term "recursive"
> particularly so; a DDT MR explores the EID topology (DDT) using an
> interactive process. From the perspective of an ITR that sends a request
> to a a DDT MR, the process appears to be recursive (just as the iterative
> DNS resolution process appears recursive to a host that sends a DNS request
> to a caching resolver); that does not mean that the process is recursive.
>
> Your mentioning of DDT MR caching in this paragraph contracts the
> statements you made earlier about having to start at the root; again,
> quite confusing.
another try for the full paragraph then:
In LISP-DDT, the hierarchical nature of EID prefixes is leveraged to
construct a hierarchical mapping resolution infrastructure. When an ITR
has to obtain a mapping, it sends a Map-Request for that mapping to one
of its assigned Map Resolver (MR). The MR then iteratively resolves the
DDT hierarchy until a referral for Map Servers (MS) responsible for the
requested EID is obtained, then the MR sends a Map-Request to a MS
on behalf of the ITR such that the ITR eventually receives the mapping.
As opposed to LISP+ALT, mapping resolution can significantly be
speeded up thanks to caching. Indeed, the MR can cache the results
of its iterative walk in the hierarchy such that for latter request, the entire
hierarchy does not need to be traversed.
>
>>> 11.2.1. Why Not Use DNS
>>>
>>> One obvious question is 'Since DDT is so similar to DNS, why not
>>> simply use DNS?' In particular, people are familiar with the DNS,
>>> how to configure it, etc - would it not thus be preferable to use it?
>>> To completely answer this would take more space that available here,
>>> but, briefly, there were two main reasons, and one lesser one.
>>>
>>> First, the syntax of DNS names did not lend itself to looking up
>>> names in other syntaxes (e.g. bit fields). This is a problem which
>>> has been previously encountered, e.g. in reverse address lookups.
>>> [RFC5855]
>>>
>>> Second, as an existing system, the interfaces between DNS (should it
>>> have been used as an indexing subsystem for LISP) would not be
>>> 'tuneable' to be optimal for LISP. For instance, if it were desired
>>> to have the leaf node in an indexing lookup directly contact the ETR
>>> on behalf of the node doing the lookup (thereby avoiding a round-trip
>>> delay), that would not be easy without modifications to the DNS code.
>>> Obviously, with a 'custom' system, this issue does not arise.
>>>
>>> Finally, DNS security, while robust, is fairly complex. Doing DDT
>>> offered an opportunity to provide a more nuanced security model.
>>> (See [Architecture], Section "Security" for more about this.)
>>
>> will see with time, but I am not sure that security will really be
>> easier with DDT.
>
> Maybe "easier" is the wrong word, but given that ALT does not define any
> security mechanism (it simply assumes the use of whatever is available
> with BGP), the explicit description of how security works with DDT would
> seem to be "easier"/"better" to me.
>
ok
Damien Saucez
> --Vince
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
