[Ila] Potential issues, questions, and contentious items concerning ILA

Tom Herbert <tom@quantonium.net> Thu, 08 February 2018 00:37 UTC

Return-Path: <tom@quantonium.net>
X-Original-To: ila@ietfa.amsl.com
Delivered-To: ila@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38F21124207 for <ila@ietfa.amsl.com>; Wed, 7 Feb 2018 16:37:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=quantonium-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eADH6Um005J6 for <ila@ietfa.amsl.com>; Wed, 7 Feb 2018 16:37:19 -0800 (PST)
Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B23D5120721 for <ila@ietf.org>; Wed, 7 Feb 2018 16:37:18 -0800 (PST)
Received: by mail-wm0-x22c.google.com with SMTP id j21-v6so24957806wmh.1 for <ila@ietf.org>; Wed, 07 Feb 2018 16:37:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quantonium-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=IJF5vhyn5yzQfSI7vyxexOjrdmY+LfN4e3zytQ7kiT4=; b=D8S985b+qjjuuviFZRxz9d4xp2f5Q+zo4BEBxHWmfMl8u1oUD3rmmZrDWqMZKBL502 hSBCGDS4UgteVPBrjux++8ChRkE7NhnyMpIsgewy/e9TLb480v02RR8DRhEeRT2G79x/ /hgp5NtL7xTtXB8NjWsyXy0gU2Mgak/4uETvVhxy8elpkCpJP1xTdOsWn9KeRY8QVw4M BroVXXkkZ4LaM8qye5l1qeSVJxEd1xtnRuhbCnDbPq/iL37B6AYW8mZtTOEtkQro9OLG ladnytA39nkbTkB3mxxE5OUOy0P5f5IVxjdoiEVE37X7P60aFGkc/cUmGc8DiRNdg63b mD9Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=IJF5vhyn5yzQfSI7vyxexOjrdmY+LfN4e3zytQ7kiT4=; b=T+0PqfS5yviWVLCfGa8CPZTL4paaZfgHYiPdjFALBx3ExiOcbB+3MekLXyhkIXXS0O cGJZnR1G6v9cpXvGUWWQZYuxZyRJRx0xtdHvkYuNOOsj/7burSQK9Pg8WVGAz6McC2b7 iz5P3K/GeuxOON9yHeSO9HhHUuZBBOv97eJoZeytO7PJ6f2QMIzTJRpX01YtNSUJFo/n 9rsOBokDCHRlSgzj7PZ5FygRHtBP2STWSbPH8P7bwNhoYPBOQUhHbu5aUTWuuyiUIeUr tYCeGq2P+U1ldg8Bj7D8pwtQH3ZhpJtbSTIF2ccYEEZuf0VCHjBS8wvxfjGO6uujoomf 0ODQ==
X-Gm-Message-State: APf1xPDmaJc+v8IHkFf9PyEmzbZ4chuuzcHBJq9sVWoMhPHPXRtnzoRv lAueQ8GRB0fpADuR/r5kQp74Bmfxu2FKGX8lU3gcO7/0
X-Google-Smtp-Source: AH8x225TSMxVfvWA2h7J5grO1istSUNHQ4KkjtLUT8EkFJJ3wkYVrpPUuw9iyv50P515mSDreHqMcz2RSuLNcCMFYYo=
X-Received: by 10.28.156.81 with SMTP id f78mr6374943wme.131.1518050236310; Wed, 07 Feb 2018 16:37:16 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.173.66 with HTTP; Wed, 7 Feb 2018 16:37:15 -0800 (PST)
From: Tom Herbert <tom@quantonium.net>
Date: Wed, 07 Feb 2018 16:37:15 -0800
Message-ID: <CAPDqMerrbx1urHRRW1JAnwM7nki7=jLk5jemFJYq0VYpz5KPTQ@mail.gmail.com>
To: ila@ietf.org
Content-Type: multipart/alternative; boundary="001a114b2dc21640690564a89d2c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ila/u5i4sE2J6fUOTDs3tsNgSynCKHQ>
Subject: [Ila] Potential issues, questions, and contentious items concerning ILA
X-BeenThere: ila@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Identifier Locator Addressing <ila.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ila>, <mailto:ila-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ila/>
List-Post: <mailto:ila@ietf.org>
List-Help: <mailto:ila-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ila>, <mailto:ila-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Feb 2018 00:37:21 -0000

Hello,

In preparation for the BOF, I have compiled an initial list of problems
that might be raised, areas that need clartification, or questions that
could be asked for ILA. Special emphasis is given on security, privacy, and
scalability-- items related to these are marked as such. Also, many of
these items are not specific to ILA and are more related to a general
identifier/locator problem. The distinction is that an item is considered
general if it would still be applicable if the ILA dataplane (address
transformations) were swapped out with a functionally equivalent
encapsulation. Items that don't fall in the general identifier/locator
class are mark "DP-only".

Items that might be raised as major issues or could be contentious are
marked by *** with a note follows.

The goal of this thead is to identify as many potential issues and
questions surrounding ILA as possible. This is not the thread to solve the
issues or answer the questions!

Please review and suggest any additional items that should be in the list.

Thanks,
Tom

----------------------

- Value proposition of ILA (i.e. cost-benefit) *** There are many ways to
implement network overlays. What is the need for yet another method?
   - Value of zero overhead solution (DP-only)
   - Disassociation of identity from location
   - Fine grained object addressing
   - Need for seamless and transparent network layer mobility

- Limitations of ILA
   - Limited amount of information can be fit into 128 bits (DP-only) ***
ILA is not extensible protocol. What use cases would extensibility be
required and ILA not usable?
   - Multicast support not fully scoped out

- Comparison with alternative/similar solutions
  - NAT (DP-only) *** How is ILA different from NAT and why doesn't it have
the same problems of NAT?
  - ILNP, 8+8 *** Similar identifier/locator split protocols have been
proposed. How is ILA different and better then these?
  - Encapsulation protocols and segment routing

- Compatibility and conformance
  - Standards conformance
  - Proper ICMP handling (possible security issues)
  - Interoperability with existing hardware, software, protocol
optimizations (DP-only)
  - Interaction with firewalls (security) (DP-only for applying rules to
ILA addresses)
  - Interaction with diffserv, ECN, other fields in IP header, NFV
  - Transport layer pseudo checksum/checksum neutral mapping (DP-only)

- Identifier/locator mapping system
  - Overall architecture
  - Number of mappings in system (scalability) *** Mappings are
non-aggregable and effectively become host routes. How does this scale?
  - Number of ILA routers needed (scalability) *** What infrastructure
investment needed in large deployments to scale?
  - Thoughput, CPU on routers (scalability)
  - Control plane (scalability, security)
  - Use of databases as the routing protocol (scalability, security)
  - Use of TCP for control protocols (possible scalability)

- Mapping caches
  - Cache maintainence, sizing (scalability)
  - Denial of Service threat (security) *** Untrusted entities may try to
DOS a cache by exhausting its memory or causing flood of control messages.
What are mitigations for DOS attack?
  - Pull vs. push vs. redirect model (scalability)
  - Security of mapping protocol (security)
  - Load from control messages to manage cache (scalability)

- Implementation
  - Open source availability
  - Multiple implemenations
  - Hardware considerations
  - Effects on logging, network tools, diagnostics

- Inter domain support
  - How does ILA work across domains?
  - How is roaming achieved?
  - What if ILA is being done in one direction, or both for a flow?

- Domain isolation
   - Preventing untrusted nodes from spoofing ILA addressed packets
(security)
   - Prevent exposing locators to third parties (security, privacy)

- Datacenter use case
  - Number of addressed objects starting with address per container
(scalability)

- Alternative address encodings (DP-only)
  - Virtualization, multicast, IPv4 address encoding (DP-only)
  - Mechanism of network prefix assignment encoding (DP-only) *** Proposed
solution involves encoding identifier into upper 64 bit of a SIR address
and a layer of indirection in ILA to SIR address transformation. Is this
solution feasible?
  - Non-local address identifiers (DP-only)

- Network virtualization
  - Number of VMs and tenants supported? (scalability)
  - Number of addresses (or address prefix) assign per VM (scalability)
  - Encoding tenant preifx (VNID) assignment in ILA
  - Isolation between tenants (security)
  - Access to common network services

- Mobile use case
  - End user privacy (prevent inferences of PII by third parties)
  - Intregation into technology specific architecure (ILA 3GPP 5G for
instance)
  - Address assignment privacy (single addresses vs. prefix, DHCPv6 vs.
SLAAC) *** Do current practices for network address provide sufficient user
privacy? Can ILA and singleton address assignment address this?
  - UEs may be assigned multiple (may 1000s) singleton addresses *** How
does this scale? Is there possibility to implement hidden aggregation by
something like CGA?
  - Protection of user identity and location in mapping system (privacy)
  - Law enforcement, policy requirements (security, privacy)