Subject: [lisp] Comments on lisp-architecture-01

From: Luigi Iannone <[email-masked]>
Date: Tue, 30 Oct 2012 13:18:47 +0100

Hi,

hereafter my comments on the architectural document.

ciao

Luigi

General comments on the document:

- Currently, acronyms are used without their long version. Yes we all know the acronyms but the document is meant for LISP beginners, hence would be helpful to have the acronyms explained the first time that they are used.

- In order to make the document self-contained wouldn't be better to put a section at the beginning giving a very high level overview of how LISP works? This would help in understanding the architectural choices described in the remaining of the document. 

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

IMHO the following paragraph has too many details for an abstract.

>    LISP upgrades the architecture of the IPvN internetworking system by
>    separating location and identity, current intermingled in IPvN
>    addresses. This is a change which has been identified by the IRTF as
>    a critically necessary evolutionary architectural step for the
>    Internet. In LISP, nodes have both a 'locator' (a name which says
>    _where_ in the network's connectivity structure the node is) and an
>    'identifier' (a name which serves only to provide a persistent handle
>    for the node). A node may have more than one locator, or its locator
>    may change over time (e.g. if the node is mobile), but it keeps the
>    same identifier.
> 

The following paragraph should be the first so that the content and purpose of the document is clear from the very beginning of the abstract.

>    This document gives additional architectural insight into LISP, and
>    considers a number of aspects of LISP from a high-level standpoint.
> 
>    [NOTE: This is still a somewhat rough draft version; a few sections
>    at the end are just rough frameworks, but almost all the key
>    sections, and all the front part of the document, are here, and in
>    something like reasonably complete form.]
> 

[snip]

> 
> 2. Goals of LISP
> 
>    As previously stated in the abstract, broadly, the goal of LISP is to
>    be a practically deployable architectural upgrade to IPvN which
>    performs separation of location and identity. But what is the value
>    of that?  What will it allow us to do?
> 
>    The answer to that obviously starts with the things mentioned in the
>    "Initial Applications"

For readability, I would put a list of these initial applications. The interested reader can then go to the intro document for details.

> section of [Introduction], but there are
>    other, longer-range (and broader) goals as well.
> 
> 2.1. Reduce DFZ Routing Table Size
> 
>    One of the main design drivers for LISP, as well as other location-
>    identity separation proposals, is to decrease the overhead of running
>    global routing system. In fact, it was this aspect that led the IRTF
>    Routing RG to conclude that separation of location and identity was a
>    key architectural underpinning needed to control the growth of the
>    global routing system. [RFC6115]
> 
>    As noted in [Introduction], many of the practical needs of Internet
>    users are today met with techniques that increase the load on the
>    global routing system (Provider Independent addresses for the
>    provision of provider independence, multihoming, etc; more-specific
>    routes for TE; etc.)  Provision of these capabilities by a mechanism
>    which does not involve extra load on the global routing system is
>    therefore very desirable.
> 
>    A number of factors, including the use of these techniques, has led
>    to a great increase in the fragmentation of the address space, at
>    least in terms of routing table entries. In particular, the growth
>    in demand for multi-homing has been forseen as driving a large
>    increase in the size of the global routing tables.
> 
>    In addition, as the IPv4 address space becomes fuller and fuller,

I don't think Vince has nothing to do with this… ;-)

Ok bad joke.

I would state "IPv4 address space becomes the more and more a scarce resource,"

>    there will be an inevitable tendency to find use in smaller and
>    smaller 'chunks' of that space. [RFC6127]

Concerning the citation style see my comment on the Introduction document.

> This too would tend to
>    increase the size of the global routing table.

I would put a ref to the potaroo web site.

> 
>    LISP, if successful and widely deployed, offers an opportunity to use
>    separation of location and identity to control the growth of the size
>    of the global routing table. (A full examination of this topic is
>    beyond the scope of this document - see {{find reference}}.)
> 

May I suggest: 

http://biblio.info.ucl.ac.be/2007/415406.pdf

> 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

typo? abe => have????

> some sort of MPLS-specific name.
> 
>    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.

I did not yet read the document, but may the WG should consider to adopt it so to have a fully fledged citation here.

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

typo: they they are => that 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.)
> 

Unless the ETR performs sanity check on the received LISP-encapsulated packets. This is also stated in the main spec and should be added.

>    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.
> 
> 3.2. 'Double-Ended' Approach
> 
>    LISP may be thought of as a 'double-ended' approach to enhancing the
>    architecture, in that it uses pairs of devices, one at each end of a
>    communication stream. In particular, to interact with the population
>    of 'legacy' hosts (which will be, inevitably, the vast majority, in
>    the early stages of deployment) it requires a LISP device at both
>    ends of the 'tunnel'.
> 
>    This is in distinction to, say, NAT systems ([RFC1631]), which only
>    need a device deployed at one end: the host at the other end doesn't
>    need a matching device at its end to massage

Ok to talk about happy packets … but to massage them ;-)

typo???: massage => message???

> the packets, but can
>    simply consume them on its own, as any packets it receives are fully
>    normal packets. This allows any site which deploys such a 'single-
>    ended' device to get the full benefit, whilst acting entirely on its
>    own. [Wasserman]
> 
>    The issue is not that LISP uses tunnels. Designs like HIP
>    ([RFC4423]) and ILNP ([ILNP]), which do not involve tunnels, inhabit
>    a similar space to tunnel-based designs like LISP, in that unless
>    both ends are upgraded - or there is a proxy at the un-upgraded end -
>    one doen't

typo: doen't => dosn't

> get any benefits. So it's really not the tunnel which is
>    the key aspect, it's the 'all at one end' part which is key. Whether
>    the system is tunnel, versus non-tunnel, is not that important.
> 
>    However, the double-ended approach of LISP does have advantages, as
>    well as costs. To put it simply, the 'feature' of the alternative
>    approach, that there's only a box at one end, has a 'bug':

Instead of "bug" I would use "issue" or "drawback" or "limitation".

> there's
>    only a box at one end. There are things which such a design cannot
>    accomplish, because of that.

Like for instance?

> 
>    To put it another way, does the fact that the packet thus necessarily
>    has only a single 'name' in it for the entities at each end (i.e. the
>    IPvN source and destination addresses), because it is a 'normal'
>    packet, present a limitation?  Put that way, it would seem natural
>    that it should cause certain limits.
> 
>    To compile a complete list of the things that can be done, when two
>    separate 'names' are in the packet, is beyond the scope of this
>    document. However, one example of the kind of thing that can be done
>    is mobility with open connections, without needing to 'triangle
>    route' the packets through some sort of 'base station' at the
>    original location. Another is that is possible to automatically
>    tunnel IPv6 traffic over IPv4 infrastructure, or vice versa,
>    invisibly to the hosts on both ends.
> 
>    In the longer term, having having

typo: delete "having"

> tunnel boxes will allow (and is
>    allowing) us to explore other kinds of wrappings. For example, we
>    can transport 'raw' local-network packets (such as Ethernet MAC
>    frames) across an IPvN infrastructure.
> 
>    One could also wrap packets in non-IPvN formats: perhaps to take
>    direct advantage of the capabilities of underlying switching fabrics
>    (e.g. MPLS [RFC3031]); perhaps to deploy new carriage protocols,
>    etc, where non-standard packet formats will allow extended semantics.
> 
> 4. Architectual Aspects
> 
>    LISP does take some novel architectural approaches in a number of
>    ways: e.g. its use of a separate mapping system, etc, etc. This
>    section contains some commentary on some of the high-level
>    architectural aspects of LISP.
> 
> 4.1. Critical State
> 
>    LISP does have 'critical state' in the network (i.e. state which, if
>    if lost, causes the communication to fail). However, because LISP is
>    designed as an overall system, 'designing it in' allows for a
>    'systems' approach to its state issues. In LISP, this state has been
>    designed to be maintained in an 'architected' way, so it does not
>    produce systemic brittleness in the way that the state in NATs does.
> 
>    For instance, throughout the system, provisions have been made to
>    have redundant copies of state, in multiple devices, so that the loss
>    of any one device does not necessarily cause a failure of an ongoing
>    connection.
> 
> 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

typo?: Have => has ??

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

What about citing rfc 5218, which makes the same point?

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

You can cite:

http://www.net.t-labs.tu-berlin.de/papers/IB-CCLIM-07.pdf
http://www.net.t-labs.tu-berlin.de/papers/KIF-ADDITLCAWISKAI-11.pdf

The number of mappings in the cache are a measure of the LISP switch fanout.

>    Explicit control traffic, especially if good response times are
>    desired, could amount to a very great deal of overhead in such a
>    case.
> 
> 5. Namespaces
> 
>    One of the key elements in any architecture, or architectural
>    analysis, are the namespaces involved: what are their semantics and
>    syntax, what are the kinds of things they name, etc.
> 
>    LISP has two key namespace, EIDs and RLOCs, but it must be emphasized
>    that on an architectural level, neither the syntax, or, to a lesser
>    degree, the semantics, of either are absolutely fixed. There are
>    certain core semantics which are generaly unchanging (such as the
>    notion that EIDs provide only identity, whereas RLOCs provide
>    location), but as we will see, there is a certain amount of
>    flexibility available for the long-term.
> 
>    In particular, all of LISP's key interfaces always include an Address
>    Family Identifier (AFI) [AFI] for all names, so that new forms can be
>    introduced at any time the need is felt.

I would cite here as well the LCAF document.

> Of course, in practise such
>    an introduction would not be a trivial exercise - but neither is is

typo: delete "is"

>    impossibly painful, as is the case with IPv4's 32-bit addresses,
>    which are effectively impossible to upgrade.
> 
> 5.1. LISP EIDs
> 
>    A 'classic' EID is defined as a subset of the possible namespaces for
>    endpoints. [Chiappa] Like most 'proper' endpoint names, as proposed
>    there, they contain contain no information about the location of the
>    endpoint. EIDs are the subset of possible endpoint names which are:
>    fixed length, 'reasonably' short', binary (i.e. not intended for
>    direct human use), globally unique (in theory), and allocated in a
>    top-down fashion (to achieve the former).
> 
>    LISP EIDs are, in line with the general LISP deployment philosophy, a
>    reuse of something already existing - i.e. IPvN addresses. For
>    those used as in LISP as EIDs, LISP removes much (or, in some cases,
>    all) of the location-naming function of IPvN addresses.
> 
>    In addition, the goal is to have EIDs name hosts (or, more properly,
>    their end-end communication stacks), whereas the other LISP namespace
>    group (RLOCs) names interfaces. The idea is not just to have two
>    namespaces (with different semantics), but also to use them to name
>    _different classes of things_ - classes which currently do not have
>    clearly differentiated names. This should produce even more
>    functionality.
> 
> 5.1.1. Residual Location Functionality in EIDs
> 
>    LISP retains, especially in the early stages of the deployment, in
>    many cases some residual location-naming functionality in EIDs, This
>    is to allow the packet to be correctly routed/forwarded to the
>    destination node, once it has been unwrapped by the ETR - and this is
>    a direct result of LISP's deployment philosophy (see [Introduction],
>    Section "Deployment").
> 
>    Clearly, if there are one or more unmodified routers between the ETR
>    and the desination node, those routers will have to perform a routing
>    step on the packet, for which it will need _some_ information as to
>    the location of the destination.
> 
>    One can thus view such LISP EIDs, which retain 'stub' location
>    information, as 'addresses' (in the definition of the generic sense
>    of this term, as used here), but with the location information
>    restricted to a limited, local scope.
> 
>    This retention of some location functionality in LISP EIDs, in some
>    cases, has led some people to argue that use of the name 'EID' is
>    improper. In response, it was suggested that LISP use the term
>    'LEID', to distinguish LISP's 'bastardized'

Don't like the term, what about "variant"???

> EIDs from 'true' EIDs,
>    but this usage has never caught on.
> 
>    It has also been suggested that one usage mode for LISP EIDs, in
>    existing software loads, is to assign them as the address on an
>    internal virtual interface; all the real interfaces would have RLOCs
>    only. [Templin] This would make such LISP EIDs functionally
>    equivalent to 'real' EIDs - they are names which are purely identity,
>    have no location information of any kind in them, and cannot be used
>    to make any routing decisions anywhere outside the host.
> 
>    It is true that even in such cases, the EID is still not a 'pure'
>    EID, as it names an interface, not the end-end stack directly.
>    However, to do a perfect job here (or on separation of location and
>    identity) is impossible without modifying existing hosts (which are,
>    inevitably, almost always one end of an end-end communication) - and
>    that has been ruled out, for reasons of viable deployment.
> 
>    The need for interoperation with existing unmodified hosts limits the
>    semantic changes one can impose,

On this point you can cite: 

http://www.computer.org/csdl/mags/ic/preprint/mic2012990288-abs.html

> much as one might like to provide a
>    cleaner separation. (Future evolution can bring us toward that
>    state, however: see [Future].)
> 
> 5.2. RLOCs
> 
>    RLOCs are basically pure 'locators' [RFC1992], although their syntax
>    and semantics is restricted at the moment, because in practise the
>    only forms of RLOCs supported are IPv4 and IPv6.
> 

Pretty short section. May be we can add something about implications of different model, e.g., RLOC on the device interface like in LISP-MN vs. RLOC at the border of stub networks vs. other….

> 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

typo: ti => is

> 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.
> 
> 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"/),

Broken reference.

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

You can cite:

http://www.net.t-labs.tu-berlin.de/papers/IB-CCLIM-07.pdf
http://www.net.t-labs.tu-berlin.de/papers/KIF-ADDITLCAWISKAI-11.pdf

[snip]

> 
> 6.4. Scalability of The Indexing Subsystem
> 
>    LISP initially used an indexing subsystem 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. [DDT]
> 
>    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]
> 

None of the above paragraphs sketches what is ALT, what is TREE, and what is DDT.
I think that to add a very short description will improve and ease the reading of this section.

>    From an architectural point of view, the main advantage of DDT is
>    that it enables client side caching of information about intermediate
>    nodes in the resolution hierarchy, and also enables direct
>    communication with them. As a result, DDT has much better scaling
>    properties than ALT.
> 
>    The most important result of this change is that it avoids a
>    concentration of resolution request traffic at the root of the
>    indexing tree, a problem which by itself made ALT unsuitable for a
>    global-scale system. The problem of root concentration (and thus
>    overload) is almost unavoidable in ALT (even if masses of 'bypass'
>    links are created).
> 
>    ALT's scalability also depends on enforcing an intelligent
>    organization that aincreases aggregation. Unfortunately, the current
>    backbone routing BGP system shows that there is a risk of an organic
>    growth of ALT, one which does not achieve aggregation. DDT does not
>    display this weakness, since its organization is inherently
>    hierarchical (and thus inherently aggregable).
> 
>    The hierarchical organization of DDT also reduces the possibility for
>    a configuration error which interferes with the operation of the
>    network (unlike the situation with the current BGP DFZ). DDT
>    security mechanisms can also help produce a high degree of
>    robustness, both against misconfiguration, and deliberate attack.
>    The direct communication with intermediate nodes in DDT also helps to
>    quickly locate problems when they occur, resulting in better
>    operational characteristics.
> 
>    Next, since in ALT mapping requests must be transmitted through an
>    overlay network, a significant share of requests can see
>    substantially increased latencies. Simulation results in the TREE
>    work clearly showed, and quantified, this effect.
> 
>    The simulations also showed that the nodes composing the ALT and DDT
>    networks for a mapping database of full Internet size could have
>    thousands of neighbours. This is not an issue for DDT, but would
>    almost certainly have been problematic for ALT nodes, since handling
>    that number of simultaneous BGP sessions would likely to be
>    difficult.
> 
> 7. Security
> 
>    LISP does not yet have an overarching security architecture. Many
>    parts of the system have been hardened, but more on a case-by case
>    basis, rather than from an overall perspective. (This is in part due
>    to the 'just enough' approach to security initially taken in LISP;
>    see [Introduction], Section "Just Enough Security".)
> 
>    This section represents an attempt to produce a more broadly-based
>    view of security in LISP; it mostly resulted from an attempt to add
>    security to the DDT indexing system ([DDT]), but the analysis is is

typo: delete is

>    general enough to apply to LISP broadly.
> 
>    The _good_ thing about the Internet is that it brings the world to
>    your doorstep - masses of information from all around the world are
>    instantly available on your computing device. The _bad_ thing about
>    the Internet is that it brings the world to your doorstep - including
>    legions of crackers, thieves, and general scum and villainy. Thus,
>    any node may be the target of fairly sophisticated attack - often
>    automated (thereby reducing the effort required of the attacker to
>    spread their attack as broadly as possible).
> 
>    Security in LISP faces many of the same challenges as security for
>    other parts of the Internet: good security usually means work for the
>    users, but without good security, things are vulnerable.
> 
>    The Internet has seen many very secure systems devised, only to see
>    them fail to reach wide adoption; the reasons for that are complex,
>    and vary, but being too much work to use is a common thread. It is
>    for this reason that LISP attempts to provide 'just enough' security
>    (see [Introduction], Section "Just Enough Security").
> 
> 7.1. Basic Philosophy
> 
>    To square this circle, of needing to have very good security, but of
>    it being too difficult to use very good security, the general concept
>    is for LISP to have a series of 'graded' security measures available,
>    with the 'ultimate' security mechanisms being very high-grade indeed.
> 
>    The concept is to devise a plan in which LISP can simultaneously
>    attempt to have not just 'ultimate' security, but also one or more
>    'easier' modes, ones which will be easier to configure and use. This
>    'easier' mode can be both an interim system (with the full powered
>    system available for when it it

typo: it => is

> needed), as well as the system used
>    in sections of the network where security is less critical (following
>    the general rule that the level of any security should generally be
>    matched to what is being protected).
> 
>    The challenge is to do this in a way that does not make the design
>    more complex, since it has to include both the 'full strength'
>    mechanism(s), and the 'easier to configure' mechanism(s). This is
>    one of the fundamental tradeoffs to struggle with: it is easy to
>    provide 'easier to configure' options, but that may make the overall
>    design more complex.
> 
>    As far as making it hard to implement to begin with (also something
>    of a concern initially, although obviously not for the long term): we
>    can make it 'easy' to deploy initially by simply not implementing/
>    configuring the heavy-duty security early on. (Provided, of course,
>    that the packet formats, etc, needed to support such security are all
>    included in the design to begin with.)
> 

[snip]

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

I guess here the threat analysis document can be cited.

>    - Lookups
>    - Indexing
>    - Mappings
> 
> 7.3.1. Securing Lookups
> 
>    {{To be written.}} Nonces, [SecurityReq]
> 
> 7.3.2. Securing The Indexing Subsystem
> 
>    It is envisioned that DDT will be highly securable, with all the
>    delegations cryptographiclly secured via public-private signatures,
>    very similar to the way DNS is ([RFC4033]).
> 
>    The detailed mechanisms will be based on DNS's; this has the obvious
>    benefit that all the lessons of DNS's years of practical experience
>    with deployment, operations, etc, as well as the improvements to the
>    basic design of DNS Security to provide a secure but usable system
>    can be taken into account. However, DDT's security will also apply
>    the thinking above, about making a 'versio'  

typo?? versio => version???

> which is easier to use
>    available.
> 
>    {{To be written.}}
> 
> 7.3.3. Securing Mappings
> 
>    There are two approaches to securing the provision of mappings. The
>    first, which is of course not completely satisfactory, is to only
>    secure the channel between the ITR and the entities involved in
>    providing mappings for it. (See above, Section 7.3.1)
> 
>    The second is to secure the mappings themselves, by signing them 'at
>    birth' (much the same way in which DNS Security operates).
>    [RFC4033]. There was an attempt early on to suggest such a system
>    for LISP ([SecurityAuth]), but it was not adopted (although the
>    particular proposal was rather complex).
> 
>    In the long run, the latter approach would obviously be superior,
>    since it would be almost immune to any compromises of the mapping
>    distribution system. {{Tie-in to space allocation security}}
> 
> 7.4. Securing the xTRs
> 
>    --- Cache management
>    --- Unsoliticed Map-Replies are _very bad_ - must go through
>        mapping system to verify that the sender is authoritative for
>        that range of EIDs
> 
> 8. Robustness
> 
>    -- Depends on deployment as well as design
>    -- Architected, visible replication of state/data
>    -- Overlapping mechanisms (ref redundancy as key for robustness)
> 
> 9. Fault Discovery/Handling
> 
>    Any global communication system must be robust, and to be robust, it
>    must be able to discover and handle problems. LISP's general
>    philosophy of robustness is usually to have overlapping, simple
>    mechanisms to discover and repair problems.
> 
> 10. Optimization
> 
> 
>    -- Philosophy
>    -- Piggybacking
>    -- 'Wiretapping' return mappings
>    --- Security is an issue on that
> 
> 11. Open Issues
> 
>    Although much work has been done on LISP, and it operates
>    satisfactorily in a reasonably large initial deployment, there are a
>    few potentially problematic issues which remain. It is not clear if
>    they will be issues which need to be dealt, since they have not
>    proven to be obstacles so far, but it is worth listing them.
> 
>    We can divide them in _local_ issues, i.e. ones which can be solved
>    on a node-by-node basis, without requiring co-ordinated change, and
>    systemic issues, which are obviously more problematic, since they
>    could require co-ordinated changes to the protocols.
> 
> 11.1. Local Open Issues
> 
> 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

typo: APR => ARP

> 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.
> 
> 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.
> 
> 11.2. Systemic Open Issues
> 
> 11.2.1. Mapping Database Provider Lock-in
> 
>    This refers to the fact that if one does not like the entity which is
>    providing the indexing for the part of the address space which one's
>    EIDs are allocated out of, there isn't

typo: delete isn't

> probably isn't any way to
>    switch to an alternative provider.
> 
>    It is not clear that this is a real probem, though - the fact that
>    all DNS top-level zones only have a single registry has not been a
>    problem, nor has the fact that if one doesn't like the service the
>    registry offers, one can't take one's DNS name to another registry.
> 
>    Doing anything about it would also be difficult. Although it is
>    _technically_ possible to duplicate any node in the delegation tree,
>    and in theory such duplicates could be provided by different
>    providers, it is not clear that such an arrangement would make
>    _business_ sense.
> 
>    For instance, if the holder of 10.1.1/24 decides they do not like the
>    entity providing indexing for 10.1/16 (call them E1), and ask another
>    entity (E2) to provide alternative service for 10.1/16, two problems
>    arise. First, E1 is _still_ going to have to maintain the correct
>    data for 10.1.1/24, and response to queries asking about them.
>    Second, E2 will similarly have to maintain data for, and reply to
>    queries about, all the other space-holders in 10.1/16 - even though
>    they will likely not have any business relationship with them.
> 
> 11.2.2. Automated ETR Synchronization
> 
>    LISP requires that all the ETRs which are authoritative for the
>    mappings for a particular address block return the same mapping data.
>    In particular, their idea of the 'liveness' of all the ETRs should be
>    identical, and correct.
> 
>    At the moment, this is mostly a manual process, although liveness
>    information can be currently be gathered from some IGPs.
> 
> 11.2.3. EID Reachability
> 
>    At the moment, LISP assumes that if an ETR is reachable from a given
>    ITR, all destination EIDs behind that ETR are reachable from that
>    ETR. There is no way to detect if any are not, nor to switch to an
>    alternate ETR.
> 
>    It is not clear that this is a problem that needs attention. The
>    same has been true for all border routers for many years now, and
>    there does not seem to be any general mechanism to deal with it
>    (Although some BGP implementations may advertize changes in
>    reachability status if what they are seeing from their IGP changes.)
> 
> 11.2.4. Detect and Avoid Broken ETRs
> 
>    {{To be written}}

WHy not discuss as well ITR failures?

In this case this paper might be useful:

http://inl.info.ucl.ac.be/system/files/Networking12-CRV.pdf

[snip]

---

From: Vince Fuller <[email-masked]>
Date: Tue, 30 Oct 2012 12:22:31 -0700

Hi Luigi-

> http://biblio.info.ucl.ac.be/2007/415406.pdf

want to make sure that this is a stable document to reference (i.e. it
will be around on that web site for many years to come)

> http://www.net.t-labs.tu-berlin.de/papers/KIF-ADDITLCAWISKAI-11.pdf

same comment as above.

> http://www.computer.org/csdl/mags/ic/preprint/mic2012990288-abs.html

This is the same reference you offered for "lisp-introduction-01". At a
minimum, that abstract needs to be re-written so that it makes sense.
Right now, it says:

    The Internet has been created for interconnecting few hundreds
    networks, but is now close to one billion hosts, grouped in 40,000
    Autonomous Systems, using more than 400,000 prefixes. Such a situation
    raises scalability issues that have driven both academia and industry
    to review the current Internet Architecture in the light of the
    Locator/Identifier Split paradigm. In particular, the Internet
    Engineering Task Force (IETF) has adopted and is actively designing
    and developing the Locator/ID Separation Protocol (LISP). However,
    changing the routing and addressing architecture of the Internet in an
    incrementally deployable manner Several constraints impact such a
    design. We use LISP as reference to describe the different design
    choices necessary to achieve deployability, which is the ultimate goal
    of any new Future Internet architecture. Furthermore, we showcase
    several alternate usages of LISP, which go beyond improving the
    Internet scalability.

I realize that you are not a native English speaker but this text,
especially the sentence fragment that begins "However, changing the
routing...", is so badly written as to be almost unreadable.

I also reiterate my concern that a citation that points to this web page
1) may not be stable and 2) is to an abstract for a document that one needs
to pay to download.

> http://www.net.t-labs.tu-berlin.de/papers/KIF-ADDITLCAWISKAI-11.pdf

same question/comment as my first regarding stability.

> http://inl.info.ucl.ac.be/system/files/Networking12-CRV.pdf

same question/comment as my first regarding stability.

I don't doubt that the materials you have reference is valuable; I just want
to make sure that they are likely to be accessible to potential readers when
and long after the LISP intro and architecture documents are published.

	--Vince

---

From: Damien Saucez <[email-masked]>
Date: Tue, 30 Oct 2012 20:46:06 +0100

> will be around on that web site for many years to come)

Bruno Quoitin, Luigi Iannone, Cédric de Launois, and Olivier Bonaventure. 2007. Evaluating the benefits of the locator/identifier separation. In Proceedings of 2nd ACM/IEEE international workshop on Mobility in the evolving internet architecture (MobiArch '07). ACM, New York, NY, USA, , Article 5 , 6 pages. DOI=10.1145/1366919.1366926 http://doi.acm.org/10.1145/1366919.1366926

>> http://www.net.t-labs.tu-berlin.de/papers/IB-CCLIM-07.pdf

Luigi Iannone and Olivier Bonaventure. 2007. On the cost of caching locator/ID mappings. InProceedings of the 2007 ACM CoNEXT conference (CoNEXT '07). ACM, New York, NY, USA, , Article 7 , 12 pages. DOI=10.1145/1364654.1364663 http://doi.acm.org/10.1145/1364654.1364663

>> http://www.net.t-labs.tu-berlin.de/papers/KIF-ADDITLCAWISKAI-11.pdf

Juhoon Kim, Luigi Iannone, and Anja Feldmann. 2011. A deep dive into the LISP cache and what ISPs should know about it. In Proceedings of the 10th international IFIP TC 6 conference on Networking - Volume Part I (NETWORKING'11), Jordi Domingo-Pascual, Pietro Manzoni, Ana Pont, Sergio Palazzo, and Caterina Scoglio (Eds.), Vol. Part I. Springer-Verlag, Berlin, Heidelberg, 367-378.

> routing...", is so badly written as to be almost unreadable.

As you can see, IEEE website completely screwed up (also the strange
characters in the title), the real abstract is

The Internet has been created for interconnecting few hundreds
networks, but is now close to one billion hosts, grouped in 40,000
Autonomous Systems, using more than 400,000 prefixes. Such situation
raises scalability issues that have driven both academia and industry
to review the current Internet architecture in the light of the
Locator/Identifier Split paradigm. In particular, the Internet
Engineering Task Force (IETF) has adopted and is actively designing
and developing the Locator/ID Separation Protocol (LISP). However,
changing the routing and addressing architecture of the Internet in an
incrementally deployable manner imposes several constraints in the
new design. For the sake of illustration, we use LISP as reference to
describe the different design choices necessary to achieve
deployability, which is the ultimate goal of any new Future Internet
architecture. Furthermore, we showcase several alternate usages of
LISP, which go beyond improving the Internet scalability.

is that more readable?

As I said in the previous mail, the reference is for a pre-print so
we still have to wait to have the final reference.

>> http://www.net.t-labs.tu-berlin.de/papers/IB-CCLIM-07.pdf

Luigi Iannone and Olivier Bonaventure. 2007. On the cost of caching locator/ID mappings. InProceedings of the 2007 ACM CoNEXT conference (CoNEXT '07). ACM, New York, NY, USA, , Article 7 , 12 pages. DOI=10.1145/1364654.1364663 http://doi.acm.org/10.1145/1364654.1364663

>> http://www.net.t-labs.tu-berlin.de/papers/KIF-ADDITLCAWISKAI-11.pdf

Juhoon Kim, Luigi Iannone, and Anja Feldmann. 2011. A deep dive into the LISP cache and what ISPs should know about it. In Proceedings of the 10th international IFIP TC 6 conference on Networking - Volume Part I (NETWORKING'11), Jordi Domingo-Pascual, Pietro Manzoni, Ana Pont, Sergio Palazzo, and Caterina Scoglio (Eds.), Vol. Part I. Springer-Verlag, Berlin, Heidelberg, 367-378.

>> http://inl.info.ucl.ac.be/system/files/Networking12-CRV.pdf
Damien Saucez, Juhoon Kim, Luigi Iannone, Olivier Bonaventure, and Clarence Filsfils. 2012. A local approach to fast failure recovery of LISP ingress tunnel routers. In Proceedings of the 11th international IFIP TC 6 conference on Networking - Volume Part I (IFIP'12), Robert Bestak, Lukas Kencl, Li Erran Li, Joerg Widmer, and Hao Yin (Eds.), Vol. Part I. Springer-Verlag, Berlin, Heidelberg, 397-408. DOI=10.1007/978-3-642-30045-5_30 http://dx.doi.org/10.1007/978-3-642-30045-5_30

> and long after the LISP intro and architecture documents are published.

If you reference the ACM way, you are sure that it will last (assuming ACM will
of course).

Damien Saucez

> 
> 	--Vince
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp