Hi all,
Here are my comments to draft-lisp-architecture,
Thanks!
Albert
> LISP Working Group J. N. Chiappa
> Internet-Draft Yorktown Museum of Asian Art
> Intended status: Informational July 16, 2012
> Expires: January 17, 2013
>
>
> An Architectural Perspective on the LISP
> Location-Identity Separation System
> draft-chiappa-lisp-architecture-01
[snip]
> 2.2. Deployment of New Namespaces
>
> Once the mapping system is widely deployed and available, it should
> make deployment of new namespaces (in the sense of new syntax, if not
> new semantics) easier. E.g. if someone wishes in the future to
> devise a system which uses native MPLS [RFC3031] for a data carriage
> system joining together a large number of xTRs, it would easy enough
> to arrange to have the mappings for destinations attached to those
> xTRs abe some sort of MPLS-specific name.
Once-> I suggest removing this word given that the Mapping System is already
there.
MPLS-> Although it is a good analogy, I don´t think that MPLS is a good example
given that with LISP we can´t stack labels.
> More broadly, the existence of a binding layer, with support for
> multiple namespace built into the interface on both sides (see
> Section 5) is a tremendously powerful evolutionary tool; one can
> introduce a new namespace (on one side) more easily, if it is mapped
> to something which is already deployed (on the other). Then, having
> taken that step, one can invert the process, and deploy yet another
> new namespace, but this time on the other.
>
> 2.3. Future Development of LISP
>
> Speculation about long-term future developments which are enabled by
> the deployment of LISP is not really proper for this document.
> However, interested readers may wish to consult [Future] for one
> person's thoughts on this topic.
>
> 3. Architectual Perspectives
>
> This section contains some high-level architectural perspectives
> which have proven useful in a number of ways for thinking about LISP.
> For one, when trying to think of LISP as a complete system, they
> provide a conceptual structure which can aid analysis of LISP. For
> another, they can allow the application of past analysis of, and
> experience with, similar designs.
>
> 3.1. Another Packet-Switching Layer
Weak suggestion, maybe it is worth to mention Van Jacobson´s view that the
Internet was an overlay of the Public Switched Telephone Network, in this
context LISP is an overlay of the Internet.
> When considering the overall structure of the LISP system at a high
> level, it has proven most useful to think of it as another packet-
> switching layer, run on top of the original internet layer - much as
> the Internet first ran on top of the ARPANET.
>
> All the functions that a normal packet switch has to undertake - such
> as ensuring that it can reach its neighbours, and they they are still
> up - the devices that make up the LISP overlay also have to do, along
> the 'tunnels' which connect them to other LISP devices.
>
> There is, however, one big difference: the fanout of a typical LISP
> ITR will be much larger than most classic physical packet switches.
> (ITRs only need to be considered, as the LISP tunnels are all
> effectively unidirectional, from ITR to ETR - an ETR needs to keep no
> per-tunnel state, etc.)
>
> LISP is, fundamentally, a 'tunnel' based system. Tunnel system
> designs do have their issues (e.g. the high inter-'switch' fan-out),
> but it's important to realize that they also can have advantages,
> some of which are listed below.
[snip]
> 4.2. Need for a Mapping System
>
> LISP does need to have a mapping system, which brings design,
> implementation, configuration and operational costs. Surely all
> these costs are a bad thing? However, having a mapping system have
> advantages, especially when there is a mapping layer which has global
> visibility (i.e. other entities know that it is there, and have an
> interface designed to be able to interact with it). This is unlike,
> say, the mappings in NAT, which are 'invisible' to the rest of the
> network.
Typo? "Surely all these costs are a bad thing."
Typo: However, having a mapping system *has*...
> In fact, one could argue that the mapping layer is LISP's greatest
> strength. Wheeler's Axiom* ('Any problem in computer science can be
> solved with another level of indirection') indicates that the binding
> layer available with the LISP mapping system will be of great value.
> Again, it is not the job of this document to list them all - and in
> any event, there is no way to forsee them all.
>
> The author of this document has often opined that the hallmark of
> great architecture is not how well it does the things it was designed
> to do, but how well it does things it was never expected to have to
> handle. Providing such a powerful and generic binding layer is one
> sure way to achieve the sort of lasting flexibility and power that
> leads to that outcome.
>
> [Footnote *: This Axiom is often mis-attributed to Butler Lampson,
> but Lampson himself indicated that it came from David Wheeler.]
>
> 4.3. Piggybacking of Control on User Data
>
> LISP piggybacks control transactions on top of user data packets.
> This is a technique that has a long history in data networking, going
> back to the early ARPANET. [McQuillan] It is now apparently regarded
> as a somewhat dubious technique, the feeling seemingly being that
> control and user data should be strictly segregated.
>
> It should be noted that _none_ of the piggybacking of control
> functionality in LISP is _architecturally fundamental_ to LISP. All
> of the functions in LISP which are performed with piggybacking could
> be performed almost equally well with separate control packets.
>
> The "almost" is solely because it would cause more overhead (i.e.
> control packets); neither the response time, robustness, etc would
> necessarily be affected - although for some functions, to match the
> response time observed using piggybacking on user data would need as
> much control traffic as user data traffic.
>
> This technique is particularly important, however, because of the
> issue identified at the start of this section - the very large fanout
> of the typical LISP switch. Unlike a typical router, which will have
> control interactions with only a few neighbours, a LISP switch could
> eventually have control interactions with hundreds, or perhaps even
> thousands (for a large site) of neighbours.
>
> Explicit control traffic, especially if good response times are
> desired, could amount to a very great deal of overhead in such a
> case.
Maybe it´s worth mentioning a specific example of piggybacked control on user
data: Echo-nonce.
[snip]
> 5.3. Overlapping Uses of Existing Namespaces
>
> It is in theory possible to have a block of IPvN namespace used as
> both EIDs and RLOCs. In other words, EIDs from that block might map
> to some other RLOCs, and that block might also appear in the DFZ as
> the locators of some other ETRs.
>
> This is obviously potentially confusing - when a 'bare' IPvN address
> from one of these blocks, is it the RLOC, or the EID? Sometimes it
> it obvious from the context, but in general one could not simply have
> a (hypothetical) table which assigns all of the address space to
> either 'EID' or 'RLOC'.
>
> In addition, such usage will not allow interoperation of the sites
> named by those EIDs with legacy sites, using the PITR mechanism
> ([Introduction], Section "Proxy Devices"), since that mechanisms
> depends on advertizing the EIDs into the DFZ, although the LISP-NAT
> mechanism should still work ([Introduction], Section "LISP-NAT").
>
> Nevertheless, as the IPv4 namespace becomes increasingly used up,
> this may be an increasingly attractive way of getting the 'absolute
> last drop' out of that space.
I think that there might be some potential issues of overlapping namespaces and
LISP-TE recursion mechanism. In this scenario the mapping system is queried
using RLOCs. If a given address has meaning both in terms of EID and RLOC this
might cause some issues.
> 5.4. LCAFs
>
> {{To be written.}}
>
> --- Key-ID
> --- Instance-IDs
>
> 6. Scalability
>
> As with robustness, any global communication system must be scalable,
> and scalable up to almost any size. As previously mentioned (xref
> target="Perspectives-Packet"/), the large fanouts to be seen with
> LISP, due to its 'overlay' nature, present a special challenge.
>
> One likely saving grace is that as the Internet grows, most sites
> will likely only interact with a limited subset of the Internet; if
> nothing else, the separation of the world into language blocks means
> that content in, say, Chinese, will not be of interest to most of the
> rest of the world. This tendency will help with a lot of things
> which could be problematic if constant, full, N^2 connectivity were
> likely on all nodes; for example the caching of mappings.
I suggest removing the `Chinese´example for a more general sentence, something
like "the separation of the world into language blocks might suggest that users
speaking a given language do not typically access content written in other
languages". Besides this many measurements show that because of port-scans
networks reach the entire Internet, so this might not be strictly true.
> 6.1. Demand Loading of Mappings
>
> One question that many will have about LISP's design is 'why demand-
> load mappings - why not just load them all'? It is certainly true
> that with the growth of memory sizes, the size of the complete
> database is such that one could reasonably propose keeping the entire
> thing in each LISP device. (In fact, one proposed mapping system for
> LISP, named NERD, did just that. [NERD])
>
> A 'pull'-based system was chosen over 'push' for several reasons; the
> main one being that the issue is not just the pure _size_ of the
> mapping database, but its _dynamicity_. Depending on how often
> mappings change, the update rate of a complete database could be
> relatively large.
>
> It is especially important to realize that, depending on what
> (probably unforseeable) uses eventually evolve for the
> identity->location mapping capability LISP provides, the update rate
> could be very high indeed. E.g. if LISP is used for mobility, that
> will greatly increase the update rate. Such a powerful and flexible
> tool is likely be used in unforseen ways (Section 4.2), so it's
> unwise to make a choice that would preclude any which raise the
> update rate significantly.
>
> Push as a mechanism is also fundamentally less desirable than pull,
> since the control plane overhead consumed to load and maintain
> information about unused destinations is entirely wasted. The only
> potential downside to the pull option is the delay required for the
> demand-loading of information.
>
> (It's also probably worth noting that many issues that some people
> have with the mapping approach of LISP, such as the total mapping
> database size, etc are the same - if not worse - for push as they are
> for pull.)
>
> Finally, for IPv4, as the address space becomes more highly used, it
> will become more fragmented - i.e. there will tend to be more,
> smaller, entries. For a routing table, which every router has to
> hold, this is problematic. For a demand-loaded mapping table, it is
> not bad. Indeed, this was the original motivation for LISP
> ([RFC4984]) - although many other useful and desirable uses for it
> have since been enumerated (see [Introduction], Section
> "Applications").
>
> For all of these reasons, as long as there is locality of reference
> (i.e. most ITRs will use only a subset of the entire set), it makes
> much more sense to use the a pull model, than the classic push one
> heretofore seen widely at the internetwork layer (with a pull
> approach thus being somewhat novel - and thus unsettling to many - to
> people who work at that layer).
>
> It may well be that some sites (e.g. large content providers) may
> need non-standard mechanisms - perhaps something more of a 'push'
> model. This remains to be determined, but it is certainly feasible.
>
> 6.2. Caching of Mappings
>
> It should be noted that the caching spoken of here is likely not
> classic caching, where there is a fixed/limited size cache, and
> entries have to be discarded to make room for newly needed entries.
> The economics of memory being what they are, there is no reason to
> discard mappings once they have been loaded (although of course
> implementations are free to chose to do so, if they wish to).
I am unsure if I understood this last paragraph. AFAIK the map-cache must be
implemented -for high-speed routers- in TCAM memories which are expensive and
hence, have a fixed/limited cache size.
> This leads to another point about the caching of mappings: the
> algorithms for management of the cache are purely a local issue. The
> algorithm in any particular ITR can be changed at will, with no need
> for any coordination. A change might be for purposes of
> experimentation, or for upgrade, or even because of environmental
> variations - different environments might call for different cache
> management strategies.
>
> The local, unsynchronized replacability of the cache management
> scheme is the architectural aspect of the design; the exact
> algorithm, which is engineering, is not.
Related paper:
http://ebookbrowse.com/an-analytical-model-for-the-lisp-cache-size-pdf-d362171631
[snip]
> 7.2. Design Guidance
>
> In designing the security, there are a small number of key points
> that will guide the design:
>
> - Design lifetime
> - Threat level
>
> How long is the design intended to last? If LISP is successful, a
> minimum of a 50-year lifetime is quite possible. (For comparison,
> IPv4 is now 34 at the time of writing this, and will be around for at
> least several decades yet, if not longer; DNS is 28, and will
> probably last indefinitely.)
"will probably last indefinitely" is a strong statement, I suggest removing it.
> How serious are the threats it needs to meet? As mentioned above,
> the Internet can bring the worst crackers from anywhere to any
> location, in a flash. Their sophistication level is rising all the
> time: as the easier holes are plugged, they go after others. This
> will inevitably eventually require the most powerful security
> mechanisms available to counteract their attacks.
>
> Which is not to say that LISP needs to be that secure _right away_.
> The threat will develop and grow over a long time period. However,
> the basic design has to be capable of being _securable_ to the
> expanded degree that will eventually be necessary. However,
> _eventually_ it will need to be as securable as, say, DNS - i.e. it
> _can_ be secured to the same level, although people may chose not to
> secure their LISP infrastructure as well as DNSSEC potentially does.
> [RFC4033]
>
> In particular, it should be noted that historically many systems have
> been broken into, not through a weakness in the algorithms, etc, but
> because of poor operational mechanics. (The well-known 'Ultra'
> breakins of the Allies were mostly due to failures in operational
> procedure. [Welchman]) So operational capabilities intended to
> reduce the chance of human operational failure are just as important
> as strong algorithms; making things operationally robust is a key
> part of 'real' security.
>
> 7.2.1. Security Mechanism Complexity
>
> Complexity is bad for several reasons, and should always be reduced
> to a minimum. There are three kinds of complexity cost: protocol
> complexity, implementation complexity, and configuration complexity.
> We can further subdivide protocol complexity into packet format
> complexity, and algorithm complexity. (There is some overlap of
> algorithm complexity, and implementation complexity.)
>
> We can, within some limits, trade off one kind of complexity for
> others: e.g. we can provide configuration _options_ which are simpler
> for the users to operate, at the cost of making the protocol and
> implementation complexity greater. And we can make initial (less
> capable) implementations simpler if we make the protocols slightly
> more complex (so that early implementations don't have to implement
> all the features of the full-blown protocol).
>
> It's more of a question of some operational convenience/etc issues -
> e.g. 'How easy will it be to recover from a cryptosystem
> compromise'. If we have two ways to recover from a security
> compromise, one which is mostly manual and a lot of work, and another
> which is more automated but makes the protocol more complicated, if
> compromises really are very rare, maybe the smart call _is_ to go
> with the manual thing - as long as we have looked carefully at both
> options, and understood in some detail the costs and benefits of
> each.
>
> 7.3. Security Overview
>
> First, there are two different classes of attack to be considered:
> denial of service (DoS, i.e. the ability of an intruder to simply
> cause traffic not to successfully flow) versus exploitation (i.e. the
> ability to cause traffic to be 'highjacked', i.e. traffic to be sent
> to the wrong location).
>
> Second, one needs to look at all the places that may be attacked.
> Again, LISP is a relatively simple system, so there are not that many
> parts to examine. The following are the things we need to secure:
>
> - Lookups
> - Indexing
> - Mappings
I suggest citing LISP-SEC.
[snip]
> 11.1.1. Missing Mapping Packet Queueing
>
> Currently, some (all?) ITRs discard packets when they need a
> mapping, but have not loaded one yet, thereby causing the applicaton
> to have to retransmit their opening packet. True, many ARP
> implementations use the same strategy, but the average APR cache will
> only ever contain a few mappings, so it will not be so noticeable as
> with the mapping cache in an ITR, which will likely contain
> thousands.
>
> Obviously, they could queue the packets while waiting to load the
> mapping, but this presents a number of subtle implementation issues:
> the ITR must make sure that it does not queue too many packets, etc.
>
> In particular, if such packets are queued, this presents a potential
> DoS attack vector, unless the code is carefully written with that
> possibility in mind.
A missing mapping packet can be also forwarded to a PETR avoiding
drop/buffering.
> 11.1.2. Mapping Cache Management Algorithm
>
> Relatively little work has been done on sophisticated mapping cache
> management algorithms; in particular, the issue of which mapping(s)
> to drop if the cache reaches some maximum allowed size.
>
> This particular issue has also been identified as another potential
> DoS attack vector.
We have a technical report (not published yet, but public) discussing and
evaluating precisely this aspect. If needed we can share the document.
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
